Re: What is the closest to ConcurrentHashMap and NavigableMap in Java?
On Friday, 15 November 2013 at 22:22:32 UTC, Jacek Furmankiewicz wrote: Sohow does Facebook handle it with their new D code? No GC at all, explicit memory management? AFAWK, Facebook doesn't use D for its core business yet, only for buiding tools. OTOH, Andrei has been working hard on memory allocators, so maybe that's one idea that they are digging.
Re: A little of coordination for Rosettacode
On Tuesday, 5 February 2013 at 20:10:37 UTC, bearophile wrote: Jos van Uden: I'll give it a shot if you like. The RCRPG I'd like to try first. I have already partially written those: Partial translation of rcrpg-Python: http://codepad.org/SflrKqbT Partial translation of permutations_rank_of_a_permutation-Python: http://codepad.org/El9SQwOE Plus a better Perl implementation of the uniform() on BigInts: http://codepad.org/LGcMpk2f Partial translation of the universal_turing_machine-Ruby: http://codepad.org/nUXLzAg2 Bye, bearophile codepad.org doesn't work at all here. Maybe you should use dpaste (or pastebin for other languages) instead ?
Re: mysql binding/wrapper?
On Saturday, 28 April 2012 at 17:42:42 UTC, Adam D. Ruppe wrote: On Saturday, 28 April 2012 at 16:19:37 UTC, simendsjo wrote: As it resides in this big misc repository, does it have many dependecies? It depends on the database.d module in there too. (database.d provides the base interface and some common functions with other db providers.) That's it though, D wise. It also uses the mysql C library so you'll need libmysql on your system for it to link too. Would you mind if the module was added to vibe, and thus relicensed to MIT? No idea if the vibe folks would actually want that though :) My stuff is all free to take as far as I'm concerned, but since this uses libmysql it might technically be GPL. I don't really know. But if you're ok with that, you can have it. There is one small compilation error on the postgres driver line 44. I'm not sure it's the right thing to do but changing the offending type to size_t seems to do the trick.
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 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.
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 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: Should I wait for the new edition of TDPL ?
On Saturday, 28 April 2012 at 19:06:27 UTC, Jesse Phillips wrote: On Saturday, 28 April 2012 at 16:27:53 UTC, SomeDude wrote: Hi all, Not owning TDPL right now, I feel I could learn the language much more quickly with it. But Andrei hinted somewhere that there would be a new edition of his book. Should I wait for it ? Andrei mentioned it may be time for a new Printing. This would mean that you won't know if you'd get the newest printing when it was done. I'd say buy it now, I don't know the odds of getting new printings. Ah, right, it's a new printing, not a new edition. Thx. I'll get it through Amazon, I think.
Re: [OT] functional programming resources ?
On Friday, 27 April 2012 at 20:52:28 UTC, Mariusz Gliwiński wrote: Hello, could You recommend me some books / materials explaining different concepts in functional programming from *practical point of view*? Most preferably not requiring me to understand Haskell or other classical functional language. I'd like to try it with D. I'm using more functional style overtime, but i'm afraid to rely on compiler optimizations so highly. Anyways, i don't feel like i could write big part of my code pure && functional yet, so i'd like to learn about it at least a bit more. Thanks, Mariusz Gliwiński It has nothing to do with D, (Scheme instead, don't worry, you learn the language along), but Abelson and Süssman's "Structure and Interpretation of Computer Programs" (SICP) probably is one of the best computer science books ever written. And an eye opener. http://mitpress.mit.edu/sicp/ http://deptinfo.unice.fr/~roy/sicp.pdf It's free online, and there is a a free online course in videos. http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/ And you can use any scheme interpreter to try the examples (Racket is good for instance).
Should I wait for the new edition of TDPL ?
Hi all, Not owning TDPL right now, I feel I could learn the language much more quickly with it. But Andrei hinted somewhere that there would be a new edition of his book. Should I wait for it ?
Re: Strange measurements when reproducing issue 5650
On Friday, 27 April 2012 at 14:14:37 UTC, Steven Schveighoffer
wrote:
Have you tried measuring the code timings just inside main
instead of the full execution of the program including runtime
startup and shutdown?
-Steve
OK, it seems you are right. It turns out using
Measure-Command{...} was a rather poor way of measuring runtimes
because of startup/shutdown.
Using StopWatch, I now get consistent results, i.e nearly the
same times with or without the writeln, but always slightly
faster without. So all is sorted now.
Thx again.
Re: Strange measurements when reproducing issue 5650
On Wednesday, 25 April 2012 at 17:37:33 UTC, H. S. Teoh wrote: First of all, differences as small as 20ms really should be considered as background noise. The exact measurements depend on a lot of system-specific and environment-specific factors, such as OS memory usage, CPU cache behaviour, disk activity & speed, the exact points of context switches, etc.. If you really want to check for substantial performance differences, you need to magnify your test case so that differences are measured >5 seconds. Second, on my AMD hexacore 64-bit Linux system, the running time consistently measures between 0.57 or 0.58 seconds for both cases. The exact figure changes between runs, and as far as I can tell, there's no discernible difference between the two. Third, to make any timing differences stand out from the background noise, I increased n to 20_000_000, and both versions of the program consistently runs in about 11 seconds each time. There's no discernible difference between the two. What all this means is that a single call to writeln does not make enough difference to be measurable compared to the rest of the program. It doesn't mean that the version with writeln is "faster", just that the difference is too small and you're probably just seeing background noise. If you put the writeln inside a loop, on the other hand, you'll see a big difference, because now its cost is magnified by the number of times the loop runs. (Say if you put it inside a foreach(i;0..1000) at the end of the program, you'll see the difference when you comment it out.) So I'd chalk it up to inherent measurement inaccuracies. T Thanks, indeed, for n = 5_000_000, I observe the expected result, i.e the writeln version being almost 1 second slower than without. Below 2_000_000, though, I consistently see the opposite on my machine, i.e the version with writeln being slightly faster. If it was background noise, it would be about equal, no ?
Re: Strange measurements when reproducing issue 5650
On Wednesday, 25 April 2012 at 17:06:00 UTC, SomeDude wrote: On Wednesday, 25 April 2012 at 15:35:44 UTC, Steven Schveighoffer wrote: On Wed, 25 Apr 2012 07:27:29 -0400, SomeDude wrote: On Wednesday, 25 April 2012 at 08:34:40 UTC, SomeDude wrote: Noone reproduces this ? On my linux box, it runs in about 580ms, with or without the writeln. This is what I would expect. But things can be strange when dealing with GC timings. Have you tried profiling the code to see where the time is being added? -Steve Did you compile with dmd -O -inline -release ? I'll do some profiling later. OK, I'm having a hard time producing data that support what I see without profiling on, but it's still quite consistent accross runs. I dunno what's wrong here.
Re: Strange measurements when reproducing issue 5650
On Wednesday, 25 April 2012 at 15:35:44 UTC, Steven Schveighoffer wrote: On Wed, 25 Apr 2012 07:27:29 -0400, SomeDude wrote: On Wednesday, 25 April 2012 at 08:34:40 UTC, SomeDude wrote: Noone reproduces this ? On my linux box, it runs in about 580ms, with or without the writeln. This is what I would expect. But things can be strange when dealing with GC timings. Have you tried profiling the code to see where the time is being added? -Steve Did you compile with dmd -O -inline -release ? I'll do some profiling later.
Re: Strange measurements when reproducing issue 5650
On Wednesday, 25 April 2012 at 08:34:40 UTC, SomeDude wrote: Noone reproduces this ?
Strange measurements when reproducing issue 5650
Discussion here:
http://d.puremagic.com/issues/show_bug.cgi?id=5650
On my Windows box, the following program
import std.stdio, std.container, std.range;
void main() {
enum int range = 100;
enum int n = 1_000_000;
auto t = redBlackTree!int(0);
for (int i = 0; i < n; i++) {
if (i > range)
t.removeFront();
t.insert(i);
}
writeln(walkLength(t[]));
//writeln(t[]);
}
runs in about 1793 ms.
The strange thing is, if I comment out the writeln line, runtimes
are in average *slower* by about 20 ms, with timings varying a
little bit more than when the writeln is included.
How can this be ?
Re: What am I doing wrong ?
On Sunday, 22 April 2012 at 21:50:32 UTC, Dmitry Olshansky wrote: Omagad, thank you, too much Java is bd for your brains.
What am I doing wrong ?
Sorry for the noob questions, but
import std.stdio;
struct Foo {
int x;
}
void main() {
auto array = new Foo[10];
auto i = array.length;
foreach(Foo f; array) { f.x = --i; write(f.x);}
writeln();
foreach(Foo f; array) { write(f.x);}
}
gives me:
PS E:\DigitalMars\dmd2\samples> rdmd bug.d
9876543210
00
Also,
void main() {
auto array = new Foo[10];
--> for(int i = array.length; i > 1; i--) { array[i].x = i; }
writeln();
foreach(Foo f; array) { write(f.x);}
}
throws core.exception.RangeError@bug(8): Range violation on the
line with the arrow.
What am I doing wrong ?
Re: avoid toLower in std.algorithm.sort compare alias
On Saturday, 21 April 2012 at 23:24:57 UTC, Jay Norwood wrote:
While playing with sorting the unzip archive entries I tried
use of the last example in
http://dlang.org/phobos/std_algorithm.html#sort
std.algorithm.sort!("toLower(a.name) <
toLower(b.name)",std.algorithm.SwapStrategy.stable)(entries);
It was terribly slow for sorting the 34k entries in my test
case. I'd guess it is doing the toLower call on both strings
for every compare.
It was much, much faster to add an entries.lowerCaseName =
std.string.toLower(entries.name) foreach entry prior to the
sort execution and then use
std.algorithm.sort!("a.lowerCaseName < b.lowerCaseName
",std.algorithm.SwapStrategy.stable)(entries);
The difference was on the order of 10 secs vs no noticeable
delay when executing the sort operation in the debugger.
Good point. Perhaps this should be added in the documentation of
std.algorithm ? It's easy to get trapped.
Re: Newbie Introduction (was Re: arrays and foreach)
On Wednesday, 18 April 2012 at 19:43:50 UTC, Paul D. Anderson wrote: SomeDude: Your outline and especially your emphasis on what a rank beginner needs to know is very good. Would you consider writing it up yourself? Not the whole thing, maybe but the beginner info and the compiler/linker appendices. You have a commendable prose style. There are tutorials available already, but too many is way better than too few. Paul Thanks. I wouldn't mind having a stab at it, but: 1. it is Ali's book, not mine, so we would need Ali's agreement. If he offers me to contribute, why not, 2. I'm myself a D beginner, so you would probably need to proof read and correct me afterwards.
How does this work ?
I'm going through a number of bug reports, trying to reproduce the
problems and see what can be closed easily (i.e non reproduced, correct
behaviour, etc), and I just came accross
http://d.puremagic.com/issues/show_bug.cgi?id=7326 titled
"write interprets enum with byte backing type as a character"
Here is the case description:
import std.stdio;
enum X : byte
{
Foobar = 65,
}
void main()
{
X x;
writeln(x); // writes 'A'
writeln(cast(byte)x); // writes 65
}
That's it.
When I run this on Win32, I get:
Foo
65
Can anyone explain me if it is the correct behaviour, and if yes, why ?
Thx.
Re: Is this a bug in iota?
On Thursday, 19 April 2012 at 11:38:39 UTC, Steven Schveighoffer wrote: On Thu, 19 Apr 2012 04:07:00 -0400, Jonathan M Davis wrote: Having an assertion may be desirable, but the bug is in the usage of iota, not iota itself. Yes, and iota should detect that bug with an assert. No case can really be made that iota shouldn't be changed. Please file an enhancement request. -Steve http://d.puremagic.com/issues/show_bug.cgi?id=7944
Re: Is this a bug in iota?
Le 19/04/2012 11:11, Jonathan M Davis a écrit :
> On Thursday, April 19, 2012 10:14:39 Somedude wrote:
>> Le 19/04/2012 10:07, Jonathan M Davis a écrit :
>>> Having an assertion may be desirable, but the bug is in the usage of iota,
>>> not iota itself. At best, the assertion would help indicate that the
>>> caller has a bug. It's exactly the same as doing something like
>>>
>>> for(size_t i = 3; cond; --i) {}
>>>
>>> It's basic integer arithmetic. If you subtract from the minimum value that
>>> the integral type will hold, then its value will wrap around to the
>>> maximum. So, while adding an assertion would be desirable, I don't see
>>> how this could be considered a bug in iota.
>>>
>>> - Jonathan M Davis
>>
>> I don't get it, for me iota has nothing to do with the problem, the
>> problem is in the implementation of popfront(), which should check
>> beforehand whether the range is empty, right ?
>
> Maybe, maybe not. popFront _must_ succeed. It has three options if the range
> is empty: assert, throw an exception, or just assume that it's going to
> succeed and choke in whatever manner the implementation ends up choking if
> the
> range is empty when it tries to pop an element from an empty range.
>
> Very few ranges are going to throw exceptions from popFront, because that
> incures overhead, and really, it's a bug in the caller if they keep trying to
> pop elements from an empty range. So, throwing an exception really isn't the
> correct behavior.
>
> Asserting is an option, and since iota is templated, it should probably do
> that (asserting in non-templated code is more debatable, because it'll only
> be
> there if Phobos itself is compiled without -release rather than the program
> or
> library call it - in most cases, such an assertion would probably never end
> up
> being run, because using a release version of Phobos is the default). But
> it's
> not doing that right now. An enhancement request for such would be
> appropriate.
>
Oh that's right. Still I think it should be done for development, and I
also think Phobos should ship in both versions, dev AND release.
We shouldn't link against the release phobos when we compile without
-release.
Re: tupleof.length of a class in a template return 0
Le 19/04/2012 05:04, "Michaël Larouche" " a écrit : > > Reading the bug thread, I am wondering why my template worked in a > struct but not inside a class. > > Anyway, I decided to move my mixin outside the struct/class and abuse > UFCS instead. Now everything works like a charm :) Cool. Glad it helpted. :)
Re: Is this a bug in iota?
Le 19/04/2012 10:07, Jonathan M Davis a écrit :
> Having an assertion may be desirable, but the bug is in the usage of iota,
> not
> iota itself. At best, the assertion would help indicate that the caller has a
> bug. It's exactly the same as doing something like
>
> for(size_t i = 3; cond; --i) {}
>
> It's basic integer arithmetic. If you subtract from the minimum value that
> the
> integral type will hold, then its value will wrap around to the maximum. So,
> while adding an assertion would be desirable, I don't see how this could be
> considered a bug in iota.
>
> - Jonathan M Davis
I don't get it, for me iota has nothing to do with the problem, the
problem is in the implementation of popfront(), which should check
beforehand whether the range is empty, right ?
Re: Is this a bug in iota?
Le 19/04/2012 05:36, bearophile a écrit :
> Brad Anderson:
>> You can popFront() for as long as you want well passed the length.
>> Obviously popping off the front of a zero length range isn't valid but
>> I would have expected a range violation to occur rather than it to
>> silently continuing the series with a wrapped around length.
>
> I think it's a matter of design and it's a matter of having an
> alternative Phobos release that contains asserts too. Adding the test
> slows down something (iota) that must be as fast as possible. And
> currently asserts are removed from the compiled Phobos...
>
> Bye,
> bearophile
You've gotta be kidding. How can this NOT be a bug ?
import std.range, std.stdio;
void main()
{
auto r = iota(3);
//writeln(isInfinite!r);
assert(!isInfinite!(int[]));
assert(isInfinite!(Repeat!(int)));
//assert(isRandomAccessRange!i);
writeln(r.front, ", length: ", r.length, " empty ? ", r.empty);
r.popFront();
writeln(r.front, ", length: ", r.length, " empty ? ", r.empty);
r.popFront();
writeln(r.front, ", length: ", r.length, " empty ? ", r.empty);
r.popFront();
writeln(r.front, ", length: ", r.length, " empty ? ", r.empty);
r.popFront();
writeln(r.front, ", length: ", r.length, " empty ? ", r.empty);
r.popFront();
}
Returns:
0, length: 3 empty ? false
1, length: 2 empty ? false
2, length: 1 empty ? false
3, length: 0 empty ? true
4, length: 4294967295 empty ? false
Re: appending newly initialized struct to array
On Wednesday, 18 April 2012 at 18:18:44 UTC, Ali Çehreli wrote: On 04/18/2012 10:13 AM, Jonathan M Davis wrote: > > It's by design. An enhancement request is a waste of time. Comparisons with > NaN _always_ return false regardless of what they're compared against - even > NaN. It's not going to change. > > - Jonathan M Davis It shouldn't be a problem to detect comparisons against literal .nan values. The compiler can warn with "comparison is always false". Ali Now THAT makes sense.
Re: appending newly initialized struct to array
On Wednesday, 18 April 2012 at 16:36:39 UTC, bearophile wrote: Ali: That a thousandth time I have made that mistake and still have not learned. :( Yes, .nan may not be compared with any other value, including .nan. Today I'll present an enhancement request to remove this problem from D. Hugs, bearophile I don't see how this could be enhanced.
Re: tupleof.length of a class in a template return 0
On Tuesday, 17 April 2012 at 00:04:16 UTC, Michaël Larouche wrote: My template works with a struct but when I try to mixin my template in a class, I get compile error because T.tupleof.length returns 0. Here's the whole code: http://ideone.com/UR6YU For what it's worth, dmd 2.059 (it seems you are using v2.042) gives this message: serial.d(21): Error: class serial.MyObject no size yet for forward reference serial.d(11): Error: template instance serial.GenerateFieldSerialization!(MyObject,0,"m_id","m_data","AMethod","AutoDelete","AnotherMethod","RefCount","Method1","toString","toHash","opCmp","opEquals","Monitor","factory") error instantiating According to Kenji Hara, "tupleof property requires complete semantic analysis to get the fields of a type." http://d.puremagic.com/issues/show_bug.cgi?id=7249 If you haven't solved your problem yet, you may try the workaround described or have a look at the result of googling this: "no size yet for forward reference" site:digitalmars.com/d
Re: Compiling Was: arrays and foreach
On Tuesday, 17 April 2012 at 12:11:21 UTC, David wrote: In this case, I had to type: rdmd -unittest --main test.d Without the --main, I would get linker errors, and couldn't find the reason for these errors. Happily, someone here explained me that the effect of the --main flag was to insert a main() function just for this case. That's not surprising, try to write a C program with no main: ─[ArchBox][/tmp]╼ touch foo.c ─[ArchBox][/tmp]╼ LANG=C gcc foo.c /usr/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../crt1.o: In function `_start': (.text+0x18): undefined reference to `main' collect2: error: ld returned 1 exit status You get the linker errors, because there is no entry-point for your program, but that has nothing to do with D, it's a common behaviour for C, C++, D and other languages. And the unittest(-switch) is also good relativly good explained at http://dlang.org/unittest.html (dlang -> search -> unittest) Yeah I understand, but I thought that by writing unit tests, I would implicitly add an entry point, but now I see how dumb an idea that is.
Re: Sampling algorithms for D
Le 18/04/2012 05:15, Joseph Rushton Wakeling a écrit : > On 13/04/12 10:04, Dmitry Olshansky wrote: >>> OK, I'll see what I can do. I'd like to discuss and refine the design a >>> bit further before making any pull request -- should I take things over >>> to the Phobos mailing list for this ... ? >> >> I'm no authority but there is this d.D newsgroup which is perfectly >> fine for >> this kind of thing. A lot of nice people just don't (have time to) >> mess with >> unwashed masses in D.learn :) > > Tweaked version, an revision of RandomSample from std.random, is > available from > https://github.com/WebDrake/RandomSample > > Feedback on code details and on tests would be very welcome. It seems > about 10% slower than the original code I wrote, which I guess is down > to factors in the design of the RandomSample struct. This looks very C++ ish. I can't comment very much, being myself quite noob, but I think you can do this, for style as well as performance: - add pure nothrow everywhere you can. - move some imports within the static if when possible, as close to their actual usage, and it's better to do: import core.time:clock_t, clock; You may also want to use a bit of contract programming for input and output. Also not sure the _ convention for private attributes is recommended in D.
Re: Clearly Label D1/D2/Tango/Phobos
Le 18/04/2012 14:34, Paul a écrit : > I bought the book and am trying to patiently learn this language. I > follow various tutorials here and around the web that frequently won't > compile. I suspect it has something to do with D1/D2/Phobos/Tango and > not just really poor unvetted tutorials. It would really be helpful if > those providing references, code snippets, tutorials, etc clearly > identify the context (i.e D1/D2/Phobos/Tango). I just think it would > help accelerate the spread and acceptance of this language if more of > the code worked as listed. > > If people are out cruising the web and download a fresh copy of D with > excitement (about a cleaned-up, updated c-type systems language) and > then the first several things don't compile w/o errors, they're going to > move on. > > Thanks so much to all who provide references, tutorials, etc! It is > great service in helping others learn. I hope this is seen as > constructive criticism for that is what it is. Hi ! It's simple: use D2, and forget about Tango. D1 is deprecated and its maintainance will be stopped by the end of the year. Noone should be starting with D1 now. You can start here: http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial I cleaned up this page a little bit, I hope this helps.
Re: learn.newbie forum
Le 18/04/2012 14:19, Paul a écrit : > I think there should be a learn.newbie forum. After I post my little > problems of a sample code snippet that won't compile, I read some of the > other threads. There are those c/c++ programmers learning the ins/outs > of D and then there are the greenies like me. Just a thought. D is a very complex language, so if you haven't programmed before, it's gonna be hard, but not impossible. For complete beginners, I can recommend, on this page http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial starting with "A Newbie oriented tutorial" and "Programming in D" These two should get you started.
Re: appending newly initialized struct to array
Le 18/04/2012 12:41, maarten van damme a écrit :
> That's a very odd design. Making it work when instantiating a new struct
> of that type but not inline. Anyway, test(3,5) works perfect, thank you.
It's not odd at all. You append a structure, not an array.
{3,5} is for array initialization, it's the same syntax as in C, C++,
Java, C#.
What if you want to append an array of structures ?
why~=[test(3,5), test(3,6)];
Re: Hacking on Phobos
Le 18/04/2012 12:04, Jacob Carlborg a écrit : > >> I can't find any easy or friendly "get started hacking on Phobos" page, >> so can anyone advise how to get set up correctly? > > I've thought about this several times, we need one badly. > I've just created a page in the Wiki with the posts here: http://prowiki.org/wiki4d/wiki.cgi?HackingPhobos I'm sure it's not perfect and can be improved upon, so feel free to contribute. The page is accessible from here: http://prowiki.org/wiki4d/wiki.cgi?DevelopmentWithD
Re: arrays and foreach
Le 18/04/2012 10:26, Somedude a écrit : > Yes, I think that you have a lot of valuable information, but the > organization is lacking. The advanced chapters look good, but the first > "beginner" chapters can be . > ... largely improved.
Re: arrays and foreach
Le 17/04/2012 16:07, Ali Çehreli a écrit : > On 04/17/2012 12:42 AM, Somedude wrote: > >> Sorry for hijacking this thread, but since you're around, I hope you'll >> see this message. As a D beginner, I'm browsing through your book. >> I wanted to tell you that there is something essential missing in it: >> how to compile. It's actually quite hard to find it in the official >> website, and since the first chapters are targetted at complete >> beginners, I thought it would be nice to add a few lines or pages about >> compilation, linking, debugging, etc. >> What do you think ? > > Thank you very much for the feedback. I will do something about that. > > Although there is no hello world compilation, the dmd command line > appears multiple times throughout the chapters. > > The 'assert and enforce' chapter shows it for the -release compiler > switch and coincidentally I am on the 'Unit Testing' chapter as we > speak, which includes the -unittest switch. :) > > But you are right, both dmd and rdmd command lines must appear earlier. > > Thank you, > Ali > Yes, I think that you have a lot of valuable information, but the organization is lacking. The advanced chapters look good, but the first "beginner" chapters can be . what struck me as an error in your "Hello world program" chapter, you give as an exercise: "Type or copy the hello world program into your editor as a source file, compile it, and run the program. The program should produce the following output: Hello world! If you are new to using a compiler, you will need to get help from the compiler documentation or, preferably, an experienced person. You can't benefit from the rest of this book if you can't compile and run programs." Spock would have said: "Illogical, captain!" At this point, you haven't told how to compile and run the program. Seriously, if your book is aimed at complete beginners (and the first chapters seem to say that), you really want to tell them what to do, not "go find the compiler documentation", else if they can do that, they simply don't need to read your book. For a complete beginner, it's very frustrating to have to read 4 chapters of fluff, then write the program, and still not knowing how to run the program. Where is the fun ? I can guarantee that at this point, 9 out of 10 beginners will drop the reading. FIRST show, THEN explain. Better yet: first show, then ask questions, and finally explain. So how would I have organized this chapter ? Something like this: --- The first program to show in most programming... Here is a hello world in D: ... Copy this program and save it in a file under the name hello.d .d is the extension for D source code. Now we'll compile it, that is to say the compiler will check that the syntax of this source code, and if it is valid D, will translate it into machine language and make it a program. Type in the command prompt: rdmd hello.d If you didn't make any mistake, you should have the impression that nothing happened. In the contrary, everything went well ! You can check that the executable file hello (or hello.exe under window) has been created. If instead the compiler barked at you lots of text, you probably made a mistake while copying. Correct it and retry. You will routinely make many mistakes when programming so that this process of correcting and compiling will get very familiar. Once this is done, type the name of the executable to run it. You should see Hello, world ! Congratulations, your first D program is running ! Then ONLY after that, I would proceed to the explanations. (As an exercise, I would ask also: what is the smallest valid D program ?) I would put the "Hello, world" chapter at the very beginning, right after "The practice of programming". This chapter would be enriched by an example on the computer, showing the values. The order of the beginning chapters I think should be: Intro Practice of programming Hello world writeln and write Compiler Fundamental types I would then merge "Assignment and order of evaluation" with "Variables" I would also remove the "Standard Input and Output Streams", they don't belong to an introduction. In fact, the problem is, you really want to separate your chapters into a sections, one as an introductory course, and one for more advanced explanations of the core language, and maybe one to introduce specific concepts of the standard library (your last chapters). I would put in Introduction section the first 19 chapters until "Redirecting input and output", as well as all the flow constructs (do-while, for, foreach, switch case, you really want to merge those with other chapters like while, these don't need se
Re: "No stack address"
Le 17/04/2012 09:30, Somedude a écrit : > Anyway, I think I'll add this simple piece of info somewhere in the > wiki. I've already cleaned it up a little. Ok, here it is: http://prowiki.org/wiki4d/wiki.cgi?HowTo/UnitTests
Re: Compiling Was: arrays and foreach
Le 17/04/2012 12:19, Mike Parker a écrit : > On 4/17/2012 4:42 PM, Somedude wrote: > >>> >>> Ali >>> >>> >> Hi Ali, >> >> Sorry for hijacking this thread, but since you're around, I hope you'll >> see this message. As a D beginner, I'm browsing through your book. >> I wanted to tell you that there is something essential missing in it: >> how to compile. It's actually quite hard to find it in the official >> website, and since the first chapters are targetted at complete >> beginners, I thought it would be nice to add a few lines or pages about >> compilation, linking, debugging, etc. >> What do you think ? > > In the sidebar at dlang.org, under Documentation, is a link labeled > "Tutorial". The very first code example shows a minimal program and how > to compile it. Well, yes, that's sufficient for "Hello, world", but not for something barely more complex, i.e a function with a unit test. In this case, I had to type: rdmd -unittest --main test.d Without the --main, I would get linker errors, and couldn't find the reason for these errors. Happily, someone here explained me that the effect of the --main flag was to insert a main() function just for this case. Now, I see there is a mention of this in http://dlang.org/rdmd.html But without rdmd, I would compile with dmd, which has no --main switch, and it would still fail to link, because of lack of main(). The code I posted wasn't my code, and I knew it had worked, so I assumed it was correct, I didn't figure out that adding a main() was necessary given there was a unit test. And anyway, explaining in the book how to link is a necessary step imho. This is why I made this page more visible in the Wiki: http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/CompilingLinkingD
Re: Thread join behaviour
Le 17/04/2012 08:40, Russel Winder a écrit : > On Mon, 2012-04-16 at 21:03 +0200, Somedude wrote: > [...] > > Issue 7919 > > http://d.puremagic.com/issues/show_bug.cgi?id=7919 > Thanks.
Re: arrays and foreach
Le 17/04/2012 02:01, Ali Çehreli a écrit :
> On 04/16/2012 04:56 PM, darkstalker wrote:
>> i have this example program:
>>
>> ---
>> void main()
>> {
>> int[3] a;
>> foreach (p; a)
>> p = 42;
>> writeln(a);
>> }
>> ---
>>
>> after running it, i expect to get [42, 42, 42] but instead i get [0, 0,
>> 0] (i know that you can do a[] = 42, it's just a trivial example). So it
>> seems that you cannot write into the array because the elements are
>> being passed by value each iteration. It possible to have 'p' passed by
>> reference?
>
> Yes:
>
> foreach (ref p; a)
>
> Ali
>
>
Hi Ali,
Sorry for hijacking this thread, but since you're around, I hope you'll
see this message. As a D beginner, I'm browsing through your book.
I wanted to tell you that there is something essential missing in it:
how to compile. It's actually quite hard to find it in the official
website, and since the first chapters are targetted at complete
beginners, I thought it would be nice to add a few lines or pages about
compilation, linking, debugging, etc.
What do you think ?
Re: "No stack address"
Le 17/04/2012 01:26, Andrej Mitrovic a écrit : > On 4/17/12, Somedude wrote: >> But running the exe crashes immediately at execution with "unauthorized >> instruction". Why ? > > That's the old exectuable leftover from the previous compile. RDMD > generates the exe in a temporary folder with a random name and runs it > immediately. Because the main function doesn't do anything (RDMD > provides an empty one via --main), the app exited immediately. > >> And how do I execute the unit test ? > > rdmd -unittest --main test.d Thanks, it works. BTW, I couldn't find this information. Do you have any idea where this is explained (in particular the --main switch) that I overlooked ? Anyway, I think I'll add this simple piece of info somewhere in the wiki. I've already cleaned it up a little.
Re: "No stack address"
Le 16/04/2012 21:51, Andrej Mitrovic a écrit :
> On 4/16/12, Somedude wrote:
>> OPTLINK : Warning 134: No Start Address
>
> This means you're missing a void main or int main function. You can
> pass --main to rdmd to add it automatically (useful when e.g.
> unittesting).
All right, now I have a bunch of questions.
Sorry, D newcomer here.
I hate to do this, but I'll simply dump the full code, it should save me
a lot of questions.
/++
Xinok Sort for the D Programming Language
Written and tested for DMD 2.055 and Phobos
Authors: Xinok
Date: November 2011
License: Public Domain
Web: $(LINK http://www.sourceforge.net/projects/xinoksort)
Todo:
Parallelization - Write a separate function which runs xinok sort in
multiple threads
Support for CTFE - Sorting arrays at compile time
Unittest for ranges - Test implementation of xinok sort using range
primitives
In / Out conditions and asserts
++/
module xinoksort;
import std.range;
import std.functional : binaryFun, not;
import std.algorithm : swap, swapRanges, copy, reverse, isSorted;
import std.traits : isCallable;
import core.exception : OutOfMemoryError;
/++
This function will sort an array or range in-place,
optionally using a custom predicate.
Returns: Sorted input as SortedRange
Throws: OutOfMemoryError if memory allocation fails
Predicate:
The predicate can be a string, function, or delegate.
A string should represent the two elements to compare
using the characters 'a' and 'b'.
A function or delegate should take two arguments of the
same type and return a bool.
The default predicate for sorting is "a < b".
Examples:
---
int[] arr = [20, 40, 60, 10, 30, 50];
xinokSort(arr);
// Sort in reverse order
xinokSort!("a > b")(arr);
// Use a function or delegate as predicate
bool comp(int a, int b){ return a < b; }
xinokSort!(comp)(arr);
// Sort an array of strings, case insensitive
string[] list;
xinokSort!("icmp(a, b) < 0")(list);
---
++/
SortedRange!(Range, pred) xinokSort(alias pred = "a < b", Range)(Range arr){
typeof(Range[0])[] temp;
if(!__ctfe){ // Allocate temporary memory
size_t len = arr.length >= 1024*64 ? arr.length / 1024 : 64;
while(temp is null){
try temp.length = len;
catch(OutOfMemoryError err){ // Reduce memory usage and
try again
len /= 2;
if(len >= 8) continue;
else throw err;
}
}
}
else temp.length = 1024;
XinokSortImpl!(pred, Range).findRuns(arr, arr.length, temp);
return assumeSorted!(pred, Range)(arr);
}
/++ Generate compare functions from predicate
Example:
---
mixin Compares!("a > b");
---
++/
template Compares(alias pred){
static if(is(typeof(pred) : string)){
alias binaryFun!(pred) less;
alias binaryFun!(pred, "b", "a") greater;
alias not!(binaryFun!(pred)) greaterEqual;
alias not!(binaryFun!(pred, "b", "a")) lessEqual;
}
else static if(isCallable!pred){
alias pred less;
auto greater(T)(T a, T b){ return pred(b, a); }
auto greaterEqual(T)(T a, T b){ return !pred(a, b); }
auto lessEqual(T)(T a, T b){ return !pred(b, a); }
}
else static assert(false, "Invalid predicate");
}
/// Implementation of xinok sort for ranges
template XinokSortImpl(alias pred, Range){
static assert(isRandomAccessRange!Range && isBidirectionalRange!Range
&& hasSlicing!Range, Range.toString ~ " is incompatible with xinok sort");
alias typeof(Range[0]) T;
mixin Compares!pred;
/// Find runs in ascending or descending order and merge them
size_t findRuns(Range arr, size_t t, T[] temp){
enum min_run = 8;
if(arr.length <= min_run){
insertSort(arr);
return arr.length;
}
if(t > arr.length) t = arr.length;
// Find first run
size_t lef = 2;
if(lessEqual(arr[0], arr[1])){ // Ascending order
"No stack address"
I'm trying to compile a D source on win32 with DMD 2.059, and I get this: PS E:\DigitalMars\dmd2\samples> rdmd xinoksort.d OPTLINK (R) for Win32 Release 8.00.12 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Warning 23: No Stack OPTLINK : Warning 134: No Start Address PS E:\DigitalMars\dmd2\samples> Clearly, the link phase didn't complete correctly: -a---16/04/2012 08:55 12600 xinoksort.d -a---16/04/2012 21:12 56 xinoksort.exe -a---16/04/2012 21:12889 xinoksort.obj Phobos wasn't linked. What happened ? Does it link dynamically now ? How do I set the libpath (I'm using the Powershell) ?
Re: Thread join behaviour
Le 15/04/2012 20:40, Russel Winder a écrit : > On Sun, 2012-04-15 at 16:04 +0200, Artur Skawina wrote: > [...] >> (my old GDC needs the explicit "function", no idea if newer >> frontends still require that) > > OK, works for me with GDC as well, DMD is broken! I'll file a bug > report. > Did you file a bug report ? If yes, which number ? This is an annoying regression in my opinion.
Re: D 50% slower than C++. What I'm doing wrong?
Le 15/04/2012 23:41, Somedude a écrit : > Le 15/04/2012 23:33, Ashish Myles a écrit : >> On Sun, Apr 15, 2012 at 5:16 PM, Somedude wrote: > > Oh right, sorry for this. It's a bit confusing. Now apart from comparing the generated asm, I don't see.
Re: D 50% slower than C++. What I'm doing wrong?
Le 15/04/2012 23:33, Ashish Myles a écrit : > On Sun, Apr 15, 2012 at 5:16 PM, Somedude wrote: >> Le 15/04/2012 09:23, ReneSac a écrit : >>> On Sunday, 15 April 2012 at 02:56:21 UTC, Joseph Rushton Wakeling wrote: >>>>> On Saturday, 14 April 2012 at 19:51:21 UTC, Joseph Rushton Wakeling >>>>> wrote: >>>>>> GDC has all the regular gcc optimization flags available IIRC. The >>>> >>> >>> >> >> I notice the 2D array is declared >> int ct[512][2]; // C++ >> int ct[2][512]; // D >> > > Not quite. It is declared > int[2][512] ct; // not valid in C++ > which is the same as > Int ct[512][2], // also valid in C++ > > That's because you look at it as ((int)[2])[512] 512-sized array of > 2-sized array of ints. Oh right, sorry for this. It's a bit confusing.
Re: Thread join behaviour
Le 15/04/2012 20:40, Russel Winder a écrit : > On Sun, 2012-04-15 at 16:04 +0200, Artur Skawina wrote: > [...] >> (my old GDC needs the explicit "function", no idea if newer >> frontends still require that) > > OK, works for me with GDC as well, DMD is broken! I'll file a bug > report. > It works here (DMD 2.058 win32), even without "function".
Re: D 50% slower than C++. What I'm doing wrong?
Le 15/04/2012 09:23, ReneSac a écrit : > On Sunday, 15 April 2012 at 02:56:21 UTC, Joseph Rushton Wakeling wrote: >>> On Saturday, 14 April 2012 at 19:51:21 UTC, Joseph Rushton Wakeling >>> wrote: GDC has all the regular gcc optimization flags available IIRC. The >> > > I notice the 2D array is declared int ct[512][2]; // C++ int ct[2][512]; // D Any particular reason for this ? May this impede the cache utilization ? As for the executable size, the D compiler links the druntime and libraries statically in the binary while I would believe g++ links them dynamically.
Re: Thread join behaviour
Le 14/04/2012 18:04, Russel Winder a écrit :
> I thought the following would terminate gracefully having printed 0..9
> in some (random) order:
>
> #! /usr/bin/env rdmd
>
> import std.algorithm ;
> import std.range ;
> import std.stdio ;
> import core.thread ;
>
> int main ( immutable string[] args ) {
> auto threads = map ! ( ( int a ) {
> void delegate ( ) f ( ) {
> return delegate ( ) { writeln ( a ) ; } ;
> }
> return new Thread ( f ) ;
> } ) ( iota ( 10 ) ) ;
> foreach ( t ; threads ) { t.start ( ) ; }
> foreach ( t ; threads ) { t.join ( ) ; }
> return 0 ;
> }
>
> However, this does not happen, at least with 2.059 on Linux as per
> Debian Unstable. Instead I get:
>
> 1
> 2
> 4
> 5
> 8
> 3
> 7
> 6
> 9
> 0
> core.thread.ThreadException@src/core/thread.d(906): Unable to join
> thread
>
>
> /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(_Dmain+0x83)
> [0x425edb]
>
> /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
> (C) int rt.dmain2.main(int, char**).void runMain()+0x17) [0x429bab]
>
> /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
> (C) int rt.dmain2.main(int, char**).void tryExec(scope void
> delegate())+0x23) [0x42952b]
>
> /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
> (C) int rt.dmain2.main(int, char**).void runAll()+0x3d) [0x429bf9]
>
> /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
> (C) int rt.dmain2.main(int, char**).void tryExec(scope void
> delegate())+0x23) [0x42952b]
>
> /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(main+0xd3)
> [0x4294c3]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)
> [0x7f1ed17f8ead]
>
>
> I think I must be having a dumb moment as my reaction continues to be
> WTF.
>
This works:
int main ( immutable string[] args ) {
auto threadgroup = new ThreadGroup();
void delegate ( ) f (int a ) {
return delegate ( ) { writeln ( a ) ; } ;
}
for ( int n = 0; n < 10; n++ ) {
threadgroup.create(f(n));
}
threadgroup.joinAll( );
return 0 ;
}
Threads are tracked by the threadgroup, which knows who can be joined.
Re: D 50% slower than C++. What I'm doing wrong?
Le 14/04/2012 21:53, q66 a écrit : > On Saturday, 14 April 2012 at 19:05:40 UTC, ReneSac wrote: >> I have this simple binary arithmetic coder in C++ by Mahoney and >> translated to D by Maffi. I added "notrow", "final" and "pure" and >> "GC.disable" where it was possible, but that didn't made much >> difference. Adding "const" to the Predictor.p() (as in the C++ >> version) gave 3% higher performance. Here the two versions: >> >> http://mattmahoney.net/dc/ <-- original zip >> >> http://pastebin.com/55x9dT9C <-- Original C++ version. >> http://pastebin.com/TYT7XdwX <-- Modified D translation. >> >> The problem is that the D version is 50% slower: >> >> test.fpaq0 (16562521 bytes) -> test.bmp (33159254 bytes) >> >> Lang| Comp | Binary size | Time (lower is better) >> C++ (g++) - 13kb - 2.42s (100%) -O3 -s >> D(DMD) - 230kb - 4.46s (184%) -O -release -inline >> D(GDC) -1322kb - 3.69s (152%) -O3 -frelease -s >> >> >> The only diference I could see between the C++ and D versions is that >> C++ has hints to the compiler about which functions to inline, and I >> could't find anything similar in D. So I manually inlined the encode >> and decode functions: >> >> http://pastebin.com/N4nuyVMh - Manual inline >> >> D(DMD) - 228kb - 3.70s (153%) -O -release -inline >> D(GDC) -1318kb - 3.50s (144%) -O3 -frelease -s >> >> Still, the D version is slower. What makes this speed diference? Is >> there any way to side-step this? >> >> Note that this simple C++ version can be made more than 2 times faster >> with algoritimical and io optimizations, (ab)using templates, etc. So >> I'm not asking for generic speed optimizations, but only things that >> may make the D code "more equal" to the C++ code. > > I wrote a version http://codepad.org/phpLP7cx based on the C++ one. > > My commands used to compile: > > g++46 -O3 -s fpaq0.cpp -o fpaq0cpp > dmd -O -release -inline -noboundscheck fpaq0.d > > G++ 4.6, dmd 2.059. > > I did 5 tests for each: > > test.fpaq0 (34603008 bytes) -> test.bmp (34610367 bytes) > > The C++ average result was 9.99 seconds (varying from 9.98 to 10.01) > The D average result was 12.00 seconds (varying from 11.98 to 12.01) > > That means there is 16.8 percent difference in performance that would be > cleared out by usage of gdc (which I don't have around currently). The code is nearly identical (there is a slight difference in update(), where he accesses the array once more than you), but the main difference I see is the -noboundscheck compilation option on DMD.
Re: Sampling algorithms for D
On Thursday, 12 April 2012 at 16:59:31 UTC, Joseph Rushton Wakeling wrote: On 12/04/12 16:45, Joseph Rushton Wakeling wrote: What I thought I'd do is implement some clever algorithms for random sampling which I've already done in a C based on the GNU Scientific Library. I noticed that there is already a randomSample class in std.random, which by the look of it is using Knuth's Algorithm S. Would there be any interest in my adapting Vitter's Algorithms A and D (as in my library) for Phobos in order to make this function more efficient? I think there is always interest for better efficiency. You may submit your patches to Don Clugston for review.
Re: Spurious imports in Phobos ?
Le 09/11/2011 14:50, Jacob Carlborg a écrit :
2. what is your opinion about public import ? In C++, "hidden" or
"implicit" #includes is a common source of compilation problems (order
of #includes), I tend to think it's a bad thing.
Sometimes public imports are useful. It's possible to emulate Java's
import foo.* using public imports:
// a._.d
public import a.foo;
public import a.bar;
// foobar.d
import a._;
It can also be useful to have public imports if you have a module with
array functions and a module with string functions. Then the string
module can publicly import the array module since all(most) array
functions will work with strings as well.
As I said, this is considered sloppy programming, and both in Java and
in Python ("from xxx import *"), this practice is highly discouraged.
This is because you bind modules together more than necessary.
If you need in module A name B.b and deprecate B.b later, then there is
no reason to have imported everything from B.
In Java, the IDE does the work of importing the exact packages/classes
needed for you, but in Python, you have to do it by hand. It seems that
it would be just as bad in D as in Python since compilation errors don't
appear until templates are instantiated.
Dude
Database API
Hello, what is the currently DB API considered usable today ? http://prowiki.org/wiki4d/wiki.cgi?DatabaseBindings#ODBC d-dbapi looked quite decent, but the source code is no longer available :( Thank you Dude
Re: Spurious imports in Phobos ?
Le 09/11/2011 14:15, Trass3r a écrit : 2. what is your opinion about public import ? In C++, "hidden" or "implicit" #includes is a common source of compilation problems (order of #includes), I tend to think it's a bad thing. It can be quite useful. I use it often for C library wrappers. As soon as you import the wrapper code you automatically import the bindings to be able to use constants etc. I agree it's useful in this special case, but in the general case, I think it encourages sloppy programming: it binds modules together more than necessary, and it seems that once public import is used, it can be very hard to remove it afterward.
Re: Spurious imports in Phobos ?
Le 09/11/2011 13:15, Jacob Carlborg a écrit : Phobos contains a lot of templates and if a template isn't instantiated it won't be compiled. Meaning there can be hidden compile errors if you start to remove imports and they will not show until a template that uses something from the import is instantiate. I see, but then 1. is there a systematic procedure to know if a an import is really needed ? 2. what is your opinion about public import ? In C++, "hidden" or "implicit" #includes is a common source of compilation problems (order of #includes), I tend to think it's a bad thing.
Re: Spurious imports in Phobos ?
Le 09/11/2011 10:14, Somedude a écrit : > > My question is: how do we know if std.range, std.regex, std.traits and > std.algorithm are spurious imports or if we can (and threfore should) > remove them safely from std.string ? > > Dude I meant: how do we know if std.range, std.regex, std.traits and > std.algorithm are necessary imports or if we can (and threfore should) > remove them safely from std.string ?
Spurious imports in Phobos ?
Hello, When I display the dependencies with "dmd -deps=depends", I see that simply importing std.stdio imports dozens of modules, among which std.ranges, std.datetime, std.c.windows.winsock, std.regex, etc In fact, the depends file is 433 lines long. I noticed that std.string imports quite a lot of stuff. Here is a copypasta of the code: import core.exception : onRangeError; import core.vararg, core.stdc.stdlib, core.stdc.string, std.algorithm, std.ascii, std.conv, std.exception, std.format, std.functional, std.metastrings, std.range, std.regex, std.traits, std.typetuple, std.uni, std.utf; //Remove when repeat is finally removed. They're only here as part of the //deprecation of these functions in std.string. public import std.algorithm : startsWith, endsWith, cmp, count; public import std.array : join, split; So as an experiment, I tried to remove a few imports: std.range, std.regex, std.traits and std.algorithm as well as the two lines of public import. To my surprise, it still compiles ! The depends file goes down to 402 lines, but the executable size is understandably not reduced because all the removed dependencies are still used elsewhere. Then I thought this may be due to public imports from other modules, which makes me think that public imports are a bad idea, as we can compile a module only because we imported unknowingly a namespace from imported modules. My question is: how do we know if std.range, std.regex, std.traits and std.algorithm are spurious imports or if we can (and threfore should) remove them safely from std.string ? Dude
