digitalmars.D - SQLite Bindings
- dsimcha (15/15) Mar 13 2011 One of the features I miss most in Phobos is support for SQLite.
- Bane (2/2) Mar 13 2011 That is great idea. I already hove something similar i n library I use f...
- Jonas Drewsen (7/22) Mar 13 2011 It's a great idea. But I think there need to be some kind of janitor for...
- Jonathan M Davis (3/29) Mar 13 2011 http://d.puremagic.com/test-results/
- Jonas Drewsen (3/32) Mar 14 2011 Very nice. Is this you own build setup or an official one?
- Jonathan M Davis (5/40) Mar 14 2011 No. That's the official autotester. Brad Roberts manages it. It's expand...
- dsimcha (20/23) Mar 13 2011 I don't see why this is a concern. This is what I have in mind:
- Andrej Mitrovic (10/10) Mar 13 2011 Wrapping is also bug-prone. htod could fail to translate a header file
- Jonas Drewsen (8/31) Mar 14 2011 Maybe I'm too concerned yes. Would just hate to have new users using bit...
- Daniel Gibson (12/27) Mar 13 2011 I think it's a good idea.
- Jesse Phillips (3/3) Mar 13 2011 libcurl, SQLite, libpng, libbzip2, and the WindowsAPI stuff all sound li...
- Andrej Mitrovic (2/3) Mar 13 2011 I see you are very committed to the cause. :p
- Andrei Alexandrescu (3/6) Mar 14 2011 I'm not seeing the pull requests yet. :o)
- nedbrek (8/16) Mar 14 2011 Hello all,
- Jonas Drewsen (9/27) Mar 15 2011 Regarding the licensing issues... maybe an officially "blessed" library
- Jacob Carlborg (5/39) Mar 15 2011 You can always just include bindings to the library. Then the user needs...
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.
Mar 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.
Mar 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
Mar 13 2011
On Sunday 13 March 2011 14:56:34 Jonas Drewsen wrote:On 13/03/11 18.29, dsimcha wrote:http://d.puremagic.com/test-results/ - Jonathan M DavisOne 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?
Mar 13 2011
On 14/03/11 00.07, Jonathan M Davis wrote:On Sunday 13 March 2011 14:56:34 Jonas Drewsen wrote:Very nice. Is this you own build setup or an official one? /JonasOn 13/03/11 18.29, dsimcha wrote:http://d.puremagic.com/test-results/ - Jonathan M DavisOne 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?
Mar 14 2011
On Monday 14 March 2011 02:24:45 Jonas Drewsen wrote:On 14/03/11 00.07, Jonathan M Davis wrote:No. That's the official autotester. Brad Roberts manages it. It's expanded quite a bit recently. FreeBSD and OSX are _very_ recent, and 64-bit Linux is fairly recent. - Jonathan M DavisOn Sunday 13 March 2011 14:56:34 Jonas Drewsen wrote:Very nice. Is this you own build setup or an official one?On 13/03/11 18.29, dsimcha wrote:http://d.puremagic.com/test-results/ - Jonathan M DavisOne 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?
Mar 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.
Mar 13 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
Mar 13 2011
On 14/03/11 04.33, dsimcha wrote:On 3/13/2011 5:56 PM, Jonas Drewsen wrote:Maybe I'm too concerned yes. Would just hate to have new users using bit rotten code because no one suddently cared about a specific module for a while. But maybe curl,png,sqlite etc. libraries are used enough so that someone always cares keeping it up-to-dat and this does not become a problem. Lets see :) /JonasIt'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.
Mar 14 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
Mar 13 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.
Mar 13 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
Mar 13 2011
On 3/13/11 11:54 PM, Jesse Phillips wrote: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.I'm not seeing the pull requests yet. :o) Andrei
Mar 14 2011
Hello all, "Jesse Phillips" <jessekphillips+D gmail.com> wrote in message news:ilk728$gk0$1 digitalmars.com...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.I have started D bindings for Tcl, I volunteer to support them. https://github.com/nedbrek/tcld Tcl uses a BSD-like license (which might keep it out the standard D library...) Ned
Mar 14 2011
On 15/03/11 01.33, nedbrek wrote:Hello all, "Jesse Phillips"<jessekphillips+D gmail.com> wrote in message news:ilk728$gk0$1 digitalmars.com...Regarding the licensing issues... maybe an officially "blessed" library (libphobos-ext) could be made for all the things that does not go well with the boost license then? A bit messy but it would open up access to a great number of libs with a default dmd + phobos + phobos-ext installation. I guess BSD/MIT/lgpl etc. licenses are permissive enough for almost every case anyway. /Jonaslibcurl, 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.I have started D bindings for Tcl, I volunteer to support them. https://github.com/nedbrek/tcld Tcl uses a BSD-like license (which might keep it out the standard D library...) Ned
Mar 15 2011
On 2011-03-15 10:30, Jonas Drewsen wrote:On 15/03/11 01.33, nedbrek wrote:You can always just include bindings to the library. Then the user needs to have the library on the system if the users decides to use the bindings. -- /Jacob CarlborgHello all, "Jesse Phillips"<jessekphillips+D gmail.com> wrote in message news:ilk728$gk0$1 digitalmars.com...Regarding the licensing issues... maybe an officially "blessed" library (libphobos-ext) could be made for all the things that does not go well with the boost license then? A bit messy but it would open up access to a great number of libs with a default dmd + phobos + phobos-ext installation. I guess BSD/MIT/lgpl etc. licenses are permissive enough for almost every case anyway. /Jonaslibcurl, 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.I have started D bindings for Tcl, I volunteer to support them. https://github.com/nedbrek/tcld Tcl uses a BSD-like license (which might keep it out the standard D library...) Ned
Mar 15 2011