[Issue 2254] Size of executable almost triples
http://d.puremagic.com/issues/show_bug.cgi?id=2254 --- Comment #32 from Jacob Carlborg d...@me.com 2011-05-19 23:27:57 PDT --- Is this only a problem on Windows? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2452] Unimplemented method errors should show function overload
http://d.puremagic.com/issues/show_bug.cgi?id=2452 Mariusz Gliwiński alienballa...@gmail.com changed: What|Removed |Added CC||alienballa...@gmail.com --- Comment #1 from Mariusz Gliwiński alienballa...@gmail.com 2011-05-20 07:56:31 PDT --- I'd like to see this in D2 as well. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6038] core.cpuid reports unexpected values for threadsPerCPU and hyperThreading
http://d.puremagic.com/issues/show_bug.cgi?id=6038 --- Comment #2 from k...@redstar.de 2011-05-20 09:02:02 PDT --- Created an attachment (id=986) Use level type instead of level number -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6038] core.cpuid reports unexpected values for threadsPerCPU and hyperThreading
http://d.puremagic.com/issues/show_bug.cgi?id=6038 --- Comment #3 from k...@redstar.de 2011-05-20 09:02:39 PDT --- With the fix, I get the right numbers. Thanks. (Now, threadsPerCPU() returns the total number of logical thread in the CPU. With this interpretation, the numbers for the Core Duo2 are ok, too.) In an attempt to fix it by myself, I read the latest Instruction Set Manual from Intel. From my understanding, there is no hardcoded relationship between the level number (bits [7:0] in ECX) and the level type (bits [15:8] in ECX). E.g. returning the number of cores for level number 0 and the number of threads per core for level number 1 would also match the specification. The attached patch uses the level type instead of the level number to fix this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6038] core.cpuid reports unexpected values for threadsPerCPU and hyperThreading
http://d.puremagic.com/issues/show_bug.cgi?id=6038 --- Comment #4 from Vladimir Panteleev thecybersha...@gmail.com 2011-05-20 09:41:40 PDT --- I noticed that myself, but from reading the docs, I believe that the type will always correspond to the level, so the returned type is simply informative. I guess we won't know for sure until we see a CPU which implements this but acts differently than the i7. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6040] New: std.cpuid and core.cpuid return different values for some methods
http://d.puremagic.com/issues/show_bug.cgi?id=6040 Summary: std.cpuid and core.cpuid return different values for some methods Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: k...@redstar.de --- Comment #0 from k...@redstar.de 2011-05-20 10:29:14 PDT --- Created an attachment (id=987) Implement std.cpuid in terms of core.cpuid std.cpuid (from Phobos) duplicates functionality from core.cpuid (from druntime). Worse, some methods return different values. E.g. hyperThreading() and threadsPerCPU(). (BTW: std.cpuid.threadsPerCPU() returns 16 for my i7, which is totally wrong.) The attached patch removes the implementation from std.cpuid and uses alias to reuse core.cpuid while preserving API compatibility. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.
http://d.puremagic.com/issues/show_bug.cgi?id=5813
--- Comment #1 from Rob Jacques sandf...@jhu.edu 2011-05-20 10:29:57 PDT ---
*Update*
The previous version ended up having value semantics, not reference semantics,
due to the fact _tail wouldn't get updated and later nodes would be ignored.
For example:
auto test = Appender!string(16);
void func(Writer)(Writer w) {
w.put(The quick brown fox jumps over the lazy dog);
}
func(test);
assert(test.data == The quick brown );
//assert(test.data == The quick brown fox jumps over the lazy dog);
I've updated the code to check/update tail lazily as needed. As an out of date
_tail naturally triggers memory allocation, this doesn't overly change the
performance of put on average.
==
struct Appender(A : T[], T) {
private {
enum PageSize = 4096; // Memory page size
alias Unqual!T E; // Internal element type
struct Data {
Data* next; // The next data segment
size_t capacity; // Capacity of this segment
E[] arr;// This segment's array
// Initialize a segment using an existing array
void opAssign(E[] _arr) {
next = null;
capacity = _arr.capacity;
arr= _arr;
if(_arr.length capacity) {
arr.length = capacity;
arr.length = _arr.length;
}
assert(_arr.ptr is arr.ptr,Unexpected reallocation occurred);
}
// Create a new segment using an existing array
this(Unqual!T[] _arr) { this = _arr; }
// Create a new segment with at least size bytes
this(size_t size) {
if(size PageSize)
size = (size + PageSize-1) ~(PageSize-1);
auto bi = GC.qalloc(size, !hasIndirections!T * 2);
next = null;
capacity = bi.size / T.sizeof;
arr = (cast(E*)bi.base)[0..0];
static assert(!false*2 == GC.BlkAttr.NO_SCAN);
}
}
Data* _head = null; // The head data segment
Data* _tail = null; // The last data segment
// Returns: the total number of elements in the appender
size_t _length() {
size_t len = 0;
for(auto d = _head; d !is null; d = d.next)
len += d.arr.length;
return len;
}
// Flatten all the data segments into a single array
E[] flatten() {
if(!_head) return null;
if( _head _head.next is null)
return _head.arr;
size_t N = _length;
size_t len = N;
size_t i = 0;
auto arr = new E[N];
for(auto d = _head; N 0; d = d.next, N -= len, i += len) {
len= min(N, d.arr.length);
memcpy(arr.ptr+i, d.arr.ptr, len * T.sizeof);
}
return arr;
}
// Returns: the next capacity size
size_t nextCapacity() nothrow pure {
auto cap = _tail.capacity * T.sizeof * 2;
return cap PageSize ? cap : PageSize;
}
}
/** Construct an appender with a given array. Note that this does not copy
* the data. If the array has a larger capacity as determined by
* arr.capacity, it will be used by the appender. After initializing an
* appender on an array, appending to the original array will reallocate.
*/
this(T[] arr) {
if(arr is null) _head = _tail = new Data( 16 * T.sizeof );
else_head = _tail = new Data( cast(E[]) arr );
}
/// Construct an appender with a capacity of at least N elements.
this(size_t N) { _head = _tail = new Data( N * T.sizeof ); }
/// Returns: the maximum length that can be accommodated without allocation
size_t capacity() {
size_t cap = 0;
for(auto d = _head; d !is null; d = d.next)
cap += d.capacity;
return cap;
}
/// Returns: a mutable copy of the data.
E[] dup() {
if(_head _head.next is null)
return flatten.dup;
return flatten;
}
/// Returns: a immutable copy of the data.
immutable(E)[] idup() {
return cast(immutable(E)[]) dup;
}
/// Returns: the appender's data as an array.
T[] data() {
auto arr = flatten;
if(_head !is _tail) {
*_head = arr;
_tail = _head;
}
return cast(T[]) arr;
}
/** Reserve at least newCapacity elements for appending. Note that more
* elements may be reserved than requested. If newCapacity capacity,
* then nothing is
[Issue 6040] std.cpuid and core.cpuid return different values for some methods
http://d.puremagic.com/issues/show_bug.cgi?id=6040 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Attachment #987|application/octet-stream|text/plain mime type|| Attachment #987 is|0 |1 patch|| -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6040] std.cpuid and core.cpuid return different values for some methods
http://d.puremagic.com/issues/show_bug.cgi?id=6040 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2011-05-20 14:48:52 PDT --- std.cpuid should just be removed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6041] New: std.algorithm.remove wrong code in assert
http://d.puremagic.com/issues/show_bug.cgi?id=6041 Summary: std.algorithm.remove wrong code in assert Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-05-20 18:28:44 PDT --- int[] a = [ 1, 2, 3, 2, 3, 4, 5, 2, 5, 6 ]; assert(a[0 .. $ - remove!(a == 2)(a).length] == [ 1, 3, 3, 4, 5, 5, 6 ]); Last line should be: assert(a[0 .. remove!(a == 2)(a).length] == [ 1, 3, 3, 4, 5, 5, 6 ]); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5516] .init is broken for fields
http://d.puremagic.com/issues/show_bug.cgi?id=5516 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-05-20 18:31:55 PDT --- Invalid, code should be: Foo.init.b There's another report for the bug in docs so I'm closing this down. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5433] Cannot use auto functions at compile-time
http://d.puremagic.com/issues/show_bug.cgi?id=5433 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-05-20 18:42:48 PDT --- Confirmed, issues is fixed. *** This issue has been marked as a duplicate of issue 2810 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4737] typeid doesn't work for scoped enum with initializer
http://d.puremagic.com/issues/show_bug.cgi?id=4737 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Summary|enum breaks linker when |typeid doesn't work for |passed to typeid() |scoped enum with ||initializer --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-05-20 19:11:53 PDT --- typeid works with scoped enums, but not with ones that have an initializer. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
http://d.puremagic.com/issues/show_bug.cgi?id=1001 Matt Peterson revcompg...@gmail.com changed: What|Removed |Added CC||revcompg...@gmail.com --- Comment #39 from Matt Peterson revcompg...@gmail.com 2011-05-20 20:53:12 PDT --- I'm not sure what the problem is, but this isn't working for me on Linux 64bit. I get the line that signifies the start of the stack trace but nothing shows up. I've been tinkering around with the druntime library a little bit but I can't seem to get any useful information, I'm not sure where to check anyway. What can I do to help resolve this? Would it be useful to test the latest version from github? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
