On Tuesday, 9 June 2015 at 17:56:57 UTC, luminousone wrote:
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.
Yep. Containers.
containers + right allocation strategy => interfacing to data
base with the right containers
