Re: C1X features
Please ignore this post, my error, I am sorry. I'll post it elsewhere again.
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #67 from Leandro Lucarella llu...@gmail.com 2010-08-08 08:10:19 PDT --- Sor(In reply to comment #66) http://www.llucax.com.ar/blog/blog/post/1490c03e That page shows me a spectacularly complex page of Python error messages. Sorry about that, fixed! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4595] Accessing non-static member of a null reference compiles
http://d.puremagic.com/issues/show_bug.cgi?id=4595 --- Comment #9 from Andrej Mitrovic andrej.mitrov...@gmail.com 2010-08-08 09:16:57 PDT --- This is not a feature request. The TDPL specifically states that in *simple* cases such as these, DMD should flag this as an error. Otherwise if it can't figure out if it indeed is a null-reference, it will compile and let the user handle it. I usually compile with all warnings on. Thanks for the -O trick, bearophile. I never thought adding optimizations can catch bugs like that. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4595] Accessing non-static member of a null reference compiles
http://d.puremagic.com/issues/show_bug.cgi?id=4595 --- Comment #10 from bearophile_h...@eml.cc 2010-08-08 12:05:25 PDT --- With -O -unittest DMD is already able to catch the first of the two shown cases (it doesn't catch the case with __traits(compiles, a.x = 5). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3848] functions in std.file don't take symbolic links into account
http://d.puremagic.com/issues/show_bug.cgi?id=3848 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #17 from Don clugd...@yahoo.com.au 2010-08-08 13:12:55 PDT --- (In reply to comment #16) Created an attachment (id=706) [details] Patch with changes based off of phobos revision 1817 Here's the patch version of the changes. By the way, is there any particular reason that these changes have not been applied to Phobos beyond no one taking the time to look at the issue? That is, is there anything definitively wrong with my patch that I would need to fix? Or is it just that the Phobos devs are busy with other things and haven't looked at my patch? The latter. There's a huge backlog of quality patches -- for the compiler as well. Unfortunately a couple of issues have been grabbing all the attention. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4599] New: Error messages with missing memory for array operations
http://d.puremagic.com/issues/show_bug.cgi?id=4599
Summary: Error messages with missing memory for array
operations
Product: D
Version: D1 D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: diagnostic
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-08-08 14:29:12 PDT ---
(I don't know where to file this, so I open a new bug report, sorry if it is a
duplicated.)
I'd like DMD 2.047 to catch this bug at compile time (so this is more an
enhancement request):
import std.stdio: writeln;
void main() {
double[] a = [1];
writeln(a[] + 1); // access violation
}
This prints nothing and raises no compile-time or run-time errors (this is more
like a bug):
import std.stdio: writeln;
void main() {
int[] a1 = [1, 2];
int[] a2 = [3, 4];
int[] a3;
a3[] = a1[] + a2[];
writeln(a3);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3848] functions in std.file don't take symbolic links into account
http://d.puremagic.com/issues/show_bug.cgi?id=3848 --- Comment #18 from Jonathan M Davis jmdavisp...@gmail.com 2010-08-08 16:05:16 PDT --- I figured as much, but I didn't want to keep trying to keep my patch up-to-date if there were definitely a problem with it that made it unacceptable. So, I'll just keep making sure it's at least reasonably up-to-date until someone gets around to it. Thanks. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4599] Error messages with missing memory for array operations
http://d.puremagic.com/issues/show_bug.cgi?id=4599 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2010-08-08 17:54:43 PDT --- Isn't the second one similar to what I've reported in Issue 4521 ? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4599] Error messages with missing memory for array operations
http://d.puremagic.com/issues/show_bug.cgi?id=4599 --- Comment #2 from bearophile_h...@eml.cc 2010-08-08 18:55:32 PDT --- I think it is not, because here you aren't setting the items of a3 to a certain value, you are assigning a certain number of values coming from the vector operation. And there is not enough space for them. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4516] Regression(2.040): forward declaration of enum not supported
http://d.puremagic.com/issues/show_bug.cgi?id=4516 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com Version|D2 |D1 --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2010-08-08 20:51:50 PDT --- You're right that D1 doesn't check for it, as defaultVal is just an integer. I'll apply your fix for D2, but leave the bug open for D1. http://www.dsource.org/projects/dmd/changeset/605 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4600] New: writeln() is not thread-safe
http://d.puremagic.com/issues/show_bug.cgi?id=4600
Summary: writeln() is not thread-safe
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmail.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmail.com 2010-08-08
20:53:43 PDT ---
Okay. Maybe I misunderstood something somewhere, but as I understand it,
writeln() is supposed to be thread-safe. Multiple threads can interleave lines
that they're printing, but each line that a thread prints with writeln() is
supposed to be completely printed before a line from another thread can be
printed. However, at least some of the time, the output from one thread is
mixed with another on the same line. For instance, take this program:
import std.concurrency;
import std.stdio;
void main(string[] args)
{
spawn(func1, thisTid, args.idup);
spawn(func2, thisTid, args.idup);
writeln(main() 1);
writeln(main() 2);
writeln(main() 3);
}
void func1(Tid parentTid, immutable string[] args)
{
writefln(func1() begin);
writefln(func1(): %s, args);
writefln(func1() end);
}
void func2(Tid parentTid, immutable string[] args)
{
writefln(func2() begin);
writefln(func2(): %s, args);
writefln(func2() end);
}
If I run it like so
./d hello world
I get:
main() 1
main() 2
main() 3
func1() beginfunc2() begin
func1() beginfunc2() begin
[./d, hello, world]
func2() end
or
main() 1
func1() beginfunc2() begin
main() 2
func1() beginfunc2() begin
main() 2
main() 3
eginfunc2() begin
main() 3
or in this case, the line printing out the args array doesn't even print the
whole beginning of the line:
main() 1
main() 2
main() 3
func1() begin
func1() begin
func2() begin
, hello, world]
func1() end
In some cases, the lines are properly printed (naturally with whole lines
potentially interleaved due to the multiple threads running), but often they
aren't. So, if writeln() is really supposed to be thread-safe, it's buggy. If
it's not, then programs intending to use writeln() (or its sibling write
functions) are going to need to wrap them with locks or some other concurrency
mechanism to being able to safely print, which certainly wouldn't play well
with the whole message-passing for concurrency paradigm.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4601] New: Spawned threads frequently don't terminate or let other threads ever run if you spawn more than one thread
http://d.puremagic.com/issues/show_bug.cgi?id=4601
Summary: Spawned threads frequently don't terminate or let
other threads ever run if you spawn more than one
thread
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmail.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmail.com 2010-08-08
21:03:34 PDT ---
In trying to use spawn() from std.concurrency, I've noticed that it's
frequently the case that once a thread starts, none of the other threads that I
have run. In some cases, another thread might take over the CPU from another
thread - it might even give it back - but rarely do all of the threads actually
complete executing. And even if they do, the application never terminates. For
instance, take the program:
import std.concurrency;
import std.stdio;
void main(string[] args)
{
spawn(func1, thisTid, args.idup);
spawn(func2, thisTid, args.idup);
writeln(main() 1);
writeln(main() 2);
writeln(main() 3);
}
void func1(Tid parentTid, immutable string[] args)
{
writefln(func1() begin);
writefln(func1(): %s, args);
writefln(func1() end);
}
void func2(Tid parentTid, immutable string[] args)
{
writefln(func2() begin);
writefln(func2(): %s, args);
writefln(func2() end);
}
Aside from the issues with writeln() in bug 4600 (
http://d.puremagic.com/issues/show_bug.cgi?id=4600 ), if you run it, you'll
notice that it never terminates and that never prints the last print statement
from each thread (though whether that's an issue with writeln() followed by the
application never terminating or whether the threads are in fact not actually
running to completion, I don't know).
If I only spawn one thread, then the application seems to run just fine and
terminate properly, but if I spawn two or more, then the threads do not run to
completion, and the application does not terminate.
For spawn() and its compatriot's send() and receive() to be of any use, threads
started with spawn() obviously need to run to termination (barring infinite
loops or other such errors in the functions that the threads are running), and
the application itself needs to terminate. Unfortunately, from what I can see,
that's far from a guarantee for a moment. I don't know if I'm supposed to mark
bugs as major or worse or if only Phobos devs are supposed to do that, but this
one seems severe enough, that I'm marking it as Major. As it is, this bug makes
most cases where I would try and use multi-theading in an application
completely infeasible.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4503] forward reference to aliased template instance
http://d.puremagic.com/issues/show_bug.cgi?id=4503 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2010-08-08 21:32:00 PDT --- http://www.dsource.org/projects/dmd/changeset/607 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4267] forward reference error when 2-fold aliasing a template instance
http://d.puremagic.com/issues/show_bug.cgi?id=4267 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2010-08-08 21:33:28 PDT --- Fixed with 4503 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3326] $ in delegate literal causes Access Violation
http://d.puremagic.com/issues/show_bug.cgi?id=3326 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2010-08-08 22:30:46 PDT --- http://www.dsource.org/projects/dmd/changeset/608 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
