Re: unit testing
- Jonathan M Davis wrote: >LOL. Goodness no. They're done by hand. I'm currently reworking std.datetime's >unit tests, and it's very time consuming (since it's a large module with lots >of tests). I don't know how you'd get a framework to generate what I want >anyway. The fact that D has unit testing built in like it does is fantastic, >but it is fairly simplistic. I'm new to this concept of uni testing. Thanks for the help :)
Re: Container access in std.container
>Your environment looks wrong. Note that > >/usr/lib/gcc/x86_64-linux-gnu/4.3.5/../../../../include/d/4.3.5 > >is equivalent to > >/usr/include/d/4.3.5 I copied container.d to /usr/include/d/4.3.5/std . But the problem is still there :s
Re: Container access in std.container
Steven wrote: >Your environment looks wrong. Note that > >/usr/lib/gcc/x86_64-linux-gnu/4.3.5/../../../../include/d/4.3.5 > >is equivalent to > >/usr/include/d/4.3.5 > >so I expect it can't find container.d Really sorry for being a burden, I'm new to D. How can I fix this Environment?
Re: Container access in std.container
Your environment looks wrong. Note that /usr/lib/gcc/x86_64-linux-gnu/4.3.5/../../../../include/d/4.3.5 is equivalent to /usr/include/d/4.3.5 so I expect it can't find container.d On 29/03/11 04:54, Ishan Thilina wrote: I am using DGC due to the problems I'm witnessing with DMD. I tried a similar approach. But the following error comes. " structures.d:4: Error: module container cannot read file 'std/container.d' import path[0] = /usr/lib/gcc/x86_64-linux-gnu/4.3.5/../../../../include/d/4.3.5/x86_64-linux-gnu import path[1] = /usr/lib/gcc/x86_64-linux-gnu/4.3.5/../../../../include/d/4.3.5 " I dont know what is wrong. I'll try to compile in Windows and let you know. @David : Thanks for the clarifications :)
Re: clear()
On Mon, 28 Mar 2011 16:57:17 +0200, Kai Meyer wrote: On 03/25/2011 01:10 PM, Dr.Smith wrote: To empty many arrays of various types, rather than: clear(arr1); clear(arr2); ... clear(arrN); is there something like: clear(ALL); No, but perhaps you can do a: foreach(a; ALL) a.clear() That should probably be foreach ( a; ALL ) clear( a ); -- Simen
Re: Container access in std.container
>I am using GDC due to the problems I'm witnessing with DMD. I tried a similar >approach. But the following error comes. > >" > >structures.d:4: Error: module container cannot read file 'std/container.d' >import path[0] = >/usr/lib/gcc/x86_64-linux-gnu/4.3.5/../../../../include/d/4.3.5/x86_64-linux-gnu >import path[1] = >/usr/lib/gcc/x86_64-linux-gnu/4.3.5/../../../../include/d/4.3.5 > >" > >I dont know what is wrong. I'll try to compile in Windows and let you know. > > A module std.container cannot be found error comes in windows too. I'm using GDC to compile in linux and DMD to compile in windows. I'm really confused about this :s
Re: Assertion failure: '!vthis->csym' on line 703 in file 'glue.c'
nrgyzer wrote: Hey guys, I got "Assertion failure: '!vthis->csym' on line 703 in file 'glue.c'" after I add "LinkList!(uint) myList;" to my source file. I figured out that the same bug was already reported on http://lists.puremagic.com/ pipermail/digitalmars-d-bugs/2010-October/019237.html Ticket 4129 describes a bug in glue.c but for DMD 1.x and I'm using DMD 2.052. It's still the same bug. The source code for the backend is the same for all versions of DMD. The reported line number might change slightly (eg, might be line 691 on an old DMD version).
Re: unit testing
On 2011-03-28 11:29, Ishan Thilina wrote: > @David: > > No, my question was not about running them,but on how that code was > generated. I thought they were auto generated using a unitest framework > :). Your answer clarifies everything. Thank you..! :-) LOL. Goodness no. They're done by hand. I'm currently reworking std.datetime's unit tests, and it's very time consuming (since it's a large module with lots of tests). I don't know how you'd get a framework to generate what I want anyway. The fact that D has unit testing built in like it does is fantastic, but it is fairly simplistic. - Jonathan M Davis
Re: How do you use BinaryHeap with Array (or just make a growable heap)?
On 2011-03-28 20:24:55 +0200, Jonathan M Davis said: Well, Array definitely shouldn't be a random access range. The range for it (which you'd typically get by slicing it) would be random access, but the container itself isn't a range of any kind. Containers aren't ranges (barring the oddities of dynamic arrays). I've never used BinaryHeap, but glancing at it, my guess would be that the correct solution (if you want to use Array with it) is to create an Array and then pass its range to heapify: Array!uint a; //... put stuff in a. auto heap = heapify(a[]); I'm not sure if that's growable or not though. Hm. I can't even get the slicing to work: /path/to/phobos/std/container.d(2436): Error: function std.container.Array!(uint).Array.Range.opSlice (uint a, uint b) is not callable using argument types () Glancing at BinaryHeap, it'll work with arrays though, so you don't need to use Array. Hm. The docs say "If Store is a range, the BinaryHeap cannot grow beyond the size of that range. If Store is a container that supports insertBack, the BinaryHeap may grow by adding elements to the container." So it seems that a container (such as Array, which has insertBack) should be usable, according to the docs. And an array/slice would not be growable. (At least, it isn't growable in practice.) See also: http://www.digitalmars.com/d/archives/digitalmars/D/std.algorithm.BinaryHeap_88811.html What I'm looking for is a completely standard priority queue, where I can add and remove objects, and not have to know the maximum size beforehand. I'd also like to have tuple entries, but it seems that BinaryHeap has trouble with that as well... I don't know what the ideal container to use with a BinaryHeap is though. Also, in my experience, Array is pretty buggy at this point, so I'm not sure how far you'll get with it. Yeah, it seems to be. At the moment, I've just reimplemented BinaryHeap myself (with a subset of the Phobos API), so that it can handle arrays of tuples (which I couldn't get std.container.BinaryHeap to accept). I then wrapped it in a PriorityQueue class, which takes care of resizing the array (and having BinaryHeap switch to the possibly reallocated new one). Not an ideal solution, but at least it works. -- Magnus Lie Hetland http://hetland.org
Re: unit testing
@David: No, my question was not about running them,but on how that code was generated. I thought they were auto generated using a unitest framework :). Your answer clarifies everything. Thank you..! :-)
Re: How do you use BinaryHeap with Array (or just make a growable heap)?
On 2011-03-28 05:35, Magnus Lie Hetland wrote: > I need a (growable) binary heap, and I'm trying to avoid writing one > myself (which isn't too hard, of course :) ... but for some reason I > can't figure out how to use Phobos to do it. > > I've seen stated (e.g., by Andrei and in the docs) that the standard > way is combining BinaryHeap with an Array. Which is fine with me. > Except I can't make it work. E.g., I try: > > Array!uint A; > auto Q = heapify(A); > > The error is > > /path/to/phobos/std/container.d(2658): Error: template instance > BinaryHeap!(Array!(uint)) does not match template declaration > BinaryHeap(Store,alias less = "a < b") if (isRandomAccessRange!(Store) > > || isRandomAccessRange!(typeof(Store.init[]))) > > /path/to/phobos/std/container.d(2658): Error: BinaryHeap!(Array!(uint)) > is used as a type > > When I check it out, it seems that isRandomAccessRange!(Array!uint) > returns false (and it doesn't, AFAIK, have an init), which means that > the error makes sense. > > Does this mean... > > 1. That Array isn't, and shouldn't be, a random access range? > 2. That Array can't, and shouldn't be (despite official statements to > the contrary) be used with BinaryHeap? > > (I suspect the answer to both is "you're doing it wrong" ;) > > And, of course, my main question: > > 3. How do you (canonically) make a growable heap using Phobos? Well, Array definitely shouldn't be a random access range. The range for it (which you'd typically get by slicing it) would be random access, but the container itself isn't a range of any kind. Containers aren't ranges (barring the oddities of dynamic arrays). I've never used BinaryHeap, but glancing at it, my guess would be that the correct solution (if you want to use Array with it) is to create an Array and then pass its range to heapify: Array!uint a; //... put stuff in a. auto heap = heapify(a[]); I'm not sure if that's growable or not though. Glancing at BinaryHeap, it'll work with arrays though, so you don't need to use Array. I don't know what the ideal container to use with a BinaryHeap is though. Also, in my experience, Array is pretty buggy at this point, so I'm not sure how far you'll get with it. - Jonathan M Davis
Re: Container access in std.container
I am using DGC due to the problems I'm witnessing with DMD. I tried a similar approach. But the following error comes. " structures.d:4: Error: module container cannot read file 'std/container.d' import path[0] = /usr/lib/gcc/x86_64-linux-gnu/4.3.5/../../../../include/d/4.3.5/x86_64-linux-gnu import path[1] = /usr/lib/gcc/x86_64-linux-gnu/4.3.5/../../../../include/d/4.3.5 " I dont know what is wrong. I'll try to compile in Windows and let you know. @David : Thanks for the clarifications :)
Re: null Vs [] return arrays
Steven Schveighoffer: > So essentially, you are getting the same thing, but using [] is slower. It seems I was right then, thank you and Kagamin for the answers. Bye, bearophile
Re: Little quiz
Kai Meyer: > auto f2 = foo().tupleof; Thank you. From the output of this line of code the problem seems not caused by the static foreach. Bye, bearophile
Re: std.conv.to can't convert to bool?
It can't implicitly convert an int to a bool. The C function returns an int.
Re: object.d: Error: module object is in file 'object.d' which cannot be read
On 03/28/2011 04:49 PM, Ishan Thilina wrote: now I get a whole lot more errors :s. " ishan@ishan-Ubu-I1464:~/Geany Projects$ dmd untitle.d /usr/include/d/dmd/phobos/object.d(51): C-style function pointer and pointer to array syntax is deprecated. Use 'function' to declare function pointers /usr/include/d/dmd/phobos/std/format.d(672): no identifier for declarator inout(fakevalue) /usr/include/d/dmd/phobos/std/c/stdlib.d(43): C-style function pointer and pointer to array syntax is deprecated. Use 'function' to declare function pointers /usr/include/d/dmd/phobos/std/c/stdlib.d(59): C-style function pointer and pointer to array syntax is deprecated. Use 'function' to declare function pointers /usr/include/d/dmd/phobos/std/c/linux/linux.d(558): C-style function pointer and pointer to array syntax is deprecated. Use 'function' to declare function pointers /usr/include/d/dmd/phobos/std/c/linux/linux.d(574): C-style function pointer and pointer to array syntax is deprecated. Use 'function' to declare function pointers " I'm trying to compile the following simple code. As you can see it should work without any problem. " import std.stdio; int main() { writefln("Hello world"); return 0; } I have no idea why and where your issues in using D with dmd come from. AFAIK, it just works out of the box if you use release versions. Just 2 notes about the piece of code: First, you often do not need in D a program result code (int). Second, writefln, as opposed to writeln, expects a format string as first argument. void main () { writeln("Hello, world!"); auto userName = "Otto"; writefln("Hello, %s!", userName); } Denis -- _ vita es estrany spir.wikidot.com
Re: std.conv.to can't convert to bool?
Andrej Mitrovic Wrote: > Wow not a minute later and I get bitten by my own solution. A C > function returned 1 for a supported feature, and -1 otherwise. And of > course -1 got converted to true, so then I had a bug in my code. > > Damn silly C functions which return -1 when they should return 0. > > Or damn me for not RTFM'ing. Yeah, so the reason it doesn't do that conversion is because it will bite you. Actually D already uses non-zero as true. Why do you need to cast it?
Re: unit testing
On 3/28/11 5:55 PM, Caligo wrote: and how does one do unit testing with GDC? It works fine with DMD, but GDC doesn't do unit testing when -unittest is supplied. -funittest, IIRC. David
Re: Container access in std.container
On 2011-03-28 07:48, David Nadlinger wrote: > --- > import std.container; > import std.stdio; > > void main() { > auto rb = redBlackTree(4, 1, 2, 3); > foreach (e; rb) { > writeln(e); > } > } > --- I believe that the redBlackTree function is only in the git repository at present (so, it'll be in the next release), so if he's using dmd 2.052, that particular way of creating a RedBlackTree won't work. - Jonatahn M Davis
Re: unit testing
On Mon, Mar 28, 2011 at 9:34 AM, David Nadlinger wrote: > On 3/28/11 4:23 PM, Ishan Thilina wrote: >> >> I see that almost all of the phobos library files have "unittests". Were >> these >> unit tests were created using some framework? If so, then what is it? >> >> Thank you...! > > No, these unit test were just written by hand while writing the > corresponding pieces of code, and extended after a bug was fixed which they > previously missed. > > Or was your question related to actually running them? > > David > and how does one do unit testing with GDC? It works fine with DMD, but GDC doesn't do unit testing when -unittest is supplied.
Re: Where does the template parameter E come from?
On 28.03.2011 17:07, David Nadlinger wrote: On 3/28/11 4:54 PM, simendsjo wrote: When running compose with two arguments, the implementation uses the template parameter E. I don't understand what's going on here as E isn't submitted to the template - what type is E? […] typeof({ E a; return fun0(fun1(a)); }()) doIt(E)(E a) { […] } doIt is a function template, so E will be deduced to be whatever type the passed argument is – you won't notice the extra »template layer« as E is automatically inferred from the argument. For better understanding, you might want to look at the definition like this: --- template composeImpl(fun...) { […] template doIt(E) { typeof({ E a; return fun0(fun1(a)); }()) doIt(E a) { […] } } } --- David Thanks. That seems like a good way of mentally mapping template usage until it comes more naturally.
Re: Where does the template parameter E come from?
On 3/28/11 5:14 PM, simendsjo wrote: On 28.03.2011 17:07, David Nadlinger wrote: On 3/28/11 4:54 PM, simendsjo wrote: When running compose with two arguments, the implementation uses the template parameter E. I don't understand what's going on here as E isn't submitted to the template - what type is E? […] typeof({ E a; return fun0(fun1(a)); }()) doIt(E)(E a) { […] } doIt is a function template, so E will be deduced to be whatever type the passed argument is – you won't notice the extra »template layer« as E is automatically inferred from the argument. For better understanding, you might want to look at the definition like this: --- template composeImpl(fun...) { […] template doIt(E) { typeof({ E a; return fun0(fun1(a)); }()) doIt(E a) { […] } } } --- David Thanks. That seems like a good way of mentally mapping template usage until it comes more naturally. Even more, due to the eponymous template »trick«, there is almost no difference between the forms – with the important exception being that function templates enjoy IFTI (implicit function template instantiation), the feature which allows you to omit the type parameter(s) if it can be deduced from the arguments. David
Re: Where does the template parameter E come from?
On 3/28/11 4:54 PM, simendsjo wrote: When running compose with two arguments, the implementation uses the template parameter E. I don't understand what's going on here as E isn't submitted to the template - what type is E? […] typeof({ E a; return fun0(fun1(a)); }()) doIt(E)(E a) { […] } doIt is a function template, so E will be deduced to be whatever type the passed argument is – you won't notice the extra »template layer« as E is automatically inferred from the argument. For better understanding, you might want to look at the definition like this: --- template composeImpl(fun...) { […] template doIt(E) { typeof({ E a; return fun0(fun1(a)); }()) doIt(E a) { […] } } } --- David
Re: Where does the template parameter E come from?
On 28.03.2011 16:54, simendsjo wrote: When running compose with two arguments, the implementation uses the template parameter E. I don't understand what's going on here as E isn't submitted to the template - what type is E? I've also seen this in unary/binaryFun using ElementType. template compose(fun...) { alias composeImpl!(fun).doIt compose; } // Implementation of compose template composeImpl(fun...) { static if (fun.length == 1) { static if (is(typeof(fun[0]) : string)) alias unaryFun!(fun[0]) doIt; else alias fun[0] doIt; } else static if (fun.length == 2) { // starch static if (is(typeof(fun[0]) : string)) alias unaryFun!(fun[0]) fun0; else alias fun[0] fun0; static if (is(typeof(fun[1]) : string)) alias unaryFun!(fun[1]) fun1; else alias fun[1] fun1; // protein: the core composition operation typeof({ E a; return fun0(fun1(a)); }()) doIt(E)(E a) { return fun0(fun1(a)); } } else { // protein: assembling operations alias composeImpl!(fun[0], composeImpl!(fun[1 .. $]).doIt).doIt doIt; } } I think I get it. doIt becomes the function being called. So E is the type of the parameter being used when calling compose.
Re: Little quiz
On 03/24/2011 06:50 PM, bearophile wrote: A little quiz for people here: guess the output of this little D2 program (it compiles correctly and doesn't crash at run time, so it's a fair question): import std.typecons: tuple; import std.c.stdio: printf; auto foo() { printf("foo\n"); return tuple(1, 2); } void main() { foreach (x; foo().tupleof) printf("%d\n", x); } Bye, bearophile That's pretty cool :) Seems like we should be able to expect the same behavior in all of these, but that doesn't appear to be the case at all. import std.typecons: tuple; import std.c.stdio: printf; auto foo() { printf("foo\n"); return tuple(1, 2); } void main() { printf("-\n"); foreach (x; foo().tupleof) printf("%d\n", x); printf("-\n"); auto f = foo(); printf("-\n"); foreach (x; f.tupleof) printf("%d\n", x); printf("-\n"); auto f2 = foo().tupleof; printf("-\n"); foreach (x; f2) printf("%d\n", x); printf("-\n"); }
Re: clear()
On 03/25/2011 01:10 PM, Dr.Smith wrote: To empty many arrays of various types, rather than: clear(arr1); clear(arr2); ... clear(arrN); is there something like: clear(ALL); No, but perhaps you can do a: foreach(a; ALL) a.clear() But that would require you having an iterable sequence that contains all of your arrays, which may or may not be worth your time to explore. Also, after "clear(arr)", will "arr ~= value" assign starting from element 0? Yes
Where does the template parameter E come from?
When running compose with two arguments, the implementation uses the template parameter E. I don't understand what's going on here as E isn't submitted to the template - what type is E? I've also seen this in unary/binaryFun using ElementType. template compose(fun...) { alias composeImpl!(fun).doIt compose; } // Implementation of compose template composeImpl(fun...) { static if (fun.length == 1) { static if (is(typeof(fun[0]) : string)) alias unaryFun!(fun[0]) doIt; else alias fun[0] doIt; } else static if (fun.length == 2) { // starch static if (is(typeof(fun[0]) : string)) alias unaryFun!(fun[0]) fun0; else alias fun[0] fun0; static if (is(typeof(fun[1]) : string)) alias unaryFun!(fun[1]) fun1; else alias fun[1] fun1; // protein: the core composition operation typeof({ E a; return fun0(fun1(a)); }()) doIt(E)(E a) { return fun0(fun1(a)); } } else { // protein: assembling operations alias composeImpl!(fun[0], composeImpl!(fun[1 .. $]).doIt).doIt doIt; } }
Re: object.d: Error: module object is in file 'object.d' which cannot be read
@Jonathan: Yeah I checked. It's there :s. I dont know what has gone wrong, but I'm using the default settings . I have GDC installed too. Can this have any connection with this problem( just a wild guess ) ? @Jacob: I wasn't sure about which libraries you were talking about. The only lib set I left out was ia32-libs. So I installed it too.That didn't solve the problem. So I tried to install the deb file by force. "sudo dpkg -i --force-architecture dmd***.dmd" now I get a whole lot more errors :s. " ishan@ishan-Ubu-I1464:~/Geany Projects$ dmd untitle.d /usr/include/d/dmd/phobos/object.d(51): C-style function pointer and pointer to array syntax is deprecated. Use 'function' to declare function pointers /usr/include/d/dmd/phobos/std/format.d(672): no identifier for declarator inout(fakevalue) /usr/include/d/dmd/phobos/std/c/stdlib.d(43): C-style function pointer and pointer to array syntax is deprecated. Use 'function' to declare function pointers /usr/include/d/dmd/phobos/std/c/stdlib.d(59): C-style function pointer and pointer to array syntax is deprecated. Use 'function' to declare function pointers /usr/include/d/dmd/phobos/std/c/linux/linux.d(558): C-style function pointer and pointer to array syntax is deprecated. Use 'function' to declare function pointers /usr/include/d/dmd/phobos/std/c/linux/linux.d(574): C-style function pointer and pointer to array syntax is deprecated. Use 'function' to declare function pointers " I'm trying to compile the following simple code. As you can see it should work without any problem. " import std.stdio; int main() { writefln("Hello world"); return 0; } " "
Re: Container access in std.container
On 3/28/11 4:17 PM, Ishan Thilina wrote: I know that D has some Containers implemented by default( such as a a List, Red-black tree, Array). In C++ these data structures can be used as follows. #include int main(){ std::vector myVector; std::vector::iterator myIterator; } Then I can use "myIterator" to manipulate "myVector". But in D the containers are embedded in the std.container( as far as I understood it) and I can't do "import std.container" too. So how can I access the built in containers? Hi Ishan, First, to avoid confusion in further discussions, the term »built-in« is usually used when referring to the types which are part of the D language itself (e.g. the built-in arrays and associative arrays, i.e. int[] and int[string]). The types std.container, on the other hand, could be in any other library as well, so I wouldn't call them built-in, but rather just Phobos containers. What exactly do you mean by »I can't do "import std.container"«? Assuming you have a working D2 environment, you should be able to use them like this: --- import std.container; import std.stdio; void main() { auto rb = redBlackTree(4, 1, 2, 3); foreach (e; rb) { writeln(e); } } --- To get a range over all elements (in an container-defined order), use the slicing operator [], e.g. rb[] – if I remember correctly, the std.container ddoc page has more information on commonly supported operations. David
Re: unit testing
On 3/28/11 4:23 PM, Ishan Thilina wrote: I see that almost all of the phobos library files have "unittests". Were these unit tests were created using some framework? If so, then what is it? Thank you...! No, these unit test were just written by hand while writing the corresponding pieces of code, and extended after a bug was fixed which they previously missed. Or was your question related to actually running them? David
unit testing
I see that almost all of the phobos library files have "unittests". Were these unit tests were created using some framework? If so, then what is it? Thank you...!
Re: Sample source code for D
@Denis: The tutorials in the dsource were very helpful. I have read most of those articles that are in the prowiki( the ones you have given links to). As you have stated they are more suited for beginners :-/ . Thank you for the help :)
Container access in std.container
I know that D has some Containers implemented by default( such as a a List, Red-black tree, Array). In C++ these data structures can be used as follows. #include int main(){ std::vector myVector; std::vector::iterator myIterator; } Then I can use "myIterator" to manipulate "myVector". But in D the containers are embedded in the std.container( as far as I understood it) and I can't do "import std.container" too. So how can I access the built in containers? Thank you..!
Re: null Vs [] return arrays
On Sun, 27 Mar 2011 09:37:47 -0400, bearophile wrote: I have compiled this little D2 program: int[] foo() { return []; } int[] bar() { return null; } void main() {} Using DMD 2.052, dmd -O -release -inline test2.d This is the asm of the two functions: _D5test23fooFZAicomdat L0: pushEAX mov EAX,offset FLAT:_D11TypeInfo_Ai6__initZ push0 pushEAX callnear ptr __d_arrayliteralT mov EDX,EAX add ESP,8 pop ECX xor EAX,EAX ret _D5test23barFZAicomdat xor EAX,EAX xor EDX,EDX ret Is this expected and desired? Isn't it better to compile the foo() as bar()? Probably. The runtime that allocates an array looks like this (irrelevant parts collapsed): extern (C) void* _d_arrayliteralT(TypeInfo ti, size_t length, ...) { auto sizeelem = ti.next.tsize();// array element size void* result; ... if (length == 0 || sizeelem == 0) result = null; else { ... } return result; } So essentially, you are getting the same thing, but using [] is slower. -Steve
Re: inline functions
On Fri, 25 Mar 2011 22:04:20 -0400, Caligo wrote: T[3] data; T dot(const ref Vector o){ return data[0] * o.data[0] + data[1] * o.data[1] + data[2] * o.data[2]; } T LengthSquared_Fast(){ return data[0] * data[0] + data[1] * data[1] + data[2] * data[2]; } T LengthSquared_Slow(){ return dot(this); } The faster LengthSquared() is twice as fast, and I've test with GDC and DMD. Is it because the compilers don't inline-expand the dot() function call? I need the performance, but the faster version is too verbose. ref parameters used to make functions not be inlined, but apparently that was fixed: http://d.puremagic.com/issues/show_bug.cgi?id=2008 The best thing to do is check the disassembly to see if the call is being inlined. Also, if you want more help besides guessing, a complete working program is good to have. -Steve
How do you use BinaryHeap with Array (or just make a growable heap)?
I need a (growable) binary heap, and I'm trying to avoid writing one myself (which isn't too hard, of course :) ... but for some reason I can't figure out how to use Phobos to do it. I've seen stated (e.g., by Andrei and in the docs) that the standard way is combining BinaryHeap with an Array. Which is fine with me. Except I can't make it work. E.g., I try: Array!uint A; auto Q = heapify(A); The error is /path/to/phobos/std/container.d(2658): Error: template instance BinaryHeap!(Array!(uint)) does not match template declaration BinaryHeap(Store,alias less = "a < b") if (isRandomAccessRange!(Store) || isRandomAccessRange!(typeof(Store.init[]))) /path/to/phobos/std/container.d(2658): Error: BinaryHeap!(Array!(uint)) is used as a type When I check it out, it seems that isRandomAccessRange!(Array!uint) returns false (and it doesn't, AFAIK, have an init), which means that the error makes sense. Does this mean... 1. That Array isn't, and shouldn't be, a random access range? 2. That Array can't, and shouldn't be (despite official statements to the contrary) be used with BinaryHeap? (I suspect the answer to both is "you're doing it wrong" ;) And, of course, my main question: 3. How do you (canonically) make a growable heap using Phobos? -- Magnus Lie Hetland http://hetland.org
Re: Sample source code for D
On 03/28/2011 05:43 AM, Ishan Thilina wrote: @ David: I'm looking for example code that explains specific pieces of functionality :) @Lutger: Those two links were really helpful :). Thank you :) There are tutorial examples of D code at DSource; they were initially D1, but many of them are compatible or translated to D2; rather good place to start: http://www.dsource.org/projects/tutorials On the "official" D wiki, you'll find some useful material and links (tutorial, example, howto); unfortunatly, some of those materials are rather light: http://prowiki.org/wiki4d/wiki.cgi?DevelopmentWithD http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial http://prowiki.org/wiki4d/wiki.cgi?HowTo http://prowiki.org/wiki4d/wiki.cgi?ExamplesRoadmap Also useful comparisons: http://prowiki.org/wiki4d/wiki.cgi?LanguagesVersusD http://en.wikibooks.org/wiki/D_Transition_Guide Denis -- _ vita es estrany spir.wikidot.com
Re: null Vs [] return arrays
bearophile Wrote: > Kagamin: > > > [] is not null, it's an array of 0 elements, what is done exactly. > > edx points to the allocated array. > > I don't understand what you say. I think the caller of foo() and bar() > receive the same thing, two empty registers. I think that cast(int[])null and > cast(int[])[] are the same thing for D. That's a mistake. Well, if there's no differnce for you, you can use either of them. What's the problem?
Re: object.d: Error: module object is in file 'object.d' which cannot be read
On 2011-03-27 23:05, Jonathan M Davis wrote: On 2011-03-27 13:20, Jacob Carlborg wrote: On 2011-03-27 21:24, Ishan Thilina wrote: @Jacob: An error comes when the " ./dvm install dvm" command is given. " ./dvm: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory You don't have libz installed? Oh, you're running 64bit, you need to install 32bit libraries. I also forgot to mention that DVM currently only installs the 32bit version of DMD. The 64bit version is quite new, don't know if it's experimental, alpha or beta. Probably alpha. I believe that it mostly works, but there are still plenty of bugs to find, I'm sure. However, depending on what you mean by "installing" the compiler, there is no 32-bit vs 64-bit version. Only the libraries differ. There is only a 32-bit binary for the compiler, and you pass it -m64 if you want it to compile 64-bit binaries. So, if your tool deals with the compiler only, then 32-bit vs 64-bit is currently a moot point. On the other hand, if it deals with the standard libraries too (as it probably does), then 32-bit vs 64-bit _is_ an issue, but it isn't an issue for the compiler itself. And unless you're not using the standard dmd.conf as part of switching compilers, there would already be a difference in the library layout once 64-bit compilation was introduced, since the 32-bit Phobos was moved from dmd2/linux/lib to dmd2/linux/lib32 (with the 64-bit version in dmd2/linux/lib64). And if you made the lib32 change, then having it work with 64-bit is likely trivial. And if you didn't make such a change, you're going to have to eventually. Personally, I don't see tha alpha quality of the 64-bit code generation to be a reason not to support it. It's been released. But then again, I don't use your tool at all and find no need for it, so it's not like I'm one of your users. - Jonathan M Davis What I meant with "installing" is that he shouldn't expect to be able to produce 64bit binaries with a DMD installed with my tool. I have changed the tool to handle the lib -> lib32/lib64 change. It is a trivial change to make the 64bit installation possible. The reason I have made that change yet is a couple of reasons: * I was planning to refactor the whole tool into a library and a tool using that library. I was planning to wait with all the new functionality until after the refactoring was done. * I'm not 100% how I want the default behavior to be. When the 64bit is mature enough that will probably be the default when running on a 64bit machine and otherwise 32bit. I will also provide an option to installed the non-native library as well. The question is, what should be the default behavior now on a 64bit machine, 32bit or 64bit? Yes, I do have a custom dmd.conf. No reason to put the "bin" folder in an extra folder just because that's the layout in the zip file. I guess you're right, that I shouldn't blame the current status of the 64bit code generation as a reason not to support installing it. Just thought it was easier to explain it that way the more complete explanation I gave here. I do know that the compiler can produce both 32 and 64bit binaries and the only difference is the standard library. -- /Jacob Carlborg