[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with guile-sqlite3
From: |
Andy Wingo |
Subject: |
Re: Problems with guile-sqlite3 |
Date: |
Thu, 31 Mar 2011 12:25:18 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) |
On Thu 31 Mar 2011 00:52, Detlev Zundel <address@hidden> writes:
> | scheme@(guile-user)> (sqlite-open "mydb" SQLITE_OPEN_READONLY)
> | ;;; <stdin>:2:0: warning: possibly unbound variable `SQLITE_OPEN_READONLY'
> | <unnamed port>:1:0: In procedure #<procedure 9335250 at <current input>:2:0
> ()>:
> | <unnamed port>:1:0: In procedure module-lookup: Unbound variable:
> SQLITE_OPEN_READONLY
> `----
>
> Hm ok, so the constants seem not to be exported, right?
Hah, it appears not. Want to fix it? Fork the project on github and
send me a merge request :)
> ,----
> | scheme@(guile-user)> (define db (sqlite-open "mydb" 1))
> | <unnamed port>:0:0: In procedure #<procedure 9bf9690 at <current input>:1:0
> ()>:
> | <unnamed port>:0:0: Throw to key `sqlite-error' with args `(sqlite-open 14
> "Unable to open the database file")'.
> `----
>
> But that is strange, I'm sure I have this file. So lets do an "strace
> -e open guile" and see what guile accesses:
>
> ,----
> | ....
> | open("/usr/local/lib/guile/2.0/ccache/language/bytecode/spec.go", O_RDONLY)
> = 91
> | open("/opt/src/git/guile-sqlite3/tests/mydb\315\201", O_RDONLY|O_LARGEFILE)
> = -1 ENOENT (No such file or directory)
> | <unnamed port>:0:0: In procedure #<procedure 8ce37d0 at <current input>:1:0
> ()>:
> | <unnamed port>:0:0: Throw to key `sqlite-error' with args `(sqlite-open 14
> "Unable to open the database file")'.
> `----
>
> Huh, what are those characters after "mydb"? Funnily enough, if I use
> filenames longer than 4 characters it works. Can someone hit me with a
> clue-stick please?
Interesting. It seems that the string->pointer code is doing the wrong thing:
(define (string->utf8-pointer s)
(bytevector->pointer (string->utf8 s)))
Indeed, there's no null-termination on this string. I guess we need to
copy into a bytevector that is longer and provide a NUL byte. Want to
patch that one too?
Cheers,
Andy
--
http://wingolog.org/