[Issue 11845] selective (and renamed) imports clash with local symbols
https://d.puremagic.com/issues/show_bug.cgi?id=11845 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-01-03 00:01:22 PST --- (In reply to comment #2) In particular, in my original report, I did a *renamed* import: From my module's point of view, there is only foo. Why is splitter conflicting with foo? I think you imported that wrong, it should be: import std.algorithm : foo = splitter; and not: import foo = std.algorithm : splitter; -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6673] Map file contains broken lines on every 16,384 bytes
https://d.puremagic.com/issues/show_bug.cgi?id=6673 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added Keywords||pull CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de 2014-01-03 02:00:49 PST --- https://github.com/DigitalMars/optlink/pull/12 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11437] [Mago] No source for step-by-step debugging, only raw assembler.
https://d.puremagic.com/issues/show_bug.cgi?id=11437 --- Comment #5 from Rainer Schuetze r.sagita...@gmx.de 2014-01-03 03:16:59 PST --- While I have added a workaround in mago for the test case, it is actually an instance of issue 7634. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11858] Comparison of unconnected classes using `is` must be disallowed
https://d.puremagic.com/issues/show_bug.cgi?id=11858 Stewart Gordon s...@iname.com changed: What|Removed |Added Keywords|accepts-invalid | CC||s...@iname.com Severity|major |enhancement --- Comment #2 from Stewart Gordon s...@iname.com 2014-01-03 05:53:13 PST --- This isn't accepts-invalid, because there's no rule against it. It's an enhancement request. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11844] ICE(template.c:6643) Assertion failed: (td-semanticRun != PASSinit)
https://d.puremagic.com/issues/show_bug.cgi?id=11844 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||ice, pull Platform|x86_64 |All --- Comment #1 from Kenji Hara k.hara...@gmail.com 2014-01-03 06:39:37 PST --- https://github.com/D-Programming-Language/dmd/pull/3056 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11849] Recursive enum causes segfault
https://d.puremagic.com/issues/show_bug.cgi?id=11849 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2014-01-03 06:47:29 PST --- https://github.com/D-Programming-Language/dmd/pull/3057 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11849] Recursive enum causes segfault
https://d.puremagic.com/issues/show_bug.cgi?id=11849
--- Comment #2 from Jacob Carlborg d...@me.com 2014-01-03 06:51:15 PST ---
(In reply to comment #1)
https://github.com/D-Programming-Language/dmd/pull/3057
Does that pull request handle the second case:
enum : DWORD
{
DWORD = REG_DWORD
}
I don't see an explicit test for that case.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11849] Recursive enum causes segfault
https://d.puremagic.com/issues/show_bug.cgi?id=11849
--- Comment #4 from Jacob Carlborg d...@me.com 2014-01-03 07:09:23 PST ---
(In reply to comment #3)
Do you mean this full test case?
No, I mean only exact this code:
enum : DWORD
{
DWORD = REG_DWORD
}
This is without having declared DWORD or REG_DWORD previously. That will
cause a segmentation fault as well. Seems to be an infinite loop there as well.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11849] Recursive enum causes segfault
https://d.puremagic.com/issues/show_bug.cgi?id=11849
--- Comment #3 from Kenji Hara k.hara...@gmail.com 2014-01-03 07:05:13 PST ---
(In reply to comment #2)
(In reply to comment #1)
https://github.com/D-Programming-Language/dmd/pull/3057
Does that pull request handle the second case:
enum : DWORD
{
DWORD = REG_DWORD
}
I don't see an explicit test for that case.
Do you mean this full test case?
module test;
alias DWORD = uint; // L3 first definition of 'test.DWORD'
enum : DWORD
{
REG_DWORD = 4
}
enum : DWORD
{
DWORD = REG_DWORD // L12 second definition of 'test.DWORD'
}
Output:
test.d(12): Error: enum member test.DWORD conflicts with alias test.DWORD at
test.d(3)
There's no recursive definition, so that's not directly related to the
reported segfault issue.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11862] New: Using byChunk inside a std.parallelism's parallel loop causes crash when compiled in 32 bits
https://d.puremagic.com/issues/show_bug.cgi?id=11862
Summary: Using byChunk inside a std.parallelism's parallel loop
causes crash when compiled in 32 bits
Product: D
Version: D2
Platform: x86_64
OS/Version: Windows
Status: NEW
Severity: major
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: anci...@gmail.com
--- Comment #0 from Louis Geuten anci...@gmail.com 2014-01-03 07:23:48 PST ---
The following code produce some weird behavior when compiled in 32bits on my
Windows 7 64b machine. Removing the parallel or compiling in 64b removes the
problems.
import std.md5;
import std.stdio;
import std.file;
import std.conv;
import std.getopt;
import std.string;
import std.process;
import std.parallelism;
import std.exception;
struct Entry
{
string name;
ubyte[16] md5;
}
void main(string[] args)
{
string folder1 = args[1];
string folder2 = args[2];
Entry[] entries1;
foreach (name; parallel(dirEntries(folder1, SpanMode.breadth), 1)) // not
working
{
if(name.isFile())
{
entries1 ~= Entry(name ,mdFile(name));
}
}
writeln(folder1, has ,entries1.length, entries);
Entry[] entries2;
foreach (string name; dirEntries(folder2, SpanMode.breadth)) //working fine
{
if(name.isFile())
{
entries2 ~= Entry(name ,mdFile(name));
}
}
writeln(folder2, has , entries2.length, entries);
}
/// Digests a file and prints the result.
ubyte[16] mdFile(string filename)
{
MD5_CTX context;
ubyte[16] digest;
context.start();
File f = File(filename,r);
foreach (buffer; f.byChunk(4096))
context.update(buffer);
context.finish(digest);
try{
f.close();
}
catch(ErrnoException e)
{
writeln(e.errno);
}
writefln(MD5 (%s) = %s, filename, digestToString(digest));
return digest;
}
When executed, the program starts opening files and calculating their MD5.
After a short amount of files have been scanned, depending on the WorkUnitSize
(between 2 and 10 if set to 1, if default to 100, around 30-40 are processed),
the program begins malfunctioning
- Seemingly random files throw an ErrnoException (error n� 0) when closed (not
interrupting the rest of the program)
- The program sometime just freeze (need to close it manually)
- The program generates Object.Error: Access violation
- The program crashes (program.exe has stopped working).
The culprit seems to be the function byChunk used to calculate the MD5.
Using std.stream like suggested in this question's answer (
http://stackoverflow.com/questions/20888596/opening-files-in-a-parallel-loop-crash-the-program
) makes the program work in 32 and 64bits.
While this issue can be fixed by compiling in 64bit, it's still a major
problem.
PS : It's my first time reporting a bug, so if some information is lacking or
I've submitted this wrong, please let me know and I'll try to fix it.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11863] New: std.conv.to!string(int/uint, radix) returns incorrect string
https://d.puremagic.com/issues/show_bug.cgi?id=11863
Summary: std.conv.to!string(int/uint, radix) returns incorrect
string
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: electrolysis.j...@gmail.com
--- Comment #0 from e10s electrolysis.j...@gmail.com 2014-01-04 03:38:46 JST
---
import std.conv, std.stdio;
void main(){
/// int
static assert(to!string(15, 10) == 15); // success
// assert(to!string(15, 10) == 15); // failure
assert(to!wstring(15, 10) == 15w); // success
assert(to!dstring(15, 10) == 15d); // success
writeln(to!string(15, 10)); // ??
/// uint
static assert(to!string(15u, 10) == 15); // success
// assert(to!string(15u, 10) == 15); // failure
assert(to!wstring(15u, 10) == 15w); // success
assert(to!dstring(15u, 10) == 15d); // success
writeln(to!string(15u, 10)); // ??
/// long
static assert(to!string(15L, 10) == 15); // success
assert(to!string(15L, 10) == 15); // success
}
In the case of (r)dmd foo.d, only to!string(int, radix) and
to!string(uint, radix) return 0 at run time with any radix
though 15 is returned when compiled with -debug.
Environment: DMD 2.064.2 on Win7 SP1 32-bit
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11863] std.conv.to!string(int/uint, radix) returns incorrect string
https://d.puremagic.com/issues/show_bug.cgi?id=11863 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com Component|Phobos |DMD Platform|x86 |All OS/Version|Windows |All Severity|normal |regression --- Comment #1 from monarchdo...@gmail.com 2014-01-03 12:55:28 PST --- I did some investigating, and the Phobos code is legit. Duplicating the function, while leaving it where it is, does not reproduce the issue. Furthermore, older versions of DMD do not reproduce this issue either. It makes me think that ctfe instantiation is causing something weird later for runtime. I did a bissect, and hit this commit: 12bb9afb753ad2f2aef65550b960357c63854cbc is the first bad commit commit 12bb9afb753ad2f2aef65550b960357c63854cbc Author: Walter Bright wal...@walterbright.com Date: Wed Sep 11 14:33:14 2013 -0700 fix Issue 10441 - Static libraries too big :04 04 00ef3e43d4274d2e24514810353fead7bbcdaee9 313550fcc47de2b124d69f05bce5f94586bc2b01 M src :04 04 13dbdadb43e009e4e10041a161e1c825110f8028 7bcbc44d497d9056603b0863d781b894ff49b4ab M test Seems to be related. I think. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11862] Using byChunk inside a std.parallelism's parallel loop causes crash when compiled in 32 bits
https://d.puremagic.com/issues/show_bug.cgi?id=11862
Daniel Kozak kozz...@gmail.com changed:
What|Removed |Added
CC||kozz...@gmail.com
--- Comment #1 from Daniel Kozak kozz...@gmail.com 2014-01-03 13:11:11 PST ---
Problem seems to be in T[] rawRead(T)(T[] buffer)
version(Win32)
{
immutable fd = ._fileno(_p.handle);
//immutable mode = ._setmode(fd, _O_BINARY); when comment this line
//scope(exit) ._setmode(fd, mode); and this line it seems to works
much better
version(DIGITAL_MARS_STDIO)
{
// @@@BUG@@@ 4243
immutable info = __fhnd_info[fd];
__fhnd_info[fd] = ~FHND_TEXT;
scope(exit) __fhnd_info[fd] = info;
}
}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11864] New: std.variant.Variant doesn't work with CTFE
https://d.puremagic.com/issues/show_bug.cgi?id=11864
Summary: std.variant.Variant doesn't work with CTFE
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: tcdknut...@gmail.com
--- Comment #0 from Dylan Knutson tcdknut...@gmail.com 2014-01-03 14:45:12
PST ---
e.g.
---
import std.variant : Variant;
Variant makeVariant(T)(T value)
{
return Variant(value);
}
void main()
{
const a = makeVariant(bar);
pragma(msg, a);
}
---
Results in:
/opt/compilers/dmd2/include/std/variant.d(547): Error: memcpy cannot be
interpreted at compile time, because it has no available source code
/opt/compilers/dmd2/include/std/variant.d(512):called from here:
this.opAssign(value)
/d214/f186.d(6):called from here: (VariantN!(32LU) __ctmp1402 =
VariantN;
, __ctmp1402).this(value)
/d214/f186.d(11):called from here: makeVariant(bar)
/d214/f186.d(12):while evaluating a.init
/d214/f186.d(12):while evaluating pragma(msg, a)
Note that the error doesn't happen if pragma(msg, a) is removed. I guess the
compiler is lazily evaluating 'a'?
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3956] linker removes underscore from all exported symbols of a module but the first
https://d.puremagic.com/issues/show_bug.cgi?id=3956 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #7 from Walter Bright bugzi...@digitalmars.com 2014-01-03 18:26:06 PST --- Fixed 8.00.15 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11792] Investigate migrating to a meta repo
https://d.puremagic.com/issues/show_bug.cgi?id=11792 Mathias LANG pro.mathias.l...@gmail.com changed: What|Removed |Added CC||pro.mathias.l...@gmail.com --- Comment #2 from Mathias LANG pro.mathias.l...@gmail.com 2014-01-03 19:01:53 PST --- That's simple to setup but tedious to use. I made some tests in https://github.com/Geod24/MetaD This is my feedback: 1) Starting from 1.8.2, git can track a branch, not only a commit. When you checkout it's still set to a specific commit though, you need to pass the `--remote` option to `git submodule update` So I think we could make the repo point to the latest release, and our contributor just need to keep in mind to passe `--remote`. This design void the necessity of a hook. 2) I was wondering what the workflow would be with submodules. I'm currently still testing and updating the README accordingly. The most annoyance so far is that submodule HEAD gets detached quite easily. The other problem is that your repository gets dirty by using --remote. I think we should try to lower the need of git submodule commands, as using them is tricky and often leads to confusion, like commiting in the wrong order. We should also take care not to accept a PR with a modif to .gitmodules unless it's a stable version update. 3) I'll take a look at the merging strategy soon. By default submodules are just binary object, but git provide a way to merge/rebase them too as part of the update process. I'll keep experimenting with it, any comment / example of your normal workflow is very welcome. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
