Re: Frustration [Was: mysql binding/wrapper?]
As for mysqln, I merged jrogers patches and changed uint to size_t so it compiles on x64. You can look at it here: https://github.com/simendsjo/mysqln/tree/compile-on-recent-dmd It hasn't been tested beyond connecting to the database and fetching metadata yet. And my repository will go away very soon as I'll rather help with the original library (if Steve Teale comes back) or the one in vibe. Thanks for sharing the modified code. I was able to compile it without any issue and I am able to fetch the meta data. I will be testing more to run insert and select queries. But I found a bug in the code. If you don't specify the password for your test mySQL server then the mysql.d fails. It is always expecting a password and on empty password it throws the exception. file: mysql.d function: open [line 1415] I think when it calls _socket.send then it fails. So far other that this issue, it is working good and if it gets stable then certainly I will move forward with a project in D Language. I will be using the mongoDB and mySQL so this driver will be important for me, in fact for other's too as they mentioned in this thread. One question though, is it thread safe? Thanks for everyone's effort to make this driver work!
Re: Frustration [Was: mysql binding/wrapper?]
On Tue, 01 May 2012 04:04:01 +0200, Ary Manzana a...@esperanto.org.ar wrote: It's sad. I always want to give D a chance. And when I do I always bump into errors and inconveniences. (...) Every time I want to start coding in D, or helping some project, I stumble into all kind of troubles. I have the same feeling. I used D quite a lot around 1.007-1.0028, and every library broke with each release. And new bugs were introduced each release. It was a big PITA. It seems the situation has gotten a lot better, so I hope I'll be able to use D for a small project now. As for mysqln, I merged jrogers patches and changed uint to size_t so it compiles on x64. You can look at it here: https://github.com/simendsjo/mysqln/tree/compile-on-recent-dmd It hasn't been tested beyond connecting to the database and fetching metadata yet. And my repository will go away very soon as I'll rather help with the original library (if Steve Teale comes back) or the one in vibe.
Re: Frustration [Was: mysql binding/wrapper?]
On Tuesday, 1 May 2012 at 02:04:03 UTC, Ary Manzana wrote: On 5/1/12 2:44 AM, simendsjo wrote: On Mon, 30 Apr 2012 20:55:45 +0200, Ary Manzana a...@esperanto.org.ar wrote: Looking at the code of mysql.d I see a big switch with many cases like case 0x01: // TINYINT. But then there's the SQLType enum with those constants. Why the enum values are not used in the cases? (and also in other parts of the code?) It's not finished: http://www.britseyeview.com/software/mysqln/ Ah, I see. The last commit is 6 months old. I tried to compile mysql.d --- dmd -c mysql.d /usr/share/dmd/src/phobos/std/exception.d(492): Error: constructor mysql.MySQLException.this (string msg, string file, uint line) is not callable using argument types (string,string,ulong) /usr/share/dmd/src/phobos/std/exception.d(492): Error: cannot implicitly convert expression (line) of type ulong to uint mysql.d(105): Error: template instance std.exception.enforceEx!(MySQLException).enforceEx!(ulong) error instantiating (...) (and more...) --- It's sad. I always want to give D a chance. And when I do I always bump into errors and inconveniences. I thought, maybe the project is 6 months old, it's not compatible anymore with the current DMD (but my code really doesn't break at all with new Ruby versions, for example). I thought of trying to fix the error. Apparently I need to compile it with -m32 so that lengths of arrays are uint instead of ulong. --- dmd -c -m32 mysql.d mysql.d(4185): Error: cannot cast r.opIndex(cast(uint)j).get!(ulong) mysql.d(4201): Error: cannot cast r.opIndex(cast(uint)j).get!(ulong) mysql.d(4204): Error: cannot cast r.opIndex(cast(uint)j).get!(ulong) --- (What does it mean cannot cast? Give me the reason, please...) Or maybe instead of the flag the code is wrong and instead of uint it needs to be size_t. But I still get errors. Every time I want to start coding in D, or helping some project, I stumble into all kind of troubles. But I wonder... is this case in particular D's fault or the library's fault? (if the answer is the project is 6 months old, of course it won't compile then it's D's fault) Ah, finally, someone has found Steve Teale's batcave. It seems that you are not too far from having it compiled. If you end up succeeding, maybe you can propose him to update his file, so that we can benefit ? Looking at his code, it seems to me that he is very far from the original goal, which was to make a generic database driver. This one seems completely linked to MySQL and will need to be completely rewritten for Postgres. Am I wrong ?
Re: Frustration [Was: mysql binding/wrapper?]
On Tuesday, 1 May 2012 at 08:40:27 UTC, SomeDude wrote: On Tuesday, 1 May 2012 at 02:04:03 UTC, Ary Manzana wrote: On 5/1/12 2:44 AM, simendsjo wrote: On Mon, 30 Apr 2012 20:55:45 +0200, Ary Manzana a...@esperanto.org.ar wrote: Looking at the code of mysql.d I see a big switch with many cases like case 0x01: // TINYINT. But then there's the SQLType enum with those constants. Why the enum values are not used in the cases? (and also in other parts of the code?) It's not finished: http://www.britseyeview.com/software/mysqln/ Ah, I see. The last commit is 6 months old. I tried to compile mysql.d --- dmd -c mysql.d /usr/share/dmd/src/phobos/std/exception.d(492): Error: constructor mysql.MySQLException.this (string msg, string file, uint line) is not callable using argument types (string,string,ulong) /usr/share/dmd/src/phobos/std/exception.d(492): Error: cannot implicitly convert expression (line) of type ulong to uint mysql.d(105): Error: template instance std.exception.enforceEx!(MySQLException).enforceEx!(ulong) error instantiating (...) (and more...) --- It's sad. I always want to give D a chance. And when I do I always bump into errors and inconveniences. I thought, maybe the project is 6 months old, it's not compatible anymore with the current DMD (but my code really doesn't break at all with new Ruby versions, for example). I thought of trying to fix the error. Apparently I need to compile it with -m32 so that lengths of arrays are uint instead of ulong. --- dmd -c -m32 mysql.d mysql.d(4185): Error: cannot cast r.opIndex(cast(uint)j).get!(ulong) mysql.d(4201): Error: cannot cast r.opIndex(cast(uint)j).get!(ulong) mysql.d(4204): Error: cannot cast r.opIndex(cast(uint)j).get!(ulong) --- (What does it mean cannot cast? Give me the reason, please...) Or maybe instead of the flag the code is wrong and instead of uint it needs to be size_t. But I still get errors. Every time I want to start coding in D, or helping some project, I stumble into all kind of troubles. But I wonder... is this case in particular D's fault or the library's fault? (if the answer is the project is 6 months old, of course it won't compile then it's D's fault) Ah, finally, someone has found Steve Teale's batcave. It seems that you are not too far from having it compiled. If you end up succeeding, maybe you can propose him to update his file, so that we can benefit ? Looking at his code, it seems to me that he is very far from the original goal, which was to make a generic database driver. This one seems completely linked to MySQL and will need to be completely rewritten for Postgres. Am I wrong ? OK, never mind, I should have read before jumping in. I asked where this code was a few weeks ago, and got no answer, so I'm quite glad that this comes up. I haven't tested the driver, but at least, it compiles fine.
Frustration [Was: mysql binding/wrapper?]
On 5/1/12 2:44 AM, simendsjo wrote: On Mon, 30 Apr 2012 20:55:45 +0200, Ary Manzana a...@esperanto.org.ar wrote: Looking at the code of mysql.d I see a big switch with many cases like case 0x01: // TINYINT. But then there's the SQLType enum with those constants. Why the enum values are not used in the cases? (and also in other parts of the code?) It's not finished: http://www.britseyeview.com/software/mysqln/ Ah, I see. The last commit is 6 months old. I tried to compile mysql.d --- dmd -c mysql.d /usr/share/dmd/src/phobos/std/exception.d(492): Error: constructor mysql.MySQLException.this (string msg, string file, uint line) is not callable using argument types (string,string,ulong) /usr/share/dmd/src/phobos/std/exception.d(492): Error: cannot implicitly convert expression (line) of type ulong to uint mysql.d(105): Error: template instance std.exception.enforceEx!(MySQLException).enforceEx!(ulong) error instantiating (...) (and more...) --- It's sad. I always want to give D a chance. And when I do I always bump into errors and inconveniences. I thought, maybe the project is 6 months old, it's not compatible anymore with the current DMD (but my code really doesn't break at all with new Ruby versions, for example). I thought of trying to fix the error. Apparently I need to compile it with -m32 so that lengths of arrays are uint instead of ulong. --- dmd -c -m32 mysql.d mysql.d(4185): Error: cannot cast r.opIndex(cast(uint)j).get!(ulong) mysql.d(4201): Error: cannot cast r.opIndex(cast(uint)j).get!(ulong) mysql.d(4204): Error: cannot cast r.opIndex(cast(uint)j).get!(ulong) --- (What does it mean cannot cast? Give me the reason, please...) Or maybe instead of the flag the code is wrong and instead of uint it needs to be size_t. But I still get errors. Every time I want to start coding in D, or helping some project, I stumble into all kind of troubles. But I wonder... is this case in particular D's fault or the library's fault? (if the answer is the project is 6 months old, of course it won't compile then it's D's fault)
