[Issue 11378] implicit runtime initialization/finalization is broken
http://d.puremagic.com/issues/show_bug.cgi?id=11378 Martin Nowak c...@dawg.eu changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #11 from Martin Nowak c...@dawg.eu 2013-10-30 23:10:27 PDT --- (In reply to comment #9) OK, that's probably workable, would be nice if there was some function to correctly exit the thread at any moment, though. Case closed for me. Exiting a thread is different from exiting the process and even that would require more for a correct shutdown than C's exit function. The only mechanism that we have which could correctly unwind a stack and free all resources is throwing an Exception. What's your use-case for this? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11378] implicit runtime initialization/finalization is broken
http://d.puremagic.com/issues/show_bug.cgi?id=11378 Jacob Carlborg d...@me.com changed: What|Removed |Added CC||d...@me.com --- Comment #12 from Jacob Carlborg d...@me.com 2013-10-31 00:29:11 PDT --- (In reply to comment #11) Exiting a thread is different from exiting the process and even that would require more for a correct shutdown than C's exit function. The only mechanism that we have which could correctly unwind a stack and free all resources is throwing an Exception. What's your use-case for this? Can't we setup a callback using atexit which correctly terminates the runtime? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11395] link error (struct+opEquals) on separate compilation
http://d.puremagic.com/issues/show_bug.cgi?id=11395 --- Comment #3 from github-bugzi...@puremagic.com 2013-10-31 01:44:40 PDT --- Commit pushed to 2.064 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b52c07181deed50fdbff5efc019906b3803d924c Merge pull request #2698 from 9rnsr/fix11395 [REG2.064a] Issue 11395 - link error (struct+opEquals) on separate compilation -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11395] link error (struct+opEquals) on separate compilation
http://d.puremagic.com/issues/show_bug.cgi?id=11395 --- Comment #2 from github-bugzi...@puremagic.com 2013-10-31 01:44:00 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f70c40dce3928ddd2c2d4fc886f66e0587509487 fix Issue 11395 - link error (struct+opEquals) on separate compilation https://github.com/D-Programming-Language/dmd/commit/9dabf26ab0edf216c994137e09a58db6d509669a Merge pull request #2698 from 9rnsr/fix11395 [REG2.064a] Issue 11395 - link error (struct+opEquals) on separate compilation -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11395] link error (struct+opEquals) on separate compilation
http://d.puremagic.com/issues/show_bug.cgi?id=11395 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11392] dirEntries segfaults (fails in 2.064 beta 4, works in 2.063.2)
http://d.puremagic.com/issues/show_bug.cgi?id=11392 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #1 from monarchdo...@gmail.com 2013-10-31 02:00:09 PDT --- I was not able to reproduce on linux64, on any of beta 1, 3 or 4. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11392] dirEntries segfaults (fails in 2.064 beta 4, works in 2.063.2)
http://d.puremagic.com/issues/show_bug.cgi?id=11392 --- Comment #2 from monarchdo...@gmail.com 2013-10-31 02:09:43 PDT --- I was not able to reproduce on win32 either. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1512] GC infinite loop when invalid user code runs.
http://d.puremagic.com/issues/show_bug.cgi?id=1512 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added CC||safety0ff.b...@gmail.com --- Comment #10 from safety0ff.bugz safety0ff.b...@gmail.com 2013-10-31 02:25:49 PDT --- Works for me, recent versions of DMD, LDC give: Error: Cannot modify 'this' inside func. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1512] GC infinite loop when invalid user code runs.
http://d.puremagic.com/issues/show_bug.cgi?id=1512 --- Comment #11 from safety0ff.bugz safety0ff.b...@gmail.com 2013-10-31 02:34:55 PDT --- (In reply to comment #10) Works for me, recent versions of DMD, LDC give: Error: Cannot modify 'this' inside func. For D2, probably still valid for D1 (what it is marked as.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11392] dirEntries segfaults (fails in 2.064 beta 4, works in 2.063.2)
http://d.puremagic.com/issues/show_bug.cgi?id=11392 --- Comment #3 from thelastmamm...@gmail.com 2013-10-31 02:39:47 PDT --- well that would explain why it would've gone un-noticed... can anyone verify on OSX? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11392] dirEntries segfaults (fails in 2.064 beta 4, works in 2.063.2)
http://d.puremagic.com/issues/show_bug.cgi?id=11392 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added CC||safety0ff.b...@gmail.com --- Comment #4 from safety0ff.bugz safety0ff.b...@gmail.com 2013-10-31 03:31:28 PDT --- Maybe my PR https://github.com/D-Programming-Language/phobos/pull/1657 changed the test that might have caught it. I looked at the reports which lead to those tests and the directory string did not look relevant. In retrospect, I should have used something like: auto cwd = getcwd(); chdir(testdir); scope(exit) chdir(cwd); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11399] New: time.di(365) error
http://d.puremagic.com/issues/show_bug.cgi?id=11399 Summary: time.di(365) error Product: D Version: D2 Platform: x86_64 OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: ronald@gmail.com --- Comment #0 from ronald@gmail.com 2013-10-31 05:11:49 PDT --- On windows 7, DMD32 D Compiler v2.063.2 failed to all my trivial tests including the hello world. The error message was shown below: C:\D\dmd2\windows\bin\..\..\src\druntime\import\core\time.di(365): Error: Declaration expected, not '}' -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11369] time.di(365)
http://d.puremagic.com/issues/show_bug.cgi?id=11369 --- Comment #2 from ronald@gmail.com 2013-10-31 05:13:51 PDT --- (In reply to comment #1) It sounds like you probably have a messed up install, but I can't really help you much without actual code examples. You really should bring this up in D.Learn to get some help there: http://forum.dlang.org/ http://forum.dlang.org/group/digitalmars.D.learn I'd be very surprised if there were an actual bug in core.time that was causing your problem. Thanks. I will post my question over there. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11400] New: Floating point numbers with fractional part printing alignment problem
http://d.puremagic.com/issues/show_bug.cgi?id=11400
Summary: Floating point numbers with fractional part printing
alignment problem
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-10-31 05:54:29 PDT ---
void main() {
import std.stdio;
writefln(%2d, 5);
writefln(%2d, -5);
writefln(%3d, 5);
writefln(%3d, 12);
writefln(%3d, -12);
writeln;
writefln(%2.0f, 5.0);
writefln(%2.0f, -5.0);
writefln(%3.0f, 5.0);
writefln(%3.0f, 12.0);
writefln(%3.0f, -12.0);
writeln;
writefln(%2.1f, 5.0);
writefln(%2.1f, -5.0);
writefln(%3.1f, 5.0);
writefln(%3.1f, 12.0);
writefln(%3.1f, -12.0);
}
dmd 2.064beta3 gives:
5
-5
5
12
-12
5
-5
5
12
-12
5.0
-5.0
5.0
12.0
-12.0
But I expect:
5
-5
5
12
-12
5
-5
5
12
-12
5.0 == note here
-5.0
5.0 == note here
12.0 == note here
-12.0
Note that the problem is not present if you use .0 when you print floating
point numbers.
This is useful to correct align a 2D matrix, to print it in a more readable
way. You can see in this program:
void main() {
import std.stdio;
double[][] m = [[4.243, 0.000, 0.000, 0.000],
[5.185, 6.566, 0.000, 0.000],
[12.728, 3.046, 1.650, 0.000],
[9.899, 1.625, 1.850, 1.393]];
writefln(%(%(%2.3f %)\n%), m);
}
That prints a table with misaligned columns:
4.243 0.000 0.000 0.000
5.185 6.566 0.000 0.000
12.728 3.046 1.650 0.000
9.899 1.625 1.850 1.393
that is a little harder to read than:
4.243 0.000 0.000 0.000
5.185 6.566 0.000 0.000
12.728 3.046 1.650 0.000
9.899 1.625 1.850 1.393
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11365] Allow D source file names to have no extension (or an arbitrary extension)
http://d.puremagic.com/issues/show_bug.cgi?id=11365 --- Comment #9 from bearophile_h...@eml.cc 2013-10-31 07:42:41 PDT --- Having a standard extension for D code is useful for programs like cloc that count lines of code, with editors that open .d files with correct D colorization, for my scripts that select files with .d suffix to test incompatibilities across different compiler versions. I have testing scripts that test .d files differently from .py files looking in directories. And it's not just a matter of my own code, it also mattes from D libraries from other people. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11365] Allow D source file names to have no extension (or an arbitrary extension)
http://d.puremagic.com/issues/show_bug.cgi?id=11365 --- Comment #11 from Dicebot pub...@dicebot.lv 2013-10-31 07:50:47 PDT --- In other words, it is not a as much of a problem of DMD codebase that is uses .c for C++ code, it is a problem of IDE's/tools that assume it is a C code without providing any convenient way to override that assumption. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11378] implicit runtime initialization/finalization is broken
http://d.puremagic.com/issues/show_bug.cgi?id=11378 --- Comment #13 from Martin Nowak c...@dawg.eu 2013-10-31 07:50:45 PDT --- (In reply to comment #12) Can't we setup a callback using atexit which correctly terminates the runtime? No, because then we couldn't clean up the stack. I still don't understand the need for this. I don't even know if a C program can be terminated by a call to exit from another thread. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11365] Allow D source file names to have no extension (or an arbitrary extension)
http://d.puremagic.com/issues/show_bug.cgi?id=11365 Dicebot pub...@dicebot.lv changed: What|Removed |Added CC||pub...@dicebot.lv --- Comment #10 from Dicebot pub...@dicebot.lv 2013-10-31 07:48:57 PDT --- As I have already mentioned in NG, the very idea that file extension should have any relation with its content is just plain wrong and needs to be discouraged, as well as any arbitrary limitations that may impose. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11401] New: ElementType returns constructor instead of type
http://d.puremagic.com/issues/show_bug.cgi?id=11401
Summary: ElementType returns constructor instead of type
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: regression
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: jcrapuchet...@gmail.com
--- Comment #0 from Jonathan Crapuchettes jcrapuchet...@gmail.com 2013-10-31
09:42:06 PDT ---
Using latest git HEAD, the following code produces an error where 2.063.2 does
not. It appears to be a problem with either std.range.ElementType or
std.traits.lvalueOf.
Code
---
import std.range;
void main()
{
alias ElementType!RowRange E;
static assert(is(typeof(E.id)), E.stringof~ is expected to have a 'id'
member);
}
struct RowRange
{
BasicNode front()
{
return BasicNode.init;
}
}
struct BasicNode { ushort id; }
Output
---
$ ~/dmd-git/build/bin/dmd serialize.d
test.d(6): Error: static assert BasicNode() is expected to have a 'id'
member
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11365] Allow D source file names to have no extension (or an arbitrary extension)
http://d.puremagic.com/issues/show_bug.cgi?id=11365 Mathias LANG pro.mathias.l...@gmail.com changed: What|Removed |Added CC||pro.mathias.l...@gmail.com --- Comment #12 from Mathias LANG pro.mathias.l...@gmail.com 2013-10-31 10:08:55 PDT --- Why should we enforce this ? We enforce things to prevent obvious mistakes. D language plays well in this field. It ensures what it is sure needs to be ensured, and give you the tools to build your own rules, with the least burdens. It's not a mistake to have a source file with an arbitrary extension, or no extension at all. DMD will still now it's argument is a source file, whatever its name is. And they're some valid use cases where you would not want a .d[i] extension, as eles noticed in the quoted comment above, and in the NG. (In reply to comment #9) Having a standard extension for D code is useful for programs like cloc that count lines of code, with editors that open .d files with correct D colorization, for my scripts that select files with .d suffix to test incompatibilities across different compiler versions. I have testing scripts that test .d files differently from .py files looking in directories. And it's not just a matter of my own code, it also mattes from D libraries from other people. As you point, there are also some use cases where some tool require a specific extension. But that's none of our business, the tool should ensure it, not DMD. The real problem for those tools is to know what the file holds. We don't have such problems with DMD. For the record, good editors solve the problem easily, like vim or emacs: # vim: syntax=d ts=4 sw=4 sts=4 sr noet # -*- d-mode -*- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4101] [tdpl] DMD doesn't give error when goto skips initialization
http://d.puremagic.com/issues/show_bug.cgi?id=4101 Martin Nowak c...@dawg.eu changed: What|Removed |Added Status|NEW |RESOLVED CC||c...@dawg.eu Resolution||DUPLICATE --- Comment #4 from Martin Nowak c...@dawg.eu 2013-10-31 10:15:09 PDT --- *** This issue has been marked as a duplicate of issue 602 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 602] Compiler allows a goto statement to skip an initalization
http://d.puremagic.com/issues/show_bug.cgi?id=602 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||jlqu...@optonline.net --- Comment #5 from Martin Nowak c...@dawg.eu 2013-10-31 10:15:09 PDT --- *** Issue 4101 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3454] Inconsistent flag setting in GC.realloc()
http://d.puremagic.com/issues/show_bug.cgi?id=3454 --- Comment #3 from github-bugzi...@puremagic.com 2013-10-31 10:26:34 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/4fe17c32bcfa9140e3b52e92b27474c3b60b3f95 fix Issue 3454 - inconsistent flag setting in GC.realloc() https://github.com/D-Programming-Language/druntime/commit/487f0a1ed1aad76d1b4ca638fd25b730fd87aa4f regression test for Issue 3454 https://github.com/D-Programming-Language/druntime/commit/0fe338f42a1225a6041bb0f7707375cfbee7b54b Merge pull request #645 from Safety0ff/fix3454 fix Issue 3454 - inconsistent flag setting in GC.realloc() -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 602] Compiler allows a goto statement to skip an initalization
http://d.puremagic.com/issues/show_bug.cgi?id=602
--- Comment #6 from Martin Nowak c...@dawg.eu 2013-10-31 10:31:38 PDT ---
Any ideas how to implement this? It seems like an algorithm to distinguish this
is non-trivial.
I tested the following with clang and it gives me a correct warning (gcc 4.7.2
doesn't).
goto.c:3:9:warning: variable 'test' is used uninitialized whenever 'if'
condition is true [-Wsometimes-uninitialized]
int bug(int val)
{
if (val)
goto Lno;
int test = 0;
Lno: {}
return test;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11365] Allow D source file names to have no extension (or an arbitrary extension)
http://d.puremagic.com/issues/show_bug.cgi?id=11365 --- Comment #13 from Leandro Lucarella leandro.lucare...@sociomantic.com 2013-10-31 10:50:57 PDT --- I quickly tried to implement this by only disabling the extension checks when the `-run` option is passed, but I failed miserably because the automatic extension appending is some deeply in the module code, and then object.d isn't found because the .d isn't added to the module name. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11399] time.di(365) error
http://d.puremagic.com/issues/show_bug.cgi?id=11399 Martin Krejcirik m...@krej.cz changed: What|Removed |Added CC||m...@krej.cz --- Comment #1 from Martin Krejcirik m...@krej.cz 2013-10-31 19:04:21 CET --- Whay are you posting bug 11369 again ? Both look invalid. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11365] Allow D source file names to have no extension (or an arbitrary extension)
http://d.puremagic.com/issues/show_bug.cgi?id=11365 --- Comment #14 from Leandro Lucarella leandro.lucare...@sociomantic.com 2013-10-31 11:38:36 PDT --- https://github.com/D-Programming-Language/dmd/pull/2700 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11365] Allow D source file names to have no extension (or an arbitrary extension)
http://d.puremagic.com/issues/show_bug.cgi?id=11365 --- Comment #15 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-31 12:08:58 PDT --- (In reply to comment #12) Why should we enforce this ? We enforce things to prevent obvious mistakes. D language plays well in this field. It ensures what it is sure needs to be ensured, and give you the tools to build your own rules, with the least burdens. It's not a mistake to have a source file with an arbitrary extension, or no extension at all. DMD will still now it's argument is a source file, whatever its name is. That's not true. It can't have a .lib extension, or an .obj/.o extension. Arbitrary extensions means import switches will not work, the compiler won't know which files it has to inspect to find D code. So this feature will be useful for scripts and in cases where you're explicitly passing all files to DMD. (In reply to comment #10) As I have already mentioned in NG, the very idea that file extension should have any relation with its content is just plain wrong and needs to be discouraged, as well as any arbitrary limitations that may impose. That's exactly what happens when you allow arbitrary extensions, tools end up inventing their own semantics *based on* the extension: http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Overall-Options.html: file.c C source code that must be preprocessed. file.i C source code that should not be preprocessed. file.ii C++ source code that should not be preprocessed. file.tcc C++ header file to be turned into a precompiled header or Ada spec. See what I mean? If it's only .d/.di and for [1] extensionless files we allow then we make everything simple. In other words, it is not a as much of a problem of DMD codebase that is uses .c for C++ code, it is a problem of IDE's/tools that assume it is a C code without providing any convenient way to override that assumption. So now every tool in existence has to do heuristics on text files? The benefit of having known and defined extensions is to make it easier to figure out what a file is without having to open it, to make it easier to filter through a directory of files and organize them based on their extension. Using .c for C++ files is Walter's fault and nobody else's. There are no excuses here. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11365] Allow D source file names to have no extension (or an arbitrary extension)
http://d.puremagic.com/issues/show_bug.cgi?id=11365 --- Comment #16 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-31 12:14:39 PDT --- (In reply to comment #12) For the record, good editors solve the problem easily, like vim or emacs: # vim: syntax=d ts=4 sw=4 sts=4 sr noet # -*- d-mode -*- You call that a solution? Arbitrary tools adding an arbitrary amount of HEADER information they've invented? So then other tools have to be able to interpret these lines too. This doesn't scale. It's not a solution. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11402] New: any/all are not documented in std.algorithm header
http://d.puremagic.com/issues/show_bug.cgi?id=11402 Summary: any/all are not documented in std.algorithm header Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: monarchdo...@gmail.com --- Comment #0 from monarchdo...@gmail.com 2013-10-31 12:54:17 PDT --- As title implies: http://dlang.org/phobos/std_algorithm.html They should appear in Searching (or Comparing? Searching I think). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11403] New: functions in std.algo can't be used as pred
http://d.puremagic.com/issues/show_bug.cgi?id=11403 Summary: functions in std.algo can't be used as pred Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: rejects-valid Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: monarchdo...@gmail.com --- Comment #0 from monarchdo...@gmail.com 2013-10-31 12:55:31 PDT --- There are a ton of functions in std.algorithm that can be customized with a predicate. At ton of them can also be used as predicates themselves. Here is a cool example: assert(equal!equal([[1, 2], [3, 4]], iota(1, 5).chunks(2))); The problem with this piece of code is that: The inner equal only works because it itself doesn't have a predicate. The outer equal works because it takes arguments. However, neither of this works: alias fun = equal!equal; //Nope equal!(equal!equal))(3Dmatrix1, 3Dmatrix2); //Nope It is *not* possible to declare an algorithm function with a predicate, unless you also specify the argument types. Long story short, they are not eagerly specialize-able. equal (I think) is the most obvious offender, but so are any/all: import std.ascii : isWhite; assert( all!(any!isWhite)([a a, b b])); //Nope assert(!any!(all!isWhite)([a a, b b])); //Nope Any function that takes a pred (+an argument) and returns a bool is faulty. Here is a (probably incomplete) list: -equal -canFind -any -all -cmp -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11404] New: Assertion failure: '0' on line 1215 in file 'glue.c'
http://d.puremagic.com/issues/show_bug.cgi?id=11404 Summary: Assertion failure: '0' on line 1215 in file 'glue.c' Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: agustin.l.alva...@hotmail.com --- Comment #0 from Agustin agustin.l.alva...@hotmail.com 2013-10-31 13:03:51 PDT --- Using TypeTuple as value in an associative array won't work. Example: TypeTuple!(int, int)[string] my_map; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11365] Allow D source file names to have no extension (or an arbitrary extension)
http://d.puremagic.com/issues/show_bug.cgi?id=11365 --- Comment #17 from Dicebot pub...@dicebot.lv 2013-10-31 13:27:13 PDT --- (In reply to comment #15) That's not true. It can't have a .lib extension, or an .obj/.o extension. This is purely a problem of how DMD argument list is designed, not meaningful limitation. And yet another example of what apps shouldn't do. Arbitrary extensions means import switches will not work, the compiler won't know which files it has to inspect to find D code. So this feature will be useful for scripts and in cases where you're explicitly passing all files to DMD. Exactly. And someone who wants to use arbitrary extensions will be aware that he is stepping aside from common naming convention and thus losing some convenience offered by compiler. It is perfectly expected. (In reply to comment #10) As I have already mentioned in NG, the very idea that file extension should have any relation with its content is just plain wrong and needs to be discouraged, as well as any arbitrary limitations that may impose. That's exactly what happens when you allow arbitrary extensions, tools end up inventing their own semantics *based on* the extension: ... See what I mean? It is exactly what happens when _someone_ (compiler, tools, whatever) decides to strictly couple some behavior exclusively to extension. See what I mean? :) In other words, it is not a as much of a problem of DMD codebase that is uses .c for C++ code, it is a problem of IDE's/tools that assume it is a C code without providing any convenient way to override that assumption. So now every tool in existence has to do heuristics on text files? Yes if it is important (there are standard tools for that like famous file command). In most cases though it should just try interpret input as if it is legal file and fail in process if it has garbage. Similar to how it will fail if you put garbage into .d file. And context of interpretation should be defined by compiler switches, configuration files or some other external thing. Using default interpretation defined by convention like file extension is also fine if it can be overridden with a manual option. The benefit of having known and defined extensions is to make it easier to figure out what a file is without having to open it, to make it easier to filter through a directory of files and organize them based on their extension. As I have said, crazy DOS legacy. Luckily, most Linux file managers don't do this and actually explore file metadata. Using .c for C++ files is Walter's fault and nobody else's. There are no excuses here. There are no excuses but there is also no disaster. It is bad to break common practice but any sane IDE will allow to trivially configure mapping of .c files to C++ semantics. Just as they should do. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10403] memchr optimization for std.algorithm.find
http://d.puremagic.com/issues/show_bug.cgi?id=10403 --- Comment #6 from github-bugzi...@puremagic.com 2013-10-31 13:32:19 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/67e3c321a880dbeb29f69fe46efffa5f19aac633 fix Issue 10403 - memchr optimization for std.algorithm.find https://github.com/D-Programming-Language/phobos/commit/482d0e161b04fa1eade0937deecc964d23bca88f Merge pull request #1492 from monarchdodra/findImprov fix Issue 10403 - memchr optimization for std.algorithm.find -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11171] Text relocations in Phobos shared library
http://d.puremagic.com/issues/show_bug.cgi?id=11171 Martin Krejcirik m...@krej.cz changed: What|Removed |Added CC||m...@krej.cz --- Comment #2 from Martin Krejcirik m...@krej.cz 2013-10-31 22:43:50 CET --- Just noticed this too. It makes shared libraries unusable on hardened system (like grsecurity). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11171] Text relocations in Phobos shared library
http://d.puremagic.com/issues/show_bug.cgi?id=11171 --- Comment #4 from Martin Krejcirik m...@krej.cz 2013-10-31 23:07:52 CET --- (In reply to comment #3) Duplicate of #5278? Likely, but it's not just Gentoo. I use Grsecurity kernel on Debian and get this error: ./prog: error while loading shared libraries: /usr/local/lib/libphobos2.so.0.64: cannot make segment writable for relocation: Permission denied The only solution is to disable MPROTECT for given exacutable. http://pax.grsecurity.net/docs/mprotect.txt -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11171] Text relocations in Phobos shared library
http://d.puremagic.com/issues/show_bug.cgi?id=11171 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added CC||safety0ff.b...@gmail.com --- Comment #3 from safety0ff.bugz safety0ff.b...@gmail.com 2013-10-31 14:55:11 PDT --- Duplicate of #5278? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11171] Text relocations in Phobos shared library
http://d.puremagic.com/issues/show_bug.cgi?id=11171 --- Comment #5 from safety0ff.bugz safety0ff.b...@gmail.com 2013-10-31 15:10:09 PDT --- (In reply to comment #4) (In reply to comment #3) Duplicate of #5278? Likely, but it's not just Gentoo. I'm aware, it should probably be renamed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11403] functions in std.algo can't be used as pred
http://d.puremagic.com/issues/show_bug.cgi?id=11403 --- Comment #1 from monarchdo...@gmail.com 2013-10-31 15:33:42 PDT --- https://github.com/D-Programming-Language/phobos/pull/1676 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10403] memchr optimization for std.algorithm.find
http://d.puremagic.com/issues/show_bug.cgi?id=10403 monarchdo...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11405] New: rdmd should limit it's tmp cache
http://d.puremagic.com/issues/show_bug.cgi?id=11405 Summary: rdmd should limit it's tmp cache Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: c...@dawg.eu --- Comment #0 from Martin Nowak c...@dawg.eu 2013-10-31 16:28:42 PDT --- Old discussion but still a valid issue. http://forum.dlang.org/thread/gomtj5$1iut$1...@digitalmars.com Rdmd needs a reasonable policy to evict old cached folders. A simple solution would be to delete an existing folder with the same first 2-3 bytes of the digest. This means we'd have to lock the folders to synchronize different rdmd processes. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11237] zero initializer emitted to read-only data segment, slow compilation
http://d.puremagic.com/issues/show_bug.cgi?id=11237
Martin Nowak c...@dawg.eu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Comment #6 from Martin Nowak c...@dawg.eu 2013-10-31 18:39:41 PDT ---
The broke struct initializers.
They are emitted to object files with a symbol size of 1 byte regardless of
their actual size.
Also I wonder why the initializer are now common symbols ('V') while they
previously were normal uninitialized variables ('B').
Test case
cat bug.d CODE
struct Buffer { ubyte[64 * 1024] buffer; }
CODE
dmd2.063.2 -c bug
nm -S bug.o
0001 B _D4bug26Buffer6__initZ
// 1-byte size and weak object
dmd2.064 -c bug
nm -S bug.o
0001 V _D4bug26Buffer6__initZ
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11237] zero initializer emitted to read-only data segment, slow compilation
http://d.puremagic.com/issues/show_bug.cgi?id=11237 Martin Nowak c...@dawg.eu changed: What|Removed |Added Keywords||pull, wrong-code --- Comment #7 from Martin Nowak c...@dawg.eu 2013-10-31 19:37:39 PDT --- https://github.com/D-Programming-Language/dmd/pull/2701 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11406] New: ld.gold links incorrect dmd binaries
http://d.puremagic.com/issues/show_bug.cgi?id=11406
Summary: ld.gold links incorrect dmd binaries
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: link-failure
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: c...@dawg.eu
--- Comment #0 from Martin Nowak c...@dawg.eu 2013-10-31 20:39:09 PDT ---
cat bug.d CODE
import std.stdio;
void main()
{
writefln(Hello %1$s!, World);
}
CODE
dmd -run bug
When debugging this gdb constantly barks that it can't find the function
frames.
In this specific program the format spec is incorrect.
It seems that some data/code is corrupted when linking with gold.
We should investigate whether this is an issue in dmd's codegen.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11407] New: can't move struct with disabled default constructor
http://d.puremagic.com/issues/show_bug.cgi?id=11407
Summary: can't move struct with disabled default constructor
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: c...@dawg.eu
--- Comment #0 from Martin Nowak c...@dawg.eu 2013-10-31 22:37:31 PDT ---
cat bug.d CODE
import std.algorithm;
struct Unique
{
int* _p;
@disable this(this);// non-copyable
~this() { _p = null; } // release resource
@disable this();// non-null
this(int* p) { _p = p; }// acquire resource
}
Unique bug(Unique u)
{
return move(u);
}
CODE
dmd -c bug
The use-case is to encapsulate unique ownership in a struct.
It seems the static T empty; in move() is only need to reinitialized the moved
value. Maybe it could be done with destroy or by copying from
typeid(T).init().ptr.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11392] dirEntries segfaults (fails in 2.064 beta 4, works in 2.063.2)
http://d.puremagic.com/issues/show_bug.cgi?id=11392 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com Platform|All |x86_64 OS/Version|All |Mac OS X --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2013-10-31 22:36:59 PDT --- I can confirm this seg faults on OSX, 64 bits only. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
