Re: Phobos unittest failure on single-core machines
On 08/24/12 12:27, dsimcha wrote: This looks to be a bug in a recently-added feature. I'll look at it in detail tonight, but I think I know what the problem is and it's pretty easy to fix. Thanks for the quick fix! Phobos unittests are building fine for me now. --Ed
Re: Wrong lowering for a[b][c]++
On 03/23/2012 01:24 AM, H. S. Teoh wrote: WAT?! What on earth is "cast()" supposed to mean?? I think it removes one level of const or immutable from the type of its argument. Why that helps in this case, I don't know. --Ed
Nested function bug?
I ran into a strange and hard-to-describe problem with nested functions
closing over the argument to their enclosing function.
When a nested function (A) returns the value of another nested function
(B) that returns a parameter of the enclosing function (C), and when (A)
is returned from (C), then calling (A) returns an incorrect value if (A)
has a parameter of class type (it works when (A) has no class parameters).
The code below demonstrates this (using DMD 2.058, no optimizations). Is
this a bug?
auto foo(T)(int val)
{
int nested()
{
return val;
}
int escaping(T ignored)
{
return nested();
}
return &escaping;
//return &nested; // this works
}
struct Bar {}
class Baz {}
void main()
{
auto func1 = foo!int(55);
auto val1 = func1(12);
assert(val1 == 55); // works fine with integral type
auto func2 = foo!Bar(55);
Bar bar;
auto val2 = func2(bar);
assert(val2 == 55); // works fine with struct
auto func3 = foo!Baz(55);
auto baz = new Baz();
auto val3 = func3(baz);
assert(val3 == 55); // fails; val3 is different value on each run
}
Re: Nested function bug?
On 03/30/2012 04:51 PM, Andrej Mitrovic wrote: You mean the result is 55 when you uncomment "return&nested;"? All asserts pass for me when I use that return. Otherwise when using "return&escaping;" I get: 1244764 1244764 4202631 2.058 win32. On 64-bit linux, the first two asserts always pass using either "return &nested" or "return &escaping". Just checked on 32-bit linux and I see the same behavior you are, with all three asserts failing using "return &escaping". --Ed
Re: Nested function bug?
On 03/30/2012 04:45 PM, Walter Bright wrote: On 3/30/2012 1:13 PM, Ed McCardell wrote: The code below demonstrates this (using DMD 2.058, no optimizations). Is this a bug? Looks like one. Please report this to http://d.puremagic.com/issues/enter_bug.cgi?product=D Done: http://d.puremagic.com/issues/show_bug.cgi?id=7801
Problem with dmd2.059.zip
The versions of std.datetime and std.path in the 2.059 zip file don't
have the latest fixes that take care of switching from the deprecated
std.path.sep and undeprecating std.path.onOutOfMemoryError.
Compiling this simple program:
import std.datetime;
void main() {}
gives an error when using "-inline -release -noboundscheck"
std/datetime.d(29600): Error: variable std.path.sep is deprecated
std/datetime.d(29601): Error: variable std.path.sep is deprecated
std/path.d(2715): Error: alias std.path.onOutOfMemoryError is deprecated
(Oddly enough, it compiles without error with any other combination of
those three options.)
Since it's fixed in the git repo, and can be worked around using the -d
switch, is it worth opening a bug report?
Re: shared gitconfig
On 01/06/2013 02:50 PM, Andrei Alexandrescu wrote: Sent this to dmd-internals, opening for a broader discussion: Hello, I wonder how we can define a few aliases of project-wide usefulness to git. For example, I tried today to get the latest and greatest phobos into my repo, and got a bunch of conflicts. I searched a while on the net to figure what the command for "just get the latest remote into my local copy", which is entirely possible but not obvious and not easy to find. If you use local branches instead of working directly on master then getting the latest and greatest is as simple as git checkout master git pull Then you can do git checkout mybranch git rebase master to get new upstream changes into your local branch(es). You might sometimes need to use more complicated versions of the rebase command, but no matter how wacky things get with merge conflicts, it will only be affecting your local branch. (I often do "git checkout mybranch; git checkout -b newmybranch; git rebase master", if I'm worried about conflicts; this way I have a new branch to play around with fixing conflicts in, and it's easy to just scrap it and switch back to known-good versions of master and local branches). tl;dr: more local branches means less need for arcane git options. --Ed
Re: shared gitconfig
On 01/10/2013 04:20 AM, mist wrote: tl;dr: more local branches means less need for arcane git options. --Ed AFAIR you can resist the temptation to have a local master branch at all and just run "git pull --rebase upstream/master" where upstream is configured to be original D repo. And then you're right back where we started; Andrei's original problem was how to just get a local copy of the latest and greatest upstream without having merge conflicts, which (if you don't have a separate local master) means using "git pull --rebase -s recursive -X ours". But: "rebase -X ours" does not throw away all of your changes; it keeps the ones that can be cleanly merged. So what you end up with is "the latest and greatest plus SOME of my local changes", which might not be what you wanted. (Also, git branches are not temptations to be resisted.) --Ed
Re: shared gitconfig
On 01/11/2013 12:35 PM, mist wrote: I do not propose to get rid of master at all, just made an observation that it is easy to make small fix directly on master when it is hanging around so close. Looks like we're in violent agreement :) Mainly, I was trying to argue against the inclusion of Andrei's suggested git script in the official repository. --Ed
Re: Proposal: takeFront and takeBack
On 07/04/2012 04:50 AM, Jonathan M Davis wrote: But reducing code was never my concern (nor Dmitry's in considering proposing essentially the same thing). It's efficiency that's the problem - particularly with strings. IIRC, with the tests that I ran, it took about 33% longer to use front and popFront separately than it did to use consumeFront with strings. Does the speed difference show up in both GDC and DMD? (If you can post some test code, I can check GDC on linux). --Ed
Re: Proposal: takeFront and takeBack
On 07/04/2012 10:11 PM, Jonathan M Davis wrote: Just adjust the strings to try different strings, and adjust then number of iterations if you need to. It prints out a two lines looking like: ascii 82.89%: old [5 secs, 176 ms, 602 μs, and 8 hnsecs], new [4 secs, 290 ms, 683 μs, and 6 hnsecs] uni 74.78%: old [6 secs, 876 ms, 3 μs, and 1 hnsec], new [5 secs, 141 ms, 955 μs, and 6 hnsecs] Using GDC* without optimizations, I am seeing similar numbers (consumeFront taking 75%-85%). With gdmd -release -O -inline (which translates to gdc -frelease -finline-functions -fweb -O3), I am getting results like this: ascii 17.91%: old [3 secs, 102 ms, 490 μs, and 7 hnsecs], new [555 ms and 747 μs] uni 42.80%: old [3 secs, 929 ms, 632 μs, and 9 hnsecs], new [1 sec, 681 ms, 862 μs, and 7 hnsecs] I found this surprising, since I've seen several cases of performance differences, between two versions of a program built with dmd, disappear when built with gdc (presumably, because the gcc backend is better at optimizing "slower" code). --Ed * built with gcc-4.7-20120421 snapshot and gdc at commit https://github.com/D-Programming-GDC/GDC/commit/a764e6947be42c0ee47f340e0ab86190401aec24
Re: Proposal: takeFront and takeBack
On 07/05/2012 01:26 AM, Jonathan M Davis wrote:
I wonder how the results look on gdc when using the improved popFront, given
how surprising they were with consumeFront.
Improved popFront, gdc as before (-frelease -finline-functions -fweb -O3):
ascii 22.69%: old [2 secs, 449 ms, 248 μs, and 7 hnsecs], new [555 ms,
718 μs, and 3 hnsecs]
uni 42.52%: old [3 secs, 879 ms, 380 μs, and 7 hnsecs], new [1 sec,
649 ms, 387 μs, and 4 hnsecs]
For comparison, on the same machine with dmd -release -O -inline,
ascii 118.23%: old [1 sec, 754 ms, 449 μs, and 2 hnsecs], new [2 secs,
74 ms, 197 μs, and 8 hnsecs]
uni 86.82%: old [4 secs, 413 ms, 167 μs, and 8 hnsecs], new [3 secs,
831 ms, 569 μs, and 1 hnsec]
(The machine is an old 32-bit Athlon XP 3000+ ("Barton"))
When gdc finishes building on my 64-bit box I can run timings on that,
but it's a crappy underpowered emachine/acer, so any results may say
less about any 32/64 bit differences and more about what happens when
you buy a $250 computer at Walmart.
--Ed
Re: Proposal: takeFront and takeBack
On 07/05/2012 02:35 AM, Ed McCardell wrote: When gdc finishes building on my 64-bit box I can run timings on that, There also seems to be a speed improvement for consumeFront on 64-bit gdc, with both standard and Andrei's improved popFront: standard popfront: ascii 35.95%: old [3 secs, 831 ms, 261 μs, and 5 hnsecs], new [1 sec, 377 ms, 299 μs, and 7 hnsecs] uni 49.48%: old [4 secs, 860 ms, 874 μs, and 7 hnsecs], new [2 secs, 405 ms, 372 μs, and 7 hnsecs] improved popfront: ascii 62.74%: old [2 secs, 388 ms, 776 μs, and 5 hnsecs], new [1 sec, 498 ms, 736 μs, and 2 hnsecs] uni 61.26%: old [4 secs, 58 ms, 522 μs, and 5 hnsecs], new [2 secs, 486 ms, 451 μs, and 7 hnsecs] --Ed
Pull tester
Does the pull tester pick up new pull requests automatically, or is there something I need to do to have my pull request tested? https://github.com/D-Programming-Language/dmd/pull/1064 --Ed
Re: Pull tester
On 07/28/2012 05:49 PM, David wrote: That is automatically tested: http://d.puremagic.com/test-results/pull-history.ghtml?projectid=1&pullid=1064 There are great greasemonkey scripts which show the status of the pull request: http://d.puremagic.com/test-results/greasemonkey.ghtml I am using these scripts with tampermonkey (https://chrome.google.com/webstore/detail/dhdgffkkebhmkfjojejmpbldmpobfkfo) in chromium. Thanks. Is the test summary script (that is supposed to show on github/D-Programming-Language) working for you in chromium? It isn't for me.
Re: std.d.lexer requirements
On 08/02/2012 04:41 AM, Walter Bright wrote: On 8/2/2012 1:21 AM, Jonathan M Davis wrote: How would we measure that? dmd's lexer is tied to dmd, so how would we test the speed of only its lexer? Easy. Just make a special version of dmd that lexes only, and time it. I made a lexing-only version of dmd at https://github.com/edmccard/dmd/tree/lexonly by stripping non-lexer-related code from mars.c, and adding a lexModule function that is called instead of Module::parse.. There's no benchmarking code yet; it basically just does while (token.value != TOKeof) nextToken(); for each D source file passed on the command line. --Ed
Phobos unittest failure on single-core machines
When trying to run the phobos unittests on my 32- and 64-bit linux single-processor machines, I get this output: Testing generated/linux/debug/64/unittest/std/parallelism totalCPUs = 1 core.exception.AssertError@std.parallelism(4082): unittest failure Has anyone else seen this, or is possible that I have an error in my dmd setup? (I'm using dmd/druntime/phobos from git HEAD, building in what I thought was the normal manner). --Ed McCardell
Re: Phobos unittest failure on single-core machines
On 08/24/12 12:27, dsimcha wrote: This looks to be a bug in a recently-added feature. I'll look at it in detail tonight, but I think I know what the problem is and it's pretty easy to fix. Can you please file a Bugzilla and note whether it always occurs or is non-deterministic? Filed as http://d.puremagic.com/issues/show_bug.cgi?id=8582 --Ed
