Seems I'm misunderstanding something about UFFI and c pointers within
lisp.
(uffi:def-type sql-ptr *) ;I see this as a pointer
(uffi:def-function
"sqlite3_open" ((filename :cstring)) :returning :sql-ptr)
error-msg:
unknown alien-type: :sql-ptr
[condition of type simple error]
C-function within foreign library:
int sqlite3_open(
const char *filename, /* Database filename (UTF-8) */
sqlite3 **ppDb /* OUT: SQLite db handle */
);
A sqlite3* handle is returned in *ppDb, even if an error occurs. If
the database is opened (or created) successfully, then SQLITE_OK is
returned. Otherwise an error code is returned.
SQLITE_OK = 0
But redefining UFFI function it like this:
(uffi-def-function
"sqlite3_open" ((filename :cstring)) :returning :int)
=> SQLITE3-OPEN
(sqlite3-open "test.db")
=> 0 ;which is SQLITE_OK
Now the confusion, I think that the code return is a good thing. But
I believe that I'm missing a pointer back to the foreign object I
opened. So, how in uffi am i to define a pointer to a c object?
On 2007-02-06 18:19:59 -0500, "daBittweiler" <············@gmail.com> said:
> Seems I'm misunderstanding something about UFFI and c pointers within
> lisp.
> (uffi:def-type sql-ptr *) ;I see this as a pointer
> (uffi:def-function
> "sqlite3_open" ((filename :cstring)) :returning :sql-ptr)
Why not just use clsql? It has several backends including
sqlite3.
Michael
On Feb 6, 5:44 pm, Michael <········@ectospheno.com> wrote:
> On 2007-02-06 18:19:59 -0500, "daBittweiler" <············@gmail.com> said:
>
> > Seems I'm misunderstanding something about UFFI and c pointers within
> > lisp.
> > (uffi:def-type sql-ptr *) ;I see this as a pointer
> > (uffi:def-function
> > "sqlite3_open" ((filename :cstring)) :returning :sql-ptr)
>
> Why not just use clsql? It has several backends including
> sqlite3.
>
> Michael
I don't know it was a uffi-package thanks.
I'm basically looking for something useful I can implement in UFFI.
for me (personally) or even for other common lisp users to use
(hopefully). Basically, tired of going through example code in lisp
books
but, need to do something that practical & useful.
Now, I must start down the road of a new project. Any ideas?
"daBittweiler" <············@gmail.com> writes:
> On Feb 6, 5:44 pm, Michael <········@ectospheno.com> wrote:
>> On 2007-02-06 18:19:59 -0500, "daBittweiler" <············@gmail.com> said:
>>
>> > Seems I'm misunderstanding something about UFFI and c pointers within
>> > lisp.
>> > (uffi:def-type sql-ptr *) ;I see this as a pointer
>> > (uffi:def-function
>> > "sqlite3_open" ((filename :cstring)) :returning :sql-ptr)
>>
>> Why not just use clsql? It has several backends including
>> sqlite3.
>>
>> Michael
>
> I don't know it was a uffi-package thanks.
> I'm basically looking for something useful I can implement in UFFI.
> for me (personally) or even for other common lisp users to use
> (hopefully). Basically, tired of going through example code in lisp
> books
> but, need to do something that practical & useful.
> Now, I must start down the road of a new project. Any ideas?
UFFI is a de-facto deprecated package! Use CFFI instead!
And mind Verrazano, that will generate the CFFI bindings automatically
from the C headers.
So your job would be reduced to writting lispier layers above the
basic CFFI generated by Verrazano.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On 2007-02-06 19:50:47 -0500, Pascal Bourguignon <···@informatimago.com> said:
> UFFI is a de-facto deprecated package! Use CFFI instead!
>
> And mind Verrazano, that will generate the CFFI bindings automatically
> from the C headers.
>
> So your job would be reduced to writting lispier layers above the
> basic CFFI generated by Verrazano.
Is Verrazano no longer de-facto dead? I seem to recall it
uses gcc-xml which appears to still require a 4 year old gcc
(which makes it _actually_ dead as far as I'm concerned.)
And maybe it's just me, but after reading the docs for cffi
and uffi and actually using both, I still prefer uffi. Maybe
someone more intelligent than I can explain exactly how cffi
is any better.
Michael
Michael <········@ectospheno.com> writes:
> On 2007-02-06 19:50:47 -0500, Pascal Bourguignon <···@informatimago.com> said:
>
>> UFFI is a de-facto deprecated package! Use CFFI instead!
>>
>> And mind Verrazano, that will generate the CFFI bindings automatically
>> from the C headers.
>>
>> So your job would be reduced to writting lispier layers above the
>> basic CFFI generated by Verrazano.
>
> Is Verrazano no longer de-facto dead? I seem to recall it
> uses gcc-xml which appears to still require a 4 year old gcc
> (which makes it _actually_ dead as far as I'm concerned.)
>
> And maybe it's just me, but after reading the docs for cffi
> and uffi and actually using both, I still prefer uffi. Maybe
> someone more intelligent than I can explain exactly how cffi
> is any better.
Well it's better merely in that it works on a wider range of
implementations. At least both clisp and sbcl for what I'm concerned
right now.
--
__Pascal Bourguignon__ http://www.informatimago.com/
On Feb 7, 1:50 am, Pascal Bourguignon <····@informatimago.com> wrote:
>
> UFFI is a de-facto deprecated package!
It is still an integral part of CLSQL (and required by at least
20 other libraries according to the CL Directory) and it has seen
seven new releases in 2006. I wouldn't call that "de-facto
deprecated".
Cheers,
Edi.
On 2007-02-09 04:59:49 -0500, ·······@gmail.com said:
> On Feb 7, 1:50 am, Pascal Bourguignon <····@informatimago.com> wrote:
>>
>> UFFI is a de-facto deprecated package!
>
> It is still an integral part of CLSQL (and required by at least
> 20 other libraries according to the CL Directory) and it has seen
> seven new releases in 2006. I wouldn't call that "de-facto
> deprecated".
All of the people calling it "deprecated" appear to be clisp
users :)
I still prefer uffi. Apart from cffi working on clisp I can't
see how it is any better. Seems worse in several ways as far
as I can see.
Michael