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 An
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 y
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
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
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:
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
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 versi
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 th
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
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
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
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]
un
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 pop
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 u
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
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
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)
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
18 matches
Mail list logo
