www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The sorry state of the D stack?

reply Thomas Koch <thomas koch.ro> writes:
Hi,

the subject refers to my current state of sadness after trying to dig into D 
programming for a few days. I've been very exited after reading "The D 
programming language", but I've doubts now.

- There's no "standard" library to read a single character from the console. 
Instead people write their own personal helper libraries.

- I looked into GtkD, which refers to the build tool DSSS. However DSSS 
seems to be unmaintained for a couple of years. (Why does every new language 
needs its own build tool?)

- I looked for a PostgreSQL client library. I found small personal hacks and 
dead projects.

- I looked at http://www.dsource.org/forums - most forums are dead.

Is it possible that D is a dead language? For a newbie like me it would be 
very helpful to have a list of good, healthy projects for my first steps in 
D instead of finding cadavers all around. Typesafe, the company behind 
Scala, maintains a "Typesafe Stack" of active, recommendable projects.

Please don't be offended by this message. I just wanted to provide feedback 
and will keep trying to get into D. Thank you very much for this wonderful 
language!

Best regards, Thomas Koch
Oct 06 2012
next sibling parent "nazriel" <spam dzfl.pl> writes:
On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote:
 Hi,

 the subject refers to my current state of sadness after trying 
 to dig into D
 programming for a few days. I've been very exited after reading 
 "The D
 programming language", but I've doubts now.

 - There's no "standard" library to read a single character from 
 the console.
 Instead people write their own personal helper libraries.

There is always possibility to add something more high level to std.stdio if there will be such need.
 - I looked into GtkD, which refers to the build tool DSSS. 
 However DSSS
 seems to be unmaintained for a couple of years. (Why does every 
 new language
 needs its own build tool?)

supports D1). For building on Windows you also got possibility to use bud tool (you don't need to play with Make files)
 - I looked for a PostgreSQL client library. I found small 
 personal hacks and
 dead projects.

There is for example SQLd : https://github.com/robik/SQLd or https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/postgres.d And lots of other projects. To be honest there are TONS of such things on Github.
 - I looked at http://www.dsource.org/forums - most forums are 
 dead.

that DSource is graveyard for old, mostly D1 abandoned projects.
 Is it possible that D is a dead language?

 For a newbie like me it would be
 very helpful to have a list of good, healthy projects for my 
 first steps in
 D instead of finding cadavers all around.

tried D. But IRC channel, #d freenode can help a lot if resolving your thoughts
 Typesafe, the company behind
 Scala, maintains a "Typesafe Stack" of active, recommendable 
 projects.

 Please don't be offended by this message. I just wanted to 
 provide feedback
 and will keep trying to get into D. Thank you very much for 
 this wonderful
 language!

 Best regards, Thomas Koch

Oct 06 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/6/2012 4:54 AM, Thomas Koch wrote:
 - I looked at http://www.dsource.org/forums - most forums are dead.

Most of the D forum action is here.
Oct 06 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
nazriel:

 getch()
 There is always possibility to add something more high level to 
 std.stdio if there will be such need.

I think the need for a Phobos portable way to read a char in is present. Bye, bearophile
Oct 06 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 6 October 2012 at 12:52:36 UTC, bearophile wrote:
 I think the need for a Phobos portable way to read a char in is 
 present.

I just slapped together a very quick Linux struct: ===== version(Posix): import core.sys.posix.termios; import core.sys.posix.unistd; import core.sys.posix.sys.types; import core.sys.posix.sys.time; import core.stdc.stdio; enum ConsoleInputFlags { raw = 0, echo = 1 } struct RealTimeConsoleInput { disable this(); disable this(this); private int fd; private termios old; this(ConsoleInputFlags flags) { this.fd = 0; // stdin tcgetattr(fd, &old); auto n = old; auto f = ICANON; if(!(flags & ConsoleInputFlags.echo)) f |= ECHO; n.c_lflag &= ~f; tcsetattr(fd, TCSANOW, &n); } ~this() { tcsetattr(fd, TCSANOW, &old); } bool kbhit() { timeval tv; tv.tv_sec = 0; tv.tv_usec = 0; fd_set fs; FD_ZERO(&fs); FD_SET(fd, &fs); select(fd + 1, &fs, null, null, &tv); return FD_ISSET(fd, &fs); } char getch() { return cast(char) .fgetc(.stdin); } } === Usage: void main() { auto input = new RealTimeConsoleInput(ConsoleInputFlags.raw); while(true) { if(input.kbhit()) { // is a key available? auto c = input.getch(); // get it if(c == 'q' || c == 'Q') break; printf("%c", c); fflush(stdout); } usleep(10000); } } IIRC it is very easy to do this on Windows as there's no need to change the console mode.
Oct 06 2012
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Saturday, 6 October 2012 at 14:50:08 UTC, Adam D. Ruppe wrote:
 IIRC it is very easy to do this on Windows as there's no need 
 to change the console mode.

Windows already has getch() in one of its system libraries or C runtime, and I'm fairly sure it has kbhit() somewhere too. The easiest thing to do would just be to link with those.
Oct 06 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-06 13:54, Thomas Koch wrote:

 - I looked into GtkD, which refers to the build tool DSSS. However DSSS
 seems to be unmaintained for a couple of years. (Why does every new language
 needs its own build tool?)

I would say because it's possible to tune the tool specially for the language making it easier to use. Most available tools are either not cross-platform or have some kind of dependency that might not be so easy to install on all platforms. -- /Jacob Carlborg
Oct 06 2012
prev sibling next sibling parent Jeremy Sandell <jlsandell gmail.com> writes:
--047d7b33965fad5b5f04cb68cb3b
Content-Type: text/plain; charset=UTF-8

On Sat, Oct 6, 2012 at 7:54 AM, Thomas Koch <thomas koch.ro> wrote:

 (Why does every new language
 needs its own build tool?)

They often don't. I seem to recall http://www.dsource.org/projects/cmaked working just fine for one of my D2 projects. Not having to globally install it was pretty nice, too, and since I needed to build C source along side my D2 source (i.e., bindings) it was a perfect fit. HTH, Jeremy Sandell --047d7b33965fad5b5f04cb68cb3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Oct 6, 2012 at 7:54 AM, Thomas Koch <span dir=3D"ltr">&lt;<a href= =3D"mailto:thomas koch.ro" target=3D"_blank">thomas koch.ro</a>&gt;</span> = wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div id=3D":2ir"> (Why does every new language<br> needs its own build tool?)</div></blockquote></div><br><div><br></div><div>= They often don&#39;t. I seem to recall=C2=A0<a href=3D"http://www.dsource.o= rg/projects/cmaked">http://www.dsource.org/projects/cmaked</a>=C2=A0working= just fine for one of my D2 projects. Not having to globally install it was= pretty nice, too, and since I needed to build C source along side my D2 so= urce (i.e., bindings) it was a perfect fit.</div> <div><br></div><div>HTH,</div><div>Jeremy Sandell</div> --047d7b33965fad5b5f04cb68cb3b--
Oct 06 2012
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 06 Oct 2012 13:54:11 +0200
Thomas Koch <thomas koch.ro> wrote:
 
 - I looked into GtkD, which refers to the build tool DSSS. However
 DSSS seems to be unmaintained for a couple of years. 
 

DSSS has been dead for a long time, I don't know why an active project like GtkD is apparently mentioning it. The proper tool (equivalent to DSSS's "rebuild") is RDMD, which is bundled with DMD.
 (Why does every
 new language needs its own build tool?)

Because there aren't any good ones (IMO). They all seem to fall into one of two categories: - Something that either *is* make, is a variant of make, or uses make. - Introduces a requirement of some *other* language. (I don't want to force people to install or deal with Ruby or Python, and make sure they're on the right version of it, just to compile my D code.)
 - I looked for a PostgreSQL client library. I found small personal
 hacks and dead projects.
 

SQL lib support is unfortunately one of our weak points ATM. I could point you to a decent MySQL lib :/
 - I looked at http://www.dsource.org/forums - most forums are dead.
 

Like Walter said, the main, active, D forums are right here. Also, most D project hosting has moved from DSource to places like BitBucket and GitHub.
 Is it possible that D is a dead language?

Definitely not. *DSource* is dying, unfortunately, which has lead some people to assume the same of the rest of D. But no, D is going very strong, and has only been getting bigger.
 For a newbie like me it
 would be very helpful to have a list of good, healthy projects for my
 first steps in D instead of finding cadavers all around. Typesafe,
 the company behind Scala, maintains a "Typesafe Stack" of active,
 recommendable projects.
 

We have a list on the Wiki: http://www.prowiki.org/wiki4d/wiki.cgi I don't know how well-maintained that list is. If it isn't well-maintained, then it certainly needs to be.
Oct 06 2012
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/06/2012 10:59 PM, Nick Sabalausky wrote:
 Definitely not. *DSource* is dying, unfortunately, which has lead some
 people to assume the same of the rest of D. But no, D is going very
 strong, and has only been getting bigger.

Might be worth placing some prominent message on DSource stating that it's being maintained to document all the D1 work and projects, but that the active work is now over at dlang.org?
Oct 06 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-06 22:59, Nick Sabalausky wrote:

 DSSS has been dead for a long time, I don't know why an active project
 like GtkD is apparently mentioning it.

DSSS is working just fine for D1. GtkD works both with D1 and D2. -- /Jacob Carlborg
Oct 06 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-07 00:14, Nick Sabalausky wrote:

 I don't know about the rest of DSSS as I only ever used the
 'rebuild' component. But as for rebuild, there are problems:

 For one thing, 0.76 is generally considered to work much better than
 0.77 and the final version, 0.78 (I forget the details, but a lot
 of people including me have had problems with 0.78 that never showed up
 with 0.76). But despite that, read-made builds aren't available for
 0.76. As DSSS is dead none of this is likely to get fixed. And
 there's no reason to fix rebuild since RDMD is a superior and non-dead
 alternative to rebuild.

I'm still using 0.75, when I'm using it.
 Also, rebuild is slow, even with "one at a time" disabled. Try
 compiling DVM with the included rebuild-based script and the
 RDMD-based one. It takes a fair amount of time with rebuild
 (even with "one at a time" off), but with RDMD it's almost instant.

I'm well aware that RDMD is a lot faster than Rebuild.
 There's no reason for anyone to use rebuild anymore, and very few
 people do.

Maybe not only Rebuild, but DSSS offers more than RDMD. DSSS supports building libraries, build files, generating documentation and other features. With RDMD you must likely need a shell script for the build flags. Shell scripts aren't cross-platform which means you need a .bat file on Windows. That will result in duplication which is not good.
 So does RDMD, unless I'm mistaken.

Yes, but there are still reasons to use DSSS for D1, see above. -- /Jacob Carlborg
Oct 07 2012
prev sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 6 October 2012 at 21:19:58 UTC, Joseph Rushton 
Wakeling wrote:
 On 10/06/2012 10:59 PM, Nick Sabalausky wrote:
 Definitely not. *DSource* is dying, unfortunately, which has 
 lead some
 people to assume the same of the rest of D. But no, D is going 
 very
 strong, and has only been getting bigger.

Might be worth placing some prominent message on DSource stating that it's being maintained to document all the D1 work and projects, but that the active work is now over at dlang.org?

+1 Getting tired of people heading to dsource and assuming that D is dead.
Oct 07 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 06 Oct 2012 23:27:55 +0200
Jacob Carlborg <doob me.com> wrote:

 On 2012-10-06 22:59, Nick Sabalausky wrote:
 
 DSSS has been dead for a long time, I don't know why an active
 project like GtkD is apparently mentioning it.

DSSS is working just fine for D1.

I don't know about the rest of DSSS as I only ever used the 'rebuild' component. But as for rebuild, there are problems: For one thing, 0.76 is generally considered to work much better than 0.77 and the final version, 0.78 (I forget the details, but a lot of people including me have had problems with 0.78 that never showed up with 0.76). But despite that, read-made builds aren't available for 0.76. As DSSS is dead none of this is likely to get fixed. And there's no reason to fix rebuild since RDMD is a superior and non-dead alternative to rebuild. Also, rebuild is slow, even with "one at a time" disabled. Try compiling DVM with the included rebuild-based script and the RDMD-based one. It takes a fair amount of time with rebuild (even with "one at a time" off), but with RDMD it's almost instant. There's no reason for anyone to use rebuild anymore, and very few people do.
 GtkD works both with D1 and D2.
 

So does RDMD, unless I'm mistaken.
Oct 06 2012
prev sibling next sibling parent reply "denizzzka" <4denizzz gmail.com> writes:
On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote:
 - I looked for a PostgreSQL client library. I found small

dead projects.

https://github.com/denizzzka/dpq2 This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd. I really need users, comments, suggestions, bug reports and commits.
Oct 06 2012
next sibling parent Thomas Koch <thomas koch.ro> writes:
denizzzka wrote:
 https://github.com/denizzzka/dpq2

add it to this wiki page? http://www.prowiki.org/wiki4d/wiki.cgi?DatabaseBindings#PostgreSQL Best regards, Thomas Koch
Oct 07 2012
prev sibling next sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Russel Winder wrote:
 On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote:
 On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote:
 - I looked for a PostgreSQL client library. I found small

dead projects.

https://github.com/denizzzka/dpq2 This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd. I really need users, comments, suggestions, bug reports and commits.

Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.?

I wrote a PostgreSQL client too, but I also want to make MySQL and SQlite clients/wrappers and release them all at once. This is because I want to create uniform DB interface, and it must be suited for all database systems. I started with PostgreSQL because it's most complex of the three, for instance it supports array and struct fields.
  From the example I assume that this is just a library for managing
 connections and that everything else is just string-based SQL
 statements. Groovy's and Python's lowest level is roughly the same.
 However on top of these are expression languages in Groovy / Python so
 as to remove the reliance on string processing, i.e. use an internal DSL
 to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it
 will hopefully be GSQL. I am sure Scala and C++ have something similar?

As you've said, additional DSL/Abstract layer must be on built on the string based library. We should finish that first.
Oct 07 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-07 10:55, Russel Winder wrote:

 Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2,
 PervasiveSQL, SQLite3, etc.?

  From the example I assume that this is just a library for managing
 connections and that everything else is just string-based SQL
 statements. Groovy's and Python's lowest level is roughly the same.
 However on top of these are expression languages in Groovy / Python so
 as to remove the reliance on string processing, i.e. use an internal DSL
 to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it
 will hopefully be GSQL. I am sure Scala and C++ have something similar?

They do.
 So I guess the question is how to ensure this all works with all SQL
 systems and how to put an abstraction layer over this to avoid all the
 error prone string manipulation?

ActiveRecord in Ruby on Rails uses several layers to handle all database related functionality. At the highest level there's a DSL which allows you to write the SQL queries mostly in Ruby. Another library, ARel, is used by ActiveRecord to generate the SQL code from the DSL. ARel handles all the differences among all the supported databases. ARel then passes the SQL code back to ActiveRecord where a lower layer handles the connections to the database and performs the actual query. Then you have another layer that transforms the response into objects, sets up all the relations and so on. -- /Jacob Carlborg
Oct 07 2012
parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Jacob Carlborg wrote:
 On 2012-10-07 10:55, Russel Winder wrote:

 Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2,
 PervasiveSQL, SQLite3, etc.?

  From the example I assume that this is just a library for managing
 connections and that everything else is just string-based SQL
 statements. Groovy's and Python's lowest level is roughly the same.
 However on top of these are expression languages in Groovy / Python so
 as to remove the reliance on string processing, i.e. use an internal DSL
 to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it
 will hopefully be GSQL. I am sure Scala and C++ have something similar?

They do.
 So I guess the question is how to ensure this all works with all SQL
 systems and how to put an abstraction layer over this to avoid all the
 error prone string manipulation?

ActiveRecord in Ruby on Rails uses several layers to handle all database related functionality. At the highest level there's a DSL which allows you to write the SQL queries mostly in Ruby. Another library, ARel, is used by ActiveRecord to generate the SQL code from the DSL. ARel handles all the differences among all the supported databases. ARel then passes the SQL code back to ActiveRecord where a lower layer handles the connections to the database and performs the actual query. Then you have another layer that transforms the response into objects, sets up all the relations and so on.

Having distinct layers that don't know each other isn't always a good idea. In my prostgres client one may specify field types at compile time. If I had divided the client into two separate layers it would return a Variant[] at first layer, then convert it to user specified tuple at the second. For example: auto cmd = new SqlCommand(connection, "SELECT 1, 'abc'"); auto untypedRow = connection.executeRow(); // return DBRow!(Variant[]) auto typedRow = connection.executeRow!(int, string)(); // returns DBRow!(int, string); Internally executeRow could always take a Variant[], then convert it to Tuple!(int, string), but it's suboptimal. Firstly, it must allocate an array of two Variants, then each Variant must be coerced to the corresponding type. Instead, the client fills each of the tuple field directly as they come from the socket stream. With binary formatting all it has to do is swapEndian() on integers and floats (no parsing!). Of course, there's one allocation for the string, but if we change field type to char[4], there'll be no allocation at all. Just wanted to illustrate that "layers" shouldn't always be separate.
Oct 07 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
 Having distinct layers that don't know each other isn't always a good idea.

 Just wanted to illustrate that "layers" shouldn't always be separate.

Actually I'm not sure how separate they are in ActiveRecord. I wanted to mostly point out that generating the SQL was done by a separate library. -- /Jacob Carlborg
Oct 07 2012
prev sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Thiez wrote:
 On Sunday, 7 October 2012 at 12:39:35 UTC, Piotr Szturmaj wrote:
 In my prostgres client one may specify field types at compile time. If
 I had divided the client into two separate layers it would return a
 Variant[] at first layer, then convert it to user specified tuple at
 the second. For example:

 auto cmd = new SqlCommand(connection, "SELECT 1, 'abc'");
 auto untypedRow = connection.executeRow(); // return DBRow!(Variant[])
 auto typedRow = connection.executeRow!(int, string)(); // returns
 DBRow!(int, string);

 Internally executeRow could always take a Variant[], then convert it
 to Tuple!(int, string), but it's suboptimal. Firstly, it must allocate
 an array of two Variants, then each Variant must be coerced to the
 corresponding type.

 Just wanted to illustrate that "layers" shouldn't always be separate.

It's not a very convincing illustration. In practice the overhead of those operations would likely be completely insignificant compared to performing the actual database query. Avoiding intermediate layers for optimality's sake seems like a bad case of premature optimization to me.

In my opinion everything counts. For thousands of rows x thousands of clients it certainly _should_ make a difference. And I wouldn't call it premature optimization, it's just _designed_ to be fast.
Oct 07 2012
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/7/12 1:06 PM, Paulo Pinto wrote:
 The important thing are interfaces, as such you're not bringing external
 dependencies. Unless the D community decides to have the drivers as part
 of the language (comes with batteries kind of thing).

Yah, this is a chicken-and-egg kind of thing. In many languages it's the database providers who provide the drivers, but in order for that to happen the language must be widespread enough. Andrei
Oct 07 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-07 21:53, denizzzka wrote:

 So, I do not know is it possible to make a universal interface. And why
 it may need in real life?

ActiveRecord provides a universal interface for all databases. But you can't do all things with a fancy DSL. Sometimes you need to drop down to raw SQL if you want to execute some weird SQL function or similar. -- /Jacob Carlborg
Oct 08 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-07 18:54, Joseph Rushton Wakeling wrote:
 On 10/07/2012 10:55 AM, Russel Winder wrote:
 Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2,
 PervasiveSQL, SQLite3, etc.?

I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice?

I think that a uniform database interface with support for different database drivers, a DSL, an ORM wrapper and a couple of database drivers would be too much to have in Phobos. -- /Jacob Carlborg
Oct 08 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote:
 On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote:
 - I looked for a PostgreSQL client library. I found small

dead projects.

https://github.com/denizzzka/dpq2 =20 This is my personal project but it is not dead, and I am=20 determined to see it through. At the moment, it is quite suitable=20 to be used in simple situations. Compiles without warnings by dmd=20 2.060, also it can be used with rdmd. =20 I really need users, comments, suggestions, bug reports and=20 commits.

Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? =46rom the example I assume that this is just a library for managing connections and that everything else is just string-based SQL statements. Groovy's and Python's lowest level is roughly the same. However on top of these are expression languages in Groovy / Python so as to remove the reliance on string processing, i.e. use an internal DSL to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it will hopefully be GSQL. I am sure Scala and C++ have something similar? So I guess the question is how to ensure this all works with all SQL systems and how to put an abstraction layer over this to avoid all the error prone string manipulation? =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Oct 07 2012
prev sibling next sibling parent "nazriel" <spam dzfl.pl> writes:
On Sunday, 7 October 2012 at 09:07:39 UTC, Russel Winder wrote:
 On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote:
 On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote:
 - I looked for a PostgreSQL client library. I found small

dead projects.

https://github.com/denizzzka/dpq2 This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd. I really need users, comments, suggestions, bug reports and commits.

Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.?

care about other DBMS at the time of being. There are other projects for Database handling. - There is SQLd [http://github.com/robik/sqld], that focus on multiple database drivers. Some designs flaws are inherited from SQLAlchemy. Looks promising. - There is DBMI on DSource. I am not 100% sure if it works with D2 tho (but porting should be rather trivial). - Many, many other projects like that shattered on Github/BitBucket/DSource(?)
 From the example I assume that this is just a library for 
 managing
 connections and that everything else is just string-based SQL
 statements. Groovy's and Python's lowest level is roughly the 
 same.
 However on top of these are expression languages in Groovy / 
 Python so
 as to remove the reliance on string processing, i.e. use an 
 internal DSL
 to do all the SQL stuff. For Python this is SQLAlchemy, for 
 Groovy it
 will hopefully be GSQL. I am sure Scala and C++ have something 
 similar?

 So I guess the question is how to ensure this all works with 
 all SQL
 systems and how to put an abstraction layer over this to avoid 
 all the
 error prone string manipulation?

Probably because of reason I mentioned before. But yeah, after first glance it looks like project ready for some bigger tasks
Oct 07 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, October 07, 2012 11:43:21 Peter Alexander wrote:
 On Saturday, 6 October 2012 at 21:19:58 UTC, Joseph Rushton
 
 Wakeling wrote:
 On 10/06/2012 10:59 PM, Nick Sabalausky wrote:
 Definitely not. *DSource* is dying, unfortunately, which has
 lead some
 people to assume the same of the rest of D. But no, D is going
 very
 strong, and has only been getting bigger.

Might be worth placing some prominent message on DSource stating that it's being maintained to document all the D1 work and projects, but that the active work is now over at dlang.org?

+1 Getting tired of people heading to dsource and assuming that D is dead.

Isn't part of the problem that no one can get ahold of the person who runs it? At least, that's what I remember being discussed previously. It was my understanding that that's why we've never been able to get dsource cleaned up or really changed at all. - Jonathan M Davis
Oct 07 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 7 October 2012 at 09:56:30 UTC, Piotr Szturmaj wrote:
 Russel Winder wrote:
 On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote:
 On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch 
 wrote:
 - I looked for a PostgreSQL client library. I found small

dead projects.

https://github.com/denizzzka/dpq2 This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd. I really need users, comments, suggestions, bug reports and commits.

Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.?

I wrote a PostgreSQL client too, but I also want to make MySQL and SQlite clients/wrappers and release them all at once. This is because I want to create uniform DB interface, and it must be suited for all database systems. I started with PostgreSQL because it's most complex of the three, for instance it supports array and struct fields.

I would also look at commercial DB, otherwise you might still find a few surprises while defining an uniform DB. I went through that pain back in 1999-2001, when we were defining an abstraction mechanism in TCL/C to bind to multiple databases, akin to ActiveRecord on Ruby. For example, on those days using only ODBC was not enough for SQL Server 6. We also needed to make use of another binding provided for compatibility with Sybase SQL Server, to be able to offer all the same API when using SQL Server as DB. That took awhile to figure out how to integrate into the existing architecture. -- Paulo
Oct 07 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 07 Oct 2012 02:51:42 -0700
Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Sunday, October 07, 2012 11:43:21 Peter Alexander wrote:
 On Saturday, 6 October 2012 at 21:19:58 UTC, Joseph Rushton
 
 Wakeling wrote:
 
 Might be worth placing some prominent message on DSource
 stating that it's being maintained to document all the D1 work
 and projects, but that the active work is now over at dlang.org?

+1 Getting tired of people heading to dsource and assuming that D is dead.

Isn't part of the problem that no one can get ahold of the person who runs it? At least, that's what I remember being discussed previously. It was my understanding that that's why we've never been able to get dsource cleaned up or really changed at all.

No, I think he'd just been busy. I've seen him around here a few times lately.
Oct 07 2012
prev sibling next sibling parent "jerro" <a a.com> writes:
 Isn't part of the problem that no one can get ahold of the 
 person who
 runs it? At least, that's what I remember being discussed 
 previously.
 It was my understanding that that's why we've never been able 
 to get
 dsource cleaned up or really changed at all.
 

No, I think he'd just been busy. I've seen him around here a few times lately.

Are you sure about that? There is a guy named Brad Anderson posting here, but he doesn't seem to be the Brad Anderson that dsource.org is registered to.
Oct 07 2012
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/07/2012 10:55 AM, Russel Winder wrote:
 Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2,
 PervasiveSQL, SQLite3, etc.?

I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice? Perhaps better as something in Deimos rather than Phobos, as I imagine it would bring in a bunch of external dependencies that the standard library shouldn't really have. Am I right that there's something in Adam Ruppe's web modules that's heading in this direction?
Oct 07 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
Wakeling wrote:
 Am I right that there's something in Adam Ruppe's web modules
 that's heading in this direction?

Yeah, though I'm a little biased toward mysql since that's what I use every day, so some of the stuff that should be in generic database.d are instead in mysql.d. But my stuff indeed does sql strings which can then be passed to a Database class with pretty uniform interface, at least for basic queries, for some major dbs. https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff Among the string manipulation stuff is class DataObject, which builds an UPDATE or INSERT query: auto obj = new DataObject(db, "table_name"); obj.id = 10; obj.name = "cool"; obj.commitChanges(); /* runs: if(db.query("select id from table_name where id = 10").empty) db.query("insert into table_name (id, name) values (10, 'cool')"); else db.query("UPDATE table_name set name = 'cool' where id = 10"); */ and also a build data object subclass from sql create table which kinda works, ugly mixin stuff. And there's also a SelectBuilder which does basic concat stuff: auto query = new SelectBuilder(); query.table = "something"; query.fields ~= "something.*"; query.wheres ~= "id > ?0"; db.query(query.toString(), 10); expands into select something.* from something where (id > 10); Nothing super fancy but it works for me.
Oct 07 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
Wakeling wrote:
 On 10/07/2012 10:55 AM, Russel Winder wrote:
 Why only PostgreSQL. Shouldn't it also work with MySQL, 
 Oracle, DB2,
 PervasiveSQL, SQLite3, etc.?

I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice? Perhaps better as something in Deimos rather than Phobos, as I imagine it would bring in a bunch of external dependencies that the standard library shouldn't really have. Am I right that there's something in Adam Ruppe's web modules that's heading in this direction?

There was a std.database proposal from Steve Teale, but it appears to have died. http://prowiki.org/wiki4d/wiki.cgi?ReviewQueue It could work like in other languages with OO support. Everything is interface based and it is up to the respective driver to provide proper implementations. Those implementations can be provided either as static or dynamic libraries. The important thing are interfaces, as such you're not bringing external dependencies. Unless the D community decides to have the drivers as part of the language (comes with batteries kind of thing). -- Paulo
Oct 07 2012
prev sibling next sibling parent "Thiez" <thiezz gmail.com> writes:
On Sunday, 7 October 2012 at 12:39:35 UTC, Piotr Szturmaj wrote:
 In my prostgres client one may specify field types at compile 
 time. If I had divided the client into two separate layers it 
 would return a Variant[] at first layer, then convert it to 
 user specified tuple at the second. For example:

 auto cmd = new SqlCommand(connection, "SELECT 1, 'abc'");
 auto untypedRow = connection.executeRow(); // return 
 DBRow!(Variant[])
 auto typedRow = connection.executeRow!(int, string)(); // 
 returns DBRow!(int, string);

 Internally executeRow could always take a Variant[], then 
 convert it to Tuple!(int, string), but it's suboptimal. 
 Firstly, it must allocate an array of two Variants, then each 
 Variant must be coerced to the corresponding type.

 Just wanted to illustrate that "layers" shouldn't always be 
 separate.

It's not a very convincing illustration. In practice the overhead of those operations would likely be completely insignificant compared to performing the actual database query. Avoiding intermediate layers for optimality's sake seems like a bad case of premature optimization to me.
Oct 07 2012
prev sibling next sibling parent "denizzzka" <4denizzz gmail.com> writes:
On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
Wakeling wrote:
 On 10/07/2012 10:55 AM, Russel Winder wrote:
 Why only PostgreSQL. Shouldn't it also work with MySQL, 
 Oracle, DB2,
 PervasiveSQL, SQLite3, etc.?

I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice?

Each database engine has a unique distinguishing features that make this engine interesting. (for example, different implementations of transactions - SQL standard does not describe the SQL transactions precisely enough) So, I do not know is it possible to make a universal interface. And why it may need in real life?
Oct 07 2012
prev sibling next sibling parent "denizzzka" <4denizzz gmail.com> writes:
On Sunday, 7 October 2012 at 08:05:10 UTC, Thomas Koch wrote:
 denizzzka wrote:
 https://github.com/denizzzka/dpq2

you like to add it to this wiki page? http://www.prowiki.org/wiki4d/wiki.cgi?DatabaseBindings#PostgreSQL

I could not register there. :( Who have the opportunity, please add https://github.com/denizzzka/dpq2 to this wiki. Thank you!
Oct 07 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 07 Oct 2012 18:39:16 +0200
"jerro" <a a.com> wrote:

 Isn't part of the problem that no one can get ahold of the 
 person who
 runs it? At least, that's what I remember being discussed 
 previously.
 It was my understanding that that's why we've never been able 
 to get
 dsource cleaned up or really changed at all.
 

No, I think he'd just been busy. I've seen him around here a few times lately.

Are you sure about that? There is a guy named Brad Anderson posting here, but he doesn't seem to be the Brad Anderson that dsource.org is registered to.

Oh, I guess I don't know. I just noticed the name.
Oct 07 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 07 Oct 2012 21:58:49 +0200
"denizzzka" <4denizzz gmail.com> wrote:

 On Sunday, 7 October 2012 at 08:05:10 UTC, Thomas Koch wrote:
 denizzzka wrote:
 https://github.com/denizzzka/dpq2

you like to add it to this wiki page? http://www.prowiki.org/wiki4d/wiki.cgi?DatabaseBindings#PostgreSQL

I could not register there. :( Who have the opportunity, please add https://github.com/denizzzka/dpq2 to this wiki. Thank you!

You don't really register there, you just go here: http://www.prowiki.org/wiki4d/wiki.cgi?action=editprefs&oldid=edit=DatabaseBindings Enter something UpperCamelCased for username (it requires at least two words for some odd reason, so "Foobar" won't work, but "FooBar" will), hit "save preferences", and that's it.
Oct 07 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 07 Oct 2012 18:54:17 +0200
Joseph Rushton Wakeling <joseph.wakeling webdrake.net> wrote:

 On 10/07/2012 10:55 AM, Russel Winder wrote:
 Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2,
 PervasiveSQL, SQLite3, etc.?

I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice?

Probably, yes. But someone needs to build such a lib first and then propose it as a std.db candidate.
 Perhaps better as something in Deimos rather than Phobos, as I
 imagine it would bring in a bunch of external dependencies that the
 standard library shouldn't really have.

Not necessarily: Steve Teale's "mysqln" is a native D MySQL driver that connects to the DB server directly and bypasses MySQL's official client lib entirely. Teale has inexplicably disappeared off the face of the internet, but Vibe.d has adapted the lib for use with Vibe.d, and this guy has also made some updates: https://github.com/simendsjo/mysqln/tree/misc-cleanups I'm using that with Vibe.d and it seems to be working pretty well. (I'm not sure if the simendsjo version or the Vibe.d version is more up-to-date, though.)
Oct 07 2012
prev sibling next sibling parent "Pragma Tix" <bizprac or.fr> writes:
On Sunday, 7 October 2012 at 09:07:39 UTC, Russel Winder wrote:

 Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, 
 DB2,
 PervasiveSQL, SQLite3, etc.?

Good question. A wrong approach since we talk about DB support. Design the Interface first, would be the solution. Then decide what you want. DAL, or Active Record. Then create a DSL, or LINQ or whatsoever. Since you are a Python guy, the data access layer from web2py is simply excellent. But I doubt that D, respective phobos, will ever have more than rudimentary db support.
Oct 07 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote:
 On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
 Wakeling wrote:
 On 10/07/2012 10:55 AM, Russel Winder wrote:
 Why only PostgreSQL. Shouldn't it also work with MySQL, 
 Oracle, DB2,
 PervasiveSQL, SQLite3, etc.?

I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice?

Each database engine has a unique distinguishing features that make this engine interesting. (for example, different implementations of transactions - SQL standard does not describe the SQL transactions precisely enough)

There are plenty of existing interfaces to base D's design on, just a few of them: Perl - DBI Python - DB API C, C++ - ODBC (there is an UNIX variant of it) C++ - OLE DB (Although Windows specific) Java - JDBC .NET - Data Providers Ruby - DBI TCL - TDBC Go - database package Delphi - Data Access Haskell - HaskellDB (HDBC)
 So, I do not know is it possible to make a universal interface. 
 And why it may need in real life?

At least in the enterprise world, we tend to write applications in a DB independent way. One reason is to be able to deploy the applications without forcing the customers to invest in new DB engines, thus reaching a broader client base. Sometimes inside the same organization different business units have different DB engines running (even different versions of the same DB). Finally, to minimize costs when management decides for whatever reason, to change the DB licenses being used. -- Paulo
Oct 08 2012
prev sibling next sibling parent "simendsjo" <simendsjo gmail.com> writes:
On Sunday, 7 October 2012 at 22:08:45 UTC, Nick Sabalausky wrote:
 Not necessarily: Steve Teale's "mysqln" is a native D MySQL 
 driver that
 connects to the DB server directly and bypasses MySQL's 
 official client
 lib entirely. Teale has inexplicably disappeared off the face 
 of the
 internet, but Vibe.d has adapted the lib for use with Vibe.d, 
 and
 this guy has also made some updates:
 https://github.com/simendsjo/mysqln/tree/misc-cleanups

 I'm using that with Vibe.d and it seems to be working pretty 
 well.

 (I'm not sure if the simendsjo version or the Vibe.d version is 
 more
 up-to-date, though.)

The important updates (compile on x64) is incorporated in vibe. The other updates in my repo is just code cleanups, but it's a WIP, and I don't think I'll finish it unless I need to use MySQL+D.
Oct 08 2012
prev sibling next sibling parent "denizzzka" <4denizzz gmail.com> writes:
On Monday, 8 October 2012 at 07:35:13 UTC, Paulo Pinto wrote:
 On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote:
 On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
 Wakeling wrote:
 On 10/07/2012 10:55 AM, Russel Winder wrote:
 Why only PostgreSQL. Shouldn't it also work with MySQL, 
 Oracle, DB2,
 PervasiveSQL, SQLite3, etc.?

I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice?

Each database engine has a unique distinguishing features that make this engine interesting. (for example, different implementations of transactions - SQL standard does not describe the SQL transactions precisely enough)

There are plenty of existing interfaces to base D's design on, just a few of them: Perl - DBI Python - DB API C, C++ - ODBC (there is an UNIX variant of it) C++ - OLE DB (Although Windows specific) Java - JDBC .NET - Data Providers Ruby - DBI TCL - TDBC Go - database package Delphi - Data Access Haskell - HaskellDB (HDBC)
 So, I do not know is it possible to make a universal 
 interface. And why it may need in real life?

At least in the enterprise world, we tend to write applications in a DB independent way. One reason is to be able to deploy the applications without forcing the customers to invest in new DB engines, thus reaching a broader client base. Sometimes inside the same organization different business units have different DB engines running (even different versions of the same DB). Finally, to minimize costs when management decides for whatever reason, to change the DB licenses being used. -- Paulo

For this to work you need to implement an independent way to create queries that would work on all database engines the same way. I believe that this problem is in principle much more complicated than it would have been implemented interfaces to databases in separate libs.
Oct 08 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 8 October 2012 at 10:26:35 UTC, denizzzka wrote:
 On Monday, 8 October 2012 at 07:35:13 UTC, Paulo Pinto wrote:
 On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote:
 On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
 Wakeling wrote:
 On 10/07/2012 10:55 AM, Russel Winder wrote:
 Why only PostgreSQL. Shouldn't it also work with MySQL, 
 Oracle, DB2,
 PervasiveSQL, SQLite3, etc.?

I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice?

Each database engine has a unique distinguishing features that make this engine interesting. (for example, different implementations of transactions - SQL standard does not describe the SQL transactions precisely enough)

There are plenty of existing interfaces to base D's design on, just a few of them: Perl - DBI Python - DB API C, C++ - ODBC (there is an UNIX variant of it) C++ - OLE DB (Although Windows specific) Java - JDBC .NET - Data Providers Ruby - DBI TCL - TDBC Go - database package Delphi - Data Access Haskell - HaskellDB (HDBC)
 So, I do not know is it possible to make a universal 
 interface. And why it may need in real life?

At least in the enterprise world, we tend to write applications in a DB independent way. One reason is to be able to deploy the applications without forcing the customers to invest in new DB engines, thus reaching a broader client base. Sometimes inside the same organization different business units have different DB engines running (even different versions of the same DB). Finally, to minimize costs when management decides for whatever reason, to change the DB licenses being used. -- Paulo

For this to work you need to implement an independent way to create queries that would work on all database engines the same way. I believe that this problem is in principle much more complicated than it would have been implemented interfaces to databases in separate libs.

Sure. That is why on top of a DB driver layer, usually you have some kind of SQL adaptation layer. On the TCL/C abstraction layer we implemented for a product during the 1999-2001 timeframe, we used standard SQL '92 for all data queries, regardless of hand-written or generated from our TCL ORM. Then there was a translation layer that transformed SQL '92 into DB specific SQL, before giving it to the corresponding driver. The only two parts of the application that had DB specific code were the SQL transformation layer, and the .so/.dll with the DB specific driver. With the added benefit that any DB fully SQL '92 compliant did not need any adaptations in the transformation layer. -- Paulo
Oct 08 2012
prev sibling next sibling parent "BLM768" <blm768 gmail.com> writes:
I've been thinking about writing an interface inspired by 
ActiveRecord. It would probably be relatively simple and 
lightweight, but it should be enough for simple REST 
applications, and the interface would (hopefully) be extremely 
nice to use.
Of course, with all the other projects I want to do, I'm not sure 
how long this will live :).
Oct 08 2012
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--047d7b621e12cd2ed804cb900fbe
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Oct 7, 2012 at 10:39 AM, jerro <a a.com> wrote:

 Isn't part of the problem that no one can get ahold of the person who
 runs it? At least, that's what I remember being discussed previously.
 It was my understanding that that's why we've never been able to get
 dsource cleaned up or really changed at all.

lately.

Are you sure about that? There is a guy named Brad Anderson posting here, but he doesn't seem to be the Brad Anderson that dsource.org is registered to.

Yeah, I'm not the same guy as the Brad Anderson who runs dsource. Someone may want to email him directly. Regards, Doppelganger --047d7b621e12cd2ed804cb900fbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Oct 7, 2012 at 10:39 AM, jerro <span dir=3D"ltr">&lt;<a href=3D"mai= lto:a a.com" target=3D"_blank">a a.com</a>&gt;</span> wrote:<br><div class= =3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"> Isn&#39;t part of the problem that no one can get ahold of the person who<b= r> runs it? At least, that&#39;s what I remember being discussed previously.<b= r> It was my understanding that that&#39;s why we&#39;ve never been able to ge= t<br> dsource cleaned up or really changed at all.<br> <br> </blockquote> <br> No, I think he&#39;d just been busy. I&#39;ve seen him around here a few ti= mes<br> lately.<br> </blockquote> <br></div> Are you sure about that? There is a guy named Brad Anderson posting here, b= ut he doesn&#39;t seem to be the Brad Anderson that <a href=3D"http://dsour= ce.org" target=3D"_blank">dsource.org</a> is registered to.<br> </blockquote></div><br><div>Yeah, I&#39;m not the same guy as the Brad Ande= rson who runs dsource. Someone may want to email him directly.</div><div><b= r></div><div>Regards,</div><div>Doppelganger</div> --047d7b621e12cd2ed804cb900fbe--
Oct 08 2012
prev sibling next sibling parent "Mark Lamberton" <mark penguinsystems.com.au> writes:
As a D newbie, Thomas' post is quite timely.  I've collected all 
the books on offer and scanned the 'net for anything D related.  
Like Thomas, I was starting to feel that D was going nowhere 
fast.  Some of the comments here have helped dispel this 
impression, but it's true to say that from an outsider's 
perspective the situation is confusing.  I'm still not sure why 
(for example) Tango exists and what is its status relative to the 
D ecosystem.

Per the discussion on SQL, database access is a subject close to 
my heart.  Posters here may be interested in looking at OpenDBX - 
http://www.linuxnetworks.de/doc/index.php/OpenDBX - an open 
source, lightweight, EXTENSIBLE database access library with C 
and CPP interfaces.

I've used OpenDBX with Oracle, Firebird, and MSSQL in commercial 
applications and from what little I know (so far) about D, would 
seem to be at least a viable starting point (maybe even a viable 
end point for some...) for a 'universal' database access facility.

Mark

On Monday, 8 October 2012 at 07:35:13 UTC, Paulo Pinto wrote:
 On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote:
 On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
 Wakeling wrote:
 On 10/07/2012 10:55 AM, Russel Winder wrote:
 Why only PostgreSQL. Shouldn't it also work with MySQL, 
 Oracle, DB2,
 PervasiveSQL, SQLite3, etc.?

I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice?

Each database engine has a unique distinguishing features that make this engine interesting. (for example, different implementations of transactions - SQL standard does not describe the SQL transactions precisely enough)

There are plenty of existing interfaces to base D's design on, just a few of them: Perl - DBI Python - DB API C, C++ - ODBC (there is an UNIX variant of it) C++ - OLE DB (Although Windows specific) Java - JDBC .NET - Data Providers Ruby - DBI TCL - TDBC Go - database package Delphi - Data Access Haskell - HaskellDB (HDBC)
 So, I do not know is it possible to make a universal 
 interface. And why it may need in real life?

At least in the enterprise world, we tend to write applications in a DB independent way. One reason is to be able to deploy the applications without forcing the customers to invest in new DB engines, thus reaching a broader client base. Sometimes inside the same organization different business units have different DB engines running (even different versions of the same DB). Finally, to minimize costs when management decides for whatever reason, to change the DB licenses being used. -- Paulo

Oct 09 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, October 10, 2012 00:02:50 Mark Lamberton wrote:
 I'm still not sure why
 (for example) Tango exists and what is its status relative to the
 D ecosystem.

It's a historical thing. Phobos in D1 sucked (probably because Walter was focused on the compiler and I don't think that there was as much community participation in Phobos at the time). So, folks wrote their own libraries. Tango was one of these and became the largest 3rd party D library. Unfortunately in D1, the runtime was not separate from Phobos, so when the Tango folks decided to do their own runtime, it made Phobos and Tango incompatible, forcing people to choose, and because Tango was better, they almost always chose Tango. This made it so that some people considered Tango to be D's standard libray even though this was never technically the case (it just got used instead of D's standard library). For D2, Phobos is much better and has much stronger community support, so Tango isn't as necessary. And it wasn't until fairly recently that anyone ported Tango to D2 (and it's not even the official Tango devs that did it). So, Tango hasn't even been an option for D2 until recently, and I think that for the most part, the only people who use it are those who used D1 and want to continue to use Tango. So, I suspect that while it does get used for D2, there probably aren't very many people use it. However, since the runtime has been split out from Phobos in D2 (in fact, druntime was ported from Tango by one of the Tango developers who continues to work on druntime - Sean Kelly), it's possible to mix Phobos and Tango in D2, making it so that there's no need to choose exclusively one or the other. But they _do_ have very different design philosophies, so you probably wouldn't mix them heavily. The main thing to be aware of about Tango at this point (beyond the basic history of why it's there, if you care) is the fact that it uses a more restrictive license than Phobos, so you can't port code from Tango to Phobos without the permission of the authors of that code, and it's generally advised that anyone working on Phobos not look at Tango just to avoid the possibility of anyone accusing them of stealing code (not to say that that would happen or that anyone would be necessarily be accused of that - but we want to avoid any possible misunderstandings). In the long run, I expect that most of this will be forgotten. Either Tango will disappear (which is highly likely unless it gets higher adoption in D2), or it will just become another popular 3rd party library with cool stuff that you can use, and its status as pseudo-standard library of D1 will be mostly forgotten. But it caused enough confusion and strife in the past that many who have heard of D but don't know much about it end up asking whether D still has two standard libraries and whether any major divisions in the community like that still exist. - Jonathan M Davis
Oct 09 2012
prev sibling next sibling parent "Mark Lamberton" <mark penguinsystems.com.au> writes:
Many thanks Jonathan, that greatly clarifies the situation...
Oct 09 2012
prev sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 7 October 2012 at 19:25:06 UTC, Andrei Alexandrescu 
wrote:
 On 10/7/12 1:06 PM, Paulo Pinto wrote:
 The important thing are interfaces, as such you're not 
 bringing external
 dependencies. Unless the D community decides to have the 
 drivers as part
 of the language (comes with batteries kind of thing).

Yah, this is a chicken-and-egg kind of thing. In many languages it's the database providers who provide the drivers, but in order for that to happen the language must be widespread enough. Andrei

Probably because it's too big an endeavour for a single man. What we really want to define here is a good interface, not an implementation. Implementations will come as needed by users.
Oct 15 2012