Re: Accessing private class members with tupleof
On Thu, Jan 29, 2009 at 3:51 AM, grauzone n...@example.net wrote:
Is it legal to access private members of a class using tupleof, when normal
access would be illegal?
It is not really clear from the D1.0 specification:
The .tupleof property returns an ExpressionTuple of all the fields in
the class, excluding the hidden fields and the fields in the base
class.
Do private members count as hidden, or does the specification only consider
the vtable and monitor fields as hidden fields? What exactly are hidden
fields at all?
It seems newer dmd versions allow you to access private members, while older
versions raise a compile-time error.
Here is an example to demonstrate the issue (for D1.0):
---file a.d
module a;
class Test {
int a = 1;
protected int b = 2;
private int c = 3;
package int d = 4;
}
---file b.d
module b;
import a;
int[] get(Test t) {
int[] result;
foreach (i, x; t.tupleof) {
result ~= t.tupleof[i];
}
return result;
}
import std.stdio;
void main() {
//outputs [1,2,3,4]
writefln(get(new Test()));
}
Interesting. It used to be an error, but that made .tupleof useless
for all but the most basic aggregate types, since the compiler would
just error on anything with non-public fields. I would have expected
it to just give a tuple of the _public_ fields, but..
You could file an issue and see what Walter does or doesn't have to
say about it.
Re: Problem with dsss 0.78 rebuild error: out of memory
Spacen Jasset wrote:
Spacen Jasset wrote:
Spacen Jasset wrote:
I installing a new pc, and so have installed the latest tools
specifically dss 0.78
I find that when compiling certain things, such as Derelict (dsss net
install derelict) or the project I am working on, rebuild runs out of
memory.
version 0.75 works ok, but 0.78 does not. I have 1Gb of memory + 2G
of swap.
Has anyone encountered this problem before?
I have found that there is indeed a bug in dsss 0.78 that manifests on
at least linux DMD.
If anyone has version 0.78 could see if you can reproduce it? I have
not tried windows yet, either.
Here are the files. dsss will loop for ages and then run out of
memory. It seems to get stuck in parse.c which is the DMD front end
built into rebuild.
---dsss.conf---
[engine.d]
---engine.d---
module renderer;
class RenderEngine
{
void reset()
{
func(__FILE__ RenderEngine: reset());
}
}
--- ---
Invoke with dsss build
engine.d can be simplified to just:
func(__FILE__ RenderEngine: reset());
I reproduced this on windows, but only with the original engine.d and
not the one liner mentioned above. I've sent an email to Gregor about this.
problem with D compiler
when I try to build the program. I ge t a message: C:\Dev\DSciTE\bud.exe -DCPATHC:\Dev\DSciTE\dmd\bin -IC:\Dev\DSciTE\lib -I.. -I..\.. -full -debug -g -unittest -w hello.d Error: bud:Unable to find Config File 'sc.ini' in [.\,,C:\Documents and Settings\user,C:\Dev\DSciTE\dmd\bin\] what am I do to fix it?
Re: problem with D compiler
I didn't doing this nothing. when I open bin folder- I see this file: sc.ini. please help me :) Jarrett Billingsley Wrote: On Thu, Jan 29, 2009 at 10:11 AM, naama naama...@walla.com wrote: when I try to build the program. I ge t a message: C:\Dev\DSciTE\bud.exe -DCPATHC:\Dev\DSciTE\dmd\bin -IC:\Dev\DSciTE\lib -I.. -I..\.. -full -debug -g -unittest -w hello.d Error: bud:Unable to find Config File 'sc.ini' in [.\,,C:\Documents and Settings\user,C:\Dev\DSciTE\dmd\bin\] what am I do to fix it? sc.ini is DMD's configuration file. It normally lives in the same folder as dmd.exe; is it still there or did you do something with it?
Re: casting int[] to bool[]
Well casting it is then for me, for now. This way of reading all these booleans is a bit slow... a minute for 700_000 lines Is there some way to speed this up? Well that's stupid. Tango's to!() handles that case. Phobos needs to catch up!
Re: Segmentation error at the end problem (148 line program listing)
Gide Nwawudu wrote:
On Wed, 28 Jan 2009 13:37:40 -0800, Charles Hixson
charleshi...@earthlink.net wrote:
Gide Nwawudu wrote:
On Tue, 27 Jan 2009 22:48:33 -0800, Charles Hixson
charleshi...@earthlink.net wrote:
Main routine:
voidmain()
{
try
{ BlockFile bf;
bf = new BlockFile (test.bf, 4096);
writefln (before close);
bf.close;
bf = null;
writefln (after close);
BlockFile cf = new BlockFile (test.bf, 4096);
writefln (after second open);
}
catch (Exception e)
{ writefln (Caught Exception , e); }
}
Results in:
Exiting BlockFile::this
before close
after close
Exiting BlockFile::this
after second open
Segmentation fault
I could post all the code. It's only 146 lines. But perhaps this is
enough?
I'm thinking it might be an issue with close and the dtor being called
on the same object. If you add std.gc.fullCollect() after the bf =
null. Does that make the code seg fault before 'after close' is
written?
Gide
I had to wriggle the code around a bit. (It's D2 not D1.) However it
didn't make any difference to do:
voidmain()
{
try
{ BlockFile bf;
bf = new BlockFile (test.bf, 4096);
writefln (before close);
bf.close;
bf = null;
GC.collect;
writefln (after close);
BlockFile cf = new BlockFile (test.bf,
4096);
writefln (after second open);
}
catch (Exception e)
{ writefln (Caught Exception , e);}
}
---
And the docs say that GC.collect does a full collect;
P.S.: Attached is the full listing
Calling close and dtor on BufferedFile is the problem. Rewiting
BlockFile.close as follows fixes the problem, but I think your code
should work.
void close() { delete bf; bf = null; }
Gide
I replaced BlockFile.close with:
void close()
{ if (bf !is null) delete bf; // bf.close;
bf = null;
}
But that didn't alter the segmentation fault. (Did you try it under D1
or D2?)
Re: casting int[] to bool[]
It's probably due to the absurd amount of memory allocation you're
causing. Each call to split() allocates an array (whose size is not
known in advance, so it requires several appends), and each call to
to!(int[]) allocates _another_ array. That's 1.4 million arrays
you're allocating, most of which are garbage, and each allocation can
potentially trigger a GC cycle.
It would be a lot more efficient if you just parsed out the line yourself.
auto data = splitlines(read(`data\parsed.dat`).idup);
auto dataIn = new bool[][](data.length, 3);
foreach(i, line; data)
{
dataIn[i][0] = line[14] == '1';
dataIn[i][1] = line[16] == '1';
dataIn[i][2] = line[18] == '1';
}
Now we perform only a few allocations, all of which are before the loop.
Yay massive speedup!! (~2 sec for the loop)
Is `bool = x == y` faster than `if ( x == y ) true else false` ?
For the 60 large boolean part I used a loop.
Not that I really need the extra speedup (if any) but how could I manually
unroll that loop?
I know you can do things like that in D..
btw. side note: I love slices :D
auto sliceIn = dataIn[0..300];
auto sliceOut = dataOut[0..300];
rndGen.seed(1);
randomShuffle(sliceIn, rndGen);
rndGen.seed(1);
randomShuffle(sliceOut, rndGen);
Re: casting int[] to bool[]
Most of the std.math functions take reals and when I have a float or a double I always cast them to real to make it fit. Should I instead use to! here as well?
Re: casting int[] to bool[]
On Thu, Jan 29, 2009 at 1:57 PM, Saaa em...@needmail.com wrote:
Yay massive speedup!! (~2 sec for the loop)
Is `bool = x == y` faster than `if ( x == y ) true else false` ?
No, just shorter to type. They compile down to pretty much the same
machine code.
For the 60 large boolean part I used a loop.
Not that I really need the extra speedup (if any) but how could I manually
unroll that loop?
I know you can do things like that in D..
Oh, so you mean you have 60 bools on each line? You can do that with
some templating and string mixin magic:
// declare these at global scope
template Tuple(T...) { alias T Tuple; }
// Generates a tuple of numbers in the range [0, n)
template Range(int n)
{
static if(n == 0)
alias Tuple!() Range;
else
alias Tuple!(Range!(n - 1), n - 1) Range;
}
// then this is your loop in main
foreach(i, line; data)
{
// this foreach loop is run at compile time
foreach(j; Range!(60))
mixin(dataIn[i][ ~ j.stringof ~
] = line[14 + 2 * ~ j.stringof ~ ] == '1';);
}
Re: casting int[] to bool[]
On Thu, Jan 29, 2009 at 2:35 PM, Saaa em...@needmail.com wrote: Most of the std.math functions take reals and when I have a float or a double I always cast them to real to make it fit. Should I instead use to! here as well? You don't have to cast anything actually. floats and doubles are implicitly convertible to real. This isn't Pascal.
Re: casting int[] to bool[]
But then I get stuff like this: value += pow( x, 2); //x=double -- testcase.d(374): function std.math.pow called with argument types: (double,int) matches both: std.math.pow(real x, uint n) and: std.math.pow(real x, int n)
Re: problem with D compiler
Did you set the environment variables? http://www.digitalmars.com/d/1.0/dmd-windows.html
Re: casting int[] to bool[]
This will take some time to understand.
Things I have never used before : D
Tuple, variadic function, template, mixin
.stringof(can't find this one), static if
I'll read up until I understand this.
One question I can ask.
Why is that foreach loop run at compile time?
The compiler checks for a template parameter?
// declare these at global scope
template Tuple(T...) { alias T Tuple; }
// Generates a tuple of numbers in the range [0, n)
template Range(int n)
{
static if(n == 0)
alias Tuple!() Range;
else
alias Tuple!(Range!(n - 1), n - 1) Range;
}
// then this is your loop in main
foreach(i, line; data)
{
// this foreach loop is run at compile time
foreach(j; Range!(60))
mixin(dataIn[i][ ~ j.stringof ~
] = line[14 + 2 * ~ j.stringof ~ ] == '1';);
}
Re: casting int[] to bool[]
Saaa wrote: This will take some time to understand. Things I have never used before : D Tuple, variadic function, template, mixin ..stringof(can't find this one), static if I'll read up until I understand this. One question I can ask. Why is that foreach loop run at compile time? The compiler checks for a template parameter? [snip] Tuples are like arrays that have a fixed length, where each element can be of absolutely any type at all. What this means is that it potentially takes different code to access each element of a tuple. So when you see foreach( i ; Range!(4) ) foo(i); What is actually being generated is this: foo(0); foo(1); foo(2); foo(3); It's not really doing the foreach at compile time, but it is unrolling it. You might think but why doesn't this happen for arrays? Because you can't do THIS with arrays: foreach( i,x ; Tuple!(0, b, 3.0) ) writefln(Element %s == %s,i,x); Which expands to: writefln(Element %s == %s,0,0); writefln(Element %s == %s,1,b); writefln(Element %s == %s,2,3.0); -- Daniel
Re: casting int[] to bool[]
That gives the same error.. only casting x to real works :/ That's because '2' as a literal is both an int and a uint. Try this: value += pow( x, 2u ); -- Daniel
Re: casting int[] to bool[]
Thanks, that makes sense! Tuples are like arrays that have a fixed length, where each element can be of absolutely any type at all. What this means is that it potentially takes different code to access each element of a tuple. So when you see foreach( i ; Range!(4) ) foo(i); What is actually being generated is this: foo(0); foo(1); foo(2); foo(3); It's not really doing the foreach at compile time, but it is unrolling it. You might think but why doesn't this happen for arrays? Because you can't do THIS with arrays: foreach( i,x ; Tuple!(0, b, 3.0) ) writefln(Element %s == %s,i,x); Which expands to: writefln(Element %s == %s,0,0); writefln(Element %s == %s,1,b); writefln(Element %s == %s,2,3.0); -- Daniel
Re: casting int[] to bool[]
On Thu, Jan 29, 2009 at 6:15 PM, Saaa em...@needmail.com wrote: That gives the same error.. only casting x to real works :/ That's more an issue with D's extremely (overly?) strict overload resolution rules. Functions like sin() shouldn't be an issue, since there is only one overload with those. But yes, as far as pow() is concerned, I guess you do have to cast to real. Casting is fine here, don't bother using to!().
Re: casting int[] to bool[]
Jarrett Billingsley wrote
On Thu, Jan 29, 2009 at 6:15 PM, Saaa em...@needmail.com wrote:
That gives the same error.. only casting x to real works :/
That's more an issue with D's extremely (overly?) strict overload
resolution rules. Functions like sin() shouldn't be an issue, since
there is only one overload with those. But yes, as far as pow() is
concerned, I guess you do have to cast to real. Casting is fine here,
don't bother using to!().
This is such a common mistake, and really more of an annoyance, I wonder
if it might be better if pow were switched to a template that called the
actual pow after casting the first argument to real. Often times, one does
not use reals as their variable type, and I seem to recall this kind of
error happens even with literals for both arguments...
Something like:
real pow(T, U)(T t, U u)
{
return _pow(cast(real)t, u);
}
-Steve
Re: casting int[] to bool[]
Good to see it isn't just me doing something stupid :) You may count me among the annoyed. I never use 'real' for anything, so I get those errors a lot. --bb
Re: casting int[] to bool[]
On Thu, Jan 29, 2009 at 8:46 PM, Steven Schveighoffer
schvei...@yahoo.com wrote:
This is such a common mistake, and really more of an annoyance, I wonder
if it might be better if pow were switched to a template that called the
actual pow after casting the first argument to real. Often times, one does
not use reals as their variable type, and I seem to recall this kind of
error happens even with literals for both arguments...
Something like:
real pow(T, U)(T t, U u)
{
return _pow(cast(real)t, u);
}
That's probably how it'd be written in modern D. Most of std.math is
probably 8 years old and pre-templates.
