[Issue 4688] [patch] rdmd/Win: rdmd'ed program's output appears after cmd prompt
http://d.puremagic.com/issues/show_bug.cgi?id=4688 --- Comment #4 from Nick Sabalausky 2010-08-24 21:42:18 PDT --- Note that this bug is not just cosmetic: It causes problems for programs that launch rdmd through a "system()" call. The system() call will return *before* the rdmd'ed program runs which causes a (repeatable) race problem. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: [Issue 3725] Add united type to standard library
Oh my. Was it going too fast? ;) :Þ -- ... <
[Issue 4722] New: Debug Phobos lib
http://d.puremagic.com/issues/show_bug.cgi?id=4722
Summary: Debug Phobos lib
Product: D
Version: D2
Platform: All
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-08-24 19:51:16 PDT ---
This is one example from Phobos, a small part of std.bitmanip.BitArray:
void init(void[] v, size_t numbits)
in
{
assert(numbits <= v.length * 8);
assert((v.length & 3) == 0);
}
body
{
ptr = cast(uint*)v.ptr;
len = numbits;
}
But if you compile (with no compilation arguments but the file name) this wrong
program runs, with no runtime errors:
import std.bitmanip: BitArray;
void main() {
ubyte[4] data;
BitArray bits;
bits.init(data, 100);
}
The problem is real, but I don't know if the following suggestion is stupid or
impossible.
The idea is to have two precompiled libs, like phobos.lib and phobos_debug.lib
(where the debug one contains the asserts too), and DMD (or rmdm) may pick
phobos.lib if the -release switch is used, and use phobos_debug.lib otherwise.
This may allow to replace the enforce() in Phobos with normal asserts inside
DbC contracts.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3725] Add united type to standard library
http://d.puremagic.com/issues/show_bug.cgi?id=3725 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmail.com --- Comment #4 from Jonathan M Davis 2010-08-24 17:05:22 PDT --- Oh my. Was it going too fast? ;) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3725] Add united type to standard library
http://d.puremagic.com/issues/show_bug.cgi?id=3725 --- Comment #3 from BCS 2010-08-24 16:14:14 PDT --- I have undated it to use 4 space tabs and inserted a Boost licence deceleration. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4721] compilation slow when compiling unittests on dcollections
http://d.puremagic.com/issues/show_bug.cgi?id=4721 --- Comment #6 from Steven Schveighoffer 2010-08-24 14:10:26 PDT --- More testing, I did some printf debugging. According to the comments and the code of the function, it's a *linear* search through the symbol table for a match to a given symbol + suffix. The symbol table is a null-separated single buffer. So not only is it linear through the strings, but it's linear on the *characters*. That is, when comparing the current symbol and it's a mismatch, the code must iterate through all the characters anyways to find the next null character. I added some printouts to determine the eventual size of the symbol table, and the number of times the function is called. I also added printouts to show the number of matches found (those should theoretically not do a linear search through the entire table, but likely would search through most of it). The eventual numbers for dcollections: symbol table size: 4,253,953 number of calls: 12,677 number of matches: 648 doing the math, thats probably conservatively about 20 billion loop iterations -- way unacceptable for something that should be done via a hash lookup, or at least a tree/trie/binary search. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4717] std.bitmanip.BitArray changes
http://d.puremagic.com/issues/show_bug.cgi?id=4717
--- Comment #6 from bearophile_h...@eml.cc 2010-08-24 14:02:31 PDT ---
For efficiency on 64 bit systems too you may change this code from the BitArray
struct:
struct BitArray
{
size_t len;
uint* ptr;
...
void init(void[] v, size_t numbits)
in
{
assert(numbits <= v.length * 8);
assert((v.length & 3) == 0);
}
Into:
struct BitArray
{
size_t len;
size_t* ptr; // changed here
...
void init(void[] v, size_t numbits)
in
{
assert(numbits <= v.length * 8);
assert(v.length % size_t.sizeof == 0); // changed here
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3682] Regression(2.038) is expression fails to match types
http://d.puremagic.com/issues/show_bug.cgi?id=3682
--- Comment #3 from Don 2010-08-24 12:39:36 PDT ---
Reduced testcase shows that it doesn't require -unittest, and it is D2-only.
--- a3682.d--
struct Tuple(Types...)
{
Tuple!(Types[0..1]) slice()()
{
Tuple!(Types[0..1]) x;
return x;
}
void fail()
{
Tuple!(float, double, int) a;
auto s = a.slice();
static assert(is(typeof(s) == Tuple!(float)));
}
}
b3682.d--
import a3682;
alias Tuple!(int) tint;
--
> dmd a3682 b3682
a3682.d(14): Error: static assert (is(Tuple!(float) == Tuple!(float))) is
false
a3682.d(4):instantiated from here: Tuple!(float)
a3682.d(13):instantiated from here: slice!()
a3682.d(12):instantiated from here: Tuple!(float,double,int)
b3682.d(2):instantiated from here: Tuple!(int)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4721] compilation slow when compiling unittests on dcollections
http://d.puremagic.com/issues/show_bug.cgi?id=4721 --- Comment #5 from Steven Schveighoffer 2010-08-24 10:13:43 PDT --- (In reply to comment #3) y small from what I can tell. > > Btw your updated d2.0b library now compiles in 11 seconds on my system with > DMD > 2.048. Still over a minute for me on Linux 2.048. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4721] compilation slow when compiling unittests on dcollections
http://d.puremagic.com/issues/show_bug.cgi?id=4721 --- Comment #4 from Andrej Mitrovic 2010-08-24 09:55:55 PDT --- * not that many files, not size. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4721] compilation slow when compiling unittests on dcollections
http://d.puremagic.com/issues/show_bug.cgi?id=4721 --- Comment #3 from Andrej Mitrovic 2010-08-24 09:55:25 PDT --- (In reply to comment #2) > It might be a linux-only problem, I'm not sure. I also have an older machine, > maybe yours is twice as fast? > > 27 seconds still seems quite long for a small library. > > Re the errors, I'm working on them now, I just downloaded 2.048. Apparently > there is some issue with AssumeSorted not working as a range anymore... It's > not critical to the library, but the unit tests use it. I'm just removing the > assumeSorted for now (as unit test performance isn't important, it was more > the > "correct" thing to do), asked about it in d.learn. Yeah I guess it could be rather long, there's not that many size and they're mostly small from what I can tell. Btw your updated d2.0b library now compiles in 11 seconds on my system with DMD 2.048. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: DMD1 function template broken or did I f.u.?
On Tue, 24 Aug 2010 11:18:35 -0400, 0ffh
wrote:
Hi, all!
Try this:
---< snip >---
void remove(T)(out T[] array,T element) {
int r=0,w=0;
while (r---
I get the following output:
direct
before : [1,3,2,2,1,3,1,1,2]
after : [1,3,1,3,1,1]
template
before : [1,3,2,2,1,3,1,1,2]
after : []
So, my question is: Huh?
s/out/ref
out means "return this argument by reference, but initialize it to its
initial value first" which for arrays means, a null array.
ref means "pass the argument by reference."
Also, btw, you should not need to specifically call the !int version, you
can just do remove(array, element).
-Steve
Re: DMD1 function template broken or did I f.u.?
0ffh wrote:
So, my question is: Huh?
The answer to this should for symmetry be: Duh!
However, it is not quite that simple.
void remove(T)(out T[] array,T element) {
This is the line that gives you problems. You are expecting 'out' to
work like 'ref', which it doesn't. From [1]: "out parameters are set to
the default initializer for the type of it."
Also, this newsgroup is for automated messages from D's Bugzilla. You
might want to ask this kind of questions in digitalmars.D.learn in the
future.
[1]: http://digitalmars.com/d/2.0/function.html#parameters
--
Simen
DMD1 function template broken or did I f.u.?
Hi, all!
Try this:
---< snip >---
void remove(T)(out T[] array,T element) {
int r=0,w=0;
while (r---
I get the following output:
direct
before : [1,3,2,2,1,3,1,1,2]
after : [1,3,1,3,1,1]
template
before : [1,3,2,2,1,3,1,1,2]
after : []
So, my question is: Huh?
Kind regards.
[Issue 4721] compilation slow when compiling unittests on dcollections
http://d.puremagic.com/issues/show_bug.cgi?id=4721 --- Comment #2 from Steven Schveighoffer 2010-08-24 07:49:15 PDT --- It might be a linux-only problem, I'm not sure. I also have an older machine, maybe yours is twice as fast? 27 seconds still seems quite long for a small library. Re the errors, I'm working on them now, I just downloaded 2.048. Apparently there is some issue with AssumeSorted not working as a range anymore... It's not critical to the library, but the unit tests use it. I'm just removing the assumeSorted for now (as unit test performance isn't important, it was more the "correct" thing to do), asked about it in d.learn. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4721] compilation slow when compiling unittests on dcollections
http://d.puremagic.com/issues/show_bug.cgi?id=4721 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2010-08-24 07:31:19 PDT --- I don't know about Linux (I might try it in a VM if you want me to), but on Windows I can compile the collection in 27 seconds: C:\d2\dcollections>timeit build-lib-win32.bat unittest unittest C:\d2\dcollections>dmd -unittest unit_test.d dcollections\ArrayList.d dcollections\DefaultAllocator .d dcollections\DefaultFunctions.d dcollections\Hash.d dcollections\HashMap.d dcollections\HashMulti set.d dcollections\HashSet.d dcollections\Iterators.d dcollections\Link.d dcollections\LinkList.d dc ollections\RBTree.d dcollections\TreeMap.d dcollections\TreeMultiset.d dcollections\TreeSet.d dcolle ctions\model\Addable.d dcollections\model\Iterator.d dcollections\model\Keyed.d dcollections\model\L ist.d dcollections\model\Map.d dcollections\model\Multiset.d dcollections\model\Set.d running unit tests... Version Number: Windows NT 5.1 (Build 2600) Exit Time:4:29 pm, Tuesday, August 24 2010 Elapsed Time: 0:00:27.328 Process Time: 0:00:00.015 System Calls: 161445 Context Switches: 36381 Page Faults: 165602 Bytes Read: 10062897 Bytes Written:5792330 Bytes Other: 131570 This is with DMD 2.046 as stated in the Readme. Do you need my system specs? With the newer 2.048 I get errors: C:\d2>build-lib-win32.bat unittest unittest C:\d2>dmd -unittest unit_test.d dcollections\ArrayList.d dcollections\DefaultAllocator.d ctions\Hash.d dcollections\HashMap.d dcollections\HashMultiset.d dcollections\HashSet.d d nk.d dcollections\LinkList.d dcollections\RBTree.d dcollections\TreeMap.d dcollections\Tr llections\model\Addable.d dcollections\model\Iterator.d dcollections\model\Keyed.d dcolle Map.d dcollections\model\Multiset.d dcollections\model\Set.d std.contracts has been scheduled for deprecation. Please use std.exception instead. dcollections\HashSet.d(28): Error: template std.algorithm.find(alias pred = "a == b",R,E) ryFun!(pred)(haystack.front,needle)) : bool)) does not match any function template declar dcollections\HashSet.d(28): Error: template std.algorithm.find(alias pred = "a == b",R,E) ryFun!(pred)(haystack.front,needle)) : bool)) cannot deduce template function from argume ),ubyte) dcollections\HashSet.d(301): Error: template instance dcollections.HashSet.rangeEqual!(ub dcollections\HashSet.d(996):instantiated from here: HashSet!(ubyte) running unit tests... '.\unit_test' is not recognized as an internal or external command, operable program or batch file. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4721] New: compilation slow when compiling unittests on dcollections
http://d.puremagic.com/issues/show_bug.cgi?id=4721 Summary: compilation slow when compiling unittests on dcollections Product: D Version: D2 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: schvei...@yahoo.com --- Comment #0 from Steven Schveighoffer 2010-08-24 06:44:06 PDT --- When compiling dcollections unit tests, it takes over 1 minute to compile the small library. I am unsure what the exact trigger is to make it slow. At the request of Walter, I profiled the compiler to try and see where the slowdown was. Here are the first few lines of the results using gprof: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 77.76 6.68 6.68 2952 2.26 2.26 elf_findstr(Outbuffer*, char const*, char const*) 2.10 6.86 0.18 4342 0.04 0.04 searchfixlist 1.28 6.97 0.11 663755 0.00 0.00 ScopeDsymbol::search(Loc, Identifier*, int) 1.05 7.06 0.09 2623497 0.00 0.00 isType(Object*) 0.76 7.12 0.07 911667 0.00 0.00 match(Object*, Object*, TemplateDeclaration*, Scope*) 0.76 7.19 0.07 656268 0.00 0.00 _aaGetRvalue(AA*, void*) 0.58 7.24 0.05 2507041 0.00 0.00 isTuple(Object*) Walter said it looks like elf_findstr is a problem area and asked me to file this bug. The relevant discussion is here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=116007 All I can say to duplicate this is to download the latest svn of dcollections and compile unit tests. If you are running the profiled version, it takes a long long time to complete (I gave up after 5 minutes). I suggest compiling just one class, HashMap. The compile time for this takes 4 seconds. The appropriate commands to run are: svn co http://svn.dsource.org/projects/dcollections/branches/d2 dcollections cd dcollections dmd -unittest dcollections/HashMap.d dcollections/Hash.d dcollections/Iterators.d dcollections/model/* The compilation will fail, because there is no main function, but it will demonstrate the problem well enough. If you want to compile the entire unit test suite, use the command: ./build-lib-linux.sh unittest Which builds and runs the unit tests for the whole library. This takes over a minute to compile. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4717] std.bitmanip.BitArray changes
http://d.puremagic.com/issues/show_bug.cgi?id=4717 --- Comment #5 from bearophile_h...@eml.cc 2010-08-24 06:31:52 PDT --- I see, I think you are talking about using a SWAR approach then. I have never used it for this job, but it sounds intersting. I'd like to do some benchmarks to see what the most efficient solution is among those two. It looks like a simple problem, but has a surprisingly high number of interesting solutions. -- 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 #700 is|0 |1 obsolete|| --- Comment #71 from nfx...@gmail.com 2010-08-24 06:26:56 PDT --- Created an attachment (id=739) D1 - patch for dmd for creating pointer bitmasks don't emit pointer maps for NO_SCAN types (breaks the test program pm.d included in the other post) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4720] contracts don't work on function definitions
http://d.puremagic.com/issues/show_bug.cgi?id=4720 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4717] std.bitmanip.BitArray changes
http://d.puremagic.com/issues/show_bug.cgi?id=4717 --- Comment #4 from Don 2010-08-24 05:55:05 PDT --- (In reply to comment #3) > Answer to Comment 2: > The code in the bithacks site I have given URL of probably is what you were > talking about. > But then there are refined algorithms to use the basic code shown in bithacks, > that becomes useful as the bit array gets a little larger. No, that's not what I meant at all. The parallel adding I'm referring to does not involve any shifts. You basically implement a half adder. Given 2 words a, b the low bit of the sum is a^b, and the high bit is a&b. And with 3 words a, b, c, the low bit of the sum is a^b^c and the high word is (a&b)|((a^b)&c). The popcount is popcount(lo word) + 2* popcount(high word). So what you do is pass through the array in pairs, grabbing the values a, b. You accumulate popcount p += 2*popcount((a&b)|((a^b)&c)). calculate a new carry c = a^b^c. Then you add p+=popcount(c); at the end. In this way, you've dealt with two words, but only done one single-word popcount. In practice, you don't just use pairs, you grab 8 or 16 values at a time, and keep a 3 or 4 bit sum. You only have to perform one single-word popcount for every 8 or 16 words. You need to do a lot of logical operations, but they pipeline quite well. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4720] New: contracts don't work on function definitions
http://d.puremagic.com/issues/show_bug.cgi?id=4720
Summary: contracts don't work on function definitions
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: mrmoc...@gmx.de
--- Comment #0 from Trass3r 2010-08-24 05:23:06 PDT ---
The Matlab C headers provide some kind of hand-crafted contracts by defining
extra functions with suffix "_d" that check all the arguments and then
detouring the calls to the original functions via the preprocessor (#define foo
foo_d)
I tried to leverage D's built-in contract programming but it doesn't work:
module externcontracts;
import externcontracts2;
void foo(int a) in {assert(a>=0);}
module externcontracts2;
void foo(int a){}
yields:
externcontracts.d(3): Error: function externcontracts.foo in and out contracts
require function body
resp.
externcontracts.d(3): missing body { ... } after in or out
if you put a ';' after the in{} block
Note that this is exactly the same syntax as for interface contracts.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4717] std.bitmanip.BitArray changes
http://d.puremagic.com/issues/show_bug.cgi?id=4717 --- Comment #3 from bearophile_h...@eml.cc 2010-08-24 03:57:46 PDT --- Answer to Comment 2: The code in the bithacks site I have given URL of probably is what you were talking about. But then there are refined algorithms to use the basic code shown in bithacks, that becomes useful as the bit array gets a little larger. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4681] Appender access violation
http://d.puremagic.com/issues/show_bug.cgi?id=4681 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #9 from nfx...@gmail.com 2010-08-24 02:18:39 PDT --- There's some wtfish code in Appender, that probably tries to emulate how the runtime allocates arrays. I don't understand why it doesn't simply use the functions exported by the runtime. Even if not, there's no justification to duplicate all the code in Phobos, instead of extending the runtime itself. Or maybe the original author thought a simple function call on array reallocation is to slow? Also I doubt using gc_realloc is a good idea: in some cases, gc_realloc frees memory by force (similar to gc_free), and thus is unsafe in SafeD's definition. (Although I'm not quite sure if that is the case here.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4719] New: Clean up associative array runtime interface to enable precise GC
http://d.puremagic.com/issues/show_bug.cgi?id=4719 Summary: Clean up associative array runtime interface to enable precise GC Product: D Version: D1 & D2 Platform: Other OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: nfx...@gmail.com --- Comment #0 from nfx...@gmail.com 2010-08-24 01:58:57 PDT --- Currently, the AA implementation (in aaA.d) has no way of knowing what the type of an AA is. All it gets is the key TypeInfo and the value type's size. This makes precise GC impossible. (Issue 3463 has a compiler patch that adds pointer bitmaps to TypeInfo. The AA implementation needs these to allocate the AA data in a way that enables precise scanning.) This enhancement suggests to clean up the AA runtime interface, that consists of functions starting with "_aa" (e.g. _aaGet). All of these functions should carry a TypeInfo_AssociativeArray reference as parameter. Note that would actually _reduce_ the number of parameters these runtime functions typically have, which I find funny. There may be compatibility concerns. This is simple to solve: the compiler can just define a new version symbol to signal that a new AA ABI is used. Or if actual binary compatibility with old code is desired, the old interface could be emulated in aaA.d by still providing the old functions; the new interface would use different function names. PS: not attempting to write a patch, because even if this enhancement gets accepted, Walter most likely would rewrite the patch himself. -- 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 #70 from nfx...@gmail.com 2010-08-24 01:40:52 PDT --- Created an attachment (id=738) experiment: use ClassInfo to get bitmask for object allocations objbitmask.patch is a patch on top of tango_precise_gc.patch, which makes storing the pointer bitmap inline unnecessary. Instead, it assumes that all memory blocks flagged with BlkAttr.FINALIZE are D objects, and uses their ClassInfo to get the bitmask. Seems to be slightly slower, but also reduces space overhead. -- 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 #701 is|0 |1 obsolete|| --- Comment #69 from nfx...@gmail.com 2010-08-24 01:37:05 PDT --- Created an attachment (id=737) D1 - patch for Tango's runtime to enable precise GC scanning Same as old patch, updated to newer tango svn. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4681] Appender access violation
http://d.puremagic.com/issues/show_bug.cgi?id=4681
Don changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #8 from Don 2010-08-24 01:30:01 PDT ---
Here's another test case for what I believe is the same thing. It's memory
corruption rather than a segfault. This is a regression since 2.047.
import std.stdio;
import std.array;
void main()
{
Appender!(double[]) b, c;
string[] t;
t ~= "q";
t ~= "q";
double zzz;
b.put( 111.1 );
for (;;) {
c.put(double.nan);
b.put( 0);
double qqq = b.data()[0];
writefln("%s", qqq);
assert(qqq>0);
}
}
111.1
111.1
111.1
111.1
nan
core.exception.asserter...@test(46): Assertion failure
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4717] std.bitmanip.BitArray changes
http://d.puremagic.com/issues/show_bug.cgi?id=4717 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #2 from Don 2010-08-24 00:33:44 PDT --- (In reply to comment #0) > - The count() is also known known as Population or Hamming weight. This is > useful for Hamming distances, to count bits in many situations, like for > example for the Sieve of Eratosthenes. There are ways and refined algorithms > to > speed up this operation a lot. And this is a very commonly useful operation. I > may offer some D code if you want. See also: > http://en.wikipedia.org/wiki/Hamming_weight > http://graphics.stanford.edu/~seander/bithacks.html > And see also the __builtin_popcount() built-in function of GCC. Curious fact: the built-in popcount instruction isn't much use for bit arrays. It's great for 64 bit longs (especially for chess programs!) but once you have a dozen machine words or more, it's faster to add the bits sideways. An interesting consequence of this is that Intel/AMD's new popcount instruction is hardly ever useful... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
