[Issue 10863] [Win] executeShell() fails with spaces in cmd paths, unlike old shell()
https://d.puremagic.com/issues/show_bug.cgi?id=10863 --- Comment #3 from github-bugzi...@puremagic.com 2014-02-09 00:28:24 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/e354f65e934b972339f38e35a3e6b42ba4db9114 std.process: Improve shell escaping on Windows (issue 10863) https://github.com/D-Programming-Language/phobos/commit/d48acf249a85328ea3914c2d69b3d0ece11ce4c7 Merge pull request #1915 from CyberShadow/std-process-cmd-escaping std.process: Improve shell escaping on Windows (issue 10863) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12095] Wrong code with -O -inline
https://d.puremagic.com/issues/show_bug.cgi?id=12095 --- Comment #8 from github-bugzi...@puremagic.com 2014-02-09 00:29:13 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/97efeeae685f18a33b2090e08792e5f64d33b211 Fix Issue 12095 - Wrong code with -O -inline https://github.com/D-Programming-Language/dmd/commit/292a4b96346983cd67ca9398b54a3a143fad756b Merge pull request #3231 from yebblies/issue12095 Issue 12095 - Wrong code with -O -inline -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10863] [Win] executeShell() fails with spaces in cmd paths, unlike old shell()
https://d.puremagic.com/issues/show_bug.cgi?id=10863 Andrej Mitrovic changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12095] Wrong code with -O -inline
https://d.puremagic.com/issues/show_bug.cgi?id=12095 --- Comment #9 from yebblies 2014-02-09 19:49:46 EST --- Fixed for D2 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12095] Wrong code with -O -inline
https://d.puremagic.com/issues/show_bug.cgi?id=12095 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12095] Wrong code with -O -inline
https://d.puremagic.com/issues/show_bug.cgi?id=12095 --- Comment #10 from github-bugzi...@puremagic.com 2014-02-09 00:56:34 PST --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/079d0415ae639e339c2c876020314f9b56f805ad Merge pull request #3231 from yebblies/issue12095 Issue 12095 - Wrong code with -O -inline -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12116] New: dmd -op -od broken
https://d.puremagic.com/issues/show_bug.cgi?id=12116 Summary: dmd -op -od broken Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: blocker Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: timothee.co...@gmail.com --- Comment #0 from Timothee Cour 2014-02-09 01:36:51 PST --- dmd -c -op -odbuild ../d01/fun.d #will create ./build, and write to ./d01/fun.o instead of ./build/d01/fun.o dmd -c -op -odbuild /abspath/to/fun.d #will not create ./build and not write any .o file, and not report any error either Without -op (flat hierarchy), dmd will also produce wrong results: dmd -c fun.d util/fun.d #oops, fun.o overwritten ldc has a better way to handle the object flattening: here, it'll create: fun.o util.fun.o with no ambiguity (since '.' is not a valid character in a module anyways, unlike '_', which was previously proposed). We should have a flag to support the 'ldc' way. translate paths a/b/c containing module foo.bar to: build/a.b.c.o (choice 1, based on path given as input) or build/foo.bar.o (based on module name) For choice 1, we need to worry about the case of input files given as '../foo/bar.d' but one way that would always work would be to 1st convert to absolute paths every input file. Note, this is a blocker for incremental compilation in '1 pass' (ie where we don't compile each object file at a time but all in 1 go). -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11981] unittest 'host' deadlock
https://d.puremagic.com/issues/show_bug.cgi?id=11981 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu --- Comment #15 from Martin Nowak 2014-02-09 02:27:31 PST --- (In reply to comment #14) > The thread start up code looks very race-prone, I hadn't looked at it before. Yeah, pretty subtle, I'd really like to get rid of the Fiber context stack for example, but it's not trivial. One reason is that we're using suspend/resume on OSX and Windows but signals on Posix. > Async-safe TLS access is scheduled for glibc 2.19 (upcoming release.) As I wrote on the pull request, a correct fix would be to let Thread.sm_this use pthread_getspecific again. https://github.com/D-Programming-Language/druntime/pull/718#discussion_r9568348 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11981] unittest 'host' deadlock
https://d.puremagic.com/issues/show_bug.cgi?id=11981 --- Comment #16 from safety0ff.bugz 2014-02-09 03:13:27 PST --- (In reply to comment #15) > > Async-safe TLS access is scheduled for glibc 2.19 (upcoming > release.) > As I wrote on the pull request, a correct fix would be to let Thread.sm_this > use pthread_getspecific again. > https://github.com/D-Programming-Language/druntime/pull/718#discussion_r9568348 Looks like they've delayed async-safe TLS until a later release. I'm not familiar with pthread_getspecific, but as usual I'm learning as I go to try to help with druntime issues. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12094] typeof(null) should convert to reference types
https://d.puremagic.com/issues/show_bug.cgi?id=12094 --- Comment #3 from github-bugzi...@puremagic.com 2014-02-09 03:29:40 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e3541eee380ec22be990441cf05ca47cbbfd728d Fix Issue 12094 - typeof(null) should convert to reference types -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12117] New: Non-template overload taken when template matches better
https://d.puremagic.com/issues/show_bug.cgi?id=12117
Summary: Non-template overload taken when template matches
better
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: peter.alexander...@gmail.com
--- Comment #0 from Peter Alexander 2014-02-09
04:37:36 PST ---
import std.stdio;
struct S
{
int x;
alias x this;
}
void f(T)(T t) { writeln(T.stringof); }
void f(int t) { writeln(int.stringof); }
void main()
{
f(S.init); // f(int) called
}
This writes "int", but should write "S".
The template should be preferred because it matches without implicit
conversions while the non-template requires a conversion. TDPL states that the
non-template should be preferred only when it matches equally well (or better)
than the template.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12094] typeof(null) should convert to reference types
https://d.puremagic.com/issues/show_bug.cgi?id=12094 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #4 from bearophile_h...@eml.cc 2014-02-09 04:40:03 PST --- I suspect this request was already in bugzilla somewhere. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9506] When using alias this, writeln modifies its argument
https://d.puremagic.com/issues/show_bug.cgi?id=9506 --- Comment #14 from Peter Alexander 2014-02-09 04:41:36 PST --- (In reply to comment #13) > Hmm, I've been looking into this more, and it appears the behaviour may never > be stable across releases. > > ... [snip] ... Actually, turns out that behaviour is a bug, which I have now filed. Issue 12117 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12118] New: Modify immutable data using throw
https://d.puremagic.com/issues/show_bug.cgi?id=12118
Summary: Modify immutable data using throw
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: tim.dl...@t-online.de
--- Comment #0 from Tim 2014-02-09 04:56:54 PST ---
It is possible to throw an immutable Exception and catch it as mutable. Using
this immutable data can be modified.
Example Code:
class Dummy: Exception
{
int[] data;
@safe pure nothrow this(immutable int[] data) immutable
{
super("Dummy");
this.data = data;
}
}
@safe pure void modifyImmutable(immutable int[] data)
{
try
{
immutable Dummy e = new immutable Dummy(data);
throw e;
}
catch(Dummy e)
{
e.data[1] = 42;
}
}
@safe pure void main()
{
immutable int[] data = [1,2,3];
assert(data == [1,2,3]);
modifyImmutable(data);
assert(data == [1,42,3]);
}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12117] Non-template overload taken when template matches better
https://d.puremagic.com/issues/show_bug.cgi?id=12117 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2014-02-09 05:12:59 PST --- It likely has to do with the order of operations: 1) Try direct match of: type, then alias this, on regular function 2) Try direct match of: type, then alias this, on templated function (I'm just speculating it works /something/ like this) And the 'alias this' wins before a templated function is tried. I guess it's a question of priority. We'll see what Kenji and others have to say. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11981] unittest 'host' deadlock
https://d.puremagic.com/issues/show_bug.cgi?id=11981 --- Comment #17 from Stanislav Blinov 2014-02-09 07:03:20 PST --- I'm starting to wonder if it's really posix-specific. The issue only manifests when using shared libraries (second malloc call is made from dl-tls.c). Can Windows DLL TLS handling be susceptible to this too? Is it currently possible to replicate that unittest for Windows? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12090] Make std.concurrency compatible with fibers as threads
https://d.puremagic.com/issues/show_bug.cgi?id=12090
Jakob Ovrum changed:
What|Removed |Added
CC||jakobov...@gmail.com
--- Comment #2 from Jakob Ovrum 2014-02-09 07:15:04 PST
---
(In reply to comment #1)
> I think something like the following will work:
>
> interface Scheduler
> {
> void start(void delegate() op);
> void spawn(void delegate() op);
> void yield();
> @property ref ThreadInfo thisInfo();
> Condition newCondition(Mutex m);
> }
>
>
> When using a scheduler, main() should do any initial setup that it wants and
> then call scheduler.start(), which will effectively spawn the supplied
> delegate
> as a thread and then begin dispatching.
>
> The remaining functions are all used by the std.concurrency implementation.
> spawn() does the work of actually creating new threads, yield() will yield
> execution of the current fiber (or optionally, thread) so that multiprocessing
> can occur, and newCondition constructs a Condition object used by send() and
> receive() to indicate that a message has arrived, block waiting for a new
> message, etc. Finally, ThreadInfo is needed so that the thread-local statics
> currently in std.concurrency can be made local to the "thread" currently
> executing. If thisInfo is called by a thread or fiber not spawned by
> std.concurrency, it can return a thread-local copy instead.
It has been suggested that std.concurrency should also be able to support IPC
(most importantly by Andrei in the module's documentation). The proposed
Scheduler interface seems close to supporting that for fork()-based code (which
of course isn't an option for non-POSIX systems), but do you have any thoughts
on this?
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12119] New: core.demangle shouldn't reallocate output buffer, unnecessary GC dependency
https://d.puremagic.com/issues/show_bug.cgi?id=12119 Summary: core.demangle shouldn't reallocate output buffer, unnecessary GC dependency Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: c...@dawg.eu --- Comment #0 from Martin Nowak 2014-02-09 07:17:45 PST --- Currently it increases the length of the optional destination buffer if the length of the demangled name doesn't fit. This makes it impossible to use core.demangle without a GC. http://dlang.org/phobos/core_demangle.html#demangle -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5753] Disallow map() of void function
https://d.puremagic.com/issues/show_bug.cgi?id=5753 Peter Alexander changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m --- Comment #5 from Peter Alexander 2014-02-09 07:40:09 PST --- https://github.com/D-Programming-Language/phobos/pull/1917 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11981] unittest 'host' deadlock
https://d.puremagic.com/issues/show_bug.cgi?id=11981 --- Comment #18 from Martin Nowak 2014-02-09 10:00:29 PST --- (In reply to comment #17) > I'm starting to wonder if it's really posix-specific. The issue only manifests > when using shared libraries (second malloc call is made from dl-tls.c). > Yep, because the TLS segment for loaded shared libraries is allocated lazily, while the TLS segments the executable and linked shared libraries are allocated eagerly. > Can Windows DLL TLS handling be susceptible to this too? Is it currently > possible to replicate that unittest for Windows? The same problem cannot happen on OSX or Windows, because we're using suspend API's there, i.e. no signal handler code that does the TLS access is run. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9493] std.algorithm.canFind returns true for empty string in array of integers
https://d.puremagic.com/issues/show_bug.cgi?id=9493 Peter Alexander changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m --- Comment #3 from Peter Alexander 2014-02-09 10:06:12 PST --- int is comparable with dchar, so this is working as intended. Note: you can also do this: assert(canFind([1, 2, 3, 4], "\x02\x03")); // success assert(canFind([1, 2, 3, 4], "\x02\x05")); // fail Remember that the "needle" can be a range as well. If there are no further issues, I'll resolve this as invalid. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12120] New: Static opCall for structures skipped (Github HEAD)
https://d.puremagic.com/issues/show_bug.cgi?id=12120
Summary: Static opCall for structures skipped (Github HEAD)
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: pun...@coverify.org
--- Comment #0 from Puneet Goel 2014-02-09 10:32:02 PST
---
Here is the reduced code.
struct Foo {
this(int) {}
static Foo opCall() {
import std.stdio;
writeln("opCall");
Foo foo = Foo(0);
return foo;
}
}
void main() {
Foo foo = Foo();
}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12120] Static opCall for structures skipped (Github HEAD)
https://d.puremagic.com/issues/show_bug.cgi?id=12120 --- Comment #1 from Puneet Goel 2014-02-09 10:34:16 PST --- Seems to be due to fix12070. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12121] New: atomicLoad!(MemoryOrder.acq) should not emit additional code on X86
https://d.puremagic.com/issues/show_bug.cgi?id=12121
Summary: atomicLoad!(MemoryOrder.acq) should not emit
additional code on X86
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: stanislav.bli...@gmail.com
--- Comment #0 from Stanislav Blinov 2014-02-09
10:49:48 PST ---
Current implementation of needsLoadBarrier in core.atomic is as follows:
template needsLoadBarrier( MemoryOrder ms )
{
enum bool needsLoadBarrier = ms != MemoryOrder.raw;
}
On X86, acquire loads should not require fences, release-acquire ordering is
automatic.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8848] Array literals and AA literals are rejected as template value parameters
https://d.puremagic.com/issues/show_bug.cgi?id=8848 yebblies changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5462] std.container.BinaryHeap enforce message + pop
https://d.puremagic.com/issues/show_bug.cgi?id=5462 Peter Alexander changed: What|Removed |Added Status|NEW |RESOLVED CC||peter.alexander...@gmail.co ||m Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11830] std.stdio.byLine reports extra line if you don't call .front
https://d.puremagic.com/issues/show_bug.cgi?id=11830 Peter Alexander changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12122] New: Template with enumerated constant length array causes error.
https://d.puremagic.com/issues/show_bug.cgi?id=12122 Summary: Template with enumerated constant length array causes error. Product: D Version: D2 Platform: x86_64 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: dy70swq+kzu...@sharklasers.com --- Comment #0 from tcak 2014-02-09 11:58:18 PST --- Created an attachment (id=1323) Example D2 code to generate the error together with what causes it. When foo function is used, compile time error is seen. bugtesr.d(16): Error: template bugtesr.Test.foo does not match any function template declaration. Candidates are: bugtesr.d(4):bugtesr.Test.foo(T)(in T[Test.DATA_LENGTH] msg) if (is(T : ubyte) || is(T : char)) bugtesr.d(16): Error: template bugtesr.Test.foo(T)(in T[Test.DATA_LENGTH] msg) if (is(T : ubyte) || is(T : char)) cannot deduce template function from argument types !()(ubyte[16]) If the constant DATA_LENGTH is replaced with its real value 16, it works without a problem. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12122] Template with enumerated constant length array causes error.
https://d.puremagic.com/issues/show_bug.cgi?id=12122
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #1 from bearophile_h...@eml.cc 2014-02-09 12:27:46 PST ---
Reduced:
enum N = 1;
void foo(T)(T[N]) if(is(T == int)) {}
void main() {
int[N] data;
foo(data);
}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5462] std.container.BinaryHeap enforce message + pop
https://d.puremagic.com/issues/show_bug.cgi?id=5462 --- Comment #2 from bearophile_h...@eml.cc 2014-02-09 12:30:03 PST --- Is the heap.pop(); a WONTFIX? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5462] std.container.BinaryHeap enforce message + pop
https://d.puremagic.com/issues/show_bug.cgi?id=5462 Peter Alexander changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #3 from Peter Alexander 2014-02-09 12:37:08 PST --- Sorry, missed that. (would probably be better if this was two separate enhancements) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12118] Modify immutable data using throw
https://d.puremagic.com/issues/show_bug.cgi?id=12118
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #1 from Andrej Mitrovic 2014-02-09
12:48:38 PST ---
Interesting.. but I don't see how this can be solved except disallowing
throwing non-mutable objects. Otherwise you'd end up in a situation where "try
{ } catch (Throwable) { }" could let an Exception through because it's
non-mutable.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12118] Modify immutable data using throw
https://d.puremagic.com/issues/show_bug.cgi?id=12118 --- Comment #2 from Andrej Mitrovic 2014-02-09 12:49:16 PST --- Also since Exceptions can be chained I don't think it makes sense to allow throwing non-mutable objects. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5462] std.container.BinaryHeap enforce message + pop
https://d.puremagic.com/issues/show_bug.cgi?id=5462 bearophile_h...@eml.cc changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #4 from bearophile_h...@eml.cc 2014-02-09 12:55:24 PST --- (In reply to comment #3) > Sorry, missed that. > > (would probably be better if this was two separate enhancements) Yes, this ER is from some years ago, and since then I've learnt to avoid packing two or more enhancements or bug reports in the same issue report, unless they are really tied together. So I close this issue again, and split it into another (but I remember some issues against the idea of having a pop() function in C++). -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9493] std.algorithm.canFind returns true for empty string in array of integers
https://d.puremagic.com/issues/show_bug.cgi?id=9493 --- Comment #4 from monkeywork...@hotmail.com 2014-02-09 13:04:11 PST --- I'm not particularly satisfied with that, as I filed this as the result of a bug this behaviour caused, but I can't think of a good solution, either. Thoughts? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9493] std.algorithm.canFind returns true for empty string in array of integers
https://d.puremagic.com/issues/show_bug.cgi?id=9493 --- Comment #5 from Peter Alexander 2014-02-09 13:12:47 PST --- (In reply to comment #4) > I'm not particularly satisfied with that, as I filed this as the result of a > bug this behaviour caused, but I can't think of a good solution, either. > Thoughts? My thoughts: 1. We cannot change the fact that int is comparable with dchar. It would break too much code. 2. We cannot change the fact that canFind works with two ranges of comparable elements. It was part of the design, and would break too much code anyway. I don't see any way around this. I admit that at a first glance it doesn't look like it should compile, but it does make sense once you consider what's happening. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9493] std.algorithm.canFind returns true for empty string in array of integers
https://d.puremagic.com/issues/show_bug.cgi?id=9493 --- Comment #6 from monkeywork...@hotmail.com 2014-02-09 13:26:30 PST --- (In reply to comment #5) > My thoughts: > > 1. We cannot change the fact that int is comparable with dchar. It would break > too much code. > 2. We cannot change the fact that canFind works with two ranges of comparable > elements. It was part of the design, and would break too much code anyway. > > I don't see any way around this. > > I admit that at a first glance it doesn't look like it should compile, but it > does make sense once you consider what's happening. I suppose, though maybe it should say in the documentation that such edge cases may occur, using this as an example. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11786] Wrong keyword color for Visual Studio Dark theme
https://d.puremagic.com/issues/show_bug.cgi?id=11786 --- Comment #3 from Rainer Schuetze 2014-02-09 13:44:13 PST --- I have added support to change the default color of some color types if a dark theme is detected (restart required as VS doesn't update its color cache). Please try it in v0.3.38beta3 which can be found here: https://github.com/D-Programming-Language/visuald/releases -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9493] std.algorithm.canFind returns true for empty string in array of integers
https://d.puremagic.com/issues/show_bug.cgi?id=9493 --- Comment #7 from Peter Alexander 2014-02-09 13:42:32 PST --- (In reply to comment #6) > I suppose, though maybe it should say in the documentation that such edge > cases > may occur, using this as an example. Where do you draw the line with such things though? ints comparing with dchars is part of the language. If you add a warning about it in canFind then do you add it in every functions that does a comparison? All of the following compile and the assertions hold. // Note: 32 == ' ' in ASCII assert(count([0, 16, 32, 64], ' ') == 1); assert(commonPrefix([32, 32, 30], " x") == " "); assert(equal([32], " ")); assert([32].filter!(x => x != ' ').empty); There are many more situations where this can come up. I can't see the benefit of warning about it in the documentation. D programmers just need to be aware that characters are a form of integer and that they can be compared. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12123] New: heap.pop
https://d.puremagic.com/issues/show_bug.cgi?id=12123 Summary: heap.pop Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2014-02-09 13:45:24 PST --- This is a split from Issue 5462 . In code that uses the BinaryHeap I often use two lines of code like (note it use removeFront and not popFront): auto item = heap.front; heap.removeFront; So I suggest to add to BinaryHeap a handy member function pop() that does both things: auto item = heap.pop; (In a dynamic array a pop() should call back+popBack, so it's a function specialized for heaps.) See also: http://stackoverflow.com/questions/12600330/pop-back-return-value http://ptgmedia.pearsoncmg.com/images/020163371x/supplements/Exception_Handling_Article.html http://www.gotw.ca/gotw/008.htm -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12052] VS2013 (NuGet) complains a lot when VisualD projects are present
https://d.puremagic.com/issues/show_bug.cgi?id=12052 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze 2014-02-09 13:52:34 PST --- I have muted the NuGet errors in the latest beta: https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.38beta2 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11962] VisualD needs an option to choose the CRT to link against
https://d.puremagic.com/issues/show_bug.cgi?id=11962 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #5 from Rainer Schuetze 2014-02-09 13:50:20 PST --- A reference to LIBCMT is added by dmd to the object file that contains main, and it is generated to the C modules in phobos.lib. I don't think Visual D can do anything about changing it but to add /NODEFAULTLIB to the linker. Would that be good enough? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12021] VS2012-2013 .vcxproj files don't show in the solution explorer
https://d.puremagic.com/issues/show_bug.cgi?id=12021 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #2 from Rainer Schuetze 2014-02-09 14:13:26 PST --- I cannot reproduce this with VS2013 and small sample projects. Can you try to reduce your projects and see whether the problem goes away at some point? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9493] std.algorithm.canFind returns true for empty string in array of integers
https://d.puremagic.com/issues/show_bug.cgi?id=9493 --- Comment #8 from monkeywork...@hotmail.com 2014-02-09 14:32:22 PST --- (In reply to comment #7) > assert(commonPrefix([32, 32, 30], " x") == " "); > assert(equal([32], " ")); > assert([32].filter!(x => x != ' ').empty); This is bad and we should all feel bad that this C anachronism still persists in any language. I've never liked the fact that characters are really just numbers. Anyway, go ahead and close it. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9493] std.algorithm.canFind returns true for empty string in array of integers
https://d.puremagic.com/issues/show_bug.cgi?id=9493 Peter Alexander changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #9 from Peter Alexander 2014-02-09 14:35:45 PST --- (In reply to comment #8) > (In reply to comment #7) > > assert(commonPrefix([32, 32, 30], " x") == " "); > > assert(equal([32], " ")); > > assert([32].filter!(x => x != ' ').empty); > > This is bad and we should all feel bad that this C anachronism still persists > in any language. I've never liked the fact that characters are really just > numbers. Anyway, go ahead and close it. Maybe in D3? :-) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12098] libcurl bad argument on handle null
https://d.puremagic.com/issues/show_bug.cgi?id=12098 Kenji Hara changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #3 from Kenji Hara 2014-02-09 17:25:23 PST --- https://github.com/D-Programming-Language/phobos/pull/1920 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12120] Static opCall for structures skipped (Github HEAD)
https://d.puremagic.com/issues/show_bug.cgi?id=12120
Kenji Hara changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
--- Comment #2 from Kenji Hara 2014-02-09 17:30:31 PST ---
(In reply to comment #0)
> Here is the reduced code.
>
> struct Foo {
> this(int) {}
> static Foo opCall() {
> import std.stdio;
> writeln("opCall");
> Foo foo = Foo(0);
> return foo;
> }
> }
>
> void main() {
> Foo foo = Foo();
> }
If you define constructors in a struct, the syntax `Type()` should be reserved
for default construction.
If you want to support both Foo() and Foo(1), you should change the constructor
to static Foo opCall(int).
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11171] Text relocations in Phobos shared library
https://d.puremagic.com/issues/show_bug.cgi?id=11171 --- Comment #9 from github-bugzi...@puremagic.com 2014-02-09 17:51:47 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1a99b8b6fea24094d483251cf7c8f2d4206813aa fix Issue 11171 - text relocations in shared phobos library - Read-only data with relocations cannot be added to CDATA, because text relocations are prohibited by many security checks (SELinux). Also text relocations effectively break sharing of read-only segments across multiple processes. https://github.com/D-Programming-Language/dmd/commit/70653611a580867c232eb451b17a0f73d72e0b62 Merge pull request #3187 from MartinNowak/fix11171 [dll] fix Issue 11171 – Text relocations in Phobos shared library -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12120] Static opCall for structures skipped (Github HEAD)
https://d.puremagic.com/issues/show_bug.cgi?id=12120
--- Comment #3 from Puneet Goel 2014-02-09 18:04:52 PST
---
>
> If you define constructors in a struct, the syntax `Type()` should be reserved
> for default construction.
>
> If you want to support both Foo() and Foo(1), you should change the
> constructor
> to static Foo opCall(int).
I am sorry if I missed something, but how do I initialize a struct object
element from a call to Foo()? I believe default constructors are not allowed
for structs.
Say:
class Bar {}
struct Foo {
Bar bar; // bar is not static
static Foo opCall() {
// I want to return a Foo object with bar initialized
// How can I achieve that??
}
this() { // Does not compile
bar = new Bar();
}
}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12120] Static opCall for structures skipped (Github HEAD)
https://d.puremagic.com/issues/show_bug.cgi?id=12120
Vladimir Panteleev changed:
What|Removed |Added
CC||thecybersha...@gmail.com
--- Comment #4 from Vladimir Panteleev 2014-02-10
04:12:04 EET ---
(In reply to comment #2)
> If you define constructors in a struct, the syntax `Type()` should be reserved
> for default construction.
>
> If you want to support both Foo() and Foo(1), you should change the
> constructor
> to static Foo opCall(int).
If I understood this change correctly, I don't think it is a good change, as I
mentioned in the pull request:
https://github.com/D-Programming-Language/dmd/pull/3221
This issue only serves as further evidence towards that.
(In reply to comment #3)
> I am sorry if I missed something, but how do I initialize a struct object
> element from a call to Foo()? I believe default constructors are not allowed
> for structs.
static Foo opCall()
{
Foo foo;
foo.bar = ...;
return foo;
}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12089] std.utf.validate and inout(char[]) failts to compile
https://d.puremagic.com/issues/show_bug.cgi?id=12089 Kenji Hara changed: What|Removed |Added Keywords||pull, rejects-valid Component|Phobos |DMD --- Comment #2 from Kenji Hara 2014-02-09 18:24:47 PST --- Both compiler and Phobos fix are necessary. https://github.com/D-Programming-Language/dmd/pull/3239 https://github.com/D-Programming-Language/phobos/pull/1921 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12120] Static opCall for structures skipped (Github HEAD)
https://d.puremagic.com/issues/show_bug.cgi?id=12120
--- Comment #5 from Puneet Goel 2014-02-09 18:25:16 PST
---
> static Foo opCall()
> {
> Foo foo;
> foo.bar = ...;
> return foo;
> }
Thanks Vladimir.
Kenji the idea that this syntax "Foo foo = Foo();" would not be supported if
another constructor is available is a bit too constraining.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12124] New: Never be used static opCall should be reported
https://d.puremagic.com/issues/show_bug.cgi?id=12124
Summary: Never be used static opCall should be reported
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2014-02-09 18:57:56 PST ---
From:
https://github.com/D-Programming-Language/dmd/pull/3221#issuecomment-34595032
By fixing issue 12070, this code never asserts in runtime.
struct S
{
this(int) {}
static S opCall()
{
assert(0);
}
}
void main()
{
auto s = S();
}
To avoid silent code breaking, compiler should report message that static
opCall is never used.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12052] VS2013 (NuGet) complains a lot when VisualD projects are present
https://d.puremagic.com/issues/show_bug.cgi?id=12052 --- Comment #2 from Manu 2014-02-09 19:17:21 PST --- (In reply to comment #1) > I have muted the NuGet errors in the latest beta: > https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.38beta2 That'll do it... but what about that cause of the problem? That article I linked that says it is trying to call some missing API's from the project implementation, does that sound likely? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12124] Never be used static opCall should be reported
https://d.puremagic.com/issues/show_bug.cgi?id=12124 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara 2014-02-09 19:23:26 PST --- https://github.com/D-Programming-Language/dmd/pull/3240 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11962] VisualD needs an option to choose the CRT to link against
https://d.puremagic.com/issues/show_bug.cgi?id=11962 --- Comment #6 from Manu 2014-02-09 19:22:50 PST --- (In reply to comment #5) > A reference to LIBCMT is added by dmd to the object file that contains main, > and it is generated to the C modules in phobos.lib. > I don't think Visual D can do anything about changing it but to add > /NODEFAULTLIB to the linker. Would that be good enough? It sounds like DMD needs to introduce this concept as a compile flag, and VisualD needs to add an option in the project settings to select (just like in C++). I'd suggest a workaround that VisualD can implement immediately would be to use /NODEFAULTLIB by default, and also offer the option in the project settings to choose the CRT to link explicitly? The project option could then be switched to support a proper DMD compile flag at a later time when DMD adds such a thing? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12120] Static opCall for structures skipped (Github HEAD)
https://d.puremagic.com/issues/show_bug.cgi?id=12120 --- Comment #6 from Kenji Hara 2014-02-09 19:35:13 PST --- (In reply to comment #4) > If I understood this change correctly, I don't think it is a good change, as I > mentioned in the pull request: > https://github.com/D-Programming-Language/dmd/pull/3221 > > This issue only serves as further evidence towards that. I opened an enhancement issue 12124. (In reply to comment #5) > Kenji the idea that this syntax "Foo foo = Foo();" would not be supported if > another constructor is available is a bit too constraining. Do complex work with the syntax Foo() is not recommended in D language design. In D, Foo foo = Foo(); is normally equivalent with Foo foo;. It is important in generic code. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12125] New: Win64 phobos has hard references to LIBCMT
https://d.puremagic.com/issues/show_bug.cgi?id=12125 Summary: Win64 phobos has hard references to LIBCMT Product: D Version: D2 Platform: x86_64 OS/Version: Windows Status: NEW Severity: major Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: turkey...@gmail.com --- Comment #0 from Manu 2014-02-09 21:04:24 PST --- Unless phobos has some dependencies on a particular flavour of MS CRT, then it should be built with /Zl to omit the reference in the object files. If phobos does depend on the particular flavour of CRT it links against, then a suite of phobos libs would need to be built to match the suite of CRT options. I don't think this is the case however. Currently, linking phobos causes CRT conflicts when linking in conjunction with other libs that depend on a different CRT. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12127] New: DMD-Win64 needs an option to omit a CRT reference
https://d.puremagic.com/issues/show_bug.cgi?id=12127 Summary: DMD-Win64 needs an option to omit a CRT reference Product: D Version: D2 Platform: x86_64 OS/Version: Windows Status: NEW Severity: major Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: turkey...@gmail.com --- Comment #0 from Manu 2014-02-09 21:14:00 PST --- DMD needs an option equivalent to /Zl to omit placing a reference to a particular CRT in object files. In many cases where the choice of CRT is irrelevant to your code, is it normal to compile with this option to prevent likely linking errors when linking against libraries which may have conflicting CRT references. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12126] New: DMD needs option to select CRT flavour
https://d.puremagic.com/issues/show_bug.cgi?id=12126 Summary: DMD needs option to select CRT flavour Product: D Version: D2 Platform: x86_64 OS/Version: Windows Status: NEW Severity: major Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: turkey...@gmail.com --- Comment #0 from Manu 2014-02-09 21:11:05 PST --- Windows objects usually contain a reference to a particular flavour of the CRT it wants to link against, and it seems objects produced by DMD are no exception. Currently, DMD has no option to select which CRT reference to embed, and this makes for lots of problems in complex linkage environments. DMD should have options added to match the MSC options /MT /MD /MTd /MDd, and insert the appropriate CRT reference accordingly. The default is probably okay, but I suggest that /MTd should be selected by default when building -debug, since other C code built with /MTd is currently incompatible. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12118] Modify immutable data using throw
https://d.puremagic.com/issues/show_bug.cgi?id=12118
--- Comment #3 from Kenji Hara 2014-02-09 23:01:11 PST ---
(In reply to comment #0)
At least, defining immutable constructor in derived classes of Throwable should
be disallowed.
> class Dummy: Exception
> {
> int[] data;
> @safe pure nothrow this(immutable int[] data) immutable
> {
> super("Dummy");
--> during immutable object construction, mutable super constructor should
not
be invoked.
> this.data = data;
> }
> }
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12117] Non-template overload taken when template matches better
https://d.puremagic.com/issues/show_bug.cgi?id=12117 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Kenji Hara 2014-02-09 23:10:12 PST --- *** This issue has been marked as a duplicate of issue 5363 *** -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5363] const + alias this = wrong code
https://d.puremagic.com/issues/show_bug.cgi?id=5363 Kenji Hara changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m --- Comment #5 from Kenji Hara 2014-02-09 23:10:13 PST --- *** Issue 12117 has been marked as a duplicate of this issue. *** -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12052] VS2013 (NuGet) complains a lot when VisualD projects are present
https://d.puremagic.com/issues/show_bug.cgi?id=12052 --- Comment #3 from Rainer Schuetze 2014-02-09 23:33:34 PST --- The cause is that NuGet uses the "automation model" of a project to request project items and properties. This isn't implemented completely in Visual D, mostly because it can involve marshalling which isn't fun to do outside C#. So far, Visual D reported 0 project elements, while it didn't implement an enumerator. This is added now, always returning an empty enumerator. In addition, I support two project properties that are requested by NuGet. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12089] std.utf.validate and inout(char[]) failts to compile
https://d.puremagic.com/issues/show_bug.cgi?id=12089 --- Comment #3 from github-bugzi...@puremagic.com 2014-02-09 23:53:28 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/aaf4bd8df5f612bca0c80ed76b5d2fc3a7c3f23c fix Issue 12089 - std.utf.validate and inout(char[]) failts to compile https://github.com/D-Programming-Language/dmd/commit/c3b9b2497860e39b7ca5f4fd8da2f6ba75ef9e0c Merge pull request #3239 from 9rnsr/fix12089 [REG2.065a] Issue 12089 - std.utf.validate and inout(char[]) failts to compile -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
