[Issue 4360] Allow intrinsics in core.bitop to operate as intrinsics
http://d.puremagic.com/issues/show_bug.cgi?id=4360 --- Comment #4 from Sean Kelly s...@invisibleduck.org 2010-07-20 23:37:58 PDT --- Darnit, I did it again didn't I? I hope I still have the patch lying around. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4385] Uncaught exceptions should dump a core
http://d.puremagic.com/issues/show_bug.cgi?id=4385 --- Comment #2 from Sean Kelly s...@invisibleduck.org 2010-07-21 07:13:04 PDT --- Oh you're right. It works in C++ because C++ doesn't auto-report uncaught exceptions, so when one passes out of main the process exits in some special manner that preserves the call stack. What I don't get is why this works with object dtors that are run as the stack unwinds though. In any case, druntime has an extern (C) bool called rt_trapExceptions that is used by debuggers to enable some of this functionality, but it has to be set very early in the startup process. I guess I'll have to think about this one some more. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #31 from Leandro Lucarella llu...@gmail.com 2010-07-21 08:38:06 PDT --- (In reply to comment #30) Hm... I'd love to get this into D2, but the diffs are a bit large to apply by hand. I don't suppose you'd be inclined to provide a D2 patch as well? It should be pretty similar to the Tango patch. I would be nice to split the patch in smaller changes too, because there are a couple of extra optimizations not related to the precise scanning (for example, making findPool() use a binary search, I was just about to implement the same optimization in my GC :). There are a few changes of structure not related to the patch too, which improves the code, but makes harder to port the patch to other GCs. Thanks! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 nfx...@gmail.com changed: What|Removed |Added Attachment #689 is|0 |1 obsolete|| --- Comment #32 from nfx...@gmail.com 2010-07-21 11:49:11 PDT --- Created an attachment (id=692) D1 - patch for dmd for creating pointer bitmasks - don't use the dmd provided bit array type anymore to make the patch more 64 bit friendly - slightly change PointerMap format -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #34 from nfx...@gmail.com 2010-07-21 11:57:02 PDT --- I don't really use D2 (all my code is in D1). Porting it to D2 will require dealing with the recently added array append stuff. Not sure how hard that would be, but currently I have no intention doing the port myself. Also note that the GC mark code is unoptimized. I'm not sure how much optimization potential there is, but my own attempts have been unsuccessful so far. About the 64 bit issue: to me it looked like dmd can never cross compile, and if you want to compile it as 64 bit app, it must generate 64 bit code. Or is that wrong? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #35 from Leandro Lucarella llu...@gmail.com 2010-07-21 11:59:40 PDT --- (In reply to comment #34) I don't really use D2 (all my code is in D1). Porting it to D2 will require dealing with the recently added array append stuff. Not sure how hard that would be, but currently I have no intention doing the port myself. Also note that the GC mark code is unoptimized. I'm not sure how much optimization potential there is, but my own attempts have been unsuccessful so far. About the 64 bit issue: to me it looked like dmd can never cross compile, and if you want to compile it as 64 bit app, it must generate 64 bit code. Or is that wrong? I don't know how it should finally be, but right now, even if you compile DMD as a 64 bits app, it generates 32 bits code (I didn't even find any options to make it generate 64 bits code :). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #36 from nfx...@gmail.com 2010-07-21 12:05:08 PDT --- I guess we will have to see how Walter's 64 bit port will look like. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4491] Assigning large const value to ulong type results in signed integer overflow
http://d.puremagic.com/issues/show_bug.cgi?id=4491 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #2 from bearophile_h...@eml.cc 2010-07-21 14:51:27 PDT --- What's bad in the compiler/language accepting a line like: ulong t = 18446744073709551615; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4492] New: Version of take() which takes from the back of a range
http://d.puremagic.com/issues/show_bug.cgi?id=4492 Summary: Version of take() which takes from the back of a range Product: D Version: D2 Platform: Other OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmail.com --- Comment #0 from Jonathan M Davis jmdavisp...@gmail.com 2010-07-21 16:41:01 PDT --- Most of the functions that we have in phobos at this point seem to deal with the front of a range rather than the back. Naturally, for a lot of stuff, that's exactly what you want, and there _are_ ranges which don't have a back, but for some functions, it would be nice to have a corresponding function which acts on the back of a range. The one which immediately comes to mind is take(). There's no way to take the back n elements of a range. There are ways to get more or less the same thing - you can copy the range and then pop off elements from the front - but there are situations where taking from the back of a range would be useful. So, I suggest that std.range have a function named takeBack() - or something similar - which does the same thing as take() except that it takes from the back of the range rather than the front. Now, there may be reasons which I haven't thought of why this wouldn't work very well (unlike take(), it obviously wouldn't work with infinite ranges), but I would think that it would be useful enough to at least look into adding it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4492] Version of take() which takes from the back of a range
http://d.puremagic.com/issues/show_bug.cgi?id=4492 David Simcha dsim...@yahoo.com changed: What|Removed |Added CC||dsim...@yahoo.com --- Comment #1 from David Simcha dsim...@yahoo.com 2010-07-21 17:31:20 PDT --- What's wrong with just using take(retro(myRange), someNumber)? This is only a tiny bit more typing than takeBack and IIUC does exactly what you want. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4492] Version of take() which takes from the back of a range
http://d.puremagic.com/issues/show_bug.cgi?id=4492 --- Comment #3 from David Simcha dsim...@yahoo.com 2010-07-21 19:16:35 PDT --- Two points: 1. Retro is not inefficient. For random access, there's the overhead of translating the index to length - index, but this is negligible in most cases (though I wouldn't use it in super performance critical numerics code). In the case of front(), popFront(), etc., all it does is forward front() to back(), popFront() to popBack() and vice-versa. These are virtually guaranteed to be inlined by the compiler, resulting in truly zero overhead for non-random access. 2. Sorry for the misunderstanding on what you expected takeBack to do. However, now IIUC takeBack would be unimplementable on non-random access ranges, unless the range had a length **and** you performed an O(n) seek. If you can only access the front and back element of a range at any given time, you can't get the Nth element from the back. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
