[Issue 5485] TLS sections handled incorrectly

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5485


Brad Roberts bra...@puremagic.com changed:

   What|Removed |Added

Attachment #879|application/octet-stream|text/plain
  mime type||
 Attachment #879 is|0   |1
  patch||


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5485] TLS sections handled incorrectly

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5485


Brad Roberts bra...@puremagic.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


--- Comment #5 from Brad Roberts bra...@puremagic.com 2011-02-20 01:23:27 PST 
---
https://github.com/D-Programming-Language/druntime/commit/7d46be0ee4ba4a59a39f99d92756685c7452bcc8

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5616] std.datetime: not cross-platform

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5616


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


--- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com 2011-02-20 02:17:33 
PST ---
Fixed:
https://github.com/D-Programming-Language/phobos/commit/ac040713d33bdb959007248cd695a1554c574dd0

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5612] core.cpuid not implemented on 64

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5612



--- Comment #4 from Russel Winder rus...@russel.org.uk 2011-02-20 02:51:59 
PST ---
I don't agree this is an enhancement, it is a bug, even if the 64-bit stuff is
in early days.  OpenMP, OpenMPI, just::thread and all the other C, C++ and
Fortran paralellism frameworks handle this correctly.

Why is this being handled by assembly code, all the operating systems must have
APIs for handling this?

Of course with Mac hardware with 64-bit processors where the boot ROM is 32-bit
the OS boots 32-bit -- since Mac OS X refuses to boot 64-bit in this case. 

A hypothesis:  the current assembly code can only deal with a single processor
which is why it reports 4 in 32-bit mode on my dual quad-core workstation.  If
this is the case should a new bug be raised or can this be handled here?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---



[Issue 5612] core.cpuid not implemented on 64

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5612


Brad Roberts bra...@puremagic.com changed:

   What|Removed |Added

 CC||bra...@puremagic.com
   Platform|Other   |x86_64
 OS/Version|Windows |All
   Severity|enhancement |major


--- Comment #5 from Brad Roberts bra...@puremagic.com 2011-02-20 03:07:29 PST 
---
I agree, it's pretty important as parts of druntime and phobos use cpu info. 
Fixed up the platform as well.

Don, is this something you might be able to own?  You've done a lot of the past
cpuid stuff, right?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5619] New: coverage output path invalid

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5619

   Summary: coverage output path invalid
   Product: D
   Version: D2
  Platform: x86
OS/Version: FreeBSD
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: bugzi...@digitalmars.com
ReportedBy: bra...@puremagic.com


--- Comment #0 from Brad Roberts bra...@puremagic.com 2011-02-20 03:14:02 PST 
---
This looks like a codegen problem.  Slight alterations in druntime's
src/rt/cover.d hides the problem.

First, dmd's a20 test illustrates it.  When run without change, the .lst file
is place in test_results/runnablerunnable-a20.lst rather than
test_results/runnable/runnable-a20.lst -- missing one of the separators.

Adding printf's inside appendFN to show the results == no bug.
Adding a temporary to pull the string assembly out of the fopen call at line
165 (only fopen in cover.d) also makes it go away.

For now, disabling all coverage tests on freebsd.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5618] Fix separator schizophrenia

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5618


bearophile_h...@eml.cc changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc


--- Comment #1 from bearophile_h...@eml.cc 2011-02-20 03:53:25 PST ---
See also bug 4468

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


compile dmd 2.052 under XP -- error !

2011-02-20 Thread David Wang
I've installed dmc and dmd2 by the dinstaller.exe from
http://ftp.digitalmars.com/dinstaller.exe

After finished, I downloaded the latest dmd, druntime and phobos from github.com

When I try to compile the dmd source through the command:
make -f win32.mak release, I got many errors, please view as follows:
--
.

freebsd.mak:532: warning: ignoring old commands for target `gcov'
solaris.mak:602: warning: overriding commands for target `zip'
freebsd.mak:602: warning: ignoring old commands for target `zip'
win32.mak:40: warning: overriding commands for target `.c.obj'
win32.mak:40: warning: ignoring old commands for target `.c.obj'
win32.mak:43: warning: overriding commands for target `.asm.obj'
win32.mak:43: warning: ignoring old commands for target `.asm.obj'
win32.mak:50: warning: overriding commands for target `release'
win32.mak:50: warning: ignoring old commands for target `release'
win32.mak:57: warning: overriding commands for target `trace'
win32.mak:57: warning: ignoring old commands for target `trace'
win32.mak:60: warning: overriding commands for target `dmd'
solaris.mak:97: warning: ignoring old commands for target `dmd'
win32.mak:66: warning: overriding commands for target `debdmd'
win32.mak:66: warning: ignoring old commands for target `debdmd'
win32.mak:162: warning: overriding commands for target `dmd.exe'
win32.mak:162: warning: ignoring old commands for target `dmd.exe'
win32.mak:175: warning: overriding commands for target `msgs.h'
win32.mak:175: warning: ignoring old commands for target `msgs.h'
win32.mak:175: warning: overriding commands for target `msgs.c'
win32.mak:175: warning: ignoring old commands for target `msgs.c'
win32.mak:175: warning: overriding commands for target `sj1041.msg'
win32.mak:175: warning: ignoring old commands for target `sj1041.msg'
win32.mak:175: warning: overriding commands for target `sj1036.msg'
win32.mak:175: warning: ignoring old commands for target `sj1036.msg'
win32.mak:175: warning: overriding commands for target `sj1031.msg'
win32.mak:175: warning: ignoring old commands for target `sj1031.msg'
win32.mak:178: warning: overriding commands for target `msgsx.exe'
win32.mak:178: warning: ignoring old commands for target `msgsx.exe'
win32.mak:182: warning: overriding commands for target `elxxx.c'
win32.mak:182: warning: ignoring old commands for target `elxxx.c'
win32.mak:182: warning: overriding commands for target `cdxxx.c'
win32.mak:182: warning: ignoring old commands for target `cdxxx.c'
win32.mak:182: warning: overriding commands for target `optab.c'
win32.mak:182: warning: ignoring old commands for target `optab.c'
win32.mak:182: warning: overriding commands for target `debtab.c'
win32.mak:182: warning: ignoring old commands for target `debtab.c'
win32.mak:182: warning: overriding commands for target `fltables.c'
win32.mak:182: warning: ignoring old commands for target `fltables.c'
win32.mak:182: warning: overriding commands for target `tytab.c'
win32.mak:182: warning: ignoring old commands for target `tytab.c'
win32.mak:186: warning: overriding commands for target `impcnvtab.c'
win32.mak:186: warning: ignoring old commands for target `impcnvtab.c'
win32.mak:190: warning: overriding commands for target `id.h'
win32.mak:190: warning: ignoring old commands for target `id.h'
win32.mak:190: warning: overriding commands for target `id.c'
win32.mak:190: warning: ignoring old commands for target `id.c'
win32.mak:199: warning: overriding commands for target `total.sym'
win32.mak:199: warning: ignoring old commands for target `total.sym'
win32.mak:202: warning: overriding commands for target `impcnvtab.obj'
win32.mak:202: warning: ignoring old commands for target `impcnvtab.obj'
win32.mak:205: warning: overriding commands for target `iasm.obj'
win32.mak:205: warning: ignoring old commands for target `iasm.obj'
win32.mak:208: warning: overriding commands for target `bcomplex.obj'
win32.mak:208: warning: ignoring old commands for target `bcomplex.obj'
win32.mak:211: warning: overriding commands for target `aa.obj'
win32.mak:211: warning: ignoring old commands for target `aa.obj'
win32.mak:214: warning: overriding commands for target `bit.obj'
win32.mak:214: warning: ignoring old commands for target `bit.obj'
win32.mak:217: warning: overriding commands for target `blockopt.obj'
win32.mak:217: warning: ignoring old commands for target `blockopt.obj'
win32.mak:220: warning: overriding commands for target `cg.obj'
win32.mak:220: warning: ignoring old commands for target `cg.obj'
win32.mak:223: warning: overriding commands for target `cg87.obj'
win32.mak:223: warning: ignoring old commands for target `cg87.obj'
win32.mak:226: warning: overriding commands for target `cgcod.obj'
win32.mak:226: warning: ignoring old commands for target `cgcod.obj'
win32.mak:229: warning: overriding commands for target `cgcs.obj'
win32.mak:229: warning: ignoring old commands for target `cgcs.obj'
win32.mak:232: warning: overriding commands for target `cgcv.obj'

Re: compile dmd 2.052 under XP -- error !

2011-02-20 Thread Jonathan M Davis
On Sunday 20 February 2011 04:13:35 David Wang wrote:
 I've installed dmc and dmd2 by the dinstaller.exe from
 http://ftp.digitalmars.com/dinstaller.exe
 
 After finished, I downloaded the latest dmd, druntime and phobos from
 github.com

Please don't post to the bug list. It's intended for messages from bugzilla, 
not 
for people to post to directly. If you have questions regarded to learning 
about 
D, post at D.learn. If you have questions about the development of D, post on 
D. 
But this list is not intended to be posted to.

- Jonathan M Davis


[Issue 4944] Missing tzname even though we have tzset

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4944


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


--- Comment #7 from Jonathan M Davis jmdavisp...@gmx.com 2011-02-20 05:30:19 
PST ---
Michel Fortin has confirmed that Mac OS X does indeed declare daylight. It
seemed rather silly to create a pull request for just one line of code, so I
just pushed it.

In any case, with Sean adding tzname to core.stdc.time, this bug appears to be
fixed. It would probably, technically be more appropriate to have put tzname in
core.sys.posix.time, but tzset is already in core.stdc.time anyway. The commit
for Seans fix is:

https://github.com/D-Programming-Language/druntime/commit/2860799026c9595785580b876173dc890d22451c

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5620] New: Implicit conversion of RegexMatch to bool

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5620

   Summary: Implicit conversion of RegexMatch to bool
   Product: D
   Version: D2
  Platform: Other
OS/Version: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: d...@me.com


--- Comment #0 from Jacob Carlborg d...@me.com 2011-02-20 08:13:34 PST ---
It would be nice if RegexMatch could be implicit converted to a bool. Returning
true for a match and false for no match.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5621] New: speller.c: enhancement request

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5621

   Summary: speller.c: enhancement request
   Product: D
   Version: D1  D2
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ibuc...@ubuntu.com


--- Comment #0 from Iain Buclaw ibuc...@ubuntu.com 2011-02-20 08:29:52 PST ---
The current implementation of the spell checker (as far as I can tell) always
finds the nearest match to the incorrectly spelled symbol.

So the following example:

struct S2 {}
struct S10 {}

void main()
{
S10 a = S();
}


Will emit the error:
spell.d(6): Error: undefined identifier S, did you mean struct S2?


Whereas it would be an improvement in these cases if it were to suggest the lhs
type instead.

Regards

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5612] core.cpuid not implemented on 64

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5612



--- Comment #6 from Don clugd...@yahoo.com.au 2011-02-20 08:40:20 PST ---
(In reply to comment #4)
 I don't agree this is an enhancement, it is a bug, 

It's neither. It is a task. Bugzilla's options are ridiculously limited.

 Why is this being handled by assembly code, all the operating systems must 
 have
 APIs for handling this?

The most recent ones do, the older ones don't.
Really, this code is primarily intended for determining which features should
be supported for low-level operations used by the runtime; and as such, it must
be available at a very early stage in the initialization process, regardless of
the OS. It replaces several ad-hoc and incorrect functions which had been used
in the runtime.

It would be good to supplement this with systems calls for the most recent
OSes, but to do this without breaking older OSes. Although, probably all 64-bit
OSes support it, so maybe it's only a issue for 32-bit systems.

  Of course with Mac hardware with 64-bit processors where the boot ROM is
32-bit
 the OS boots 32-bit -- since Mac OS X refuses to boot 64-bit in this case. 
 
 A hypothesis:  the current assembly code can only deal with a single processor
 which is why it reports 4 in 32-bit mode on my dual quad-core workstation.  If
 this is the case should a new bug be raised or can this be handled here?

That should be a new bug. The value should be correct, if the BIOS has done its
job in setting the processor APIC values correctly.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5622] New: [qtd] Static members imported with alias this are inaccessible

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5622

   Summary: [qtd] Static members imported with alias this are
inaccessible
   Product: D
   Version: D2
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: samu...@voliacable.com


--- Comment #0 from Max Samukha samu...@voliacable.com 2011-02-20 08:49:26 
PST ---
class A
{
enum E
{
value
}

alias E.value value;

static void foo()
{
}
}

class B
{
A a;
alias a this;
}

void main()
{
enum v = B.E.value;
enum v2 = B.value;
B.foo();
}

Error: 'this' is only defined in non-static member functions, not main

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5623] New: Slow GC with large heaps

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5623

   Summary: Slow GC with large heaps
   Product: D
   Version: D2
  Platform: Other
OS/Version: Windows
Status: NEW
  Keywords: patch, performance
  Severity: normal
  Priority: P2
 Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com


--- Comment #0 from David Simcha dsim...@yahoo.com 2011-02-20 12:10:57 PST ---
Created an attachment (id=918)
The patch.

Here's a GC benchmark and its performance on the stock GC.

import std.stdio, std.datetime, core.memory, std.conv;

void main(string[] args) {
if(args.length  2) {
stderr.writeln(Need size.);
return;
}

immutable mul = to!size_t(args[1]);
auto ptr = GC.malloc(mul * 1_048_576, GC.BlkAttr.NO_SCAN);

auto sw = StopWatch(autoStart);
GC.collect();
immutable msec = sw.peek.msecs;
writefln(Collected a %s megabyte heap in %s milliseconds.,
mul, msec);
}

Outputs for various sizes (pre-patch):

Collected a 10 megabyte heap in 1 milliseconds.
Collected a 50 megabyte heap in 4 milliseconds.
Collected a 200 megabyte heap in 16 milliseconds.
Collected a 500 megabyte heap in 41 milliseconds.
Collected a 1000 megabyte heap in 80 milliseconds.
Collected a 5000 megabyte heap in 397 milliseconds.
Collected a 1 megabyte heap in 801 milliseconds.
Collected a 3 megabyte heap in 2454 milliseconds.
Collected a 5 megabyte heap in 4096 milliseconds. 

Attached is a patch that creates separate large and small object pools, only
stores the GC bits for the large object pool at pagesize offsets, not 16-byte
offsets, and stores, rather than computes, offsets for B_PAGEPLUS pages.  So
far, all unit tests for Phobos, dstats and std.parallelism/parallelfuture pass
with this enabled.  

Here are the new benchmarks (post-patch):

Collected a 10 megabyte heap in 0 milliseconds.
Collected a 50 megabyte heap in 0 milliseconds.
Collected a 250 megabyte heap in 1 milliseconds.
Collected a 500 megabyte heap in 0 milliseconds.
Collected a 1000 megabyte heap in 1 milliseconds.
Collected a 5000 megabyte heap in 3 milliseconds.
Collected a 1 megabyte heap in 6 milliseconds.
Collected a 3 megabyte heap in 16 milliseconds.
Collected a 5 megabyte heap in 26 milliseconds.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5623] Slow GC with large heaps

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5623



--- Comment #1 from David Simcha dsim...@yahoo.com 2011-02-20 12:12:02 PST ---
Created an attachment (id=919)
The whole gcx.d file, in case you have trouble applying the patch.

Here's the whole gcx.d file, in case you have trouble applying the patch. 
(These things never quite work for me.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5623] Slow GC with large heaps

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5623


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2011-02-20 
13:03:57 PST ---
More explanation from David from the n.g.:

I've found a way to speed up the GC massively on large heaps without excessive
ripple effects.  Technically it's still O(N), but with about a hundred fold
smaller constant in the case of large heaps with most stuff not scanned.  Now,
I think the O(N) (where N is the total size of the heap) term has such a small
constant that it's for almost all practcal purposes the GC is O(S) (where S is
the size of the scanned portion of the heap).  It also no longer has any O(N^2)
pathological case (which I had discovered while reading the code).

So far all unittests for Phobos, dstats and std.parallelism/parallelfuture pass
with this enabled.  Please test some other code so we can wring out the corner
cases in time for the next release.

Basically all I did was diverge the Pool struct slightly into large and small
object sub-varieties.  The large object sub-variety is used to allocate objects
of at least a page.  It only stores gcbits at page-size offsets, and tracks the
offsets of B_PAGEPLUS bins from the nearest B_PAGE bin so that they can be
found in O(1).

I also added a field to the Pool struct so that the number of free pages in a
pool can be tracked in O(1).  This should drastically lessen the time it takes
to perform large allocations on large heaps.  Right now a free memory region is
found by a linear search through the pools in the case of large allocations. 
Unfortunately, I don't see any easy way to fix this.  This patch at least
allows short circuiting a large number of pools, if there isn't enough free
space in the whole pool, let alone contiguous space.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 937] C-style variadic functions broken

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=937


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #4 from Walter Bright bugzi...@digitalmars.com 2011-02-20 
13:11:53 PST ---
https://github.com/D-Programming-Language/dmd/commit/888bd52ab4d07c132c38f231dfabea648bf94cba

https://github.com/D-Programming-Language/dmd/commit/8d2bf812530f51b40fe08c9b0f526b60575ae604

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5623] Slow GC with large heaps

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5623


bearophile_h...@eml.cc changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc


--- Comment #3 from bearophile_h...@eml.cc 2011-02-20 13:19:15 PST ---
A very simple benchmark, in D and Java. You may use the D version with and
without your patch, and then the Java version too, and show the three timings,
with N = 15 or 18 or more:

http://codepad.org/yMGK34cb
http://codepad.org/DIOeYn6p

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5624] New: std.conv unittest disabled

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5624

   Summary: std.conv unittest disabled
   Product: D
   Version: D2
  Platform: x86_64
OS/Version: Linux
Status: NEW
  Severity: critical
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bra...@puremagic.com


--- Comment #0 from Brad Roberts bra...@puremagic.com 2011-02-20 14:19:56 PST 
---
the debug version passes
the release version segvs

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5625] New: std.format unittest disabled

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5625

   Summary: std.format unittest disabled
   Product: D
   Version: D2
  Platform: x86_64
OS/Version: Linux
Status: NEW
  Severity: critical
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bra...@puremagic.com


--- Comment #0 from Brad Roberts bra...@puremagic.com 2011-02-20 14:21:04 PST 
---
Testing generated/linux/debug/64/unittest/std/format
core.exception.AssertError@std.format(3651): unittest failure

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5626] New: std.random unittest disabled

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5626

   Summary: std.random unittest disabled
   Product: D
   Version: D2
  Platform: x86_64
OS/Version: Linux
Status: NEW
  Severity: critical
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bra...@puremagic.com


--- Comment #0 from Brad Roberts bra...@puremagic.com 2011-02-20 14:22:13 PST 
---
Testing generated/linux/debug/64/unittest/std/random
core.exception.AssertError@std.random(796): unittest failure

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5627] New: std.internal.math.biguintnoasm unittest disabled

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5627

   Summary: std.internal.math.biguintnoasm unittest disabled
   Product: D
   Version: D2
  Platform: x86_64
OS/Version: Linux
Status: NEW
  Severity: critical
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bra...@puremagic.com


--- Comment #0 from Brad Roberts bra...@puremagic.com 2011-02-20 14:23:05 PST 
---
Testing generated/linux/debug/64/unittest/std/internal/math/biguintnoasm
core.exception.asserter...@std.internal.math.biguintnoasm(263): unittest
failure

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5628] New: std.math unittest disabled

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5628

   Summary: std.math unittest disabled
   Product: D
   Version: D2
  Platform: x86_64
OS/Version: Linux
Status: NEW
  Severity: critical
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bra...@puremagic.com


--- Comment #0 from Brad Roberts bra...@puremagic.com 2011-02-20 14:25:05 PST 
---
The test either takes an enormous amount of time or it goes into an infinite
loop somewhere.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5623] Slow GC with large heaps

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5623



--- Comment #4 from David Simcha dsim...@yahoo.com 2011-02-20 14:48:45 PST ---
(In reply to comment #3)
 A very simple benchmark, in D and Java. You may use the D version with and
 without your patch, and then the Java version too, and show the three timings,
 with N = 15 or 18 or more:
 
 http://codepad.org/yMGK34cb
 http://codepad.org/DIOeYn6p

I didn't both(In reply to comment #3)
 A very simple benchmark, in D and Java. You may use the D version with and
 without your patch, and then the Java version too, and show the three timings,
 with N = 15 or 18 or more:
 
 http://codepad.org/yMGK34cb
 http://codepad.org/DIOeYn6p

Using n = 18:

D (with patch):  62 seconds
D (without patch):  68 seconds
Java:  6 seconds

I'm not sure what this told us that we didn't already know, though.  We already
knew Java's GC is much better than D's.  My patch is meant to address issues
with large object allocation, not small object.  (Large is defined as at least
one full page.  If no large objects are allocated for the duration of the
program, then my patch has virtually no effect.)  This benchmark does tons of
small object allocation and no large object allocation.  The small difference
between with and without patch may even just be noise.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


Hidden links for Language Reference on d-programming-language.org

2011-02-20 Thread Tyro[a.c.edwards]
The links for Documentation: Language Reference gets hidden when you 
click on any of the following four items:


o   Lexical
o   Templates
o   Inline Assembler
o   Documentation Comments

- Andrew


[Issue 5630] New: array() of iterable of immutable items

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5630

   Summary: array() of iterable of immutable items
   Product: D
   Version: D2
  Platform: x86
OS/Version: Windows
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2011-02-20 15:01:52 PST ---
A D2 program:


import std.algorithm: map;
import std.array: array;
void main() {
auto r = map!q{ A[0] }([0, 1, 2]);
auto a = array(r); // Error: result[i] isn't mutable
assert(a == AAA);
}


DMD 2.052 gives the errors:
...\dmd\src\phobos\std\array.d(62): Error: result[i] isn't mutable
test.d(5): Error: template instance std.array.array!(Map!(result,int[])) error
instantiating


In my opinion array() needs to be able to build an array of immutable items
too, like a string from its immutable chars.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5623] Slow GC with large heaps

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5623



--- Comment #5 from bearophile_h...@eml.cc 2011-02-20 15:07:17 PST ---
(In reply to comment #4)

 I'm not sure what this told us that we didn't already know, though.

Thank you for the timings. This synthetic benchmark tells us something
important: that for a different situation (but an important one, because that
benchmark is quite revealing, despite being so simple) your patch doesn't make
the GC significantly worse (it may even improve things a bit).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5623] Slow GC with large heaps

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5623



--- Comment #6 from bearophile_h...@eml.cc 2011-02-20 15:11:18 PST ---
(In reply to comment #4)

 We already knew Java's GC is much better than D's.

The purpose of a 3-legged comparison: the Java timing is used as a rough
zero-scale, to allow an estimate of the absolute difference between the other
two timings.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5278] DMD generates programs that immediately segfault.

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5278


Vladimir thecybersha...@gmail.com changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com


--- Comment #12 from Vladimir thecybersha...@gmail.com 2011-02-20 15:27:04 
PST ---
I just thought I'd mention that I had some similar problems with DMD on Gentoo
due to bad permissions of certain libraries. Do your programs run under root?
If so, check permissions for libphobos and whatever 32-bit libraries your
program / libphobos uses (glibc? libstdc++?).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


Re: Hidden links for Language Reference on d-programming-language.org

2011-02-20 Thread Tyro[a.c.edwards]

On 2/21/2011 7:47 AM, Tyro[a.c.edwards] wrote:

The links for Documentation: Language Reference gets hidden when you
click on any of the following four items:

o Lexical
o Templates
o Inline Assembler
o Documentation Comments

- Andrew


By the way you cannot get to the list by clicking on Language Reference 
(http://d-programming-language.org/language-reference.html).


[Issue 5623] Slow GC with large heaps

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5623


David Simcha dsim...@yahoo.com changed:

   What|Removed |Added

 Attachment #918 is|0   |1
   obsolete||


--- Comment #7 from David Simcha dsim...@yahoo.com 2011-02-20 18:29:08 PST ---
Created an attachment (id=920)
New patch.

Here's a new patch that adds one small but important optimization that I
forgot.  Now that we're storing the number of pages for B_PAGE stuff, we can
skip over large blocks in O(1) time when doing allocPages().

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5629] core.time unittest disabled

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5629



--- Comment #1 from Brad Roberts bra...@puremagic.com 2011-02-20 18:26:33 PST 
---
in TickDuration's static this.  freebsd has clock_gettime, so it uses the
clock_getres api.  The results:

ts.tv_nsec = 280, ticksPerSec = 3571428

Later, during the unit test:

auto t = TickDuration.from!nsecs(1_000_000_000);
assert(t.nsecs == 1_000_000_000);

t.nsecs is slightly less: t.nsecs = 99840

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 5623] Slow GC with large heaps

2011-02-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5623



--- Comment #8 from David Simcha dsim...@yahoo.com 2011-02-20 18:29:43 PST ---
Created an attachment (id=921)
New gcx.d

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---