Re: RFC: std.json sucessor
Yes, no decimal point + no exponent would work without overhead to detect integers, but that wouldn't solve the proposed automatic long->double overflow, which is what I meant. My current idea is to default to double and optionally support any of long, BigInt and "Decimal" (BigInt+exponent), where integer overflow only works for long->BigInt. Ah I see. I have to say, if you are going to treat integers and floating point numbers differently, then you should store them differently. long should be used to store integers, double for floating point numbers. 64 bit signed integer (long) is a totally reasonable limitation for integers, but even that would lose precision stored as a double as you are proposing (if I'm understanding right). I don't think BigInt needs to be brought into this at all really. In the case of integers met in the parser which are too large/small to fit in long, give an error IMO. Such integers should be (and are by other libs IIRC) serialised in the form "1.234e-123" to force double parsing, perhaps losing precision at that stage rather than invisibly inside the library. Size of JSON numbers is implementation defined and the whole thing shouldn't be degraded in both performance and usability to cover JSON serialisers who go beyond common native number types. Of course, you are free to do whatever you like :)
Re: RFC: std.json sucessor
On Friday, 22 August 2014 at 17:45:03 UTC, Sönke Ludwig wrote: Am 22.08.2014 19:27, schrieb "Marc Schütz" ": On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote: Am 22.08.2014 18:31, schrieb Christian Manning: It would be nice to have integers treated separately to doubles. I know it makes the number parsing simpler to just treat everything as double, but still, it could be annoying when you expect an integer type. That's how I've done it for vibe.data.json, too. For the new implementation, I've just used the number parsing routine from Andrei's std.jgrandson module. Does anybody have reservations about representing integers as "long" instead? It should automatically fall back to double on overflow. Maybe even use BigInt if applicable? I guess BigInt + exponent would be the only lossless way to represent any JSON number. That could then be converted to any desired smaller type as required. But checking for overflow during number parsing would definitely have an impact on parsing speed, as well as using a BigInt of course, so the question is how we want set up the trade off here (or if there is another way that is overhead-free). You could check for a decimal point and a 0 at the front (excluding possible - sign), either would indicate a double, making the reasonable assumption that anything else will fit in a long.
Re: RFC: std.json sucessor
It would be nice to have integers treated separately to doubles. I know it makes the number parsing simpler to just treat everything as double, but still, it could be annoying when you expect an integer type. I'd also like to see some benchmarks, particularly against some of the high performance C++ parsers, i.e. rapidjson, gason, sajson. Or even some of the "not bad" performance parsers with better APIs, i.e. QJsonDocument, jsoncpp and jsoncons (slow but perhaps comparable interface to this proposal?).
Re: Qt bindings for D
On Sunday, 13 October 2013 at 16:20:33 UTC, David Nadlinger wrote: On Sunday, 13 October 2013 at 12:39:55 UTC, Abdulhaq wrote: […] Unfortunately the wrapping is based on QtJambi, which is now dead, but anyway it's easy with hindsight isn't it. Is anyone else interested and can anyone help me with polishing it? […] I'm very interested in having solid Qt bindings available, and I worked on QtD a while back. One thing I've been wondering about is whether keeping the QtJambi-based generator makes sense or if it would be easier start anew from some of the more active binding projects… David Perhaps KDE's SMOKE? http://techbase.kde.org/Development/Languages/Smoke
Re: DQuick a GUI Library (prototype)
On Tuesday, 20 August 2013 at 21:22:48 UTC, Flamaros wrote: I want to share a short presentation of the project I am working on with friends. It's a prototype of a GUI library written in D. This pdf contains our vision of what the project would be. Samples are directly extracted from our prototype and works. We are not able to share more than this presentation for the moment because a lot of things are missing and it's plenty of bugs. The development is really slow, so don't expect to see a real demonstration a day. The link : https://docs.google.com/file/d/0BygGiQfhIcvGOGlrWlBFNWNBQ3M/edit?usp=sharing PS : Download it for a better quality This is great! Will check this out ASAP I think. I migrated a Qt Widgets project to QML/QtQuick and I've quite enjoyed working with it, but having something with similar goals in D will bring me back to the language most probably. In fact, that project was originally written in D but I became frustrated with some things at the time (lack of shared libs for plugins, GUI, etc.), so it was rewritten in c++11. Although I don't think I shall be rewriting its current state in D (the thought of porting 15k+ lines by myself is rather daunting ;) Chris
Re: D2 Library Porters
On Wednesday, 4 July 2012 at 00:35:07 UTC, Jonathan M Davis wrote: On Wednesday, July 04, 2012 00:42:22 Iain Buclaw wrote: On 3 July 2012 17:39, Jonathan M Davis wrote: > On Tuesday, July 03, 2012 17:05:52 Iain Buclaw wrote: >> Also, I say you should drop Ubuntu in favour of Debian. :o) > > No, no, no. Use Arch! ;) > > - Jonathan M Davis Just so long as it isn't Gentoo. :o) Afterall, out of all of the linux distros out there, I would say that gentoo takes the least time to mess around... LOL. I did use Gentoo for a while, but I got sick of things breaking on updates. Arch provides most of the benefits that Gentoo does but defaults to binary packages while letting you build them from source if you want to rather than making _everything_ be built from source. And surprisingly, Arch seems to do a better job of providing bleeding edge packages quickly than Gentoo does (at least for the packages that I care about). I found this to be a downside to Arch as there were a few occasions (even in the short time I used it) when breakage occurred, whereas the bleeding edge in Gentoo requires explicit "unmasking". Having been running ~amd64 (unstable) Gentoo for ~6 years on several of my systems, I've found it to be rock solid through all its neat little admin tools, if things don't get taken care of by themselves. Gentoo isn't just portage any more. Arch is little more than pacman. But Linux distros are one of those things that you can argue about endlessly. To each their own I guess. Indeed :)
Re: Is the D community lacking development tools?
On Tuesday, 22 May 2012 at 16:23:46 UTC, Kevin Cox wrote: On May 22, 2012 12:13 PM, "s" wrote: +1 for a GUI lib, which is in sync with DMD releases. Is there any way to bind Qt without the dreaded moc and friends? Because that would give you a cross platform solution without too much work. Surely much of the functionality moc provides can be replaced by proper D features?
Re: [OT] Windows users: Are you happy with git?
On Friday, 18 May 2012 at 07:58:26 UTC, Lars T. Kyllingstad wrote: I remember back when we were considering whether to move DMD, Phobos and druntime from SVN on DSource to Git on GitHub, there were some concerns about using Git on Windows. People claimed that Git was a very Linux-centric tool, and that Windows support was buggy at best. Still, we made the switch, and I haven't really registered that many complaints since. So now I'm curious: Windows users, have you just resigned, or did Git actually turn out to work well on Windows? Specifically, is it usable from the CMD command line, and are graphical front-ends such as TortoiseGit any good? (I know running it through Cygwin works well, but that doesn't count.) -Lars Git-Extensions works pretty well, especially with its Visual Studio + PuTTY integration. It uses msysgit under the bonnet IIRC
Re: Mono-D@GSoC - Mentor needed
On Tuesday, 20 March 2012 at 13:58:51 UTC, alex wrote: Surely debugging support on platforms other than linux is much more important than any of these things you have listed. These things may be nice, but absolutely unnecessary. Integrated debugging is a must. Personally I don't want to waste time with scanning tons of API documentation just to find out what parameters my called phobos function has got. In larger projects, with large amounts of classes and methods it'll be hard to find everything in a short time. So I doubt that code completion is that unnecessary. Debugging is important, for sure, but without having abstract access to the debugged code it'll be quite impossible to e.g. read out memory and to know what this memory represents. Just imagine I was given a pointer address but don't know that it's a string[]? And now imagine you want to debug mixed-in code? I guess you won't be able to do this without knowing what your mixin code finally looks like :) Yeh I can see its utility but I would sooner have some debugging support for non-mixed-in code.
Re: Mono-D@GSoC - Mentor needed
On Tuesday, 20 March 2012 at 13:24:40 UTC, Manu wrote: On 20 March 2012 14:34, Christian Manning wrote: On Monday, 19 March 2012 at 21:18:02 UTC, alex wrote: Hi everyone, It may sounds a bit annoying because I already was asking everywhere in the IRC channels but still had no success - Is there anyone who wants to be my GSoC mentor for the Mono-D project? In the case you don't know what Mono-D is all about: It's about creating a D language binding for MonoDevelop. ( http://monodevelop.com/**Screenshots <http://monodevelop.com/Screenshots>) There are couple of things that are already implemented - like a relatively nice but fast code completion, build support, small refactoring operations like they can be used in every modern IDE and few other things which will make application development with D a lot easier - especially for D newbies. (Debugging is also available via gdb on Linux systems - so yeah, why not? :)) The main road map for this summer of code is available under https://github.com/aBothe/**Mono-D/blob/master/**MonoDevelop.DBinding/** Remaining%20features.txt<https://github.com/aBothe/Mono-D/blob/master/MonoDevelop.DBinding/Remaining%20features.txt> Surely debugging support on platforms other than linux is much more important than any of these things you have listed. These things may be nice, but absolutely unnecessary. Integrated debugging is a must. Debugging is great with VisualD in Windows. It's about the only thing VisualD does really well yet, although the rest of the experience is starting to come together. Needs a lot more polish in general. I actually found myself using Mono-D for the nice completion and VisualD for debugging, which is a total pain and probably more effort than its worth :)
Re: Mono-D@GSoC - Mentor needed
On Monday, 19 March 2012 at 21:18:02 UTC, alex wrote: Hi everyone, It may sounds a bit annoying because I already was asking everywhere in the IRC channels but still had no success - Is there anyone who wants to be my GSoC mentor for the Mono-D project? In the case you don't know what Mono-D is all about: It's about creating a D language binding for MonoDevelop. (http://monodevelop.com/Screenshots ) There are couple of things that are already implemented - like a relatively nice but fast code completion, build support, small refactoring operations like they can be used in every modern IDE and few other things which will make application development with D a lot easier - especially for D newbies. (Debugging is also available via gdb on Linux systems - so yeah, why not? :)) The main road map for this summer of code is available under https://github.com/aBothe/Mono-D/blob/master/MonoDevelop.DBinding/Remaining%20features.txt Surely debugging support on platforms other than linux is much more important than any of these things you have listed. These things may be nice, but absolutely unnecessary. Integrated debugging is a must.
Re: How about colors and terminal graphics in std.format?
On Tuesday, 13 March 2012 at 16:05:31 UTC, Jacob Carlborg wrote: On 2012-03-13 13:31, Christian Manning wrote: On Tuesday, 13 March 2012 at 07:45:19 UTC, Jacob Carlborg wrote: On 2012-03-13 02:36, Christian Manning wrote: It would be great if an std.terminal contained general stuff for manipulating/querying a terminal portably, as well as colour output, eg. get terminal size, move cursor around, erase line... just things to help with building UIs, progress bars, etc. that are easy to use. I actually have a library for this written in C++, somewhere. Any chance of a release? :) I'd like to have a stab at porting it to D, when I have time, if you aren't already planning to. I have been thinking about porting it to D from time to time. I can see what I can do :) Looking forward to it!
Re: How about colors and terminal graphics in std.format?
On Tuesday, 13 March 2012 at 07:45:19 UTC, Jacob Carlborg wrote: On 2012-03-13 02:36, Christian Manning wrote: It would be great if an std.terminal contained general stuff for manipulating/querying a terminal portably, as well as colour output, eg. get terminal size, move cursor around, erase line... just things to help with building UIs, progress bars, etc. that are easy to use. I actually have a library for this written in C++, somewhere. Any chance of a release? :) I'd like to have a stab at porting it to D, when I have time, if you aren't already planning to.
Re: How about colors and terminal graphics in std.format?
On Tuesday, 13 March 2012 at 01:53:11 UTC, Chad J wrote: On 03/12/2012 09:36 PM, Christian Manning wrote: On Monday, 12 March 2012 at 09:51:08 UTC, Jacob Carlborg wrote: I think it would nice to have, but not in std.format. std.terminal or similar would be better. It would be great if an std.terminal contained general stuff for manipulating/querying a terminal portably, as well as colour output, eg. get terminal size, move cursor around, erase line... just things to help with building UIs, progress bars, etc. that are easy to use. Although this would be cool, it is out of the scope of what I am willing to spend time on. That's fair enough, I was mostly making a point that both things are closely related and would make sense in a common module.
Re: How about colors and terminal graphics in std.format?
On Monday, 12 March 2012 at 09:51:08 UTC, Jacob Carlborg wrote: On 2012-03-12 03:16, Chad J wrote: I remember doing colored terminal output in Python. It was pretty nifty, and allows for some slick CLI design. I think D can do better by putting it in the standard library. I was thinking something along the lines of this: http://www.chadjoan.com/d/dmd.2.058/html/d/phobos/std_format.html I figure it would probably be easy to get some of the basics down. More advanced stuff would probably involve messing with terminfo or . Windows' (terribly bad) command prompt can have some of these capabilities implemented too, but in a roundabout way because Windows defines API functions that need to be called to affect terminal graphics and coloring. I figure that would require the help of the I/O routines if I were to work on that. If there's interest, I might take a stab at it. So, would this sort of thing make it in? I think it would nice to have, but not in std.format. std.terminal or similar would be better. It would be great if an std.terminal contained general stuff for manipulating/querying a terminal portably, as well as colour output, eg. get terminal size, move cursor around, erase line... just things to help with building UIs, progress bars, etc. that are easy to use.
Re: dmd/druntime/phobos makefile horror
On Friday, 30 December 2011 at 00:34:13 UTC, Trass3r wrote: The reason is druntime doesn't build separate libs like phobos does. A quick and dirty patch would be: diff --git a/posix.mak b/posix.mak index 5fd7fee..9ed2004 100644 --- a/posix.mak +++ b/posix.mak @@ -32,9 +32,9 @@ UDFLAGS=-m$(MODEL) -O -release -nofloat -w -d -Isrc -Iimport -property CFLAGS=-m$(MODEL) -O -OBJDIR=obj +OBJDIR=obj/$(MODEL) DRUNTIME_BASE=druntime -DRUNTIME=lib/lib$(DRUNTIME_BASE).a +DRUNTIME=lib/$(MODEL)/lib$(DRUNTIME_BASE).a DOCFMT= I've been using a similar patch for a while, originally from https://bugs.gentoo.org/show_bug.cgi?id=355527 but less of those changes are needed now so it's been stripped down a lot. Would be nice to have this upstream so a proper multilib d toolchain can be built out of the box --- a/src/druntime/posix.mak2011-06-25 01:39:28.0 +0100 +++ b/src/druntime/posix.mak2011-07-13 16:27:21.307999841 +0100 @@ -25,16 +25,16 @@ DOCDIR=doc IMPDIR=import -MODEL=32 +MODEL?=32 DFLAGS=-m$(MODEL) -O -release -inline -nofloat -w -d -Isrc -Iimport -property UDFLAGS=-m$(MODEL) -O -release -nofloat -w -d -Isrc -Iimport -property CFLAGS=-m$(MODEL) -O -OBJDIR=obj +OBJDIR=obj$(MODEL) DRUNTIME_BASE=druntime -DRUNTIME=lib/lib$(DRUNTIME_BASE).a +DRUNTIME=lib$(MODEL)/lib$(DRUNTIME_BASE).a DOCFMT= --- a/src/phobos/posix.mak 2011-07-10 21:19:30.0 +0100 +++ b/src/phobos/posix.mak 2011-07-13 16:27:11.585999804 +0100 @@ -75,7 +75,7 @@ # Set DRUNTIME name and full path ifeq (,$(findstring win,$(OS))) - DRUNTIME = $(DRUNTIME_PATH)/lib/libdruntime.a + DRUNTIME = $(DRUNTIME_PATH)/lib$(MODEL)/libdruntime.a else DRUNTIME = $(DRUNTIME_PATH)/lib/druntime.lib endif
Re: ldc and gdc
On 06/08/2011 12:02, Marco Leise wrote: Am 06.08.2011, 11:16 Uhr, schrieb Jacob Carlborg : On 2011-08-05 11:53, Marco Leise wrote: I have noticed DVM around. The situation on Gentoo is typically that when there are different versions of the same package, that can be installed in different 'slots'. A dependency of these packages is a control file for eselect, a tool to switch between the currently active implementation (OpenJDK, Sun Java, ...), package version (boost) and several other system configuration options. 'python' for example ends up as a symlink to either python2.7 or python3.1 and there are corresponding directory names for the libraries. It would be ideal if dmd was a symlink to either dmd1 or dmd2 and they would both use a separate dmd.conf. But since the source code is available for a while now that should be easy to make possible. I have never used DVM, but I imagine it works like Maven or the Eclipse updater. So it would download precompiled compilers and libraries into the user's home directory, right? With Gentoo being a source distribution it is usually avoided to download binaries from the internet so I guess DVM would be one of two options to install D compilers on Gentoo. The difference in usage would be like this for an installation: dvm: "dvm install 1.068" portage: "emerge =dmd-1.068" and this for setting the system-wide default compiler: dvm use 1.068 -d eselect dmd set dmd1 Granted, the portage version would only allow one dmd 1 compiler to be installed at a time, but that is ok for most users. I guess in theory there could even be slots for every single release of dmd. This is already done for Boost and automake in practice (with major revisions). OTOH there is no option to set the compiler for the current shell, but maybe "export DMD=dmd1", "make posix.mak" should work. It seems like DVM and portage/eselect are similar. I think it's a huge advantage to be able to have multiple versions of DMD installed. I use both D1 and D2, (mostly D1). I also think it's especially useful when there's almost always something that breaks in a new release of DMD. Then you can easily go back to an older version if you need to. BTW, Nick Sabalausky is working on making it possible to install DMD from github via DVM. Even if this begins to sound childish, I have to add for completeness sake that in portage you have the version number to indicate a build from online source repositories. So dmd- would be the Github version. The source tree is cloned into /usr/portage/distfiles/git-src/ and updated each time the package is being reinstalled. Additional tools like 'smart-live-rebuild' have emerged to make rebuilding changed repositories easier. emerge -1 @live-rebuild is very handy for this if you're on the portage alphas.
Re: Byte Order Swapping Function
Christian Manning wrote:
> How about this?:
>
> private template Eqsize(T) {
> static if (T.sizeof == 4) {
> alias uint S;
> }
> else static if (T.sizeof == 8) {
> alias ulong S;
> }
> }
>
> private union IntFloat {
> uint _int;
> float _float;
> }
>
> private union IntDouble {
> ulong _long;
> double _double;
> }
>
> T byteSwap(T)(T val) if (isIntegral!T || isSomeChar!T) {
> static if (T.sizeof == 2) {
> return cast(T) ((cast(ushort) val >> 8) | (cast(ushort) val <<
> 8));
> }
> else static if (T.sizeof == 4) {
> return cast(T) bswap(cast(uint) val);
> }
> else static if (T.sizeof == 8) {
> return cast(T)bswap(cast(uint) (val >> 32)) |
> (cast(T)bswap(cast(uint) val) << 32);
> }
> }
>
> Eqsize!(T).S byteSwap(T)(T val) if (isFloatingPoint!T) {
> static if (T.sizeof == 4) {
> IntFloat _if;
> _if._float = val;
> _if._int = bswap(_if._int);
> return _if._int;
> }
> else static if (T.sizeof == 8) {
> IntDouble id;
> id._double = val;
> id._long = byteSwap(id._long);
> return id._long;
> }
> }
>
> unittest {
> float a = 45.17249;
> IntFloat _if;
> _if._int = byteSwap(byteSwap(a));
> assert(a is _if._float);
> assert(a == _if._float);
>
> double b = 835.48502;
> IntDouble id;
> id._long = cast(ulong) byteSwap(byteSwap(b));
> assert(b is id._double);
> assert(b == id._double);
>
> long c = 0x0102040880402010;
> long d = 0x1020408008040201;
> assert(byteSwap(c) == d);
> assert(byteSwap(c) is d);
> assert(byteSwap(byteSwap(c)) == c);
> assert(byteSwap(byteSwap(c)) is c);
>
> assert(byteSwap(cast(short) -45) == -11265);
> assert(byteSwap(cast(short) -45) is -11265);
>
> assert(byteSwap(0x18244281) == 0x81422418);
> assert(byteSwap(0x18244281) is 0x81422418);
> }
>
> T bigEndianToNative(T)(T val) if (isNumeric!T || isSomeChar!T) {
> static if (endian == Endian.BigEndian) {
> return val;
> }
> else {
> return byteSwap(val);
> }
> }
>
> alias bigEndianToNative nativeToBigEndian;
>
> T littleEndianToNative(T)(T val) if (isNumeric!T || isSomeChar!T) {
> static if (endian == Endian.LittleEndian) {
> return val;
> }
> else {
> return byteSwap(val);
> }
> }
>
> alias littleEndianToNative nativeToLittleEndian;
Forgot to change bigEndianToNative and littleEndianToNative, woops. You get
the idea though.
Re: Byte Order Swapping Function
How about this?:
private template Eqsize(T) {
static if (T.sizeof == 4) {
alias uint S;
}
else static if (T.sizeof == 8) {
alias ulong S;
}
}
private union IntFloat {
uint _int;
float _float;
}
private union IntDouble {
ulong _long;
double _double;
}
T byteSwap(T)(T val) if (isIntegral!T || isSomeChar!T) {
static if (T.sizeof == 2) {
return cast(T) ((cast(ushort) val >> 8) | (cast(ushort) val << 8));
}
else static if (T.sizeof == 4) {
return cast(T) bswap(cast(uint) val);
}
else static if (T.sizeof == 8) {
return cast(T)bswap(cast(uint) (val >> 32)) |
(cast(T)bswap(cast(uint) val) << 32);
}
}
Eqsize!(T).S byteSwap(T)(T val) if (isFloatingPoint!T) {
static if (T.sizeof == 4) {
IntFloat _if;
_if._float = val;
_if._int = bswap(_if._int);
return _if._int;
}
else static if (T.sizeof == 8) {
IntDouble id;
id._double = val;
id._long = byteSwap(id._long);
return id._long;
}
}
unittest {
float a = 45.17249;
IntFloat _if;
_if._int = byteSwap(byteSwap(a));
assert(a is _if._float);
assert(a == _if._float);
double b = 835.48502;
IntDouble id;
id._long = cast(ulong) byteSwap(byteSwap(b));
assert(b is id._double);
assert(b == id._double);
long c = 0x0102040880402010;
long d = 0x1020408008040201;
assert(byteSwap(c) == d);
assert(byteSwap(c) is d);
assert(byteSwap(byteSwap(c)) == c);
assert(byteSwap(byteSwap(c)) is c);
assert(byteSwap(cast(short) -45) == -11265);
assert(byteSwap(cast(short) -45) is -11265);
assert(byteSwap(0x18244281) == 0x81422418);
assert(byteSwap(0x18244281) is 0x81422418);
}
T bigEndianToNative(T)(T val) if (isNumeric!T || isSomeChar!T) {
static if (endian == Endian.BigEndian) {
return val;
}
else {
return byteSwap(val);
}
}
alias bigEndianToNative nativeToBigEndian;
T littleEndianToNative(T)(T val) if (isNumeric!T || isSomeChar!T) {
static if (endian == Endian.LittleEndian) {
return val;
}
else {
return byteSwap(val);
}
}
alias littleEndianToNative nativeToLittleEndian;
Re: ID3 library wrapper (taglib, id3lib, anything)
Walter Strom wrote:
> There are no ID3 (audio tags, 'artist', 'title' et al editing) projects
> for D. There was one called id3, but it was halted 3 years ago at alpha /
> ID3v1.
>
> And there are mature Taglib & Id3lib, both written C++, but both with C
> wrapper options.
>
> I've tried to make a D wrapper around Taglib, but all it outputs for now
> are the words "You are a shameful idiot, mister", which I put into the
> failure condition without being aware of how much it'd hurt after a
> hundred runs.
>
> That C wrapper looks easy — 3 same kind struct typedefs, 2 same kind enum
> typedefs, and a bunch of simple funcs that only seem to require a type
> names replacement and extern (C).
>
> I've tried, but surely not doing it right:
>
> Original C: typedef struct { int foo; } Bar;
> I tried:struct Bar { int foo; }
> and also: struct Wrp { struct { int foo; } } alias Wrp Bar;
>
> Original C: typedef enum { foo, etc } Bar;
> I tried:enum Bar { foo, etc };
> and also: enum { foo, etc } alias int Bar;
>
> In addition to my noobish translations, I might also be using it all
> wrong, as I've discovered D a week ago :(.
>
> It would be so amazing if there was someone in the group who wants / finds
> potentially useful ID3 editing, but isn't a D virgin. It's a pity Taglib
> has simple bindings from C# to Ruby, and the guy who's doing D's is being
> insulted by his own code.
>
> If anyone has guts: http://developer.kde.org/~wheeler/taglib.html
> The c wrapper: bindings/c/tag_c.h
> The example using it: examples/tagreader_c.c
>
> Just to make it clear, it's a mere hope there is someone interested, but
> more mature than me, and is not in any way a request-like stuff.
>
> Long live D,
> Walt
I've actually been working on an audio metadata library from scratch in D!
Right now it doesn't support ID3 of any kind, but that will probably be
coming soon. The thing is I don't really want to add support for loads of
metadata formats at the moment because I keep changing things (quite
drastically) and it would be way too much effort to modify all these
formats. Once I get it more stable I can add support for other formats.
Before you ask, I haven't released this anywhere yet :)
Chris
Re: Byte Order Swapping Function
Andrew Wiley wrote: > On Sat, Jul 16, 2011 at 6:21 AM, Christian Manning > wrote: > >> Jonathan M Davis wrote: >> >> > On Thursday 14 July 2011 06:27:47 Andrei Alexandrescu wrote: >> >> On 7/14/11 5:51 AM, Regan Heath wrote: >> >> > That's my point. I need 8/16/32/64/128 bit versions and it really >> would >> >> > be better if there were general variants. My version are less than >> >> > optimal, but do use intrinsics where possible. Someone else can do a >> >> > far better job than I, and it really should be done once, by that >> >> > person. Surely we have the infrastructure for someone to add this to >> >> > phobos? If something this simple can't or won't be done, what hope >> >> > do we have!? >> >> >> >> I think we should have these functions in std.bitmanip: >> >> >> >> T toBigEndian(T)(T val) if (isArithmetic!T || isSomeChar!T); >> >> T toLittleEndian(T)(T val) if (isArithmetic!T || isSomeChar!T); >> >> T bigEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T); >> >> T littleEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T); >> >> >> >> That means all characters, all integers, and all floating point >> >> numbers. The implementations would opportunistically use intrinsics >> >> and other specialized means. >> >> >> >> The documentation should specify the relationship to htonl and ntohl. >> >> >> >> If there's a need for converting endianness of larger buffers, we >> >> might add: >> >> >> >> ubyte[] toBigEndian(ubyte[] val); >> >> ubyte[] toLittleEndian(ubyte[] val); >> >> ubyte[] bigEndianToNative(ubyte[] val); >> >> ubyte[] littleEndianToNative(ubyte[] val); >> >> >> >> They'd use std.algorithm.reverse internally as needed. >> >> >> >> It's a sweet piece of work. Anyone have the time to prepare a pull >> >> request? >> > >> > I decided to take a crack at it, and it seems to be going pretty well, >> > except that I can't seem to get the floating point values right. >> > Somehow, when I compare a floating point value with the same value >> > except that >> it's >> > had its endianness swapped twice, they return true for is but false for >> > ==, which makes absolutely no sense to me. There's obviously either >> > something that I don't understand about floating point values (or the >> > relationship between is and ==) or a bug in dmd. It'd be one thing if I >> > couldn't get the values to reverse properly, but when they're equal >> > according to is but not ==, I have no idea how that could even be >> > possible. >> > >> > - Jonathan M Davis >> >> I've managed to get floating points working with unions. How are you >> doing it? Maybe you're triggering a bug somewhere >> > > After you swap it, do you return the result as a double or as a long? I just saw your other post about this, but I'm unsure whether it's really necessary to return the long. Under what circumstance would the double become invalid? Ie. what sequence of the 64 bits is invalid?
Re: Byte Order Swapping Function
Andrew Wiley wrote: > On Sat, Jul 16, 2011 at 6:21 AM, Christian Manning > wrote: > >> Jonathan M Davis wrote: >> >> > On Thursday 14 July 2011 06:27:47 Andrei Alexandrescu wrote: >> >> On 7/14/11 5:51 AM, Regan Heath wrote: >> >> > That's my point. I need 8/16/32/64/128 bit versions and it really >> would >> >> > be better if there were general variants. My version are less than >> >> > optimal, but do use intrinsics where possible. Someone else can do a >> >> > far better job than I, and it really should be done once, by that >> >> > person. Surely we have the infrastructure for someone to add this to >> >> > phobos? If something this simple can't or won't be done, what hope >> >> > do we have!? >> >> >> >> I think we should have these functions in std.bitmanip: >> >> >> >> T toBigEndian(T)(T val) if (isArithmetic!T || isSomeChar!T); >> >> T toLittleEndian(T)(T val) if (isArithmetic!T || isSomeChar!T); >> >> T bigEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T); >> >> T littleEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T); >> >> >> >> That means all characters, all integers, and all floating point >> >> numbers. The implementations would opportunistically use intrinsics >> >> and other specialized means. >> >> >> >> The documentation should specify the relationship to htonl and ntohl. >> >> >> >> If there's a need for converting endianness of larger buffers, we >> >> might add: >> >> >> >> ubyte[] toBigEndian(ubyte[] val); >> >> ubyte[] toLittleEndian(ubyte[] val); >> >> ubyte[] bigEndianToNative(ubyte[] val); >> >> ubyte[] littleEndianToNative(ubyte[] val); >> >> >> >> They'd use std.algorithm.reverse internally as needed. >> >> >> >> It's a sweet piece of work. Anyone have the time to prepare a pull >> >> request? >> > >> > I decided to take a crack at it, and it seems to be going pretty well, >> > except that I can't seem to get the floating point values right. >> > Somehow, when I compare a floating point value with the same value >> > except that >> it's >> > had its endianness swapped twice, they return true for is but false for >> > ==, which makes absolutely no sense to me. There's obviously either >> > something that I don't understand about floating point values (or the >> > relationship between is and ==) or a bug in dmd. It'd be one thing if I >> > couldn't get the values to reverse properly, but when they're equal >> > according to is but not ==, I have no idea how that could even be >> > possible. >> > >> > - Jonathan M Davis >> >> I've managed to get floating points working with unions. How are you >> doing it? Maybe you're triggering a bug somewhere >> > > After you swap it, do you return the result as a double or as a long? I return the same type as I was given as input.
Re: Byte Order Swapping Function
Jonathan M Davis wrote: > On Thursday 14 July 2011 06:27:47 Andrei Alexandrescu wrote: >> On 7/14/11 5:51 AM, Regan Heath wrote: >> > That's my point. I need 8/16/32/64/128 bit versions and it really would >> > be better if there were general variants. My version are less than >> > optimal, but do use intrinsics where possible. Someone else can do a >> > far better job than I, and it really should be done once, by that >> > person. Surely we have the infrastructure for someone to add this to >> > phobos? If something this simple can't or won't be done, what hope do >> > we have!? >> >> I think we should have these functions in std.bitmanip: >> >> T toBigEndian(T)(T val) if (isArithmetic!T || isSomeChar!T); >> T toLittleEndian(T)(T val) if (isArithmetic!T || isSomeChar!T); >> T bigEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T); >> T littleEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T); >> >> That means all characters, all integers, and all floating point numbers. >> The implementations would opportunistically use intrinsics and other >> specialized means. >> >> The documentation should specify the relationship to htonl and ntohl. >> >> If there's a need for converting endianness of larger buffers, we might >> add: >> >> ubyte[] toBigEndian(ubyte[] val); >> ubyte[] toLittleEndian(ubyte[] val); >> ubyte[] bigEndianToNative(ubyte[] val); >> ubyte[] littleEndianToNative(ubyte[] val); >> >> They'd use std.algorithm.reverse internally as needed. >> >> It's a sweet piece of work. Anyone have the time to prepare a pull >> request? > > I decided to take a crack at it, and it seems to be going pretty well, > except that I can't seem to get the floating point values right. Somehow, > when I compare a floating point value with the same value except that it's > had its endianness swapped twice, they return true for is but false for > ==, which makes absolutely no sense to me. There's obviously either > something that I don't understand about floating point values (or the > relationship between is and ==) or a bug in dmd. It'd be one thing if I > couldn't get the values to reverse properly, but when they're equal > according to is but not ==, I have no idea how that could even be > possible. > > - Jonathan M Davis I've managed to get floating points working with unions. How are you doing it? Maybe you're triggering a bug somewhere
Re: Byte Order Swapping Function
Christian Manning wrote:
> Jonathan M Davis wrote:
>
>> On 2011-07-15 14:23, Christian Manning wrote:
>>> Andrei Alexandrescu wrote:
>>> > On 7/14/11 5:51 AM, Regan Heath wrote:
>>> >> That's my point. I need 8/16/32/64/128 bit versions and it really
>>> >> would be better if there were general variants. My version are less
>>> >> than optimal, but do use intrinsics where possible. Someone else can
>>> >> do a far better job than I, and it really should be done once, by
>>> >> that person. Surely we have the infrastructure for someone to add
>>> >> this to phobos? If something this simple can't or won't be done, what
>>> >> hope do we have!?
>>> >
>>> > I think we should have these functions in std.bitmanip:
>>> >
>>> > T toBigEndian(T)(T val) if (isArithmetic!T || isSomeChar!T);
>>> > T toLittleEndian(T)(T val) if (isArithmetic!T || isSomeChar!T);
>>> > T bigEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T);
>>> > T littleEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T);
>>> >
>>> > That means all characters, all integers, and all floating point
>>> > numbers. The implementations would opportunistically use intrinsics
>>> > and other specialized means.
>>> >
>>> > The documentation should specify the relationship to htonl and ntohl.
>>> >
>>> > If there's a need for converting endianness of larger buffers, we
>>> > might add:
>>> >
>>> > ubyte[] toBigEndian(ubyte[] val);
>>> > ubyte[] toLittleEndian(ubyte[] val);
>>> > ubyte[] bigEndianToNative(ubyte[] val);
>>> > ubyte[] littleEndianToNative(ubyte[] val);
>>> >
>>> > They'd use std.algorithm.reverse internally as needed.
>>> >
>>> > It's a sweet piece of work. Anyone have the time to prepare a pull
>>> > request?
>>> >
>>> >
>>> > Andrei
>>>
>>> Am I being naïve in thinking I can just do this:
>>> alias littleEndianToNative toLittleEndian;
>>> alias bigEndianToNative toBigEndian;
>>> ?
>>
>> What you do is have a function called swapEndian (or byteSwap or whatever
>> you want to call it) and a function which returns the original value.
>> Then you alias them based on versions. e.g.
>>
>> version(BigEndian)
>> {
>> alias doNothing bigEndianToNative;
>> alias swapEndian littleEndianToNative;
>> alias doNothing nativeToBigEndian;
>> alias swapEndian nativeToLittleEndian;
>> }
>> else
>> {
>> alias swapEndian bigEndianToNative;
>> alias doNothing littleEndianToNative;
>> alias swapEndian nativeToBigEndian;
>> alias doNothing nativeToLittleEndian;
>> }
>>
>> But you must base your conversions (and thus your aliases) on whether the
>> machine is big endian or little endian, otherwise they're going to be
>> wrong.
>>
>> - Jonathan M Davis
>
> I realise this, but I was doing this with static ifs and std.system like:
>
> T littleEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T) {
> static if (endian == Endian.LittleEndian) {
> return val;
> }
> else {
> return byteSwap(val);
> }
> }
>
> alias littleEndianToNative toLittleEndian;
>
> And the same for BigEndian.
>
> Chris
By same I mean substitute occurrences of little with big
Re: Byte Order Swapping Function
Jonathan M Davis wrote:
> On 2011-07-15 14:23, Christian Manning wrote:
>> Andrei Alexandrescu wrote:
>> > On 7/14/11 5:51 AM, Regan Heath wrote:
>> >> That's my point. I need 8/16/32/64/128 bit versions and it really
>> >> would be better if there were general variants. My version are less
>> >> than optimal, but do use intrinsics where possible. Someone else can
>> >> do a far better job than I, and it really should be done once, by that
>> >> person. Surely we have the infrastructure for someone to add this to
>> >> phobos? If something this simple can't or won't be done, what hope do
>> >> we have!?
>> >
>> > I think we should have these functions in std.bitmanip:
>> >
>> > T toBigEndian(T)(T val) if (isArithmetic!T || isSomeChar!T);
>> > T toLittleEndian(T)(T val) if (isArithmetic!T || isSomeChar!T);
>> > T bigEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T);
>> > T littleEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T);
>> >
>> > That means all characters, all integers, and all floating point
>> > numbers. The implementations would opportunistically use intrinsics and
>> > other specialized means.
>> >
>> > The documentation should specify the relationship to htonl and ntohl.
>> >
>> > If there's a need for converting endianness of larger buffers, we might
>> > add:
>> >
>> > ubyte[] toBigEndian(ubyte[] val);
>> > ubyte[] toLittleEndian(ubyte[] val);
>> > ubyte[] bigEndianToNative(ubyte[] val);
>> > ubyte[] littleEndianToNative(ubyte[] val);
>> >
>> > They'd use std.algorithm.reverse internally as needed.
>> >
>> > It's a sweet piece of work. Anyone have the time to prepare a pull
>> > request?
>> >
>> >
>> > Andrei
>>
>> Am I being naïve in thinking I can just do this:
>> alias littleEndianToNative toLittleEndian;
>> alias bigEndianToNative toBigEndian;
>> ?
>
> What you do is have a function called swapEndian (or byteSwap or whatever
> you want to call it) and a function which returns the original value. Then
> you alias them based on versions. e.g.
>
> version(BigEndian)
> {
> alias doNothing bigEndianToNative;
> alias swapEndian littleEndianToNative;
> alias doNothing nativeToBigEndian;
> alias swapEndian nativeToLittleEndian;
> }
> else
> {
> alias swapEndian bigEndianToNative;
> alias doNothing littleEndianToNative;
> alias swapEndian nativeToBigEndian;
> alias doNothing nativeToLittleEndian;
> }
>
> But you must base your conversions (and thus your aliases) on whether the
> machine is big endian or little endian, otherwise they're going to be
> wrong.
>
> - Jonathan M Davis
I realise this, but I was doing this with static ifs and std.system like:
T littleEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T) {
static if (endian == Endian.LittleEndian) {
return val;
}
else {
return byteSwap(val);
}
}
alias littleEndianToNative toLittleEndian;
And the same for BigEndian.
Chris
Re: Byte Order Swapping Function
Andrei Alexandrescu wrote: > On 7/14/11 5:51 AM, Regan Heath wrote: >> That's my point. I need 8/16/32/64/128 bit versions and it really would >> be better if there were general variants. My version are less than >> optimal, but do use intrinsics where possible. Someone else can do a far >> better job than I, and it really should be done once, by that person. >> Surely we have the infrastructure for someone to add this to phobos? If >> something this simple can't or won't be done, what hope do we have!? > > I think we should have these functions in std.bitmanip: > > T toBigEndian(T)(T val) if (isArithmetic!T || isSomeChar!T); > T toLittleEndian(T)(T val) if (isArithmetic!T || isSomeChar!T); > T bigEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T); > T littleEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T); > > That means all characters, all integers, and all floating point numbers. > The implementations would opportunistically use intrinsics and other > specialized means. > > The documentation should specify the relationship to htonl and ntohl. > > If there's a need for converting endianness of larger buffers, we might > add: > > ubyte[] toBigEndian(ubyte[] val); > ubyte[] toLittleEndian(ubyte[] val); > ubyte[] bigEndianToNative(ubyte[] val); > ubyte[] littleEndianToNative(ubyte[] val); > > They'd use std.algorithm.reverse internally as needed. > > It's a sweet piece of work. Anyone have the time to prepare a pull > request? > > > Andrei Am I being naïve in thinking I can just do this: alias littleEndianToNative toLittleEndian; alias bigEndianToNative toBigEndian; ? Chris
Re: [GSOC] Database API draft proposal
Hello all,
This is the second draft and a lot of changes have been made. Hopefully
it's a better overall proposal and I look forward to anybody's feedback :)
-
Synopsis
An API for databases is a common component of many languages' standard
library, though Phobos currently lacks this. This project will remedy
this by providing such an API and also begin to utilise it with
interfaces for some Database Management Systems (DBMS). I believe this
will benefit the D community greatly and will help bring attention and
developers to the language.
Details
---
Piotr Szturmaj has began working on DDB [1] which has a PostgreSQL
clietn written in D as well as some database neutral features such as
the DBRow type for storing rows from a database. Piotr and I have agreed
to collaborate such that DDB will continue with Piotr at the helm, and I
will begin implementing other DBMS clients based around his work. Once
there is another implementation, work will then begin on extracting a
common interface which will form the API.
For example:
module database;
interface DBConnection {
//method definitions for connecting to databases go here.
}
Then in an implementation of MySQL:
module mysql;
import database;
class Connection : DBConnection {
//implement defined methods tailoring to MySQL.
}
Exactly what will go in to these interfaces will depend on the
differences between the DBMSs, but they all share many things. The API
should also be developed in conjunction with the D community to minimise
any fallout of decisions made.
The DBMSs I plan to implement are MySQL and SQLite. Unlike PostgreSQL,
MySQL doesn't seem to have a long-term and stable client-server
protocol. As a result of this I will be wrapping around the MySQL C API
(v5.1) to bring it to D. SQLite will also undergo the same process.
Because of this, these clients are not likely to get into Phobos and so,
if the API does then these will be an external package.
If this project is completely successful, there will be a database API
and at least three DBMS clients ready for use in D applications. The
minimum amount of functionality for this to be considered successful
would be an API that is mostly utilised by the PostgreSql and MySQL
clients. In this scenario there will still be two usable clients,
however, perhaps the API is not totally complete and neither is the
SQLite client.
About Me
My name is Christian Manning and I am a second year undergraduate
studying Computer Science at De Montfort University.
I've become interested in D over time after reading about it several
years ago. I got myself "The D Programming Language" and went from
there. Although I've not done anything useful in D as I've learnt mainly
C and Java and am unable to use D for my university projects, I think
I'm capable of achieving the goals of this project.
Grades From The Past Year
-
Internet Software Development:
- XSLT/JSP: 91%
- JSP/MySQL: 70%+ (preliminary grade given in demo)
OO Software Design & Development:
- Data model: 83.33%
- Jetman (create a score + high score system and a configuration panel,
MVC style): 80% (preliminary given in demo)
Database Design & Implementation:
- Data Modelling assignment (ERD, normalisation and the like): 69.17%
- Database implementation (of the solution to the previous, in Oracle):
not yet marked.
Data Structures & Algorithms:
- Circular doubly linked list with cursor in C: not yet marked.
Computational Modelling (1st year):
- Caesar cipher in Haskell: 98%
References
--
[1] https://github.com/pszturmaj/ddb http://pszturmaj.github.com/ddb/db.html
Re: [GSOC] Database API draft proposal
On 03/04/2011 21:53, Andrei Alexandrescu wrote: On 4/3/11 3:33 PM, Christian Manning wrote: On 03/04/2011 19:30, Andrei Alexandrescu wrote: * What coursework did you complete? As a second-year student this makes it easier for us to assess where you are in terms of expertise. Scores would help as well. By this do you mean you'd like to see my completed courseworks? Or just descriptions and scores (where available)? Description and score. Andrei Ok, here are the ones I have available. Internet Software Development: - XSLT/JSP: 91% - JSP/MySQL: 70%+ (preliminary grade given in demo) OO Software Design & Development: - Data model: 83.33% - Jetman (create a score + high score system and a configuration panel, MVC style): 80% (preliminary given in demo) Database Design & Implementation: - Data Modelling assignment (ERD, normalisation and the like): 69.17% - Database implementation (of the solution to the previous, in Oracle): not yet marked. Data Structures & Algorithms: - Circular doubly linked list with cursor in C: not yet marked. The only one I can find from last year is a caesar cipher in Haskell: 98% Sorry about the unmarked ones, these were very recent, but I hope the rest helps. Chris
Re: [GSOC] Database API draft proposal
On 03/04/2011 21:57, Andrei Alexandrescu wrote: On 4/3/11 3:56 PM, Daniel Gibson wrote: Am 03.04.2011 22:53, schrieb Andrei Alexandrescu: On 4/3/11 3:33 PM, Christian Manning wrote: On 03/04/2011 19:30, Andrei Alexandrescu wrote: * What coursework did you complete? As a second-year student this makes it easier for us to assess where you are in terms of expertise. Scores would help as well. By this do you mean you'd like to see my completed courseworks? Or just descriptions and scores (where available)? Description and score. Andrei Put probably in private (a Mail to you, not in this list), right? I personally wouldn't want to expose these informations to the whole internet.. Cheers, - Daniel Either way is fine. FWIW many students put such information in resumes available online. Andrei I'm not particularly bothered about it, so I'll probably put them in this thread. I'll gather all the scores that I can tomorrow, but the last 4 of my assignments have yet to be marked, 2 of them do have preliminary marks though. This is unfortunate as they are the biggest pieces of work I've done thus far.
Re: [GSOC] Database API draft proposal
On 03/04/2011 19:30, Andrei Alexandrescu wrote: * What coursework did you complete? As a second-year student this makes it easier for us to assess where you are in terms of expertise. Scores would help as well. By this do you mean you'd like to see my completed courseworks? Or just descriptions and scores (where available)? I'll be working on my proposal to include yours and Fawzi's suggestions and post it as a reply to my first draft. Thanks for the help so far in this stage, Andrei, Fawzi and Piotr. Chris
Re: [GSOC] Database API draft proposal
On 03/04/2011 14:16, spir wrote:
On 04/03/2011 02:33 PM, Christian Manning wrote:
On 03/04/2011 13:10, spir wrote:
On 04/02/2011 10:03 PM, Christian Manning wrote:
I plan to have several interfaces in a database module which are then
implemented for specific DBMSs.
For example:
module database;
interface Connection {
//method definitions for connecting to databases go here.
}
Then in an implementation of MySQL for example:
module mysql;
import database;
class Connect : Connection {
//implement defined methods tailoring to MySQL.
}
I would recommend to use slightly longer names for generic interfaces,
eg "IConnection" or "DBConnection". Then, authors of libraries /
implementations for specific DBMS like MySQL can use the shorter ones,
eg "Connection", which will be all what library clients will see and
use. This also avoids the need for "lexical hacks" like "Connection"
versus "Connect".
What do you think?
When I was writing that it really didn't sit well and "DBConnection" in
particular is a much better way of doing it to reduce some confusion
there.
What goes in to these interfaces will be decided in conjunction with
the D
community so that there is minimal conflict and it will benefit as many
circumstances as possible. I believe this to be the best route to take
as I
cannot speak for everyone who will be using this.
Using the API created I plan to create an example implementation,
initially
wrapping around the MySQL C API. This will be a good starting point
for this
project and more can be created, time permitting.
I have no idea of the actual size of such an interface design, but I
doubt it can make you busy for 3 months full time, especially since
there are (probably good) precedents for other languages. Maybe the
example implementation should be specified as part of the project?
I'm aware that it wouldn't take 3 months, but I don't know how long it
will
take to have the API agreed upon so that there's a general consensus.
Another
way I could do it is to decide on the API myself and begin
implementing DBMSs
with it and then adapt to the ideas brought forth by the community. Then,
everyone's happy, just in a different time frame. Though, if there are
a lot of
changes wanted I'd have to change all of my implementations depending
on how
far I am at the time. What do you think about that path?
I would go for the second, especially because there is a Python example
(probably one of the best languages out there for such design
questions). Just think at usual qualities: clarity / simplicity /
consistency (and currently discussed Phobos style guidelines).
Also:
* Implementation example(s) is source of feedback for the interface
quality.
* Once you've done it, rewriting the exact same feature with a different
design can be very fast (esp if the change is only about interface),
because you master the application.
I personly would appreciate an example for a simpler and/or
non-relational, DBMS (maybe it's only me) (I'm thinking at key:value
like Berkeley DB, object DBMS, SQLite...).
Denis
SQLite could definitely be on the table. However, I don't want to be
over-ambitious at this stage and then not complete the project, and all
advice I've read on applying for GSOC suggests this too. If I could be
more certain on the time it would take for the API alone, then I would
propose more.
Would it be suitable to have something like: "If the API is not in a
good state by xx/xx/2011 then y implementation will not be undertaken" ?
Re: [GSOC] Database API draft proposal
On 03/04/2011 14:42, Piotr Szturmaj wrote:
Fawzi Mohamed wrote:
Well the comments in there are what is important, and will need to be
specified better IMHO.
The most important part in my opinion is how one chooses to represent a
record.
A big design choice is if the various fields are defined at compile time
or at runtime.
Also how does one add special behavior to a record? Do you use a
subclasses of the generic record type (as ruby does for example)?
I'm working on DB API for few months in my spare time. I'm delayed that
much by my other projects. Please take a look at my ideas:
http://github.com/pszturmaj/ddb
Documentation:
http://pszturmaj.github.com/ddb/db.html
http://pszturmaj.github.com/ddb/postgres.html
In my code, row is represented using struct DBRow!(Specs...). Fields may
be known at compile time or not. DBRow besides base types, may be
instantiated using structs, tuples or arrays. Untyped row (no compile
time information) is DBRow!(Variant[]).
Typed rows are very useful, for example you don't need to manually cast
columns to your types, it's done automatically, e.g.:
auto cmd = new PGCommand(conn, "SELECT typname, typlen FROM pg_type");
auto result = cmd.executeQuery!(string, "typName", int, "len");
foreach (row; result)
{
// here, row DBRow subtypes
// a Tuple!(string, "typName", int, "len")
writeln(row.typName, ", ", row.len);
}
What do you think? :)
I was going to reply with a link to your work but you beat me to it.
I think it's a great design and incorporating it or something similar
into the API may be the way to go.
Re: [GSOC] Database API draft proposal
On 03/04/2011 13:10, spir wrote:
On 04/02/2011 10:03 PM, Christian Manning wrote:
I plan to have several interfaces in a database module which are then
implemented for specific DBMSs.
For example:
module database;
interface Connection {
//method definitions for connecting to databases go here.
}
Then in an implementation of MySQL for example:
module mysql;
import database;
class Connect : Connection {
//implement defined methods tailoring to MySQL.
}
I would recommend to use slightly longer names for generic interfaces,
eg "IConnection" or "DBConnection". Then, authors of libraries /
implementations for specific DBMS like MySQL can use the shorter ones,
eg "Connection", which will be all what library clients will see and
use. This also avoids the need for "lexical hacks" like "Connection"
versus "Connect".
What do you think?
When I was writing that it really didn't sit well and "DBConnection" in
particular is a much better way of doing it to reduce some confusion there.
What goes in to these interfaces will be decided in conjunction with
the D
community so that there is minimal conflict and it will benefit as many
circumstances as possible. I believe this to be the best route to take
as I
cannot speak for everyone who will be using this.
Using the API created I plan to create an example implementation,
initially
wrapping around the MySQL C API. This will be a good starting point
for this
project and more can be created, time permitting.
I have no idea of the actual size of such an interface design, but I
doubt it can make you busy for 3 months full time, especially since
there are (probably good) precedents for other languages. Maybe the
example implementation should be specified as part of the project?
I'm aware that it wouldn't take 3 months, but I don't know how long it
will take to have the API agreed upon so that there's a general
consensus. Another way I could do it is to decide on the API myself and
begin implementing DBMSs with it and then adapt to the ideas brought
forth by the community. Then, everyone's happy, just in a different time
frame. Though, if there are a lot of changes wanted I'd have to change
all of my implementations depending on how far I am at the time. What do
you think about that path?
Thanks for the feedback, it's much appreciated :)
Chris
[GSOC] Database API draft proposal
Hello all,
This is my first draft proposal for a Database API for Google Summer Of
Code. I have never written a document such as this so any and all
feedback is welcome.
Thanks
-
Synopsis
An API for databases is a common component of many languages' standard
library, though Phobos currently lacks this. This project will remedy
this by providing such an API and also begin to utilise it with
interfaces for some Database Management Systems (DBMS). I believe this
will benefit the D community greatly and will help bring attention and
developers to the language.
Details
---
This project takes influence from the Java Database Connectivity API
(JDBC), the Python Database API v2 and other similar interfaces. The
idea is that any database interface created for use with D will follow
the API so that the only thing to change is the database back-end being
used. This will make working with databases in D a much easier experience.
I plan to have several interfaces in a database module which are then
implemented for specific DBMSs.
For example:
module database;
interface Connection {
//method definitions for connecting to databases go here.
}
Then in an implementation of MySQL for example:
module mysql;
import database;
class Connect : Connection {
//implement defined methods tailoring to MySQL.
}
What goes in to these interfaces will be decided in conjunction with the
D community so that there is minimal conflict and it will benefit as
many circumstances as possible. I believe this to be the best route to
take as I cannot speak for everyone who will be using this.
Using the API created I plan to create an example implementation,
initially wrapping around the MySQL C API. This will be a good starting
point for this project and more can be created, time permitting.
About Me
My name is Christian Manning and I am a second year undergraduate
studying Computer Science at De Montfort University.
I've become interested in D over time after reading about it several
years ago. I got myself "The D Programming Language" and went from
there. Although I've not done anything useful in D as I've learnt mainly
C and Java and am unable to use D for my university projects, I think
I'm capable of achieving the goals of this project.
Re: A few thoughts on the existing GSoC student proposals
On 01/04/2011 21:14, Piotr Szturmaj wrote: So, here it is :) Code: http://github.com/pszturmaj/ddb Documentation: http://pszturmaj.github.com/ddb/db.html http://pszturmaj.github.com/ddb/postgres.html Some things are unfinished yet. This is some great stuff and will definitely be a massive help! Thanks
Re: A few thoughts on the existing GSoC student proposals
On 01/04/2011 14:43, simendsjo wrote: Piotr Szturmaj: I think the end goal of a database module for Phobos should be to have native D clients for the more popular (R)DMBSs. Isn't both a large undertaking as well as difficult to keep in sync with the reference implementations? I think wrapping the c libs would make everything less fragile. I didn't mean for GSOC, but for when(/if) D's community reaches a point where it becomes feasible then it would be great to have native clients
Re: A few thoughts on the existing GSoC student proposals
On 31/03/2011 18:30, Piotr Szturmaj wrote: Andrei Alexandrescu wrote: 4. Database API This is a high impact item. I'd need to collect more information about the specifics of the application before creating an opinion about its chances of success. I see Piotr and others have some related ideas; I suggest them to apply appropriately (either as mentors or students). A solid mentor(s)/student(s) combo is a key ingredient of a successful project. Thanks, Andrei I do not feel very strong as a mentor and I'm not a student, so I'd rather not apply. However, I'll certainly try to help with this item :) That would be much appreciated, especially your PostgreSQL client. I think the end goal of a database module for Phobos should be to have native D clients for the more popular (R)DBMSs. I'm in the process of drafting my proposal which I'll post to this ng once done.
Re: [GSOC] Database API
On 25/03/2011 23:44, Masahiro Nakagawa wrote: > In Ruby, Rails 3 has Arel. > Arel seems to be a good query abstraction. > > https://github.com/rails/arel > > Arel's concept may help you :) > > > Masahiro Now that's an interesting way of going about things. Although, its description suggests that it's a framework for building frameworks which isn't really what I'm after as the database API should be able to be used by anybody easily. I don't know Ruby at all but in some of those examples, the syntax is quite neat. Chris
Re: [GSOC] Database API
On 25/03/2011 18:45, Jonathan M Davis wrote: On 24/03/2011 17:58, Trass3r wrote: Has this idea/project been assigned a mentor? I'd like to ask them and the list, what's the best thing for me to do right now to prepare for this? You could also have a look at http://dsource.org/projects/ddbi This shows some past efforts to create database interfaces. This can be of some inspiration and also brings up a point about how this project would be executed, ie. is this to be part of phobos or a totally separate project? I'm guessing to be Digital Mars supported it's more likely wanted to be a part of phobos, but could someone clarify on this? What I would expect to be the case would be that it would be implemented with the idea that it would ideally be put into Phobos but that it wouldn't necessarily make it into Phobos. Any major new functionality that gets added to Phobos at this point needs to be reviewed by the folks on this newsgroup and get voted in. So, it's possible that a fairly solid solution could be created which would not be acceptable in Phobos for one reason or another, at which point it would have to either be fixed so that it would be acceptable in Phobos or be left as a 3rd party library. So, ideally stuff like a good database solution for D would make it into Phobos, but whether it actually makes it in depends a great deal on the actual solution. - Jonathan M Davis Understood. My last deadline is Monday, so after that I should have much more time to concentrate on this to plan out what I'd like to do and submit a proper proposal. Chris
Re: [GSOC] Database API
On 25/03/2011 14:56, Piotr Szturmaj wrote: To sum up, Phobos need some additional changes for database support, mainly addition of Nullable. For now, couldn't this just be included with the database module?
Re: [GSOC] Database API
On 24/03/2011 17:58, Trass3r wrote: Has this idea/project been assigned a mentor? I'd like to ask them and the list, what's the best thing for me to do right now to prepare for this? You could also have a look at http://dsource.org/projects/ddbi This shows some past efforts to create database interfaces. This can be of some inspiration and also brings up a point about how this project would be executed, ie. is this to be part of phobos or a totally separate project? I'm guessing to be Digital Mars supported it's more likely wanted to be a part of phobos, but could someone clarify on this? Another question about Digital Mars' GSOC involvement: when it's application time do I submit a proposal to someone directly, to this list, or to the GSOC site at http://www.google-melange.com ? Thanks Chris
[GSOC] Database API
Hi, I'm a second year student at De Montfort University studying Computer Science. I am very much interested in working on the database API idea that is proposed at http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas#DatabaseAPI (I was also quite interested in the containers idea, but it looks like someone else wants to do that) I have limited experience with database libraries but have begun to study the JDBC API (in my small amount of spare time only as term doesn't finish for another 2 weeks for me and I still have assignments). Has this idea/project been assigned a mentor? I'd like to ask them and the list, what's the best thing for me to do right now to prepare for this? Thanks Chris
