Re: Strange memory corruption / codegen bug?
On Sunday, 11 December 2016 at 11:58:39 UTC, ag0aep6g wrote: Try putting an `assert(childCrossPoint !is otherCrossPoint);` before the assignment. If it fails, the variables refer to the same node. That would explain how otherCrossPoint.left gets set. Furthermore, I think he is calling breed on a Tree with itself. i.e. assert(other !is this) would be a more reliable test since it won't be subject to randomness.
Re: Will the GC scan this pointer?
On Sunday, 24 April 2016 at 11:03:11 UTC, Lass Safin wrote: So the question is: Will the GC scan ptr? As you can see, it is a write-only pointer, so reading from it will cause undefined behavior (such as return data which looks like a pointer to data..), and can potentially be reallly slow. The GC will see that ptr doesn't point to memory managed by the GC and move on. Do I have to mark it with NO_SCAN each time I call glMapNamedBufferRange? No, calling setAttr on memory not managed by the GC will do nothing.
Re: Possible to write a classic fizzbuzz example using a UFCS chain?
Just for fun: // map, join, text, iota, writeln, tuple import std.algorithm, std.array, std.conv, std.range, std.stdio, std.typecons; void main() { iota(1,100) .map!(a = tuple(a, a % 3 == 0 ? 0 : 4, a % 5 == 0 ? 8 : 4)) .map!(a = a[1] == a[2] ? a[0].text : fizzbuzz[a[1] .. a[2]]) .join(, ) .writeln; }
Re: Parallelization of a large array
On Tuesday, 10 March 2015 at 20:41:14 UTC, Dennis Ritchie wrote: Hi. How to parallelize a large array to check for the presence of an element matching the value with the data? Here's a simple method (warning: has pitfalls): import std.stdio; import std.parallelism; void main() { int[] a = new int[100]; foreach (i, ref elem; a) elem = cast(int)i; bool found; foreach (elem; a.parallel) if (elem == 895639) found = true; if (found) writeln(Yes); else writeln(No); }
Re: Purity not enforced for default arguments?
On Tuesday, 10 March 2015 at 21:56:39 UTC, Xinok wrote: I'm inclined to believe this is a bug. https://issues.dlang.org/show_bug.cgi?id=11048
Re: Strange behavior of the function find() and remove()
On Sunday, 8 March 2015 at 21:34:25 UTC, Dennis Ritchie wrote: This is normal behavior? Yes it is normal, there are two potential points of confusion: - remove mutates the input range and returns a shortened slice to the range which excludes the removed element. - remove takes an index as its second argument, not an element. For more information see: https://issues.dlang.org/show_bug.cgi?id=10959
Re: why GC not work?
On Sunday, 8 February 2015 at 16:23:44 UTC, FG wrote: 2. auto buf = new byte[](1024*1024*100); now the gc can't free this buf. can i free it by manual? Yes. import core.memory; GC.free(buf.ptr); // and don't use buf afterwards That won't work, see: http://forum.dlang.org/thread/uankmwjejsitmlmrb...@forum.dlang.org
Re: why GC not work?
On Sunday, 8 February 2015 at 18:43:18 UTC, FG wrote: On 2015-02-08 at 19:15, safety0ff wrote: That won't work, see: http://forum.dlang.org/thread/uankmwjejsitmlmrb...@forum.dlang.org Perhaps it was fixed in DMD 2.066.1, because this works for me just fine: Here's the link I couldn't find earlier: https://issues.dlang.org/show_bug.cgi?id=14134
Re: why GC not work?
False pointers, current GC is not precise.
Re: Allocating aligned memory blocks?
On Friday, 12 December 2014 at 06:17:56 UTC, H. S. Teoh via Digitalmars-d-learn wrote: Is there a way to allocate GC memory blocks in D that are guaranteed to fall on OS page boundaries? I don't know about guarantees, I think that in practice, if your OS page size is 4096, any GC allocation of 4096 or greater will be page aligned. should I just forget the GC and just use posix_memalign() manually? I think it may be possible to do what you want with mmap/munmap alone (selectively map parts of the file to memory.)
Re: naked popcnt function
On Saturday, 22 November 2014 at 18:30:06 UTC, Ad wrote: Hello, I would like to write a popcnt function. This works fine ulong popcnt(ulong x) { asm { mov RAX, x ; popcnt RAX, RAX ; } } However, if I add the naked keyword ( which should improve performance? ) it doesn't work anymore and I can't figure out what change I am supposed to make ( aside from x[RBP] instead of x ) This function is going to be *heavily* used. Thanks for any help. Last time I used naked asm simply used the calling convention to figure out the location of the parameter (e.g. RCX win64, RDI linux 64, iirc.) N.B. on LDC GDC there is an intrinsic for popcnt.
Re: new(malloc) locks everything in multithreading
On Friday, 24 October 2014 at 02:51:20 UTC, tcak wrote: I don't want to blame dmd directly because as far as I see from the search I did with __lll_lock_wait_private, some C++ programs are having same problem with malloc operation as well. But still, can this be because of compiler? Looks like bug #11981 [1], which should be fixed in the latest versions of the compiler. Which version are you using? [1] https://issues.dlang.org/show_bug.cgi?id=11981
Re: Global const variables
On Tuesday, 21 October 2014 at 08:25:07 UTC, bearophile wrote: Minas Mina: Aren't pure functions supposed to return the same result every time? If yes, it is correct to not accept it. But how can main() not be pure? Or, how can't the 'a' array be immutable? Bye, bearophile There can exist a mutable reference to a's underlying memory: const int[] a; int[] b; static this() { b = [1]; a = b; }
Re: How would you dive into a big codebase
On Wednesday, 22 October 2014 at 01:21:19 UTC, Freddy wrote: Is there any advice/tips for reading medium/big D codebases? Somewhat D specific: I would consider an IDE/editor like Eclipse with DDT that can give an outline of the data structures functions names in a source file to make the files easier to digest.
Re: A significant performance difference
The following D code runs over 2x faster than the C++ code (comparing dmd no options to g++ no options.) Its not a fair comparison because it changes the order of operations. import core.stdc.stdio; const uint H = 9, W = 12; const uint[3][6] g = [[7, 0, H - 3], [1 + (1 H) + (1 (2 * H)), 0, H - 1], [3 + (1 H), 0, H - 2], [3 + (2 H), 0, H - 2], [1 + (1 H) + (2 H), 0, H - 2], [1 + (1 H) + (1 (H - 1)), 1, H - 1]]; int main() { ulong p, i, k; ulong[uint] x, y; uint l; x[0] = 1; for (i = 0; i W; ++i) { y = null; while (x.length) foreach (j; x.keys) { p = x[j]; x.remove(j); for (k = 0; k H; ++k) if ((j (1 k)) == 0) break; if (k == H) y[j H] += p; else for (l = 0; l 6; ++l) if (k = g[l][1] k = g[l][2]) if ((j (g[l][0] k)) == 0) x[j + (g[l][0] k)] += p; } x = y; } printf(%lld\n, y[0]); return 0; }
Re: D daemon GC?
On Saturday, 30 August 2014 at 17:09:41 UTC, JD wrote: Hi all, I tried to write a Linux daemon in D 2.065 (by translating one in C we use at work). My basic skeleton works well. But as soon as I start allocating memory it crashed with several 'core.exception.InvalidMemoryOperationError's. It works for me with 2.066, I do not have 2.065 installed at the moment to see if it fails on 2.065.
Re: Appender is ... slow
IIRC it manages the capacity information manually instead of calling the runtime which reduces appending overhead.
Re: What hashing algorithm is used for the D implementation of associative arrays?
On Thursday, 14 August 2014 at 13:10:58 UTC, bearophile wrote: D AAs used to be not vulnerable to collision attacks because they resolved collisions building a red-black tree for each bucket. Later buckets became linked lists for speed, Slight corrections: It was a effectively a randomized BST, it used the hash value + comparison function to place the elements in the tree. E.g. The AA's node comparison function might be: if (hash == other.hash) return value.opCmp(other.value); else if (hash other.hash) return -1; return 1; The hash function has a significant influence on how balanced the BST will be. Insertion and removal order also have performance influence since rebalancing was only done when growing the AA. It had no performance guarantees. I believe it was removed to reduce memory consumption, see the Mar 19 2010 cluster of commits by Walter Bright to aaA.d. Since GC rounds up allocations to powers of two for small objects, the additional pointer doubles the allocation size per node. A template library based AA implementation should be able to handily outperform built-in AAs and provide guarantees. Furthermore, improved memory management could be a significant win. Fun fact: The AA implementation within DMD still uses the randomized BST though the hash functions are very rudimentary.
Re: A little of coordination for Rosettacode
On Tuesday, 12 February 2013 at 01:07:35 UTC, bearophile wrote: In practice at the moment I am maintaining all the D entries of Rosettacode. Here's a candidate for http://rosettacode.org/wiki/Extensible_prime_generator#D in case it is preferred to the existing entry: http://dpaste.dzfl.pl/43735da3f1d1
Re: Haskell calling D code through the FFI
On Tuesday, 5 August 2014 at 23:23:43 UTC, Jon wrote: So that does indeed solve some of the problems. However, using this method, when linking I get two errors, undefined reference rt_init() and rt_term() I had just put these methods in the header file. If I put wrappers around these functions and export I get the rt_init, rt_term is private. It works for me, here are the main parts of my Makefile: DC = ~/bin/dmd main: Main.hs FunctionsInD.a ghc -o main Main.hs FunctionsInD.a ~/lib/libphobos2.a -lpthread FunctionsInD.a: FunctionsInD.d $(DC) -c -lib FunctionsInD.d I passed in the phobos object directly because I don't know how to specify the ~/lib directory on the ghc command line.
Re: Haskell calling D code through the FFI
Don't forget to call rt_init: http://dlang.org/phobos/core_runtime.html#.rt_init
Re: Haskell calling D code through the FFI
On Monday, 4 August 2014 at 21:14:17 UTC, Jon wrote: On Monday, 4 August 2014 at 21:10:46 UTC, safety0ff wrote: Don't forget to call rt_init: http://dlang.org/phobos/core_runtime.html#.rt_init Where/when should I call this? Before calling any D functions, but usually it's simplest to call it early in main. It initializes the GC and notifies the D runtime of its existence. For simple D functions you might get away without calling it.
Re: Haskell calling D code through the FFI
On Monday, 4 August 2014 at 21:35:21 UTC, Jon wrote: I get Error: core.runtime.rt_init is private. And Error: core.runtime.init is not accessible. I would add them to the header and Haskell wrapper (FunctionsInD.h and ToD.hs.) The signatures are: int rt_init(); int rt_term(); When it is linked it will find the symbols in druntime.
Re: Threadpools, difference between DMD and LDC
On Sunday, 3 August 2014 at 19:52:42 UTC, Philippe Sigaud wrote: Can someone confirm the results and tell me what I'm doing wrong? LDC is likely optimizing the summation: int sum = 0; foreach(i; 0..task.goal) sum += i; To something like: int sum = cast(int)(cast(ulong)(task.goal-1)*task.goal/2);
Re: unittest affects next unittest
On Friday, 1 August 2014 at 23:09:39 UTC, sigod wrote: Code: http://dpaste.dzfl.pl/51bd62138854 (It was reduced by DustMite.) Have I missed something about structs? Or this simply a bug? Isn't this the same mistake as: http://forum.dlang.org/thread/muqgqidlrpoxedhyu...@forum.dlang.org#post-mpcwwjuaxpvwiumlyqls:40forum.dlang.org In other words: private Node * _root = new Node(); looks wrong.
Re: A little of coordination for Rosettacode
On Tuesday, 12 February 2013 at 01:07:35 UTC, bearophile wrote: In practice at the moment I am maintaining all the D entries of Rosettacode. I modified the Hamming numbers code in a personal exercise. It now uses considerably less memory but is slower. I've posted the code here in case it is of use: http://dpaste.dzfl.pl/3990023e5577 For a single n, n = 350_000_000: Alternative version 2: 13.4s and ~5480 MB of ram My code: 21s and ~74 MB of ram Regards.
Re: Segfault games with factorials
On Thursday, 24 July 2014 at 14:59:16 UTC, Darren wrote: It does seem that's the case. Which is odd, as I thought that DMD and LDC did TCO. Not in this case obviously. DMD doesn't do it with the :? operator: https://issues.dlang.org/show_bug.cgi?id=3713
Re: String to int exception
On Tuesday, 15 July 2014 at 12:24:48 UTC, Alexandre wrote: Thanks, but, when I convert I recive a 'c' in the front of my number... uint reverseBytes(uint val) { import core.bitop : bitswap; return bitswap(val); } You confused bswap with bitswap. The former reverses bytes, the latter reverses bits. If you look at bearophile's original message he says bswap.
Re: What am I doing Wrong (OpenGL SDL)
On Friday, 4 July 2014 at 09:39:49 UTC, Sean Campbell wrote: On Friday, 4 July 2014 at 08:02:59 UTC, Misu wrote: Can you try to add DerelictGL3.reload(); after SDL_GL_CreateContext ? yes this solved the problem. however why? is it a problem with the SDL binding? No. https://github.com/DerelictOrg/DerelictGL3/blob/master/README.md
CTFE bug or enhancement?
Everything compiles fine except for function qux2: http://dpaste.dzfl.pl/9d9187e0b450 Is this a bug or an enhancement for CTFE? It would be really nice to have this feature because core.simd has functions such as: void16 __simd(XMM opcode, void16 op1, void16 op2, ubyte imm8); Where all the arguments must be compile time constants. It would be nice to be able to push some parameters out from the type list and into the argument list in user code too.
Re: CTFE bug or enhancement?
Actually, this is an enhancement because adding: enum b = blah Makes them fail. :(
Re: CTFE bug or enhancement?
On Thursday, 3 July 2014 at 01:55:14 UTC, safety0ff wrote: Actually, this is an enhancement because adding: enum b = blah Makes them fail. :( The question is now: how can the delegate be evaluated for the return value but not for the enum?
Re: CTFE bug or enhancement?
On Thursday, 3 July 2014 at 02:02:19 UTC, safety0ff wrote: On Thursday, 3 July 2014 at 01:55:14 UTC, safety0ff wrote: Actually, this is an enhancement because adding: enum b = blah Makes them fail. :( The question is now: how can the delegate be evaluated for the return value but not for the enum? Looks like an ICE: https://github.com/D-Programming-Language/dmd/blob/master/src/interpret.c#L5169
Re: GC.calloc(), then what?
On Friday, 27 June 2014 at 23:26:55 UTC, Ali Çehreli wrote: I appreciated your answers, which were very helpful. What I meant was, I was partially enlightened but still had some questions. I am in much better shape now. :) Yea, I understood what you meant. :)
Re: GC.calloc(), then what?
On Friday, 27 June 2014 at 07:03:28 UTC, Ali Çehreli wrote: 1) After allocating memory by GC.calloc() to place objects on it, what else should one do? Use std.conv.emplace. In what situations does one need to call addRoot() or addRange()? Add root creates an internal reference within the GC to the memory pointed by the argument (void* p.) This pins the memory so that it won't be collected by the GC. E.g. you're going to pass a string to an extern C function, and the function will store a pointer to the string within its own data structures. Since the GC won't have access to the data structures, you must addRoot it to avoid creating a dangling pointer in the C data structure. Add range is usually for cases when you use stdc.stdlib.malloc/calloc and place pointers to GC managed memory within that memory. This allows the GC to scan that memory for pointers during collection, otherwise it may reclaim memory which is pointed to my malloc'd memory. 2) Does the answer to the previous question differ for struct objects versus class objects? No. 3) Is there a difference between core.stdc.stdlib.calloc() and GC.calloc() in that regard? Which one to use in what situation? One is GC managed, the other is not. calloc simply means the memory is pre-zero'd, it has nothing to do with C allocation / allocation in the C language 4) Are the random bit patterns in a malloc()'ed memory always a concern for false pointers? Does that become a concern after calling addRoot() or addRange()? If by malloc you're talking about stdc.stdlib.malloc then: It only becomes a concern after you call addRange, and the false pointers potential is only present within the range you gave to addRange. So if you over-allocate using malloc and give the entire memory range to addRange, then any false pointers in the un-intialized portion become a concern. If you're talking about GC.malloc(): Currently the GC zeros the memory unless you allocate NO_SCAN memory, so it only differs in the NO_SCAN case. If so, why would anyone ever malloc() instead of always calloc()'ing? To save on redundant zero'ing.
Re: GC.calloc(), then what?
I realize that my answer isn't completely clear in some cases, if you still have questions, ask away.
Re: GC.calloc(), then what?
On Friday, 27 June 2014 at 08:17:07 UTC, Ali Çehreli wrote: Thank you for your responses. I am partly enlightened. :p I know you're a knowledgeable person in the D community, I may have stated many things you already knew, but I tried to answer the questions as-is. On 06/27/2014 12:34 AM, safety0ff wrote: Add range is usually for cases when you use stdc.stdlib.malloc/calloc and place pointers to GC managed memory within that memory. This allows the GC to scan that memory for pointers during collection, otherwise it may reclaim memory which is pointed to my malloc'd memory. One part that I don't understand in the documentation is if p points into a GC-managed memory block, addRange does not mark this block as live. [SNIP] See, that's confusing: What does that mean? I still hold the memory block anyway; what does the GC achieve by scanning my memory if it's not going to follow references anyway? The GC _will_ follow references (i.e. scan deeply,) that's the whole point of addRange. What that documentation is saying is that: If you pass a range R through addRange, and R lies in the GC heap, then once there are no pointers (roots) to R, the GC will collect it anyway regardless that you called addRange on it. In other words, prefer using addRoot for GC memory and addRange for non-GC memory. 4) Are the random bit patterns in a malloc()'ed memory always a concern for false pointers? Does that become a concern after calling addRoot() or addRange()? If by malloc you're talking about stdc.stdlib.malloc then: It only becomes a concern after you call addRange, But addRange doesn't seem to make sense for stdlib.malloc'ed memory, right? The reason is, that memory is not managed by the GC so there is no danger of losing that memory due to a collection anyway. It will go away only when I call stdlib.free. addRange almost exclusively makes sense with stdlib.malloc'ed memory. As you've stated: If you pass it GC memory it does not mark the block as live. I believe the answer above clears things up: the GC does scan the range, and scanning is always deep (i.e. when it finds pointers to unmarked GC memory, it marks them.) Conversely, addRoot exclusively makes sense with GC memory. If you're talking about GC.malloc(): Currently the GC zeros the memory unless you allocate NO_SCAN memory, so it only differs in the NO_SCAN case. So, the GC's default behavior is to scan the memory, necessitating clearing the contents? That seems to make GC.malloc() behave the same as GC.calloc() by default, doesn't it? I don't believe it's necessary to clear it, it's just a measure against false pointers (AFAIK.) So, is this guideline right? GC.malloc() makes sense only with NO_SCAN. I wouldn't make a guideline like that, just say that: if you want the memory to be guaranteed to be zero'd use GC.calloc. However, due to GC internals (for preventing false pointers,) GC.malloc'd memory will often be zero'd anyway. If so, why would anyone ever malloc() instead of always calloc()'ing? To save on redundant zero'ing. And again, redundant zero'ing is saved only when used with NO_SCAN. Yup. I think I finally understand the main difference between stdlib.malloc and GC.malloc: The latter gets collected by the GC. Yup. Another question: Do GC.malloc'ed and GC.calloc'ed memory scanned deep? Yes, only NO_SCAN memory doesn't get scanned, everything else does.
Re: GC.calloc(), then what?
On Friday, 27 June 2014 at 08:17:07 UTC, Ali Çehreli wrote: So, the GC's default behavior is to scan the memory, necessitating clearing the contents? That seems to make GC.malloc() behave the same as GC.calloc() by default, doesn't it? Yes. compare: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L543 to: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L419
Re: GC.calloc(), then what?
On Friday, 27 June 2014 at 09:20:53 UTC, safety0ff wrote: Yes. compare: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L543 to: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L419 Actually, I just realized that I was wrong in saying the memory likely be cleared by malloc it's only the overallocation that gets cleared.
Re: modulo Strangeness?
On Wednesday, 11 June 2014 at 22:32:45 UTC, Taylor Hillegeist wrote: I have a simpleish bit of code here that always seems to give me an error, and i can't figure out quite why. modulo takes the sign of the dividend: http://en.wikipedia.org/wiki/Modulo_operation#Common_pitfalls It works with length because you introduce a signed - unsigned conversion.
Re: Hiding types
On Friday, 30 May 2014 at 19:50:43 UTC, Philippe Sigaud wrote: Am I misunderstanding something or is that a bug? Try: auto foo() { return Hidden();}
Re: Hiding types
On Friday, 30 May 2014 at 19:54:00 UTC, safety0ff wrote: On Friday, 30 May 2014 at 19:50:43 UTC, Philippe Sigaud wrote: Am I misunderstanding something or is that a bug? Try: auto foo() { return Hidden();} This is incorrect, please ignore.
Is this a bug or illegal code?
//*** CODE ** mixin(version = foo;); version(foo) { void main(){} } //** END CODE *** If it's illegal in D, what is the reason where is documented? The reason I was considering such a construct is the following: Some C libraries have an associated config.h header that gets generated when it is compiled. I was thinking it may be possible to parse these config.h files at compile time (using text import) and convert some of the #define's into version = foo; It wouldn't do any favors for compile times, but it would save on having an extra step in the build process to convert config.h to config.d.
Re: Is this a bug or illegal code?
On Thursday, 29 May 2014 at 15:02:48 UTC, Steven Schveighoffer wrote: Even if that is valid code, you are much better off using enums and static if. enum includeSomeFeature = ... static if(includeSomeFeature) { ... } These work much more like #defines, and can be seen outside the module. -Steve Thanks, the following works: mixin(enum hasFoo = true;); static if(hasFoo) { void main(){} }
Re: @safe @nogc memory allocation
I think malloc isn't @safe and alloca doesn't work if your function can throw.
Re: @safe @nogc memory allocation
On Wednesday, 28 May 2014 at 23:57:40 UTC, Dicebot wrote: I believe within current language semantics even considering `new` pure is broken, there was a very recent thread discussing it in digitalmars.D group. If you can be sure that your code won't break basic sanity requirements (never comparing allocated immutable pointer identity, only pointed values) it should work fine. But I have never done it in my code and not aware of possible pitfalls. You also have to make sure your calls to malloc wont be considered strongly pure and memoized. e.g.: int* a = cast(int*)malloc(4); // 4 should be considered immutable int* b = cast(int*)malloc(4); // a == b if memoized // a != b otherwise (unless out of memory) Perhaps the wrapper function should take a pointer reference as a parameter (note: not immutable,) this also means that it can use type inference.
Re: naming a variable at runtime
You should look into associative arrays ( http://dlang.org/hash-map .) Example: import std.stdio; void main() { int[][string] mybobs; mybobs[bob_1] = [-1, -1, 1, -1, -1]; mybobs[bob_2] = [-1, 1, 1, 1, -1]; mybobs[bob_3] = [-1, 1, 1, 1, -1]; writeln(mybobs); }
Re: Need help with movement from C to D
On Monday, 5 May 2014 at 03:57:54 UTC, Andrey wrote: A similar D code is, as far as I know, type.field.offsetof Is there an any way to make a corresponding D template? What you've written is the specific syntax for offsetof in D. If the intent is to create a template so that you can simply find/replace offsetof(type,field) with offsetoftemplate!(type,field) then I think it is easier to create a sed script - better yet a D program - for replacing the C macro with D code. Example program: import std.array; import std.file; import std.regex; import std.string; int main(string[] args) { if (args.length 2) return -1; auto regex = ctRegex!(`offsetof\(([^,]+),([^)]+)\)`); auto sink = appender!(char[])(); foreach (filename; args[1..$]) { auto text = readText(filename); sink.reserve(text.length); replaceAllInto!(cap = cap[1].strip~.~cap[2].strip~.offsetof)(sink, text, regex); write(filename, sink.data); sink.clear(); } return 0; }