[Issue 5412] New: import wtf2
http://d.puremagic.com/issues/show_bug.cgi?id=5412
Summary: import wtf2
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ellery-newco...@utulsa.edu
--- Comment #0 from Ellery Newcomer 2011-01-04
17:26:53 PST ---
quick, what does the following code do?
import A = std.algorithm;
import A = std.string;
import std.stdio;
void main(){
writeln(A.indexOf("abc","b"));
}
also, what does it do when you comment out either of the 'import A'?
partial answer: it happily compiles in all three cases.
though this example is a bit unglamorous since indexOf does the same thing
either way.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5411] New: import wtf1
http://d.puremagic.com/issues/show_bug.cgi?id=5411
Summary: import wtf1
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ellery-newco...@utulsa.edu
--- Comment #0 from Ellery Newcomer 2011-01-04
17:20:43 PST ---
quick! where does the following code fail?
import std.stdio, std.algorithm: writeln, indexOf;
void main(){
writefln("abc"); //1
writeln(map!("a+1")([1,2,3])); //2
std.stdio.writefln("abc"); //3
writeln(std.algorithm.map!("a+1")([1,2,3])); //5
writeln(indexOf("abc","b")); //6
}
answer:
not 1, but it should
2, as it should
not 3, erm ?
not 5, which may well be due to bug 314, or vice versa with 1
not 6, which maybe it shouldn't
summary: selective imports can select from multiple modules, but some of the
multiple modules get in to this module's symbol table anyways
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4890] GC.collect() deadlocks multithreaded program.
http://d.puremagic.com/issues/show_bug.cgi?id=4890 --- Comment #2 from Sean Kelly 2011-01-04 13:41:41 PST --- It turns out that the fix I applied produces a race condition with the GC. I'll have to re-wrap Thread.start() in a synchronized block as per the code prior to rev 392. This may re-introduce the deadlock, in which case it will be necessary to replace the isRunning flag with a state field that distinguishes starting from running. A starting thread should be suspended/resumed but not scanned. Or perhaps something else can be sorted out to deal with a thread being in the list that doesn't have its TLS section set, getThis() doesn't work, etc. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4942] Cannot use std.container.Array with a struct as type parameter
http://d.puremagic.com/issues/show_bug.cgi?id=4942 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@metalanguage.com AssignedTo|nob...@puremagic.com|and...@metalanguage.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
std.process.shell character encoding crash
Hello.
I was trying to run this simple code:
---
import std.stdio;
import std.process;
void main(){
string a = shell("dir");
}
---
DMDv2.049/linux works fine, but on windows/DMDv2.051, I've got these errors:
C:\test>rdmd shell_test.d
C:\test>dchar decode(in char[], ref size_t): Invalid UTF-8 sequence [32, 83, 118
, 97, 122, 101, 107, 32, 118, 32, 106, 101, 100, 110, 111, 116, 99, 101, 32, 67,
32, 110, 101, 109, 160, 32, 167, 160, 100, 110, 111, 117, 32, 106, 109, 101, 11
0, 111, 118, 107, 117, 46, 13, 10, 32, 83, 130, 114, 105, 111, 118, 130, 32, 159
, 161, 115, 108, 111, 32, 115, 118, 97, 122, 107, 117, 32, 106, 101, 32, 56, 56,
54, 65, 45, 67, 51, 52, 49, 46, 13, 10, 13, 10, 32, 86, 236, 112, 105, 115, 32,
97, 100, 114, 101, 115, 160, 253, 101, 32, 67, 58, 92, 116, 101, 115, 116, 13,
10, 13, 10, 48, 52, 46, 48, 49, 46, 50, 48, 49, 49, 32, 32, 49, 57, 58, 49, 52,
32, 32, 32, 32, 60, 68, 73, 82, 62, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 46,
13, 10, 48, 52, 46, 48, 49, 46, 50, 48, 49, 49, 32, 32, 49, 57, 58, 49, 52, 32,
32, 32, 32, 60, 68, 73, 82, 62, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 46, 46,
13, 10, 48, 52, 46, 48, 49, 46, 50, 48, 49, 49, 32, 32, 49, 57, 58, 49, 52, 32,
32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 48, 32, 98, 100,
52, 57, 53, 48, 102, 97, 54, 55, 54, 100, 49, 55, 97, 97, 54, 101, 55, 100, 56,
51, 100, 55, 53, 102, 48, 53, 102, 51, 55, 100, 49, 48, 55, 97, 50, 50, 99, 56,
54, 52, 51, 51, 54, 97, 100, 54, 101, 101, 50, 97, 49, 99, 56, 98, 50, 55, 57,
55, 102, 56, 98, 101, 13, 10, 48, 52, 46, 48, 49, 46, 50, 48, 49, 49, 32, 32, 49
, 56, 58, 48, 57, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 51
, 51, 50, 32, 100, 46, 116, 120, 116, 13, 10, 48, 52, 46, 48, 49, 46, 50, 48, 49
, 49, 32, 32, 49, 57, 58, 49, 51, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32
, 32, 50, 255, 53, 55, 51, 32, 115, 104, 101, 108, 108, 95, 116, 101, 115, 116,
45, 100, 45, 49, 48, 48, 70, 66, 53, 56, 49, 65, 48, 48, 70, 53, 69, 54, 51, 69,
69, 56, 54, 55, 50, 65, 51, 49, 56, 49, 50, 56, 54, 51, 69, 46, 109, 97, 112, 1
3, 10, 48, 52, 46, 48, 49, 46, 50, 48, 49, 49, 32, 32, 49, 57, 58, 49, 49, 32, 3
2, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 57, 48, 32, 115, 104,
101, 108, 108, 95, 116, 101, 115, 116, 46, 100, 13, 10, 48, 52, 46, 48, 49, 46,
50, 48, 49, 49, 32, 32, 49, 57, 58, 49, 52, 32, 32, 32, 32, 32, 32, 32, 32, 32,
32, 32, 32, 32, 53, 255, 55, 53, 51, 32, 115, 104, 101, 108, 108, 95, 116, 101,
115, 116, 46, 100, 46, 100, 101, 112, 115, 13, 10, 32, 32, 32, 32, 32, 32, 32,
32, 32, 32, 32, 32, 32, 32, 32, 53, 32, 115, 111, 117, 98, 111, 114, 133, 44, 32
, 32, 32, 32, 32, 32, 32, 32, 32, 32, 56, 255, 55, 52, 56, 32, 98, 97, 106, 116,
133, 13, 10, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 65, 100, 114, 101, 115
, 160, 253, 133, 58, 32, 32, 32, 32, 32, 50, 44, 32, 32, 32, 86, 111, 108, 110,
236, 99, 104, 32, 98, 97, 106, 116, 133, 58, 32, 32, 51, 255, 52, 53, 56, 255, 4
8, 56, 52, 255, 56, 54, 52, 13, 10] around index 24
---
It was on windows with czech locales, standard output from dir should be
something like this:
C:\test>dir
Svazek v jednotce C nem� ��dnou jmenovku.
S�riov� č�slo svazku je F30B-A03B.
V�pis adres�ře C:\test
04.01.2011 19:13 .
04.01.2011 19:13 ..
04.01.2011 18:09 332 d.txt
04.01.2011 19:13 2 573 shell_test-d-100FB581A00F5E63EE8672A31812863
E.map
04.01.2011 19:1190 shell_test.d
04.01.2011 19:13 5 753 shell_test.d.deps
4 souborů, 8 748 bajtů
Adres�řů: 2, Voln�ch bajtů: 3 458 088 960
---
I think, that shell() is doing some character encoding conversions, but it
fails, because input isn't in UTF/ASCII, but in some obscure windows encoding
(Windows-1252 or something like that).
Is there any way how to fix this problem? Or shell() is lost for everyone who
have system encoding different than UTF/ASCII?
PS: Sorry for my english. Is bad, I know..
[Issue 5130] writeln cannot take delegate
http://d.puremagic.com/issues/show_bug.cgi?id=5130 Andrei Alexandrescu changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #1 from Andrei Alexandrescu 2011-01-04 09:43:05 PST --- I wonder if printing the type of the delegate is the smartest thing to do. After all one can always print typeid(...) if that's what's needed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5410] New: Variant.convertsTo(const(char)[]) seems broke
http://d.puremagic.com/issues/show_bug.cgi?id=5410 Summary: Variant.convertsTo(const(char)[]) seems broke Product: D Version: D2 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: destructiona...@gmail.com --- Comment #0 from Adam D. Ruppe 2011-01-04 08:58:05 PST --- Variant a; a = "10"; assert(a.convertsTo!(const(char)[])); // fails but should work This breaks coercing strings to numeric types too, since this is the test inside the coerce function. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5407] X86_64: Segfault on AA Foreach
http://d.puremagic.com/issues/show_bug.cgi?id=5407 --- Comment #5 from Iain Buclaw 2011-01-04 05:15:18 PST --- (In reply to comment #3) > By the way, I have already demonstrated with a compiler/runtime patch, that > you > can have an associative array ABI that works on all architectures and doesn't > need that messy alignment stuff (how many bugs did that generate in the past, > present and future?). > Would you happen to know where you demonstrated this? :) All I can find ABI-wise on AA's is http://d.puremagic.com/issues/show_bug.cgi?id=802 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5409] New: Disallow (!x & y)
http://d.puremagic.com/issues/show_bug.cgi?id=5409 Summary: Disallow (!x & y) Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2011-01-04 04:52:27 PST --- Studying bug reports in Linux kernel I've seen many cases like: !x & y That were meant to be: !(x & y) So I suggest to turn an expression like the first one (!x & y) into a D2 syntax error. So the D2 compiler asks the programmer for explicit parentheses like (the two following cases are both accepted, the error message may show both examples): !(x & y) Or even: (!x) & y The following case is not covered, this enhancement request is about the bitwise "&" case only: !x && y -- The Coccinelle tool is able to catch bugs like that with this little semantic patch: // Copyright: (C) 2009 Gilles Muller, Julia Lawall, INRIA, DIKU. GPLv2. @@ expression E1,E2; @@ ( !E1 & !E2 | - !E1 & E2 + !(E1 & E2) ) For some of the (!x & y) Linux bugs caught by Coccinelle see: http://coccinelle.lip6.fr/impact_linux.php searching for "Correct occurrences of !x&y". An example: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b2d7c7f7a69fd953626c3e507bac70e18b21f70e -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4923] immutable module variables are modifiable in non-shared module constructors
http://d.puremagic.com/issues/show_bug.cgi?id=4923 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #3 from Jonathan M Davis 2011-01-04 00:26:06 PST --- immutable variables are implicitly shared. That's part of the point of immutable after all. And given that fact, allowing the initializing of immutable variables in non-shared static constructors is definitely a bug. If we decided that immutable variables were _not_ implicitly shared and made it so that they weren't, then that would fix the problem, but that would on some level defeat the purpose of immutable. So, if we are going to have immutable variables be implicitly shared, then I propose that we disallow the initializing of immutable variables with global scope in non-shared static constructors. That is, all global variables and static variables which are immutable _must_ be initialized in shared static constructors. The non-static local variables would be okay (and I'm not sure that those actually end up being implicitly shared anyway), since they'd be re-created on each function call, but any immutable variable which could be initialized in a static constructor would have to be initialized in a shared static constructor. I don't really see any other viable way to fix this bug if we're going to continue to have immutable variables be implicitly shared. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
