new sqlite binding

new sqlite binding

[Andy Wingo]

Hey all,

I just hacked up a new binding to sqlite. It works with sqlite3 and
Guile 1.9/2.0. Check it out at:

  http://gitorious.org/guile-sqlite3

Send me patches,

Andy
-- 
http://wingolog.org/

Re: new sqlite binding

[Linas Vepstas]

Hi,

On 25 November 2010 08:12, Andy Wingo <wingo@pobox.com> wrote:
>
> I just hacked up a new binding to sqlite. It works with sqlite3 and
> Guile 1.9/2.0. Check it out at:
>
>  http://gitorious.org/guile-sqlite3

I'd like to horn in on Andy's glory by advertising guile-dbi

   http://home.gna.org/guile-dbi/

which provides a consistent set of bindings to three different
systems: Postgres, MySQL and SQLite3

Like Andy, I solicit patches/fixes/extensions.

--linas

Re: new sqlite binding

[Neil Jerram]

Linas Vepstas <linasvepstas@gmail.com> writes:

> Hi,
>
> On 25 November 2010 08:12, Andy Wingo <wingo@pobox.com> wrote:
>>
>> I just hacked up a new binding to sqlite. It works with sqlite3 and
>> Guile 1.9/2.0. Check it out at:
>>
>>  http://gitorious.org/guile-sqlite3
>
> I'd like to horn in on Andy's glory by advertising guile-dbi
>
>    http://home.gna.org/guile-dbi/
>
> which provides a consistent set of bindings to three different
> systems: Postgres, MySQL and SQLite3
>
> Like Andy, I solicit patches/fixes/extensions.

At the moment, I assume guile-dbi involves building C glue code?

I like the backend-independence of the DBI interface, and I also like
Scheme code that I can just drop in and use without needing to compile
any C.

So, personally, I'd generally favour merging these two bindings, and
evolving the other DBD implementations to use the new FFI.  Although
probably also keeping the existing glue code implementation, as an
alternative to support older Guiles.

Regards,
        Neil

Re: new sqlite binding

[Linas Vepstas]

On 28 November 2010 05:51, Neil Jerram <neil@ossau.uklinux.net> wrote:
> Linas Vepstas <linasvepstas@gmail.com> writes:
>
>> Hi,
>>
>> On 25 November 2010 08:12, Andy Wingo <wingo@pobox.com> wrote:
>>>
>>> I just hacked up a new binding to sqlite. It works with sqlite3 and
>>> Guile 1.9/2.0. Check it out at:
>>>
>>>  http://gitorious.org/guile-sqlite3
>>
>> I'd like to horn in on Andy's glory by advertising guile-dbi
>>
>>    http://home.gna.org/guile-dbi/
>>
>> which provides a consistent set of bindings to three different
>> systems: Postgres, MySQL and SQLite3
>>
>> Like Andy, I solicit patches/fixes/extensions.
>
> At the moment, I assume guile-dbi involves building C glue code?

Yes :-(

> I like the backend-independence of the DBI interface, and I also like
> Scheme code that I can just drop in and use without needing to compile
> any C.
>
> So, personally, I'd generally favour merging these two bindings, and
> evolving the other DBD implementations to use the new FFI.  Although
> probably also keeping the existing glue code implementation, as an
> alternative to support older Guiles.

Ah, yes, of course! I'm very unlikely to get around to this any time soon,
but, for the record, is there an obvious URL documenting the new
FFI technology?

--linas

Re: new sqlite binding

[Andy Wingo]

On Sat 27 Nov 2010 07:20, Linas Vepstas <linasvepstas@gmail.com> writes:

> I'd like to horn in on Andy's glory by advertising guile-dbi
>
>    http://home.gna.org/guile-dbi/

Hey cool! Didn't know about that one. Well, I had heard, but I forgot.

Cheers,

Andy
-- 
http://wingolog.org/

Re: new sqlite binding

[Andy Wingo]

Hi,

On Sun 28 Nov 2010 12:51, Neil Jerram <neil@ossau.uklinux.net> writes:

> I like the backend-independence of the DBI interface, and I also like
> Scheme code that I can just drop in and use without needing to compile
> any C.

Yes to both! And a good suggestion you had later.

But I would like to mention the downside of the dynamic FFI
approach: with the static FFI you get typechecking by the C
compiler, but with the dynamic FFI you're on your own.

So as you see in these bindings, I declare the types of the C functions
I wrap in the Scheme source code, rather than getting that info from the
C headers. Ludovic has some code to (ab)use the C compiler to at least
get info about struct layout.

I suppose you could also use the C compiler to at least check that the
function type you declared is correct; if you want to do, at runtime,

   (pointer->procedure int (dynamic-func "foo" (dynamic-link)) (list int32))

you could at least make a compile-time check that

    typedef int (*foo_type) (int32 bar);
    int main (...)
    { foo_type bar = foo; return 0; }
    
doesn't produce any warnings with -Wall, or something.

And of course to do those compile-time checks there should be a module
to abstract the various compilers, etc; Ludovic has also said that he's
interested in poking this.

Anyway, just wanted to say that while the dynamic FFI is fun, it's a bit
more amateur than the static FFI.

Happy hacking,

Andy
-- 
http://wingolog.org/

Re: new sqlite binding

[Andy Wingo]

On Sun 28 Nov 2010 17:08, Linas Vepstas <linasvepstas@gmail.com> writes:

> is there an obvious URL documenting the new FFI technology?

Build the manual from git, and check out the section entitled "Foreign
Function Interface".

Andy
-- 
http://wingolog.org/

Re: new sqlite binding

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> But I would like to mention the downside of the dynamic FFI
> approach: with the static FFI you get typechecking by the C
> compiler, but with the dynamic FFI you're on your own.

Interesting point, thanks.

> I suppose you could also use the C compiler to at least check that the
> function type you declared is correct; if you want to do, at runtime,
>
>    (pointer->procedure int (dynamic-func "foo" (dynamic-link)) (list int32))
>
> you could at least make a compile-time check that
>
>     typedef int (*foo_type) (int32 bar);
>     int main (...)
>     { foo_type bar = foo; return 0; }
>     
> doesn't produce any warnings with -Wall, or something.

Hmm, that's almost as annoying as just writing the C code anyway.

I guess what we want is to validate Scheme FFI code against the relevant
C header file(s).  Hopefully something like SWIG or GCC modularisation
might give us that in the future.

      Neil

Re: new sqlite binding

[Linas Vepstas]

On 3 December 2010 12:35, Neil Jerram <neil@ossau.uklinux.net> wrote:
> Andy Wingo <wingo@pobox.com> writes:
>
>> But I would like to mention the downside of the dynamic FFI
>> approach: with the static FFI you get typechecking by the C
>> compiler, but with the dynamic FFI you're on your own.
>
> Interesting point, thanks.
>
>> I suppose you could also use the C compiler to at least check that the
>> function type you declared is correct; if you want to do, at runtime,
>>
>>    (pointer->procedure int (dynamic-func "foo" (dynamic-link)) (list int32))
>>
>> you could at least make a compile-time check that
>>
>>     typedef int (*foo_type) (int32 bar);
>>     int main (...)
>>     { foo_type bar = foo; return 0; }
>>
>> doesn't produce any warnings with -Wall, or something.
>
> Hmm, that's almost as annoying as just writing the C code anyway.
>
> I guess what we want is to validate Scheme FFI code against the relevant
> C header file(s).  Hopefully something like SWIG or GCC modularisation
> might give us that in the future.

Would g-wrap work?  I remember g-wrap was written about 10 years ago,
back when swig didn't work so well, and certainly didn't work well with
guile.  But I had the impression that g-wrap went defunct. Not sure.

(what do I know? for all I know, maybe g-wrap morphed into ffi).

--linas

Re: new sqlite binding

[Neil Jerram]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

On 7 December 2010 04:46, Linas Vepstas <linasvepstas@gmail.com> wrote:

> Would g-wrap work?  I remember g-wrap was written about 10 years ago,
> back when swig didn't work so well, and certainly didn't work well with
> guile.  But I had the impression that g-wrap went defunct. Not sure.
>
> (what do I know? for all I know, maybe g-wrap morphed into ffi).
>
>
As far as I know, g-wrap is still active, and part of the dev chain for
guile-gnome.

       Neil

[-- Attachment #2: Type: text/html, Size: 829 bytes --]