My work on allocators takes the last turn before the straight line. I've arranged with Dicebot to overlap the review period with finalizing details so I can act on feedback quickly.

After that I'm ready for some major library work, and I had two things in mind.

One would be a good pass of std.container, in particular (a) a design review with the DbI glasses on; (b) better documentation - sadly it seems to me so inadequate as to make containers themselves unusable; (c) investigate use of UFCS - std.container's design predates UFCS yet is a perfect fit for it, and most likely other cool language improvements we've added since.

The other would be database connectivity. Erik Smith has shown some cool ideas at DConf, and I encourage him to continue working on them, but it seems to me this is an area where more angles mean more connectivity options.

For database connectivity I'm thinking of using ODBC. What I see is that on all major platforms, vendors offer mature, good quality ODBC drivers, and most programs that have anything to do with databases offer ODBC connectivity. So connecting with ODBC means the individual database drivers are already there; no need to waste effort on creating drivers for each (or asking vendors to, which we can't afford).

So I gave myself ten minutes the other night just before I went to sleep to see if I can get an ODBC rig on my OSX machine starting from absolutely nothing. I got http://www.odbcmanager.net but then got confused about where to find some dumb driver (text, csv) and gave up.

Last night I gave myself another ten minutes, and lo and behold I got up and running. Got a demo CSV driver from http://www.actualtech.com/product_access.php (which also supports Access and others). Then I headed to http://www.easysoft.com/developer/languages/c/odbc_tutorial.html and was able to run a simple ODBC application that lists the available drivers. Nice!

It's trivial work to convert the C headers to D declarations. Then it's straight library design to offer convenient libraries on top of the comprehensive but pedestrian ODBC C API. Then, voilà - we'll have database connectivity for all databases out there!

Please help me choose what to work on next.


Andrei

On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu wrote:
>
> help me choose what to work on next.
>
>
> Andrei

I think containers would be the better option. D sorely needs to have basics like (de)queues and stacks in the standard library, as well as any other popular and useful containers.

On Tuesday, 9 June 2015 at 17:12:53 UTC, Liam McSherry wrote:
> I think containers would be the better option. D sorely needs to have basics like (de)queues and stacks in the standard library, as well as any other popular and useful containers.

And `set`.

On Tuesday, 9 June 2015 at 17:15:46 UTC, Dennis Ritchie wrote:
> On Tuesday, 9 June 2015 at 17:12:53 UTC, Liam McSherry wrote:
>> I think containers would be the better option. D sorely needs to have basics like (de)queues and stacks in the standard library, as well as any other popular and useful containers.
>
> And `set`.

+1, I was just about to post this too. ;)

On Tue, 09 Jun 2015 17:12:51 +0000
Liam McSherry via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu wrote:
> >
> > help me choose what to work on next.
> >
> >
> > Andrei
> 
> I think containers would be the better option. D sorely needs to have basics like (de)queues and stacks in the standard library, as well as any other popular and useful containers.

+1000

On Tuesday, 9 June 2015 at 17:27:34 UTC, kinke wrote:
> On Tuesday, 9 June 2015 at 17:15:46 UTC, Dennis Ritchie wrote:
>> And `set`.
>
> +1, I was just about to post this too. ;)

You already ahead in DIP80:
http://wiki.dlang.org/DIP80

On 2015-06-09 19:05, Andrei Alexandrescu wrote:
> My work on allocators takes the last turn before the straight line. I've
> arranged with Dicebot to overlap the review period with finalizing
> details so I can act on feedback quickly.
>
> After that I'm ready for some major library work, and I had two things
> in mind.
>
> One would be a good pass of std.container, in particular (a) a design
> review with the DbI glasses on; (b) better documentation - sadly it
> seems to me so inadequate as to make containers themselves unusable; (c)
> investigate use of UFCS - std.container's design predates UFCS yet is a
> perfect fit for it, and most likely other cool language improvements
> we've added since.
>
> The other would be database connectivity.

I vote for databases. I also vote for an interface that is independent of ODBC, but ODBC could be one of the drivers that implements this interface. I know that there's a native implementation of the MySQL protocol on code.dlang.org.

-- 
/Jacob Carlborg

On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu wrote:
> My work on allocators takes the last turn before the straight line. I've arranged with Dicebot to overlap the review period with finalizing details so I can act on feedback quickly.
>
> After that I'm ready for some major library work, and I had two things in mind.
>
> One would be a good pass of std.container, in particular (a) a design review with the DbI glasses on; (b) better documentation - sadly it seems to me so inadequate as to make containers themselves unusable; (c) investigate use of UFCS - std.container's design predates UFCS yet is a perfect fit for it, and most likely other cool language improvements we've added since.
>
> The other would be database connectivity. Erik Smith has shown some cool ideas at DConf, and I encourage him to continue working on them, but it seems to me this is an area where more angles mean more connectivity options.
>
> For database connectivity I'm thinking of using ODBC. What I see is that on all major platforms, vendors offer mature, good quality ODBC drivers, and most programs that have anything to do with databases offer ODBC connectivity. So connecting with ODBC means the individual database drivers are already there; no need to waste effort on creating drivers for each (or asking vendors to, which we can't afford).
>
> So I gave myself ten minutes the other night just before I went to sleep to see if I can get an ODBC rig on my OSX machine starting from absolutely nothing. I got http://www.odbcmanager.net but then got confused about where to find some dumb driver (text, csv) and gave up.
>
> Last night I gave myself another ten minutes, and lo and behold I got up and running. Got a demo CSV driver from http://www.actualtech.com/product_access.php (which also supports Access and others). Then I headed to http://www.easysoft.com/developer/languages/c/odbc_tutorial.html and was able to run a simple ODBC application that lists the available drivers. Nice!
>
> It's trivial work to convert the C headers to D declarations. Then it's straight library design to offer convenient libraries on top of the comprehensive but pedestrian ODBC C API. Then, voilà - we'll have database connectivity for all databases out there!
>
> Please help me choose what to work on next.
>
>
> Andrei

I would think a good database lib would depend on a good container lib, So IMO, the order is self evident.

1000+ to containers.

On Tue, 09 Jun 2015 10:05:24 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 
> For database connectivity I'm thinking of using ODBC. What I see is that on all major platforms, vendors offer mature, good quality ODBC drivers, and most programs that have anything to do with databases offer ODBC connectivity. So connecting with ODBC means the individual database drivers are already there; no need to waste effort on creating drivers for each (or asking vendors to, which we can't afford).

Having ODBC support in D is definitely important for some kind of applications. But for most applications which works with some (kind of) database it does not scale. We really need individual drivers for each of the most popular databases (even as a C/C++ lib with d binding around it). And I do not think DB conectivity need to be in phobos.

So as I allready wrote in another reply I think containers stuff are much more important right now (same as better JSON,XML,BSON...).

On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu
wrote:
> My work on allocators takes the last turn before the straight line. I've arranged with Dicebot to overlap the review period with finalizing details so I can act on feedback quickly.
>
> After that I'm ready for some major library work, and I had two things in mind.
>
> One would be a good pass of std.container, in particular (a) a design review with the DbI glasses on; (b) better documentation - sadly it seems to me so inadequate as to make containers themselves unusable; (c) investigate use of UFCS - std.container's design predates UFCS yet is a perfect fit for it, and most likely other cool language improvements we've added since.
>
> The other would be database connectivity. Erik Smith has shown some cool ideas at DConf, and I encourage him to continue working on them, but it seems to me this is an area where more angles mean more connectivity options.
>
> For database connectivity I'm thinking of using ODBC. What I see is that on all major platforms, vendors offer mature, good quality ODBC drivers, and most programs that have anything to do with databases offer ODBC connectivity. So connecting with ODBC means the individual database drivers are already there; no need to waste effort on creating drivers for each (or asking vendors to, which we can't afford).
>
> So I gave myself ten minutes the other night just before I went to sleep to see if I can get an ODBC rig on my OSX machine starting from absolutely nothing. I got http://www.odbcmanager.net but then got confused about where to find some dumb driver (text, csv) and gave up.
>
> Last night I gave myself another ten minutes, and lo and behold I got up and running. Got a demo CSV driver from http://www.actualtech.com/product_access.php (which also supports Access and others). Then I headed to http://www.easysoft.com/developer/languages/c/odbc_tutorial.html and was able to run a simple ODBC application that lists the available drivers. Nice!
>
> It's trivial work to convert the C headers to D declarations. Then it's straight library design to offer convenient libraries on top of the comprehensive but pedestrian ODBC C API. Then, voilà - we'll have database connectivity for all databases out there!
>
> Please help me choose what to work on next.
>
>
> Andrei

Containers.

But - we really need those allocators working in actual released
Phobos first.