Re: rdmd problems (OS X Leopard, DMD 2.052)

2011-02-21 Thread Magnus Lie Hetland

On 2011-02-20 22:42:06 +0100, Nick Sabalausky said:

[snip]
We used to have occasional breking changes in the language itself (in 
D2-only), since D2 was the deliberately the development branch rather 
than the stable branch that D1 has been, but D2's language spec is 
pretty much finalized now.




I just realized I didn't give a direct answer to your question: I'd say 
that most minor releases of DMD are *not* backward-incompatible.


Thanks for both the thorough and the more direct answer. Very helpful/useful :)

--
Magnus Lie Hetland
http://hetland.org



Re: Is std.array.replace supposed to work with char[]?

2011-02-21 Thread Lars T. Kyllingstad
On Sun, 20 Feb 2011 15:23:29 -0500, Steven Schveighoffer wrote:

 On Sun, 20 Feb 2011 14:51:10 -0500, bearophile
 bearophileh...@lycos.com wrote:
 
 Jacob Carlborg:

 Every time I try to use D2 it's just a PITA to use. I've used D1 and
 Tango for
 several years and had no problem with that.

 I use this thread to ask regarding one specific little problem I have
 with strings. I want to generate a random string of AB using the array,
 map, etc, this looks like a possible implementation (in std.random
 there is no choice() function yet):


 import std.stdio, std.random, std.string, std.algorithm, std.range;
 void main() {
 auto m = map!((i){ return AB[uniform(0,2)]; })(iota(10)); string
 s = join(array(m));
 writeln(s);
 }


 It gives this error:
 ...\dmd\src\phobos\std\array.d(62): Error: result[i] isn't mutable
 test.d(5): Error: template instance
 std.array.array!(Map!(__dgliteral1,Iota!(int,uint))) error
 instantiating

 What's the right way to write it in D?

 The same code in Python2.x:

 from random import choice
 s = .join(choice(AB) for _ in xrange(10)) print s
 
 Just a blind guess, I have not tested, but maybe it's because the
 compiler is using const(char) as the return type for your delegate
 literal since you never specify one?

It's probably using immutable(char) since that's the element type of AB.

-Lars


Multiple opCall's

2011-02-21 Thread useo
Hey guys,

I've a small problem implementing multiple opCall()-methods. At first, I've the 
following interface:

interface Invoker {
 void opCall(uint i);
}

... and an abstract class which inherits from the Invoker-interface like the 
following:

abstract class AbstractInvoker : Invoker {

 private int myInt;

 override void opCall(uint i) { /** do nothing */ }

 void opCall() {
  opCall(myInt);
 }

}

I know... I can remove the opCall(uint i) from the interface, but it's needed 
for some other classes which implements this method. For
those classes the opCall(uint i)-method is needed.

But... when I now declare a class like this:

class InvokableClass : AbstractInvoker {
 override void opCall(uint i) {
  // do something
 }
}

and do the following:

void main(string[] args) {
 InvokableClass() ic = new InvokeableClass();
 ic();
}

I always get the following errors:

Error: function InvokableClass.opCall (uint i) is not callable using argument 
types ().
Error: expected 1 function arguments, not 0

But I think opCall() is implemented in the abstract class and should be 
callable using opCall() instead using opCall(uint i)?


OpenGL in D2

2011-02-21 Thread Siqu
Hi,
I'm trying to figure out how I could get a simple OpenGL/GLUT program working
in DMD2. As an attachment, I've added a C version of what I'd like to do. I'd
compile the C version using:
gcc simple.c -lglut -lGLU -o simple

I've found a few OpenGL projects, like bindings
(http://www.dsource.org/projects/bindings/) and derelict
(http://www.dsource.org/projects/derelict/), but I still can't find any way to
easily use or install them (for D2 on Ubuntu). I'd have thought that, since D
interfaces so well with C, just using C libraries wouldn't require specific
wrapper libraries, but it seems an automated method for converting C headers
to D isn't currently possible?

Anyway, any help would be appreciated,
Thanks.
begin 644 simple.c
M(VEN8VQU94@/$=,+V=L+F@^B-I;F-L=61E(#Q'3]G;'5T+F@^@IS=%T
M:6,@:6YT('=I;CL*G9O:60@:6YI=AI;G0@87)G8RP@8VAAB`J*F%R9W8I
MGL*(\O(EN:71I86QIF4@9VQU=`H@9VQU=$EN:70H)F%R9V,L(%R9W8I
M.PH@+R\@W!E8VEF2!T:4@9ESQA2!M;V1E('1O()E(%)'0B!A;F0@
MVEN9VQE()U9F9EFEN9R`*(\O('=E('5S92!S:6YG;4@8G5F9F5R:6YG
M('-I;F-E('1H:7,@=VEL;!B92!N;VX@86YI;6%T960*(=L=71);FET1ES
MQA4UO94H1TQ55%]21T)!('P@1TQ55%]324Y'3$4I.PH@+R\@95F:6YE
M('1H92!S:7IEB!G;'5T26YI=%=I;F1O=U-IF4H-3`P+#4P,D[B`O+R!T
M:4@]S:71I;VX@=VAEF4@=AE('=I;F1O=R!W:6QL(%P5A@H@9VQU
M=$EN:717:6YD;W=0;W-I=EO;B@Q,#`L,3`P*3L*(\O(EF('=E('=O=6QD
M('=A;G0@9G5L;'-CF5E;CH*(\O(=L=71=6QL4V-R965N*D[B`O+R!C
MF5A=4@=AE('=I;F1O=RP@V5T('1H92!T:71L92!A;F0@:V5E!T:4@
MB`O+R!W:6YD;W@:61E;G1I9FEEBX*('=I;B`](=L=71#F5A=57:6YD
M;WH(E1I=QE(=O97,@:5R92(I.PH@+R]G;'5T1ESQA49U;F,H9ES
MD[B`O+V=L=71+97EB;V%R9$9U;F,H:V5Y8BD[GT*FEN=!M86EN*EN
M=!AF=C+!C:%R(HJ87)G=BE[B`O+R!I;FET($=,550@=\@:%N9QE
M('=I;F1O=PH@:6YI=AAF=C+%R9W8I.PH*(\O(]P96YG;!C;V1E(AP
M97)F;W)M960@;VYL2!O;B!S=%R='5P*0H@+R\@V5T(-L96%R+6-O;]U
M@H@9VQ#;5AD-O;]R*#`L,PP+#`I.PH@+R\@8VQE87(@9ESQA2!T
M;R!C;5ABUC;VQO=7(*(=L0VQE87(H1TQ?0T],3U)?0E51D527T))5D[
MB`O+R!S970@9')A=RUC;VQO=7(*(=L0V]L;W(S9B@Q+#$L,2D[B`O+R!S
M5C:69Y(-O+6]R9EN871E('-YW1E;2`H;6%PEN9R!I;6%G92!T;R!S
M8W)E96XIB!G;$]R=AO*TQ+`Q+TQ+`Q+TQ+`Q*3L*(\O()E9VEN
M(1E9FEN:6YG($@;F5W(]B:F5C=`H]L6=O;BD*(=L0F5G:6XH1TQ?
M4$],64=/3BD[B`@+R\@95F:6YE('!O;'EG;VXGR!C;W)N97)S(@IB`@
M9VQ697)T97@R9B@M,XU+`M,XU*3L*(!G;%9EG1E#)F*TP+C4L(#`N
M-2D[B`@9VQ697)T97@R9B@P+C4L(#`N-2D[B`@9VQ697)T97@R9B@P+C4L
M(TP+C4I.PH@+R\@96YD(1E9FEN:6YG(]B:F5C=`H@9VQ%;F0H*3L*(\O
M(]U='!U=!C;VUM86YDR!T;R!S8W)E96X*(=L1FQUV@H*3L*B`O+R!U
MV4@1TQ55!T;R!R=6X@;6%I;B!L;V]PB!G;'5T36%I;DQO;W`H*3L*(')E
*='5R;B`P.PI]@``
`
end


Re: OpenGL in D2

2011-02-21 Thread Nrgyzer
== Auszug aus Siqu (u...@example.net)'s Artikel
 Hi,
 I'm trying to figure out how I could get a simple OpenGL/GLUT
program working
 in DMD2. As an attachment, I've added a C version of what I'd like
to do. I'd
 compile the C version using:
 gcc simple.c -lglut -lGLU -o simple
 I've found a few OpenGL projects, like bindings
 (http://www.dsource.org/projects/bindings/) and derelict
 (http://www.dsource.org/projects/derelict/), but I still can't find
any way to
 easily use or install them (for D2 on Ubuntu). I'd have thought
that, since D
 interfaces so well with C, just using C libraries wouldn't require
specific
 wrapper libraries, but it seems an automated method for converting
C headers
 to D isn't currently possible?
 Anyway, any help would be appreciated,
 Thanks.
   simple.c 

I'm using derelict, primary on windows, but I've also a running
version on Ubuntu.
You can download derelict at http://www.dsource.org/projects/derelict/
changeset/525/branches/Derelict2?old_path=%2Fformat=zip

I think you've already a running version of the dmd-compiler? If yes,
you can simply extract the package, open your shell browse to the
extracted folder and run make -flinux.mak DC=dmd which worked for
me on windows and linux (make sure you've installed make and dmd is
in your environment-values). On windows you've to create a folder
called lib before you run the command above - I currently can't say
it exactly if it's needed on linux, too.
After it compiled, you can copy all the created lib-files to the lib-
folder (I think this should be /usr/lib or something like this - run
find / -name 'phobos.lib' and copy the lib-files to the same
directory where phobos.lib is located. Copy the content of the
import-dir to a location where you've all your binding for D, so
that you can simply use import derelict.sdl.sdl or similar.

When you've installed it correctly, you can use derelict/opengl like
described on the derelict site. Note that you have to use 'pragma
(lib, DerelictSDL)' or similar to use the binding. It is also
important the you insert 'pragma(lib, dl)' in you source that you
can compile it successfully.

I hope this helped :)


Re: Multiple opCall's

2011-02-21 Thread Mafi

Am 21.02.2011 11:18, schrieb useo:

Hey guys,

I've a small problem implementing multiple opCall()-methods. At first, I've the 
following interface:

interface Invoker {
  void opCall(uint i);
}

... and an abstract class which inherits from the Invoker-interface like the 
following:

abstract class AbstractInvoker : Invoker {

  private int myInt;

  override void opCall(uint i) { /** do nothing */ }


In an abstract class you can just leave this out. The inheriting class 
will then be checked to implement this.




  void opCall() {
   opCall(myInt);
  }

}

I know... I can remove the opCall(uint i) from the interface, but it's needed 
for some other classes which implements this method. For
those classes the opCall(uint i)-method is needed.

But... when I now declare a class like this:

class InvokableClass : AbstractInvoker {
  override void opCall(uint i) {
   // do something
  }
}

and do the following:

void main(string[] args) {
  InvokableClass() ic = new InvokeableClass();
  ic();
}

I always get the following errors:

Error: function InvokableClass.opCall (uint i) is not callable using argument 
types ().
Error: expected 1 function arguments, not 0

But I think opCall() is implemented in the abstract class and should be 
callable using opCall() instead using opCall(uint i)?


Overriding one opCall shadows all other opCalls inherited from the base 
class. This behaviour is like with any method. Write:


override void opCall() {
super.opCall();
}

to forward to the base class method.
AFAIK it's an anti-hijacking machanism.


Re: Multiple opCall's

2011-02-21 Thread useo
== Auszug aus Mafi (m...@example.org)'s Artikel
 Am 21.02.2011 11:18, schrieb useo:
  Hey guys,
 
  I've a small problem implementing multiple opCall()-methods. At
first, I've the following interface:
 
  interface Invoker {
void opCall(uint i);
  }
 
  ... and an abstract class which inherits from the Invoker-
interface like the following:
 
  abstract class AbstractInvoker : Invoker {
 
private int myInt;
 
override void opCall(uint i) { /** do nothing */ }
 In an abstract class you can just leave this out. The inheriting
class
 will then be checked to implement this.
 
void opCall() {
 opCall(myInt);
}
 
  }
 
  I know... I can remove the opCall(uint i) from the interface, but
it's needed for some other classes which implements this method. For
  those classes the opCall(uint i)-method is needed.
 
  But... when I now declare a class like this:
 
  class InvokableClass : AbstractInvoker {
override void opCall(uint i) {
 // do something
}
  }
 
  and do the following:
 
  void main(string[] args) {
InvokableClass() ic = new InvokeableClass();
ic();
  }
 
  I always get the following errors:
 
  Error: function InvokableClass.opCall (uint i) is not callable
using argument types ().
  Error: expected 1 function arguments, not 0
 
  But I think opCall() is implemented in the abstract class and
should be callable using opCall() instead using opCall(uint i)?
 Overriding one opCall shadows all other opCalls inherited from the
base
 class. This behaviour is like with any method. Write:
 override void opCall() {
   super.opCall();
 }
 to forward to the base class method.
 AFAIK it's an anti-hijacking machanism.

Okay, thanks... this helped a lot!


Re: rdmd problems (OS X Leopard, DMD 2.052)

2011-02-21 Thread Magnus Lie Hetland

On 2011-02-20 19:22:20 +0100, Magnus Lie Hetland said:


On 2011-02-19 22:25:31 +0100, Nick Sabalausky said:

[snip]
Unfortunately, rdmd doesn't seem to have gotten much attention lately. 
I've had a few patches for it sitting in bugzilla for a number of 
months. (Not that I'm complaning, I realize there's been other 
priorities.)


I see. Kind of surprising, given that rdmd is distributed in the 
official DMD zip file. But, yeah, no complaints. :)


Actually, if you want, you can grab a version of rdmd.d with my patches 
applied here:

http://www.dsource.org/projects/semitwist/browser/trunk/rdmdAlt.d


Thanks!


Humm. I'm still using the rdmd I had (it seems to work, so as long as I 
have already compiled it... ;)


However: I'm a bit baffled by the --shebang option. What's its purpose, 
really? If I use rdmd without it in a shebang line, it seems to work 
fine. If I *do* use --shebang, the code doesn't seem to be 
compiled/executed at all...


It seems like it interprets args[1] as a single string containing all 
the arguments, splitting it into separate items. That seems well an 
good -- except (in OS X, at least) it doesn't seem to be needed (I get 
my arguments just fine without it, and the shebang-line switches work 
well) ... and it doesn't seem to work (that is, with --shebang, nothing 
happens).


Any thoughts on this?

--
Magnus Lie Hetland
http://hetland.org



Re: OpenGL in D2

2011-02-21 Thread Dmitry Olshansky

On 21.02.2011 13:33, Siqu wrote:

Hi,
I'm trying to figure out how I could get a simple OpenGL/GLUT program working
in DMD2. As an attachment, I've added a C version of what I'd like to do. I'd
compile the C version using:
gcc simple.c -lglut -lGLU -o simple

I've found a few OpenGL projects, like bindings
(http://www.dsource.org/projects/bindings/) and derelict
(http://www.dsource.org/projects/derelict/), but I still can't find any way to
easily use or install them (for D2 on Ubuntu). I'd have thought that, since D
interfaces so well with C, just using C libraries wouldn't require specific
wrapper libraries, but it seems an automated method for converting C headers
to D isn't currently possible?


There is htod tool in the digitalmars website, but it's windows only. 
Also it still leaves much to be desired.
IMHO Derelict is so far the best way to OpenGL and such in D, because of 
the nice way it loads  handles all these weirdness with loading, say, 
OpenGL extensions. And automatically picking up any suitable shared lib 
is big win.



Anyway, any help would be appreciated,
Thanks.


Sadly your file goes like rubbish for me, is that base64 ?


--

Dmitry Olshansky



Re: OpenGL in D2

2011-02-21 Thread Denis Koroskin
On Mon, 21 Feb 2011 14:45:51 +0300, Dmitry Olshansky  
dmitry.o...@gmail.com wrote:



On 21.02.2011 13:33, Siqu wrote:

Hi,
I'm trying to figure out how I could get a simple OpenGL/GLUT program  
working
in DMD2. As an attachment, I've added a C version of what I'd like to  
do. I'd

compile the C version using:
gcc simple.c -lglut -lGLU -o simple

I've found a few OpenGL projects, like bindings
(http://www.dsource.org/projects/bindings/) and derelict
(http://www.dsource.org/projects/derelict/), but I still can't find any  
way to
easily use or install them (for D2 on Ubuntu). I'd have thought that,  
since D
interfaces so well with C, just using C libraries wouldn't require  
specific
wrapper libraries, but it seems an automated method for converting C  
headers

to D isn't currently possible?


There is htod tool in the digitalmars website, but it's windows only.  
Also it still leaves much to be desired.
IMHO Derelict is so far the best way to OpenGL and such in D, because of  
the nice way it loads  handles all these weirdness with loading, say,  
OpenGL extensions. And automatically picking up any suitable shared lib  
is big win.



Anyway, any help would be appreciated,
Thanks.


Sadly your file goes like rubbish for me, is that base64 ?




All attachments are encoded, but your client should be able to decode it  
without any issues.
Try other software, I recommend Opera's built-in mail client (which  
features NTTP support).


Re: Multiple opCall's

2011-02-21 Thread Jonathan M Davis
On Monday 21 February 2011 02:47:03 Mafi wrote:
 Am 21.02.2011 11:18, schrieb useo:
  Hey guys,
  
  I've a small problem implementing multiple opCall()-methods. At first,
  I've the following interface:
  
  interface Invoker {
  
void opCall(uint i);
  
  }
  
  ... and an abstract class which inherits from the Invoker-interface like
  the following:
  
  abstract class AbstractInvoker : Invoker {
  
private int myInt;

override void opCall(uint i) { /** do nothing */ }
 
 In an abstract class you can just leave this out. The inheriting class
 will then be checked to implement this.
 
void opCall() {

 opCall(myInt);

}
  
  }
  
  I know... I can remove the opCall(uint i) from the interface, but it's
  needed for some other classes which implements this method. For those
  classes the opCall(uint i)-method is needed.
  
  But... when I now declare a class like this:
  
  class InvokableClass : AbstractInvoker {
  
override void opCall(uint i) {

 // do something

}
  
  }
  
  and do the following:
  
  void main(string[] args) {
  
InvokableClass() ic = new InvokeableClass();
ic();
  
  }
  
  I always get the following errors:
  
  Error: function InvokableClass.opCall (uint i) is not callable using
  argument types (). Error: expected 1 function arguments, not 0
  
  But I think opCall() is implemented in the abstract class and should be
  callable using opCall() instead using opCall(uint i)?
 
 Overriding one opCall shadows all other opCalls inherited from the base
 class. This behaviour is like with any method. Write:
 
 override void opCall() {
   super.opCall();
 }
 
 to forward to the base class method.
 AFAIK it's an anti-hijacking machanism.

Or you can use alias. Inside of Invokable class, put

alias AbstractInvokableClass.opCall opCall;

That should put all of AbstractInvokableClass' in the overload set for 
InvokableClass.

- Jonathan M Davis


Re: rdmd problems (OS X Leopard, DMD 2.052)

2011-02-21 Thread Lars T. Kyllingstad
On Mon, 21 Feb 2011 12:18:54 +0100, Magnus Lie Hetland wrote:

 On 2011-02-20 19:22:20 +0100, Magnus Lie Hetland said:
 
 On 2011-02-19 22:25:31 +0100, Nick Sabalausky said:
 
 [snip]
 Unfortunately, rdmd doesn't seem to have gotten much attention lately.
 I've had a few patches for it sitting in bugzilla for a number of
 months. (Not that I'm complaning, I realize there's been other
 priorities.)
 
 I see. Kind of surprising, given that rdmd is distributed in the
 official DMD zip file. But, yeah, no complaints. :)
 
 Actually, if you want, you can grab a version of rdmd.d with my
 patches applied here:
 http://www.dsource.org/projects/semitwist/browser/trunk/rdmdAlt.d
 
 Thanks!
 
 Humm. I'm still using the rdmd I had (it seems to work, so as long as I
 have already compiled it... ;)
 
 However: I'm a bit baffled by the --shebang option. What's its purpose,
 really? If I use rdmd without it in a shebang line, it seems to work
 fine. If I *do* use --shebang, the code doesn't seem to be
 compiled/executed at all...
 
 It seems like it interprets args[1] as a single string containing all
 the arguments, splitting it into separate items. That seems well an good
 -- except (in OS X, at least) it doesn't seem to be needed (I get my
 arguments just fine without it, and the shebang-line switches work well)
 ... and it doesn't seem to work (that is, with --shebang, nothing
 happens).
 
 Any thoughts on this?

Say you have a file myscript, that starts with the line

#!/path/to/interpreter --foo --bar

If you run this as

./myscript --hello --world

then the args[] received by the interpreter program looks like this:

args[0] = /path/to/interpreter
args[1] = --foo --bar
args[2] = ./myscript
args[3] = --hello
args[4] = --world

This is the case on every shell I've tried on Linux, at least.  So if you 
have multiple rdmd options, it should in principle need --shebang to know 
that it is being run in a shebang line, so it can expand args[1].

I don't know why it works without --shebang for you, though. :)

-Lars


Re: OpenGL in D2

2011-02-21 Thread Trass3r
 I've found a few OpenGL projects, like bindings
 (http://www.dsource.org/projects/bindings/) and derelict
 (http://www.dsource.org/projects/derelict/), but I still can't find any way to
 easily use or install them (for D2 on Ubuntu).

Use derelict2 from svn and xfBuild. Then you just need to tell dmd where 
derelict is via -I


 I'd have thought that, since D
 interfaces so well with C, just using C libraries wouldn't require specific
 wrapper libraries, but it seems an automated method for converting C headers
 to D isn't currently possible?

Derelict does a lot more, it hides all the nasty handling of different OpenGL 
versions that might be installed along with extension loading.

To my knowledge there are several tools to convert C headers to D import 
modules:
- htod, which is crappy. Since it's based on dmc, it nearly always complains 
about header files and the like; it doesn't translate preprocessor conditional 
compilation to versions or static if and almost always messes something up 
(const or whatever, can't remember)
- SWIG, which I haven't tried yet for that purpose. But I think it will have 
the same problem with preprocessor conditional compilation.
- c2d, don't know how good it works: 
http://dsource.org/projects/visuald/browser/trunk/c2d
- bcd, which is obviously abandoned: http://www.dsource.org/projects/bcd


Re: rdmd problems (OS X Leopard, DMD 2.052)

2011-02-21 Thread Jacob Carlborg

On 2011-02-21 14:16, Lars T. Kyllingstad wrote:

On Mon, 21 Feb 2011 12:18:54 +0100, Magnus Lie Hetland wrote:


On 2011-02-20 19:22:20 +0100, Magnus Lie Hetland said:


On 2011-02-19 22:25:31 +0100, Nick Sabalausky said:

[snip]

Unfortunately, rdmd doesn't seem to have gotten much attention lately.
I've had a few patches for it sitting in bugzilla for a number of
months. (Not that I'm complaning, I realize there's been other
priorities.)


I see. Kind of surprising, given that rdmd is distributed in the
official DMD zip file. But, yeah, no complaints. :)


Actually, if you want, you can grab a version of rdmd.d with my
patches applied here:
http://www.dsource.org/projects/semitwist/browser/trunk/rdmdAlt.d


Thanks!


Humm. I'm still using the rdmd I had (it seems to work, so as long as I
have already compiled it... ;)

However: I'm a bit baffled by the --shebang option. What's its purpose,
really? If I use rdmd without it in a shebang line, it seems to work
fine. If I *do* use --shebang, the code doesn't seem to be
compiled/executed at all...

It seems like it interprets args[1] as a single string containing all
the arguments, splitting it into separate items. That seems well an good
-- except (in OS X, at least) it doesn't seem to be needed (I get my
arguments just fine without it, and the shebang-line switches work well)
... and it doesn't seem to work (that is, with --shebang, nothing
happens).

Any thoughts on this?


Say you have a file myscript, that starts with the line

 #!/path/to/interpreter --foo --bar

If you run this as

 ./myscript --hello --world

then the args[] received by the interpreter program looks like this:

 args[0] = /path/to/interpreter
 args[1] = --foo --bar
 args[2] = ./myscript
 args[3] = --hello
 args[4] = --world

This is the case on every shell I've tried on Linux, at least.  So if you
have multiple rdmd options, it should in principle need --shebang to know
that it is being run in a shebang line, so it can expand args[1].

I don't know why it works without --shebang for you, though. :)

-Lars


Perhaps he's not passing any arguments to rdmd.

--
/Jacob Carlborg


Re: datetime fails with undefined reference

2011-02-21 Thread Kai Meyer
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
 On Friday, February 18, 2011 16:27:23 Russel Winder wrote:
  As noted in my earlier email on the other list, I too got this problem.
  Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is
  no such thing in the 1.067 and 2.052 distributions.  So the out of the
  box configuration does seem to be broken.
 And as I said in my response to your other message, the proper dmd.conf file 
 _is_
 in the distributed zip file. So, unless you're dealing with the deb or rpm, 
 and
 they're broken, and I don't know why you wouldn't be seeing a new dmd.conf 
 with
 the 2.052 release. But I don't know what the state of the rpm or deb is. I 
 just
 always use the zip file, which is very simple.
 - Jonathan M Davis

Ok, I can fix the dmd.conf. Who does manage the RPM packaging? And how can I 
get a
hold of them?


Re: Can I parametrize template mixin's identifiers?

2011-02-21 Thread Nick

On 2/19/2011 10:46 PM, Lutger Blijdestijn wrote:

Nick wrote:


I know I can parametrize template mixin types, but how about mixin
identifiers? This is the code:



mixin template Box(T) {
T val;
}

class Set(A, B) {
mixin Box!A a;
mixin Box!B b;
}

alias Set!(int, int) IntSet;

int main(string[] argv) {
scope auto s = new IntSet();
s.a.val = 3;
}



As you can see, the A and B types can be changed and with them the boxed
values. But they need disambiguation, since they have identically named
members. I know only to hard-code that disambiguation.

I need this because I intend to change (A, B) with a type list
eventually and I need to make operations on the boxed types independent
on the template mixin  identifiers (a, b).

This pattern comes from C++ code, where Box(T) would be classes, Set (A,
B, ...) would recursively apply multiple inheritance on the type list.
Then each Box members could be addressed by casting to the correct Box(T).

Any idea if this is possible in D?

Thanks!


Possible yes, but probably not so pretty. There must be some places in
phobos where something like this is done (better), perhaps in the code for
tuples in std.typecons. Here is my unpolished attempt:

mixin template Box(T)
{
 T val;
}

mixin template MixinFields(P...)
{
 /* P[0] is the template to use as mixin
  * P[1] is the type to be use as parameter for P[0]
  * P[2] is the symbol name the mixin will be aliased to
  */
 mixin(mixin  ~ __traits(identifier, P[0]) ~ !( ~ P[1].stringof ~ )
~ P[2] ~ ;);
 static if(P.length  3)
 mixin MixinFields!(P[0], P[3..$]);
}


class Set(T...)
{
 mixin MixinFields!(Box, T);
}

alias Set!(int, a, int, b) IntSet;

void main()
{
 scope auto s = new IntSet();
 s.a.val = 3;
}


Thanks!

I was staying away from string mixins as they seem (although powerful) 
rather difficult to grok. But if I must, I must...


dmd2 assertion failure when comparing pointers

2011-02-21 Thread Matthias Pleh
Maybe a little stupid, but I get an assert when I try to compare a valid 
pointer with an int casted pointer.
I know, I could compare the pointer itself, but shouldn't is-poerator 
also work?

Also, shouldn't an assert always reproted as a bug?


struct Test {}

void main()
{
Test t,t2;
bool a = t is t2; // - works!
bool b = cast(Test*)1 is t;
// - Assertion failure: '0' on line 875 in file 'constfold.c'
}

greets
Matthias


Re: dmd2 assertion failure when comparing pointers

2011-02-21 Thread bearophile
Matthias Pleh:

 Also, shouldn't an assert always reproted as a bug?

Added:
http://d.puremagic.com/issues/show_bug.cgi?id=5633

Bye,
bearophile


Re: Are function pointers compile time constants?

2011-02-21 Thread Simon

On 21/02/2011 00:24, Steven Schveighoffer wrote:

On Sun, 20 Feb 2011 16:23:14 -0500, Nick Sabalausky a@a.a wrote:


Simon s.d.hamm...@gmail.com wrote in message
news:ijrdif$1nn6$1...@digitalmars.com...

On 20/02/2011 14:59, d coder wrote:

Greetings

I tried to initialize a struct member with a function pointer, and
found that DMD2 did not like it. Are not function pointers compile
time constants? And why they should not be?

Regards
- Cherry


No a function doesn't have an address until the .exe is loaded into
memory. And with Address space randomisation on 'doze there is no
reasonable way to make a function pointer a compile time value.



I didn't know Windows did that, I thought it was just certain versions of
Unix/Linux. Do you happen to know which version of Windows was first
to have
it?


Probably the first one with dlls? I don't see how else you could have
dlls, because you can't just say this function will always be at
address 12345, and no other function anyone else ever compiles can take
that spot.


Vista. For any particular exe, you'll find that it's dependant dlls 
alway get loaded in the same place. That's why buffer overflow bugs 
(where/are) so easy to exploit.




That being said, I'm not sure why the OP's issue couldn't be solved --
clearly position independent code works (and that is statically
created), why couldn't a reference to that function also be created in a
struct initializer? Is it a limitation of the linker?

-Steve


You can't use the relative jump of POS code.
The offset to the function will be different at each call site.

You could make function pointers compile time constants if:

You disallow ASR
You disallow them when compiling to a dll
You disallow in-lining of any function of which you take the address
You disallow the linker from rearranging functions
You disallow the linker from merging duplicate functions.
You merge the compiler and linker

And it wouldn't work with template functions anyway as you can get 
multiple copies of those.


That's a lot of stuff to give up.

--
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk


Re: dmd2 assertion failure when comparing pointers

2011-02-21 Thread Matthias Pleh

Am 21.02.2011 19:00, schrieb bearophile:

Matthias Pleh:


Also, shouldn't an assert always reproted as a bug?


Added:
http://d.puremagic.com/issues/show_bug.cgi?id=5633

Bye,
bearophile


Ah, thanks!


Re: datetime fails with undefined reference

2011-02-21 Thread Jonathan M Davis
On Monday 21 February 2011 08:40:38 Kai Meyer wrote:
 == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
 
  On Friday, February 18, 2011 16:27:23 Russel Winder wrote:
   As noted in my earlier email on the other list, I too got this problem.
   Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is
   no such thing in the 1.067 and 2.052 distributions.  So the out of the
   box configuration does seem to be broken.
  
  And as I said in my response to your other message, the proper dmd.conf
  file _is_ in the distributed zip file. So, unless you're dealing with
  the deb or rpm, and they're broken, and I don't know why you wouldn't be
  seeing a new dmd.conf with the 2.052 release. But I don't know what the
  state of the rpm or deb is. I just always use the zip file, which is
  very simple.
  - Jonathan M Davis
 
 Ok, I can fix the dmd.conf. Who does manage the RPM packaging? And how can
 I get a hold of them?

I'm not sure who deals with the RPM stuff (though looking at the download on 
the 
site, the rpm hasn't been updated 2.052 - it's still on 2.051). If it's broken, 
post on the dmd 1.067 and 2.052 release thread in D.announce, since that's 
where people are generally looking for info on the release. If you haven't 
registered with the announce list, then you can just start a thread on it in 
the 
main D list. That's the place that the most people will notice and where you're 
most likely to get the attention of whoever it is needs to know (which may be 
Walter, but I don't know).

However, I _would_ point out that it's extremely easy to just the zip file. 
I've 
never bothered with the rpm, personally. So, while the rpm should definitely 
should be fixed, if all you're really looking to do is have a working dmd, 
using 
the zip is likely a good option. You just download it and unzip it to wherever 
you want it (e.g. your home folder) and then add the path to the linux/bin 
folder within it (e.g. ~/dmd2/linux/bin) to your PATH variable (presumably in  
your .bashrc), and it then it'll work just fine. It'll grab phobos from the 
right 
place and the dmd.conf will be correct. Every time that a new version is 
released, you just replace the dmd2 folder with the newly unzipped version, and 
it works.

- Jonathan M Davis