arrays
conveniently.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi
On 2005-dec-12, at 13:06, Леонид Новиков wrote:
I expected that uffi and cffi-uffi-comapt under alike parameter
must return alike results :)
Well, you are absolutely right. :-) I think this is fixed now.
Thanks for your bug report.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa
Joerg!) :-) And it seems Lispworks does too.
The lack of uniformity is very unfortunate here. This needs to be
fixed. We should either a) translate nil-null everywhere, b) don't
translate nil-null anywhere or c) offer the two alternatives through
two different types.
--
Luís Oliveira
http
(and uffi-compat,
with whatever lisp).
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common
with malloc (and deallocated with free) or not.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http
have been more
precise, and name the patch.
Never had any conflicts with darcs yet. :-) Good luck with that!
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
WET 2005 Luis Oliveira [EMAIL PROTECTED]
* Update manual: CMUCL passes all tests.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
___
cffi-devel
something like this or if we could have some clues on how to use
unexported functionality to implement cffi-sys:%foreign-funcall (and
eventually cffi-sys:%foreign-funcall-pointer).
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http
(the whole CFFI?) would have to
be licensed under the GPL? If so, could these symbols CFFI uses be
exported? I'm certain relicensing CFFI under GPL would not be an option.
Anyway, thanks for your patch and merry christmas!
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do
occur to me
before... doh.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common
it. programs that dont
want to use the feature dont have to use it.
The consing! One extra cons cell! :-) Or, alternatively, we were
waiting until christmas to offer you this feature.
Anyway, :cffi is now pushed onto *features*. :-)
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa
James Bielman [EMAIL PROTECTED] writes:
Here's a patch that does this---I've tested it on SBCL and CMUCL, would
anyone else like to give it a spin before merging?
I've tested it in all lisps but Corman and ECL, no new failures. It's
less code and less sources of possible bugs.
--
Luís
.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
, it passes on Linux and OSX but
fails on Win32. Probably a CLISP bug, Joerg? :-)
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
___
cffi-devel mailing list
cffi
Yaroslav Kavenchuk [EMAIL PROTECTED] writes:
CFFI[11] (foreign-alloc 32)
Fixed the example, thanks.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
. We do need to investigate details like
this and point them out in the documentation.
Happy new year,
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
cffi-features:{windows,unix,darwin,ppc32,x86}
so that users can rely on these across different lisps.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
-foreign-library should handle its argument exactly the same
way an element in define-foreign-library is handled. Sounds intuitive.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
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
http
-time.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman
, define-foreign-library should probably be extended to take a
calling convention argument though ideally, IMHO, every Lisp would be
like Allegro in this regard and we wouldn't have to pick between
cdecl and stdcall and it would work with either calling convention.
--
Luís Oliveira
http
as it could be.
That's lost now.
That was indeed my initial idea. James, what do you think?
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
))
(defun xml-parser-error (control-string rest args)
(xmlParserError whatever-a-ctx-is
(format nil ~? control-string args)))
(xml-parser-error error number: ~A 42)
Does anyone have an example where some sort of defcfun-varargs could
actually be useful?
--
Luís
when given strings containing
% characters.
Oops. Um, I would have never made that mistake when my primary
programming language was C! :-)
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
. :-)
An alternative implementation strategy for cffi might be to build up a
va_list structure and call the *V() functions (e.g. TIFFVGetField)??
Uhoh...
That'd be nice too. If only the varargs stuff wasn't all macros...
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation
James Bielman [EMAIL PROTECTED] writes:
The fact that CFFI even accepts :VOID here is a bug
Should be fixed now, added an assertion to defcstruct and defcunion.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation
Hoehle, Joerg-Cyril [EMAIL PROTECTED] writes:
The attached patch includes an answer involving only exported forms.
I've pushed your patch, thanks.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
127
(defconstant +max-count+ 127)
vs.
enum {
RED,
BLUE
};
:red, :blue (or 'red, 'blue)
I suppose defcenum shouldn't force the user to use keywords though?
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca
is needed is
a mapping from name to values (and vice-versa, the CLISP FFI has it),
Right, that's what CFFI has, see
http://common-lisp.net/project/cffi/manual/html_node/defcenum.html
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca
refsection{foo}
that'd expand into:
@node foo
@unnumberedsec @code{foo}
?
Anyway, nice job!
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
___
cffi-devel
is there already. We just need to keep track
of what's loaded. And implement a higher-level abstraction on top of
%unload-foreign-library. (eg: we'll probably want to unload whole
libraries that were defined with DEFINE-FOREIGN-LIBRARY, frameworks,
etc...).
--
Luís Oliveira
luismbo (@) gmail (.) com
suggestions before I push a patch with something like this?
BTW, I silently pushed a patch that adds a new option to defcenum by
allowing a base-type (when the default, :int, is not appropriate).
[1] http://article.gmane.org/gmane.lisp.cffi.devel/26
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman
double, so adding the respective feature to cffi-features
doesn't seem worth the trouble. AFAICT, Lispworks is the only one that
mentions long double in the documentation but it doesn't seem to be
implemented in win32, linux or darwin...
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa
On 2006-feb-23, at 07:52, Yaroslav Kavenchuk wrote:
debugger invoked on a SB-ALIEN:UNDEFINED-ALIEN-ERROR: Undefined
alien: llabs
Should be fixed now. Thanks.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation
On 2006-feb-24, at 00:36, Greg Pfeil wrote:
So, using 'string-list seems to try to double-convert (which I
don't expect),
Thanks for the bug report. Should be fixed now. Added a :NULL-
TERMINATED-P option too like we discussed on IRC.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv
Stephen Compall [EMAIL PROTECTED] writes:
Tue Feb 28 10:26:38 CST 2006 Stephen Compall [EMAIL PROTECTED]
* manual: strings, foreign allocation, add `Wrapper generators'
Looks great. Thanks.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http
Hoehle, Joerg-Cyril [EMAIL PROTECTED] writes:
o provide and export a type declaration name for people who wish to
add :type information to structs, slots or bindings.
I've added this item to the TODO file. Thanks for the suggestion.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa
On 2006-mar-15, at 18:28, Goenninger, Frank wrote:
I am currently trying to get GLUT to work via CFFI.
We have complete bindings to GLUT including a CLOS interface here:
http://common-lisp.net/project/cl-opengl/darcs/
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do
not a good idea, but it might
work for your specific function. See this Linux Journal article:
Modifying a Dynamic Library Without Changing the Source Code
http://www.linuxjournal.com/node/7795/print
HTH
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation
expand-type-to-foreign-dyn.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin
I wrote:
LiamH I do have a rather elderly version of SBCL
LiamH 0.9.7.25
I suggest trying a more recent version of SBCL.
For the record, Liam reports that a more recent version SBCL does not
show this problem.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation
library)))
(defmacro use-foreign-library (name)
- `(eval-when (:load-toplevel :execute #+(or cmu scl) :compile-toplevel)
- (load-foreign-library ',name)))
+ `(load-foreign-library ',name))
;;;# Closing Foreign Libraries
;;;
Thanks.
--
Luís Oliveira
luismbo (@) gmail (.) com
a wrapper function
indeed. I suppose that when someone adds :out types we might come up
with a generalized interface to omit arguments, maybe.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
as isomorphic, as simply to recognize the relationship, and relative
precision, among each respective category.
Does this look better?
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
Yaroslav Kavenchuk [EMAIL PROTECTED] writes:
Hmm, now (SBCL 0.9.11.3) linkage table is present:
[...]
but:
Test CFFI-TESTS::DEFCFUN.UNDEFINED failed
[...]
Why?
I have no idea. I'll mark the failure as expected.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation
things for
you.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman
Yaroslav Kavenchuk [EMAIL PROTECTED] writes:
libtest.c(774) : error C2059: syntax error : '}'
Hmm, do you have any suggestion for fixing this?
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
with this kind of stuff.
For SBCL, does CFFI use sb-alien:load-shared-object to load the library?
Yes.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
___
cffi
the example cl-
opengl as done by - Luis, I think... ;-)
Oh, hmm. Really? Where?
pomajxego:~/src/cl-opengl luis$ find . | xargs grep lisp-string-to-foreign
nothing
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation
Stephen Compall [EMAIL PROTECTED] writes:
http://scompall.nocandysw.com/cffi/implicit-defbitfield-values.darcs.patch
Pushed. Thanks.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
the defbitfield doc in the manual seemed to imply.
Hmm. Now that you mention it, 1 probably makes more sense.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
will warn here because this new B is unused.
;;
;; Perhaps the declarations should go here?
;; (except for IGNORE declarations and maybe others?)
(BLOCK FOO A
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel
On 2006-maj-14, at 03:45, Luís Oliveira wrote:
Hmm, we're putting the declarations in the wrong place.
Ok, assuming that placing the declarations /after/ the translations
take place is the right thing to do, I have a fix for this.
All that poking at the declarations to figure out ignored
) if this didn't work.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
On 2006-maj-20, at 20:26, Lou Vanek wrote:
Actually, by throwing in that format (which returns nil) you
short-circuit the canonicalize recursive call and you no longer
get the error because you are no longer calling canonicalize
with nil.
Oh, right. Even worse then.
--
Luís Oliveira
http
pushed a fix to the darcs repository. Thank you for the report
and test case. And thank you and Luke for tracking the down the
changes that introduced this bug. :-)
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi
this? A
'wrapper' function in a helper DLL that will take the SDL_Color struct
pointer from CFFI and call the SDL_ttf function passing the struct as
a value?
Either that or a C function which accepts an argument for each of
SDL_Color's struct members.
--
Luís Oliveira
luismbo (@) gmail (.) com
this is but it the
cffi-lispworks bug discussed in the thread (through many of the structs
tests) so it'll hopefully be helpful in finding future bugs in the
various compiler macros present in CFFI.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing
.
But I need portability: ACL, Lispworks, mebbe OpenMCL. Where would
it run?
From the top of my head: only SBCL, OpenMCL and CLISP.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common
*) :pointer)
HTH
--
Luís Oliveira
luismbo (@) gmail (.) com
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
Stephen Compall [EMAIL PROTECTED] writes:
On Fri, 2006-07-14 at 13:30 +0100, Luís Oliveira wrote:
(defmacro incf-pointer (place optional (offset 1))
`(setf ,place (inc-pointer ,place ,offset)))
This evaluates the PLACE forms twice.
Doh!
If I follow correctly, this can be more
. :-)
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
/manual/html_node/defcallback.html
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
changes that would break Lispworks and we prefer to use
the asdf-installable RT for all Lisps anyway. (Hmm, I think we even
had a good reason, though I can't quite remember.)
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi
. This could be useful
;;; to call an hypothetical %foreign-funcall-varargs on some hypothetical lisp
;;; on an hypothetical platform that has different calling conventions for
;;; varargs functions. :-)
If ECL can do something special about varargs, we can go ahead and use that!
--
Luís Oliveira
http
? :-)
Anyway, when I find time I will finish the support for statically
compiled callbacks.
Cool, thanks!
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman
nickname it has is RT so we can't use it
conveniently anyway.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
the tests using ECL's RT.
Oh, ok. Why the change from RTEST to RT then? Ah, I see it has
REGRESSION-TEST as a nickname, I'll use that.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common
DEFCSTRUCT.
I don't know anything about how C99 compilers implement the complex
number types, but if passing structs by value is required, you'll need
to add some C glue.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel
for 19c or not though)
Works for me with Snapshot 2006-09 (19C) without pushing
#'system::reinitialize-global-table. I've applied your patch, thanks!
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
On 11/24/06, Juan Jose Garcia-Ripoll [EMAIL PROTECTED] wrote:
Attached to this email there are fixes for CFFI in the form of patch file.
Pushed. Thanks.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common
On 12/6/06, Stelian Ionescu [EMAIL PROTECTED] wrote:
I've attached a fix for WITH-POINTER-TO-VECTOR-DATA on recent SBCLs
Pushed. Thanks.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http
really fails. We should be detecting if the
foreign library is already loaded, and we should probably keep track
of this in the portable side of things. That's needed for
UNLOAD-FOREIGN-LIBRARY too, it's in the TODO list I think.
You're welcome to tackle that TODO item. :-)
--
Luís Oliveira
http
the right thing here.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
should define what behaviour we want and implement it (perhaps in the
portable side of CFFI) uniformly across al Lisps.
Thanks!
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common
such
as stdcall vs. cdecl. That's actually the context in which I had
thought about this.
I'm sure this kind of problem has been dealt with before in other
libraries (IIRC, five-am has an IN-SUITE macro). Any ideas?
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
P.S. -- Sorry Jack
))
(defmethod translate-type-from-foreign (value (type foreign-enum))
- (%foreign-enum-keyword type value))
+ (%foreign-enum-keyword type value :errorp t))
;;;# Foreign Bitfields as Lisp keywords
;;;
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi
On 12/20/06, Stelian Ionescu [EMAIL PROTECTED] wrote:
until a better solution can be found, the attached patch adds a
copy-in/out WITH-POINTER-TO-VECTOR-DATA to the clisp backend
I've applied your patch, thanks.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv
' method and leave clean up for the user.
The latter. It won't call any finalize methods.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
writing trivial-garbage I've found and
reported some GC bugs in CLISP related to finalizers so I'd guess that
you are seeing one of these.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http
too. Once again I'm
thinking we should place the options in the name argument:
(define-foreign-library (name :opt1 ... :opt2 ...) ...).
Comments and suggestions are most welcome.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing
the libraries at startup. Can you try
this with cffi-test or otherwise provide some sort of test case?
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo
/project/fetter/. Rayiner had some ideas on
how to access C++ libraries and there's some code too I believe.
Otherwise, you can handle exceptions and other C++ stuff by writing
some C glue and calling that with CFFI.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv
to load the library before the defcfun. Some lisps
won't mind but others do. They'll all complain by the time the call to
sql-handle is evaluated though.
Why aren't you loading the library? What are you trying to accomplish?
What am I missing?
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv
CFFI and trivial-garbage (what was I thinking?) so I just
wiped out CFFI's finalization code. People can use trivial-garbage if
they're interested in portable finalizers:
http://cliki.net/trivial-garbage
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv
. :-)
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
and managed to get past this particular problem.
Thanks for your report. Those particular lines actually disappeared
somewhere in the latest patches so I guess that problem's solved.
Looks to me like a CLISP bug though.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv
On 14/02/07, Stelian Ionescu [EMAIL PROTECTED] wrote:
It's not possible to pass a string or a pathname to LOAD-FOREIGN-LIBRARY
any more. could you change it back to preserve backwards compatibility ?
Ah, that's certainly a bug. Should be fixed now. Thanks.
--
Luís Oliveira
http
places.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
!
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
backwards incompatible wrt the type system interface
so I'll wait and see if there any objections before I commit it.
Comments and suggestions are welcome, as usual.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common
no problems either.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
[hmm, it seems my previous message didn't go to the list by mistake]
On 22/02/07, Luís Oliveira [EMAIL PROTECTED] wrote:
There's no rush. We should get this right. I put my changes here:
http://common-lisp.net/~loliveira/darcs/cffi-newtypes/. It includes
some updated documentation.
Here
patches, cffi-newtypes includes support for OpenMCL,
Lispworks and Allegro.
The original discussion can be found here:
Subject: a thought on string encodings
http://thread.gmane.org/gmane.lisp.cffi.devel/292
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv
#\l #\l #\o)
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
foreign-aref.diff
Description: Binary data
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
/documentation/8.0/doc/operators/system/memref.htm
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
On 12/04/07, Henry Irvine [EMAIL PROTECTED] wrote:
I added a -m64 flag to the makefile for the test libs,
now they are
I don't have access to darwin/x86-64, so I can't test this. A patch to
the Makefile would be great. :-)
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv
'asdf:load-op :cffi :force t)
2. upgrade CLISP to a more recent version
3. delete that cffi_0.9.2 directory under /var/cache/common-lisp-controller
HTH
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi-devel@common
looked
into that as closely as the current translation interface.
I've added a :class option to defcstruct for similar reasons. We could
add such a thing to defcenum too.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cffi-devel mailing list
cffi
1 - 100 of 444 matches
Mail list logo
