Jonathan M Davis wrote:
On Saturday 19 March 2011 18:04:57 Don wrote:
Jonathan M Davis wrote:
On Saturday 19 March 2011 17:11:56 Don wrote:
Here's the task:
Given a .d source file, strip out all of the unittest {} blocks,
including everything inside them.
Strip out all comments as well.
Print
On 2011-03-19 20:41:09 -0400, Jonathan M Davis said:
On Saturday 19 March 2011 17:11:56 Don wrote:
Here's the task:
Given a .d source file, strip out all of the unittest {} blocks,
including everything inside them.
Strip out all comments as well.
Print out the resulting file.
Motivation: Bug
On Saturday 19 March 2011 18:04:57 Don wrote:
> Jonathan M Davis wrote:
> > On Saturday 19 March 2011 17:11:56 Don wrote:
> >> Here's the task:
> >> Given a .d source file, strip out all of the unittest {} blocks,
> >> including everything inside them.
> >> Strip out all comments as well.
> >> Prin
Jonathan M Davis wrote:
On Saturday 19 March 2011 17:11:56 Don wrote:
Here's the task:
Given a .d source file, strip out all of the unittest {} blocks,
including everything inside them.
Strip out all comments as well.
Print out the resulting file.
Motivation: Bug reports frequently come with ve
On Saturday 19 March 2011 17:11:56 Don wrote:
> Here's the task:
> Given a .d source file, strip out all of the unittest {} blocks,
> including everything inside them.
> Strip out all comments as well.
> Print out the resulting file.
>
> Motivation: Bug reports frequently come with very large test
On Saturday 19 March 2011 16:51:19 Andrej Mitrovic wrote:
> I'm trying to do something like the following:
>
> File inputfile;
> foreach (string name; dirEntries(r".\subdir\", SpanMode.shallow))
> {
> if (!(isFile(name) && getExt(name) == "d"))
> {
> continue;
> }
>
> inpu
On 3/20/11 1:11 AM, Don wrote:
Here's the task:
Given a .d source file, strip out all of the unittest {} blocks,
including everything inside them.
Strip out all comments as well.
Print out the resulting file.
I realize that you asked for a very specific utility, but in several
instances, http:
Here's the task:
Given a .d source file, strip out all of the unittest {} blocks,
including everything inside them.
Strip out all comments as well.
Print out the resulting file.
Motivation: Bug reports frequently come with very large test cases.
Even ones which look small often import from Phobos
I'm trying to do something like the following:
File inputfile;
foreach (string name; dirEntries(r".\subdir\", SpanMode.shallow))
{
if (!(isFile(name) && getExt(name) == "d"))
{
continue;
}
inputfile = File(name, "a+");
foreach (line; inputfile.byLine)
{
On Saturday 19 March 2011 11:12:49 Ali Çehreli wrote:
> On 03/19/2011 10:05 AM, Mafi wrote:
> > Am 19.03.2011 17:29, schrieb Piotr Szturmaj:
> >> Shouldn't dynamic array be reference type?
> >
> > Just one note: appending (ar ~= 1) differs from concating (ar = ar ~ 1)
> > that while the secon
On Saturday 19 March 2011 06:02:49 bearophile wrote:
> tsukikage:
> > Would please someone explain why enum A etc. is constructed at run time?
>
> enum is currently very broken. The same happens with associative arrays,
> etc.
Well, enum works perfectly in that its value doesn't change. It's alwa
Piotr Szturmaj Wrote:
> Thank you for your very complete answers :)
>
> I was trying to avoid multiple AA key lookups while appending many
> elements to dynamic array. It's clear now, that with D2 semantics it's
> better to first build an array and then assign it to AA.
What everyone else said
On 03/19/2011 10:05 AM, Mafi wrote:
> Am 19.03.2011 17:29, schrieb Piotr Szturmaj:
>> Shouldn't dynamic array be reference type?
> Just one note: appending (ar ~= 1) differs from concating (ar = ar ~ 1)
> that while the second is guanranteed to reallocate, about the first you
> can't be sure. It
Thank you for your very complete answers :)
I was trying to avoid multiple AA key lookups while appending many
elements to dynamic array. It's clear now, that with D2 semantics it's
better to first build an array and then assign it to AA.
Am 19.03.2011 17:29, schrieb Piotr Szturmaj:
Shouldn't dynamic array be reference type?
uint[][uint] aa;
uint[] temp;
aa[5] = new uint[0];
temp = aa[5]; // copy uint[] reference
temp ~= 1;
assert(temp.length == 1 && temp[0] == 1); // pass
assert(aa[5].length == 1 && aa[5][0] == 1); // fail
Is
Piotr Szturmaj:
> Shouldn't dynamic array be reference type?
They are partially a reference type and partially a value :-)
A D dynamic array is represented with a small struct 2-words long that contains
the pointer to the first item of the array and the length of the array (you are
able to read
Shouldn't dynamic array be reference type?
uint[][uint] aa;
uint[] temp;
aa[5] = new uint[0];
temp = aa[5]; // copy uint[] reference
temp ~= 1;
assert(temp.length == 1 && temp[0] == 1); // pass
assert(aa[5].length == 1 && aa[5][0] == 1); // fail
Is this a bug?
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
> On Friday 18 March 2011 20:49:58 Sean Eskapp wrote:
> > incompatible /usr/lib/../lib/librt.so when searching
> > for -lrt
> > /usr/bin/ld: skipping incompatible /usr/lib/../lib/librt.a when searching
> > for -lrt
> > /usr/bin/ld: skip
Oh, I see. Thanks.
bearophile wrote:
tsukikage:
Would please someone explain why enum A etc. is constructed at run time?
enum is currently very broken. The same happens with associative arrays, etc.
Bye,
bearophile
tsukikage:
> Would please someone explain why enum A etc. is constructed at run time?
enum is currently very broken. The same happens with associative arrays, etc.
Bye,
bearophile
correction:
00402010: enter 4,000 // foo - function enum
00402014: mov[ebp][-04],eax
Hi,
I previous expected that the enum A inside foo, or enum B at module
level used by baz are immutable compile time generated static array, but
by looking at the disassembled source, I found A is constructed every
time entering the function in run time. Instaed, static A inside bar is
constru
22 matches
Mail list logo
