Jump to page: 1 2
Thread overview
SQLite Bindings
Mar 13, 2011
dsimcha
Mar 13, 2011
Bane
Mar 13, 2011
Jonas Drewsen
Mar 13, 2011
Jonathan M Davis
Mar 14, 2011
Jonas Drewsen
Mar 14, 2011
Jonathan M Davis
Mar 14, 2011
dsimcha
Mar 14, 2011
Andrej Mitrovic
Mar 14, 2011
Jonas Drewsen
Mar 13, 2011
Daniel Gibson
Mar 14, 2011
Jesse Phillips
Mar 14, 2011
Andrej Mitrovic
Mar 15, 2011
nedbrek
Mar 15, 2011
Jonas Drewsen
Mar 15, 2011
Jacob Carlborg
March 13, 2011
One of the features I miss most in Phobos is support for SQLite. Several people have written bindings and wrappers and haven't gotten much attention.  (For example:  https://github.com/bayun/SQLite3-D ).

IMHO, we should do the following:

1.  Put SQLite bindings and the C code (which is public domain) in etc.c, just like zlib now.  Put it in the docs, etc. to make sure people know it's there.  This will lower the barrier to entry for people who want to make wrappers.  These can probably be included without any review, since they're a pile of well-tested C code and a fairly mechanical translation of a header file.

2.  Encourage people to make wrappers **after** the C code and bindings are already "just there", ready to be used.  With the barrier to entry lowered, we might actually get someone who's serious enough about it to take it through the whole review process, etc., rather than just dumping a quick n' dirty post to the forum and then forgetting about it.
March 13, 2011
That is great idea. I already hove something similar i n library I use for work, bunch of headers converted for D, from opeanAL to libpq (postgres), sqlite etc.

That can be placed in both D1 and D2 without any problem.
March 13, 2011
On 13/03/11 18.29, dsimcha wrote:
> One of the features I miss most in Phobos is support for SQLite. Several
> people have written bindings and wrappers and haven't gotten much
> attention. (For example: https://github.com/bayun/SQLite3-D ).
>
> IMHO, we should do the following:
>
> 1. Put SQLite bindings and the C code (which is public domain) in etc.c,
> just like zlib now. Put it in the docs, etc. to make sure people know
> it's there. This will lower the barrier to entry for people who want to
> make wrappers. These can probably be included without any review, since
> they're a pile of well-tested C code and a fairly mechanical translation
> of a header file.
>
> 2. Encourage people to make wrappers **after** the C code and bindings
> are already "just there", ready to be used. With the barrier to entry
> lowered, we might actually get someone who's serious enough about it to
> take it through the whole review process, etc., rather than just dumping
> a quick n' dirty post to the forum and then forgetting about it.

It's a great idea. But I think there need to be some kind of janitor for the 'etc' modules so that it does not end up as a new dsource collection of many unmaintained, some dead and a few live projects.

Btw. are there any kind of automated nightly builds of dmd/phobos to handle regressions?

/Jonas
March 13, 2011
Am 13.03.2011 18:29, schrieb dsimcha:
> One of the features I miss most in Phobos is support for SQLite. Several
> people have written bindings and wrappers and haven't gotten much
> attention. (For example: https://github.com/bayun/SQLite3-D ).
>
> IMHO, we should do the following:
>
> 1. Put SQLite bindings and the C code (which is public domain) in etc.c,
> just like zlib now. Put it in the docs, etc. to make sure people know
> it's there. This will lower the barrier to entry for people who want to
> make wrappers. These can probably be included without any review, since
> they're a pile of well-tested C code and a fairly mechanical translation
> of a header file.
>
> 2. Encourage people to make wrappers **after** the C code and bindings
> are already "just there", ready to be used. With the barrier to entry
> lowered, we might actually get someone who's serious enough about it to
> take it through the whole review process, etc., rather than just dumping
> a quick n' dirty post to the forum and then forgetting about it.

I think it's a good idea.

Regarding the wrappers: They should not be SQLite specific but generic enough to work with any relational database. Something like JDBC. This doesn't mean that all databases need to be supported from the beginning, but the interfaces should be generic enough to allow writing drivers for other databases (and probably at least support for MySQL or PostgreSQL in addition to SQLite would be nice).

Anyway: Having bindings to SQLites C interface in etc.c is certainly a good start.

Cheers,
- Daniel
March 13, 2011
On Sunday 13 March 2011 14:56:34 Jonas Drewsen wrote:
> On 13/03/11 18.29, dsimcha wrote:
> > One of the features I miss most in Phobos is support for SQLite. Several people have written bindings and wrappers and haven't gotten much attention. (For example: https://github.com/bayun/SQLite3-D ).
> > 
> > IMHO, we should do the following:
> > 
> > 1. Put SQLite bindings and the C code (which is public domain) in etc.c, just like zlib now. Put it in the docs, etc. to make sure people know it's there. This will lower the barrier to entry for people who want to make wrappers. These can probably be included without any review, since they're a pile of well-tested C code and a fairly mechanical translation of a header file.
> > 
> > 2. Encourage people to make wrappers **after** the C code and bindings are already "just there", ready to be used. With the barrier to entry lowered, we might actually get someone who's serious enough about it to take it through the whole review process, etc., rather than just dumping a quick n' dirty post to the forum and then forgetting about it.
> 
> It's a great idea. But I think there need to be some kind of janitor for the 'etc' modules so that it does not end up as a new dsource collection of many unmaintained, some dead and a few live projects.
> 
> Btw. are there any kind of automated nightly builds of dmd/phobos to handle regressions?

http://d.puremagic.com/test-results/

- Jonathan M Davis
March 14, 2011
On 3/13/2011 5:56 PM, Jonas Drewsen wrote:
> It's a great idea. But I think there need to be some kind of janitor for
> the 'etc' modules so that it does not end up as a new dsource collection
> of many unmaintained, some dead and a few live projects.

I don't see why this is a concern.  This is what I have in mind:

1.  There are a lot of good C libraries out there, some of which are generally useful enough to be in a standard library and are license compatible with Phobos.  My thoughts are that we would only include very stable C libs that are unlikely to require significant maintenance effort.  My personal short list is libcurl (looks like it's already happening), SQLite, libpng, and, if we can get a binary attribution clause waiver, libbzip2.

2.  The hassle of compiling the C code, translating the header, etc. is a significant and annoying transaction cost that probably deters people from writing good D wrappers and leads to lots of duplication of effort among people who are kinda sorta considering writing one.

3.  Even if someone doesn't intend to write a wrapper initially, they may start using the C API directly and eventually end up refactoring out a good wrapper from the project that uses the C API.  This is more likely if the C API is already there, waiting to be used.

4.  Even if a D wrapper is not written for a long time, having the plain C API available for those that want to use it is substantially better than nothing, and the C API will not go away once a D wrapper is written.
March 14, 2011
Wrapping is also bug-prone. htod could fail to translate a header file
perfectly, and it won't work good with macros. E.g.:
http://stackoverflow.com/questions/5204460/problems-converting-a-c-header-to-d
. You could accidentally put the wrong calling convention (or rather,
htod will), and this will give you runtime errors which are hard to
figure out. So having some unittested wrappers in Phobos would be
good.

It would also be a good time to get rid of the win32 wrappers in Phobos and replace them with the more mature WindowsApi: http://www.dsource.org/projects/bindings/wiki/WindowsApi
March 14, 2011
libcurl, SQLite, libpng, libbzip2, and the WindowsAPI stuff all sound like Excellent items to include for standard distribution. It is really nice to just have these items available like zlib and zip.

Personally I think Lua would make a nice standard extension language, but the license is MIT.

So if the Phobos devs are willing, lets git some of these in.
March 14, 2011
On 3/14/11, Jesse Phillips <jessekphillips+D@gmail.com> wrote:
> So if the Phobos devs are willing, lets git some of these in.
>

I see you are very committed to the cause. :p
March 14, 2011
On 14/03/11 00.07, Jonathan M Davis wrote:
> On Sunday 13 March 2011 14:56:34 Jonas Drewsen wrote:
>> On 13/03/11 18.29, dsimcha wrote:
>>> One of the features I miss most in Phobos is support for SQLite. Several
>>> people have written bindings and wrappers and haven't gotten much
>>> attention. (For example: https://github.com/bayun/SQLite3-D ).
>>>
>>> IMHO, we should do the following:
>>>
>>> 1. Put SQLite bindings and the C code (which is public domain) in etc.c,
>>> just like zlib now. Put it in the docs, etc. to make sure people know
>>> it's there. This will lower the barrier to entry for people who want to
>>> make wrappers. These can probably be included without any review, since
>>> they're a pile of well-tested C code and a fairly mechanical translation
>>> of a header file.
>>>
>>> 2. Encourage people to make wrappers **after** the C code and bindings
>>> are already "just there", ready to be used. With the barrier to entry
>>> lowered, we might actually get someone who's serious enough about it to
>>> take it through the whole review process, etc., rather than just dumping
>>> a quick n' dirty post to the forum and then forgetting about it.
>>
>> It's a great idea. But I think there need to be some kind of janitor for
>> the 'etc' modules so that it does not end up as a new dsource collection
>> of many unmaintained, some dead and a few live projects.
>>
>> Btw. are there any kind of automated nightly builds of dmd/phobos to
>> handle regressions?
>
> http://d.puremagic.com/test-results/
>
> - Jonathan M Davis

Very nice. Is this you own build setup or an official one?

/Jonas

« First   ‹ Prev
1 2