Hi all!
After 14 years using Perl for programming at job I'm now
learning D. (And enjoying it)

Hi, and welcome.
(...)

As a newbie I've a few questions. I'm already using D and it's
working fine, although I'm writing baby-D the performance
improvement is impressive, I'm now trying to use mysql native
access. It seems there are two possibilities:
- https://github.com/simendsjo/mysqln
- https://github.com/rejectedsoftware/mysql-native
So far we've tried the second one, mysql-native, with success
while using rdmd, but I've failed to compile using dmd, (the
rather cryptic message from the compiler it's attached at the
end of this entry).

You're right in picking the rejectedsoftware repo. The first one
is in a state of flux while experimenting with a near complete
rewrite and a new API.
The rejectedsoftware repo is based on an earlier version of mine
which in turn is based on the original by Steve Teale (britseye).
(... lots of compiler errors ...)
What you are seeing are missing dependencies. DMD won't figure
out dependencies you are using without you specifying it in
detail.
You should be using dub directly rather than dmd. Specify your
dependencies in the package.json file, and use "dub run" to run
the application.
I created a video tutorial a couple of days ago that might help
you get started using dub: http://youtu.be/8TV9ZZteYEU

On Tuesday, 18 February 201hanks for the nod. It's good to see
that all those hours were
not wast4 at 11:56:23 UTC, Steve Teale wrote:

On Tuesday, 18 February 2014 at 01:04:10 UTC, simendsjo wrote:

The rejectedsoftware repo is based on an earlier version of
mine which in turn is based on the original by Steve Teale
(britseye).

Thanks for the nod. It's good to see that all those hours were
not wasted.

And this is a reminder that I should finish the rewrite to not
let all those hours go to waste :) The code everyone uses is
pretty much exactly your original code with many small
refactorings like remove magic constants. So big thanks for doing
all that work!

On Tuesday, 18 February 201hanks for the nod. It's good to see that all
those hours were
not wast4 at 11:56:23 UTC, Steve Teale wrote:

On Tuesday, 18 February 2014 at 01:04:10 UTC, simendsjo wrote:

The rejectedsoftware repo is based on an earlier version of mine
which in turn is based on the original by Steve Teale (britseye).

Thanks for the nod. It's good to see that all those hours were not
wasted.

And this is a reminder that I should finish the rewrite to not let all
those hours go to waste :) The code everyone uses is pretty much exactly
your original code with many small refactorings like remove magic
constants. So big thanks for doing all that work!

I posted it to D.learn. It was aimed at beginners, so I thought
it might be a bit spammy posting it to D.announce.
I've created two more videos, but they are pure live-coding D
basics and probably of less interest to most of the users here:
https://www.youtube.com/playlist?list=PLqABwcsDQUo59iBOM5DFtqbwrMhL4PWcQ
I expect there will be made an announcement about that YouTube
channel as soon as we upload a couple of more videos.

.. preamble
The rejectedsoftware repo is based on an earlier version of
mine which in turn is based on the original by Steve Teale
(britseye).
(... lots of compiler errors ...)
What you are seeing are missing dependencies. DMD won't figure
out dependencies you are using without you specifying it in
detail.
You should be using dub directly rather than dmd. Specify your
dependencies in the package.json file, and use "dub run" to run
the application.
I created a video tutorial a couple of days ago that might help
you get started using dub: http://youtu.be/8TV9ZZteYEU

Following Nick advice I've completed my project by using dmd and
specifying dependencies manually, it's a tiny project after all.
Everything seems to work fine. So...
After seen your tutorials (at youtube, by the way very useful
indeed) I'm now trying to port my code to use dub, again I have a
doubt.
In my code, at 'dub.json' file I've wrote:
"dependencies": {
"mysql-native" : ">=0.0.12"
}
When trying to build, I've got an error from mysql-native code:
$HOME/.dub/packages/mysql-native-0.0.12/source/mysql/connection.d(333):
Error: cannot implicitly convert expression (t % 24) of type int
to ubyte
But this error seems to be already solved in github repo for
mysql-native.
I manually copy the files from my cloned copy of mysql-native into
$HOME/.dub/packages/mysql-native-0.0.12/source/mysql/
and now everything works fine.
Am I making an error when specifying my dependencies??

Following Nick advice I've completed my project by using dmd and
specifying dependencies manually, it's a tiny project after all.
Everything seems to work fine. So...
After seen your tutorials (at youtube, by the way very useful indeed)
I'm now trying to port my code to use dub, again I have a doubt.
In my code, at 'dub.json' file I've wrote:
"dependencies": {
"mysql-native" : ">=0.0.12"
}
When trying to build, I've got an error from mysql-native code:
$HOME/.dub/packages/mysql-native-0.0.12/source/mysql/connection.d(333):
Error: cannot implicitly convert expression (t % 24) of type int to ubyte
But this error seems to be already solved in github repo for mysql-native.
I manually copy the files from my cloned copy of mysql-native into
$HOME/.dub/packages/mysql-native-0.0.12/source/mysql/
and now everything works fine.
Am I making an error when specifying my dependencies??

I thought that was deprecated (according to the format description at
code.dlang.org)

Seems like that documentation change was uploaded a bit too early. The
deprecation will come with 0.9.22 (there is a beta version available for
download) and there will be two alternative mechanisms to use non-tagged
versions of a package then; user/system wide overrides ("dub
add-override ...") and using the new dub.selections.json file.

D's build model is similar to C: The compiler only compiles the files
you give it. You didn't give it the mysql-native source files, so it
didn't compile them. Hence, linker errors for all the missing symbols.
The main point of RDMD is to find all the files used by your program and
automatically pass them all to the compiler. Usually you'll just want to
use RDMD instead of calling DMD directly. If you don't want RDMD to
automatically run your program after compiling it, use --build-only.
Or use DUB to build it and run it like simendsjo said. It grabs up all
your files and passes them all to DMD much like RDMD does.

Hey! Thanks everybody for such a quick response. Problem solved!
As Nick and you pointed I didn't understand the build process.
Now, thanks to your video simendsjo, I have new duties. Dub and
Vibed seems worth a detailed look. :-)
I look forward to see the evolution of the mysql native libraries
;-)

Hi all!
After 14 years using Perl for programming at job I'm now
learning D. (And enjoying it)
We've been using Perl (at job) for years for loading input data
(UTF files) into a database and using these data for different
purposes.
The volume of input data files has been constantly increasing
along the years and, eventually, we need a faster solution,
that's the reason to switch back to compiled languages, and D
seemed interesting enough to give it a try. :-)
As a newbie I've a few questions. I'm already using D and it's
working fine, although I'm writing baby-D the performance
improvement is impressive, I'm now trying to use mysql native
access. It seems there are two possibilities:
- https://github.com/simendsjo/mysqln
- https://github.com/rejectedsoftware/mysql-native

Quite by accident/coincidence, I recently returned to my mysqln
effort to see if it would still build with the latest dmd.
I had also reinstalled MySQL recently so it was a different
version, and that resulted in a few tweaks to the unit tests.
However, other than that, I had no great problem.
I then set about trying to minimize memory allocations, and
hopefully get the thing to be a bit more speedy. I think I have
made some improvements there.
Now I realize that the code is pretty impenetrable. It's dealing
with a protocol that is really very basic, badly documented, and
consists of streams of ubytes minimized as much as possible,
probably by disparate authors. You don't know what the next byte
might represent until you've looked at the current one in
context, so that makes it as bad a candidate for an input range
as UTF8, or worse.
However, on a return visit, I'm not inclined to change my mind
about the higher level interactions. I think the ability to read
a specific table row into a tuple of D types, or to populate a D
struct is quite cool. Also result sets with multiple rows can
constitute an input range, so the std.algorithm stuff should be
fine for doing finer graded selection than that provided by the
SQL query.
If you want to do database stuff that avoids knowledge of how to
use SQL, then I'd say it could be wrapped to provide that sort of
thing - but then I always hated Visual Basic.
If you give me a couple of weeks or less, I'll convert it into a
tidy module that will build with dub, and then I will invite the
D aficionados to tell me how I can improve the efficiency of the
protocol handling, and the template stuff that I used. From
previous experience, I'm fairly confident that I won't get any
takers, so I'll just keep up with the newsgroup and do the best I
can to keep up with idiomatic D usage, as long as it's not just
to show how cleverly things can be done.
I still quite like it, and if I had to seriously write something
in D that needed MySQL, I would use it in preference to my
earlier attempt at a wrapper around the C library.
But thanks for the interest
Steve.

Hi all!
After 14 years using Perl for programming at job I'm now learning D.
(And enjoying it)
We've been using Perl (at job) for years for loading input data (UTF
files) into a database and using these data for different purposes.
The volume of input data files has been constantly increasing along
the years and, eventually, we need a faster solution, that's the
reason to switch back to compiled languages, and D seemed interesting
enough to give it a try. :-)
As a newbie I've a few questions. I'm already using D and it's working
fine, although I'm writing baby-D the performance improvement is
impressive, I'm now trying to use mysql native access. It seems there
are two possibilities:
- https://github.com/simendsjo/mysqln
- https://github.com/rejectedsoftware/mysql-native

Quite by accident/coincidence, I recently returned to my mysqln effort
to see if it would still build with the latest dmd.

This is great news. If you look at the simendsjo repo, there's a rewrite
in progress, but it's still missing some key features.
The rejectedsoftware repo is the one in production use.
Here's a TODO:
http://forum.dlang.org/post/zsfxoggzwkmqjzyxbwgc forum.dlang.org

It looks like at least some of that TODO takes things beyond where the
rejectedsoftware version is, which is good, of course. But what would
you say are the things needed just to bring it up to parity with the
rejectedsoftware version? (So we could declare it the new "official" and
either replace or deprecate the current one.)

This is great news. If you look at the simendsjo repo, there's a rewrite
in progress, but it's still missing some key features.
The rejectedsoftware repo is the one in production use.
Here's a TODO:
http://forum.dlang.org/post/zsfxoggzwkmqjzyxbwgc forum.dlang.org

It looks like at least some of that TODO takes things beyond where the
rejectedsoftware version is, which is good, of course. But what would
you say are the things needed just to bring it up to parity with the
rejectedsoftware version? (So we could declare it the new "official" and
either replace or deprecate the current one.)

What comes to mind is
* Stored Procedures
* Purging results (cancelling queries)
* Sending and receiving large blobs
But if this should become the official version, more thought should go
into the API, or we should build a "fully" compatible API.
By "fully", I mean as much as possible - there are some very odd
behavior regarding passing values to stored procedures in the original
code that shouldn't be replicated.

The original did all of these, and user-defined functions. At the
time MySQL did not support strored procedures that returned a
result set. Maybe it does not but I have not investigated that
yet.
Steve

The original did all of these, and user-defined functions. At the time
MySQL did not support strored procedures that returned a result set.
Maybe it does not but I have not investigated that yet.
Steve

OK, can you give me a brief run-down on the changes you would
like to see/are working on. Then we can get together and agree on
an outcome that makes the best of both our points of view.
I am not inflexible. When I dropped out it was because there was
just no consensus. Now, I don't give a **ck if there's consensus
or not. The main thing is 1) does it work, ans 2) does it provide
what D programmers might expect in the context of the language
features and Phobos custom and practice.
Those who want something completely different are most welcome to
use our stuff and do it themselves.
Deal?
Steve

OK, can you give me a brief run-down on the changes you would like to
see/are working on. Then we can get together and agree on an outcome
that makes the best of both our points of view.
I am not inflexible. When I dropped out it was because there was just no
consensus. Now, I don't give a **ck if there's consensus or not. The
main thing is 1) does it work, ans 2) does it provide what D programmers
might expect in the context of the language features and Phobos custom
and practice.
Those who want something completely different are most welcome to use
our stuff and do it themselves.
Deal?

Is there some specific disagreement this is referring to, or just a
general "proposed ground rules" statement?

On a more specific topic, Nick S mentioned purging of result sets.
I have a mixed view of this. One half of me says "if you cant
present a SQL query that selects what you want, then put up with
the inefficiency of waiting for the thread to read through all
the stuff until it finds an EOF".
The other half wonders if there should be a connection pool, and
then situations like that could just switch to a new connection,
and leave the existing one at lower priority to clean up the
garbage.
But the latter is not systems programming approach.
Writing that down cleared my mind. The level we should aim at
should I think be just what is needed to exploit the capabilities
of the MySQL/MariaDB protocol version. The protocol is what it
is, and is unfriendly toward sloppy SQL.
Steve

This is great news. If you look at the simendsjo repo, there's a rewrite
in progress, but it's still missing some key features.
The rejectedsoftware repo is the one in production use.
Here's a TODO:
http://forum.dlang.org/post/zsfxoggzwkmqjzyxbwgc forum.dlang.org

FWIW, I've just tried running the tests.
In short, it seems to work fine on Windows 32-bit, although my MySQL
server breaks a few minor unittests.
Details:
- Server: MySQL version "5.0.91-community-nt" (probably getting old but,
meh, it's just for local testing) running on a Win7 64-bit box. I'm not
sure if the MySQL server itself is a 32-bit or 64-bit version (don't
recall, and the admin panel isn't telling me).
- Client 1: The same Win7 box, using DMD to compile a 32-bit exe.
- Client 2: Linux Mint 15, 32-bit VM (DMD again).
Everything behaved exactly the same between the two clients. Everything
passed except for a few asserts in the "information_schema" section.
There were two things that went wrong:
- For me, field.table was always empty string, on all 4 entries in the
field list (instead of "information_schema" as expected).
- For me, the first two entries in the field list had lengths of 192,
instead of 96 as expected.