View mode: basic / threaded / horizontal-split · Log in · Help
October 06, 2012
Re: The sorry state of the D stack?
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
October 06, 2012
Re: The sorry state of the D stack?
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.
October 06, 2012
Re: The sorry state of the D stack?
On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote:
>> - I looked for a PostgreSQL client library. I found small
> personal hacks and
> 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.
October 07, 2012
Re: The sorry state of the D stack?
denizzzka wrote:
> https://github.com/denizzzka/dpq2
Thank you very much. I think I haven't seen this project. Would you like to 
add it to this wiki page?

http://www.prowiki.org/wiki4d/wiki.cgi?DatabaseBindings#PostgreSQL

Best regards, Thomas Koch
October 07, 2012
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
> > personal hacks and
> > 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.?

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?


-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
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
October 07, 2012
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
>> > personal hacks and
>> > 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.?
>
Probably if someones needs work to be done in ie PostreSQL won't 
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
October 07, 2012
Re: The sorry state of the D stack?
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.
October 07, 2012
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
>>> personal hacks and
>>> 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.
October 07, 2012
Re: The sorry state of the D stack?
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
October 07, 2012
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
>>>> personal hacks and
>>>> 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
1 2 3 4 5
Top | Discussion index | About this forum | D home