• dsimcha <dsimcha yahoo.com> Mar 13 2011
• Bane <branimir.milosavljevic gmail.com> Mar 13 2011
• Jonas Drewsen <jdrewsen nospam.com> Mar 13 2011
• Jonathan M Davis <jmdavisProg gmx.com> Mar 13 2011
• Jonas Drewsen <jdrewsen nospam.com> Mar 14 2011
• dsimcha <dsimcha yahoo.com> Mar 13 2011
• Jonas Drewsen <jdrewsen nospam.com> Mar 14 2011
• Andrej Mitrovic <andrej.mitrovich gmail.com> Mar 13 2011
• Daniel Gibson <metalcaedes gmail.com> Mar 13 2011
• Jesse Phillips <jessekphillips+D gmail.com> Mar 13 2011
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Mar 14 2011
• "nedbrek" <nedbrek yahoo.com> Mar 14 2011
• Jonas Drewsen <jdrewsen nospam.com> Mar 15 2011
• Jacob Carlborg <doob me.com> Mar 15 2011
• Andrej Mitrovic <andrej.mitrovich gmail.com> Mar 13 2011
• Jonathan M Davis <jmdavisProg gmx.com> Mar 14 2011

dsimcha <dsimcha yahoo.com> writes:

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.

Bane <branimir.milosavljevic gmail.com> writes:

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.

Jonas Drewsen <jdrewsen nospam.com> writes:

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

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

Jonas Drewsen <jdrewsen nospam.com> writes:

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

dsimcha <dsimcha yahoo.com> writes:

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.

Jonas Drewsen <jdrewsen nospam.com> writes:

On 14/03/11 04.33, dsimcha wrote:
 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.


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 :)

/Jonas

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

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

Daniel Gibson <metalcaedes gmail.com> writes:

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

Jesse Phillips <jessekphillips+D gmail.com> writes:

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.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

"nedbrek" <nedbrek yahoo.com> writes:

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

Jonas Drewsen <jdrewsen nospam.com> writes:

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...
 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


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.

/Jonas

Jacob Carlborg <doob me.com> writes:

On 2011-03-15 10:30, Jonas Drewsen wrote:
 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...
 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


 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.

 /Jonas


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 Carlborg

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

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

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Monday 14 March 2011 02:24:45 Jonas Drewsen wrote:
 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?


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 Davis