[Issue 7442] ctRegex!`\p{Letter}` uses a lot memory in compilation
http://d.puremagic.com/issues/show_bug.cgi?id=7442 --- Comment #10 from Don 2012-04-29 00:02:21 PDT --- (In reply to comment #7) > I investigated this further and conclude that there are 2 factors at work. > > I removed few thousands of codepoints from Letter, so it doesn't run out of > RAM > outright.(see code below) > Also separated parse from build steps. > > Here are collected stats on CTFE. > > parse only: > > CTFE Performance > max call depth = 20 max stack = 44 > array allocs = 2761 assignments = 430837 > > build: > CTFE Performance > max call depth = 20 max stack = 73 > array allocs = 8264 assignments = 1293421 > > Parsing creates all the datastructures for unicode table machinery > it takes slightly less then half of all allocs already. > Another thing to notice is it fetures higher allocations per assigment. > > Then comes the codegen step and it's CTFE only and far more alloc happy. > Frankly I see no way to reduce all of this alloc fun because of COW > that will ruin any attempt to preallocate buffer for generated code. > Am I right that arrays do dup on every write? No, that was true a year or so ago, but not any more. One case which still causing array dups is comparing slices of arrays (eg, if (x[0..5] == y). I've put the machinery in place to get rid of that now (it's not gone yet, I need another simple pull request for that). That _might_ help a little bit. Slicing also causes array dups with ~, eg z = x[0..5] ~ y; creates a temporary array with x[0..5]. But those are the only two that I know of. Clearly in this case, it's slow because it does 1.3 million assignments. It's a duplicate of bug 6498, unless you can find some way of drastically reducing the work it has to do. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7997] Optlink crash with static zero length array
http://d.puremagic.com/issues/show_bug.cgi?id=7997 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don 2012-04-29 00:07:44 PDT --- Very similar to bug 5332, probably another symptom of the same bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6983] Vararg corrupts string on 64bit
http://d.puremagic.com/issues/show_bug.cgi?id=6983 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #2 from Don 2012-04-29 00:12:05 PDT --- (In reply to comment #1) > The 64 bit ABI won't allow using _argptr directly. Instead, use the functions > in core.stdc.stdarg. The real bug is bug 7893: the spec says you *can* use _argptr in this way. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7442] ctRegex!`\p{Letter}` uses a lot memory in compilation
http://d.puremagic.com/issues/show_bug.cgi?id=7442 --- Comment #11 from Dmitry Olshansky 2012-04-29 05:53:34 PDT --- > > No, that was true a year or so ago, but not any more. One case which still > causing array dups is comparing slices of arrays (eg, if (x[0..5] == y). I've > put the machinery in place to get rid of that now (it's not gone yet, I need > another simple pull request for that). That _might_ help a little bit. > > Slicing also causes array dups with ~, eg z = x[0..5] ~ y; creates a temporary > array with x[0..5]. But those are the only two that I know of. > Ok does a ~= b; *always* reallocate a ? If not I'm fine. > Clearly in this case, it's slow because it does 1.3 million assignments. It's > a > duplicate of bug 6498, unless you can find some way of drastically reducing > the > work it has to do. Well take a look at "benchmark" for CTFE. It does a lot of bit-setting on array of bytes. Posiibly a source of asigments since it does 1 bit-set per codepoint. That's unavoidable I'm afraid. I may special case things somewhat so that it checks if fullword write of zeros or ones is possible. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5650] A RedBlackTree performance problem
http://d.puremagic.com/issues/show_bug.cgi?id=5650 d...@dawgfoto.de changed: What|Removed |Added CC||d...@dawgfoto.de --- Comment #15 from d...@dawgfoto.de 2012-04-29 07:04:14 PDT --- >Gr... I hate how dmd makes poor decisions about inlining and then won't let >you force the issue... This is an issue with how the exception handling alters the control flow. Perhaps annotating the properties with nothrow would have a similar effect. Anyhow scope (success) means that you'll have to temporarily store the return value, so a small penalty will remain in most cases. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8001] New: Alias this takes ownership of explicit cast
http://d.puremagic.com/issues/show_bug.cgi?id=8001
Summary: Alias this takes ownership of explicit cast
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jesse.k.phillip...@gmail.com
--- Comment #0 from Jesse Phillips 2012-04-29
07:41:14 PDT ---
When attempting to downcast a class which uses alias this, the operation fails
because the cast is applied to the item aliased.
I think the semantics should be to attempt an implicit cast (alias this), then
a cast of the top class, afterwards the alias this item can be casted.
test.d(3): Error: e2ir: cannot cast a.val of type int to type test.B
void main () {
A a = new B();
B b = cast(B) a;
}
class A {
int val;
alias val this;
}
class B : A {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7243] Compiler should call separate function when allocating a struct on the heap
http://d.puremagic.com/issues/show_bug.cgi?id=7243 --- Comment #1 from Steven Schveighoffer 2012-04-29 11:29:39 PDT --- Martin Nowak has found a very compelling case for this to be fixed, it is affecting performance of RedBlackTree. >From bug 5650: When in 64-bit mode, each pointer is 8 bytes. RedBlackNodes have a left, right, and parent pointer, consuming 24 bytes. Then it contains the payload, followed by a byte for the color (red or black). The basic RedBlackTree!int case has a payload of int, or 4 bytes. With alignment padding, this brings the size of the struct to 32 bytes. Now, given that array appending needs the extra byte for 'used' length (also serves as a sentinel to prevent accidentally accessing the subsequent block), this will be with array padding, 33 bytes, pushing the block required to 64 bytes. Not only that, but because the struct has pointers, it must zero out those 31 unused bytes. With his measurements as quoted in bug 5650, fixing this problem resulted in roughly a 40% runtime reduction. Can we please get this fixed? I'll be happy to implement the druntime function if someone will take care of the compiler part. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7243] Compiler should call separate function when allocating a struct on the heap
http://d.puremagic.com/issues/show_bug.cgi?id=7243 --- Comment #2 from github-bugzi...@puremagic.com 2012-04-29 14:04:13 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/c8897db61b76f4f2eac12581042adcfb35543bd4 fix Issue 7243 - Compiler should call separate function when allocating a struct on the heap -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7243] Compiler should call separate function when allocating a struct on the heap
http://d.puremagic.com/issues/show_bug.cgi?id=7243 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #4 from Walter Bright 2012-04-29 14:06:50 PDT --- Back to you, Steven! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7243] Compiler should call separate function when allocating a struct on the heap
http://d.puremagic.com/issues/show_bug.cgi?id=7243 --- Comment #3 from github-bugzi...@puremagic.com 2012-04-29 14:05:47 PDT --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/4004bb3b222676c74a41c0bb2507979963167457 fix Issue 7243 - Compiler should call separate function when allocating a struct on the heap -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7243] Compiler should call separate function when allocating a struct on the heap
http://d.puremagic.com/issues/show_bug.cgi?id=7243 --- Comment #5 from github-bugzi...@puremagic.com 2012-04-29 14:07:27 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a766e4a395e4fb86ff31c6161d343d85805d96b3 fix Issue 7243 - Compiler should call separate function when allocating a struct on the heap -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8002] New: Excess initial errors when passing template args to non-templated struct
http://d.puremagic.com/issues/show_bug.cgi?id=8002
Summary: Excess initial errors when passing template args to
non-templated struct
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: cbkbbej...@mailinator.com
--- Comment #0 from Nick Sabalausky 2012-04-29
14:14:11 PDT ---
---
import std.stdio;
struct Foo
{
int a;
}
int bar()
{
writeln();
return 1;
}
void main()
{
Foo x = Foo!(bar());
}
---
A template argument is (accidentally) being passed to Foo. The compiler should,
and does, print a "not a template declaration" error. But before doing so, it
evaluates the completely erroneous template arg, resulting in a big pile of
totally non-applicable error text ("cannot be interpreted at compile time")
which obscures the one real problem.
>dmd test.d
C:\Documents and Settings\Nick Sabalausky\Application
Data\dvm\compilers\dmd-2.059\bin\..\src\phobos\std\stdio.d(1548): Error: fputc
cannot be interpreted at compile time, because it has no available source code
C:\Documents and Settings\Nick Sabalausky\Application
Data\dvm\compilers\dmd-2.059\bin\..\src\phobos\std\stdio.d(1548):called
from here: enforce(fputc(10,(*stdout.p).handle) == 10,delegate pure nothrow
@safe const(char)[]()
{
return null;
}
)
test.d(10):called from here: writeln()
test.d(16):called from here: bar()
test.d(16): Error: template instance Foo!(bar()) Foo is not a template
declaration, it is a struct
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8003] New: Phobos uses deprecated std.path sep symbol
http://d.puremagic.com/issues/show_bug.cgi?id=8003 Summary: Phobos uses deprecated std.path sep symbol Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2012-04-29 17:06:04 PDT --- DMD 2.059 release: std.file and std.datetime still use std.path.sep which is deprecated, they should use dirSeparator instead. Here are the lines: std.file: L542 L543 L1968 L1969 std.datetime: L29289 L29598 L29600 L29601 Why is Phobos being compiled with the deprecation option when distributed? The same thing goes for RDMD which Walter compiled with -d but otherwise the 2.059 release version wouldn't compile without -d. For lack of a better word, it's really unprofessional. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8004] New: Direct call of function literal should consider default arguments
http://d.puremagic.com/issues/show_bug.cgi?id=8004
Summary: Direct call of function literal should consider
default arguments
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2012-04-29 18:15:35 PDT ---
This code doesn't compile in git head.
auto n = (int n = 10){ return n; }();
This regression is introduced by fixing bug 3866.
Calling function literal directly is never indirect call, so this is regression
IMO.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8005] New: Lambda with parameter type inference should consider default args
http://d.puremagic.com/issues/show_bug.cgi?id=8005
Summary: Lambda with parameter type inference should consider
default args
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2012-04-29 18:17:27 PDT ---
This code should compile.
auto n = (a, int n = 10){ return n; }(10);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8004] Direct call of function literal should consider default arguments
http://d.puremagic.com/issues/show_bug.cgi?id=8004 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara 2012-04-29 20:26:11 PDT --- https://github.com/D-Programming-Language/dmd/pull/913 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8005] Lambda with parameter type inference should consider default args
http://d.puremagic.com/issues/show_bug.cgi?id=8005 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara 2012-04-29 20:33:36 PDT --- https://github.com/D-Programming-Language/dmd/pull/914 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4744] std.conv: string->enum doesn't look for longer match
http://d.puremagic.com/issues/show_bug.cgi?id=4744 francois.chabot@gmail.com changed: What|Removed |Added CC||francois.chabot.dev@gmail.c ||om --- Comment #2 from francois.chabot@gmail.com 2012-04-29 20:43:13 PDT --- possible fix: https://github.com/D-Programming-Language/phobos/pull/557 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6969] Forward reference on template class triangle
http://d.puremagic.com/issues/show_bug.cgi?id=6969
--- Comment #6 from Nick Sabalausky 2012-04-29
21:23:36 PDT ---
This works:
class A
{
alias C C1;
}
class B
{
alias A A1;
}
class C : B
{
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8004] Direct call of function literal should consider default arguments
http://d.puremagic.com/issues/show_bug.cgi?id=8004 --- Comment #2 from github-bugzi...@puremagic.com 2012-04-29 22:38:32 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c62833f09f75091f9fd73edf051c720829513e4b fix Issue 8004 - Direct call of function literal should consider default arguments https://github.com/D-Programming-Language/dmd/commit/aea217c612614d248c412d753ac135e86fad2931 Merge pull request #913 from 9rnsr/fix8004 Issue 8004 - Direct call of function literal should consider default arguments -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8006] New: Implement proper in-place-modification for properties
http://d.puremagic.com/issues/show_bug.cgi?id=8006
Summary: Implement proper in-place-modification for properties
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic 2012-04-29
23:26:40 PDT ---
Currently properties are only usable for reading and writing values, but they
can't really be used for in-place modification:
// fake int type, just to avoid rvalue errors in this demo
struct Bar { int x; alias x this; }
struct Foo
{
Bar _val;
@property Bar val() { return _val; }
@property void val(Bar nval) { _val = nval; }
}
void main()
{
Foo foo;
foo.val += 5; // modifies *temporary*, then discards it
foo.val++; // ditto
}
The only way to work around this is to make the getter property return by ref,
but this completely circumvents the setter property, e.g.:
struct Bar { int x; alias x this; }
struct Foo
{
Bar _val;
@property ref Bar val() { return _val; }
@property void val(Bar nval) { _val = nval; } // never called
}
void main()
{
Foo foo;
foo.val += 5;
assert(foo.val == 5); // updated, but setter circumvented
foo.val++;
assert(foo.val == 6); // ditto
}
C# apparently implements in-place modification by translating calls such as
this:
foo.val += 5;
foo.val++;
into this:
foo.val = foo.val + 5;
foo.val = foo.val + 1;
DIP4 also mentioned this feature
(http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4), but was
superseeded by DIP6 which was approved. I think we ought to implement this to
make properties more usable and less error-prone to work with.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
