• Jeremy Gibson (12/12) Apr 05 2006 I've been dabbling around with D source code for a while, but never actu...
• Regan Heath (5/21) Apr 05 2006 If you post a cut-down (yet complete) code example that exhibits the
• Jeremy Gibson (12/15) Apr 05 2006 Okay. ;-)
• kris (4/31) Apr 05 2006 I'd say you've somehow got a broken installation? Sounds like the
• John Demme (7/30) Apr 05 2006 Sounds like the compiler doesn't know where to look for the library sour...
• Jeremy Gibson (17/22) Apr 05 2006 To install the compiler, I extracted both dmd.zip and dmc.zip into my C:...
• Regan Heath (4/32) Apr 05 2006 Can you post the exact output of the compile.
• Regan Heath (5/45) Apr 05 2006 I ask because I wanted to see if there were any clues in the
• Jeremy Gibson (13/15) Apr 05 2006 Pretty much exactly similar to the first post on the thread, but I'll in...
• Jeremy Gibson (5/7) Apr 05 2006 Still nothing. Same errors through and through.
• Jeremy Gibson (11/11) Apr 05 2006 Found the problem, and it was completely irrelevant to everything -- I h...
• Regan Heath (9/25) Apr 06 2006 Ahh, of course. Yeah, at least one other person has had this exact same ...
• Don Clugston (2/32) Apr 06 2006 Definitely. He got an internal compiler error!
• Sean Kelly (6/34) Apr 06 2006 For what it's worth, I've run into this with Ares before. DMD requires
• James Dunne (13/56) Apr 06 2006 DMD's phobos should rename the object module class to something
• Hasan Aljudy (4/59) Apr 06 2006 I think it should just go into std package, making it std.object
• Chris Nicholson-Sauls (8/72) Apr 07 2006 I'm all for this solution, for two reasons. Reason 1, I've personally h...
• Justin C Calvarese (9/38) Apr 07 2006 I asked Walter to put object into std.object a long time ago. I don't

Jeremy Gibson <jtgibson telus net> <Jeremy_member pathlink.com> writes:

I've been dabbling around with D source code for a while, but never actually
tried to compile anything just yet.  I finally got around to compiling one of my
projects, and run into this error on the very first class definition I have (if
I comment out any class with /+ +/, it always occurs on the very next class
definition in the file):

data.d(45): identifier 'Object' is not defined
data.d(45): Object is used as a type

What's worse, however, is that the compiler is encountering an assertion
failure:

Assertion failure: 'b->type->ty == Tclass' on line 284 in file 'class.c'

..which leads me to believe that the dmd compiler itself is flaking out.

Any insights?

"Regan Heath" <regan netwin.co.nz> writes:

On Thu, 6 Apr 2006 04:48:07 +0000 (UTC), Jeremy Gibson <jtgibson telus net  
Jeremy_member pathlink.com> wrote:
 I've been dabbling around with D source code for a while, but never  
 actually
 tried to compile anything just yet.  I finally got around to compiling  
 one of my
 projects, and run into this error on the very first class definition I  
 have (if
 I comment out any class with /+ +/, it always occurs on the very next  
 class
 definition in the file):

 data.d(45): identifier 'Object' is not defined
 data.d(45): Object is used as a type

 What's worse, however, is that the compiler is encountering an assertion
 failure:

 Assertion failure: 'b->type->ty == Tclass' on line 284 in file 'class.c'

 ..which leads me to believe that the dmd compiler itself is flaking out.

 Any insights?

If you post a cut-down (yet complete) code example that exhibits the  
problem you'll get a faster response :)

Regan

Jeremy Gibson <jtgibson telus net> <Jeremy_member pathlink.com> writes:

If you post a cut-down (yet complete) code example that exhibits the  
problem you'll get a faster response :)

Regan

Okay. ;-)


/*******************************************************************************
TEST FILE - test.d
*******************************************************************************/

module test;

class MyClass
{

}


int main()
{
return 0;
}

kris <foo bar.com> writes:

Jeremy Gibson <jtgibson telus net> wrote:
If you post a cut-down (yet complete) code example that exhibits the  
problem you'll get a faster response :)

Regan

 
 
 Okay. ;-)
 
 
 /*******************************************************************************
 TEST FILE - test.d
 *******************************************************************************/
 
 module test;
 
 class MyClass
 {
 
 }
 
 
 int main()
 {
 return 0;
 }
 
 


I'd say you've somehow got a broken installation? Sounds like the 
compiler cannot find the default -I path (usually pointing to 
dmd/src/phobos)

John Demme <me teqdruid.com> writes:

Jeremy Gibson wrote:

If you post a cut-down (yet complete) code example that exhibits the
problem you'll get a faster response :)

Regan

 
 Okay. ;-)
 
 
 /*******************************************************************************
 TEST FILE - test.d

*******************************************************************************/
 
 module test;
 
 class MyClass
 {
 
 }
 
 
 int main()
 {
 return 0;
 }

Sounds like the compiler doesn't know where to look for the library source
code.  After you extract dmd.zip, you have to edit (dmd.conf on unix
sc.ini) on windows and give DMD the directory where the phobos library
source is (it comes with the compiler).

~John Demme

Jeremy Gibson <jtgibson telus net> <Jeremy_member pathlink.com> writes:

Sounds like the compiler doesn't know where to look for the library source
code.  After you extract dmd.zip, you have to edit (dmd.conf on unix
sc.ini) on windows and give DMD the directory where the phobos library
source is (it comes with the compiler).

~John Demme


To install the compiler, I extracted both dmd.zip and dmc.zip into my C:\dev
folder, such that the defaults should have worked just fine, assuming the % P%
evaluates correctly to the path to the current file as it's supposed to.

Since I didn't trust that completely, though, I just manually set the paths to
the following, replacing the relative paths with absolute paths, in order to
match up to the extracted paths precisely:

<sc.ini>

[Version]
version=7.51 Build 020

[Environment]
LIB="C:\dev\dmd\lib;C:\dev\dm\lib"
DFLAGS="-I C:\dev\dmd\src\phobos"
LINKCMD="C:\dev\dm\bin\link.exe"


..But I still have no luck -- the same errors are being thrown on compilation.
I just tried redownloading the compiler, also with no luck.

Maybe it just hates me? ;-)

--JT

"Regan Heath" <regan netwin.co.nz> writes:

On Thu, 6 Apr 2006 05:35:16 +0000 (UTC), Jeremy Gibson <jtgibson telus net  
Jeremy_member pathlink.com> wrote:
 Sounds like the compiler doesn't know where to look for the library  
 source
 code.  After you extract dmd.zip, you have to edit (dmd.conf on unix
 sc.ini) on windows and give DMD the directory where the phobos library
 source is (it comes with the compiler).

 ~John Demme


 To install the compiler, I extracted both dmd.zip and dmc.zip into my  
 C:\dev
 folder, such that the defaults should have worked just fine, assuming  
 the % P%
 evaluates correctly to the path to the current file as it's supposed to.

 Since I didn't trust that completely, though, I just manually set the  
 paths to
 the following, replacing the relative paths with absolute paths, in  
 order to
 match up to the extracted paths precisely:

 <sc.ini>

 [Version]
 version=7.51 Build 020

 [Environment]
 LIB="C:\dev\dmd\lib;C:\dev\dm\lib"
 DFLAGS="-I C:\dev\dmd\src\phobos"
 LINKCMD="C:\dev\dm\bin\link.exe"


 ..But I still have no luck -- the same errors are being thrown on  
 compilation.
 I just tried redownloading the compiler, also with no luck.

 Maybe it just hates me? ;-)

Can you post the exact output of the compile.

Regan

"Regan Heath" <regan netwin.co.nz> writes:

On Thu, 06 Apr 2006 17:38:42 +1200, Regan Heath <regan netwin.co.nz> wrote:
 On Thu, 6 Apr 2006 05:35:16 +0000 (UTC), Jeremy Gibson <jtgibson telus  
 net Jeremy_member pathlink.com> wrote:
 Sounds like the compiler doesn't know where to look for the library  
 source
 code.  After you extract dmd.zip, you have to edit (dmd.conf on unix
 sc.ini) on windows and give DMD the directory where the phobos library
 source is (it comes with the compiler).

 ~John Demme


 To install the compiler, I extracted both dmd.zip and dmc.zip into my  
 C:\dev
 folder, such that the defaults should have worked just fine, assuming  
 the % P%
 evaluates correctly to the path to the current file as it's supposed to.

 Since I didn't trust that completely, though, I just manually set the  
 paths to
 the following, replacing the relative paths with absolute paths, in  
 order to
 match up to the extracted paths precisely:

 <sc.ini>

 [Version]
 version=7.51 Build 020

 [Environment]
 LIB="C:\dev\dmd\lib;C:\dev\dm\lib"
 DFLAGS="-I C:\dev\dmd\src\phobos"
 LINKCMD="C:\dev\dm\bin\link.exe"


 ..But I still have no luck -- the same errors are being thrown on  
 compilation.
 I just tried redownloading the compiler, also with no luck.

 Maybe it just hates me? ;-)

 Can you post the exact output of the compile.

I ask because I wanted to see if there were any clues in the  
compiler/linker output that might suggest something.

Have you added "C:\dev\dmd\bin" to your PATH?

Regan

Jeremy Gibson <jtgibson telus net> <Jeremy_member pathlink.com> writes:

Can you post the exact output of the compile.

Regan

Pretty much exactly similar to the first post on the thread, but I'll include
the command prompt and omit my witty banter for clarity.

"
C:\Documents and Settings\JT\My Documents\Programming\Alliance>dmd test.d -debug
test.d(8): identifier 'Object' is not defined
test.d(8): Object is used as a type
Assertion failure: 'b->type->ty == Tclass' on line 286 in file 'class.c'

abnormal program termination

C:\Documents and Settings\JT\My Documents\Programming\Alliance>
"


I'm going to try adding those directories directly to my system's PATH
environment variable and see if that'll help...

--JT

Jeremy Gibson <jtgibson telus net> <Jeremy_member pathlink.com> writes:

I'm going to try adding those directories directly to my system's PATH
environment variable and see if that'll help...

Still nothing.  Same errors through and through.

(I had actually added C:\dev\dmd\bin to my path a long time ago -- I needed it
in my path to be able to use the command-line compiler from my project folder,
after all.)

--JT

Jeremy Gibson <jtgibson telus net> <Jeremy_member pathlink.com> writes:

Found the problem, and it was completely irrelevant to everything -- I had all
of the environment variables set up correctly right from the very beginning.

The problem?  The object.d file in my project folder was overriding object.d in
the Phobos directory.  I renamed it to "gameobject.d" and everything works
peachy-keen now.

(I noticed this because after I uncommented some code in object.d, I started
getting some errors in that file while I tried to compile the file test.d (which
I posted) in the same folder.  test.d does not import object.d at all, so
something had to be automatically importing it.  That's when it clicked.)

This kind of name clash should probably be documented... =)

--JT

"Regan Heath" <regan netwin.co.nz> writes:

On Thu, 6 Apr 2006 06:10:30 +0000 (UTC), Jeremy Gibson <jtgibson telus net  
Jeremy_member pathlink.com> wrote:
 Found the problem, and it was completely irrelevant to everything -- I  
 had all
 of the environment variables set up correctly right from the very  
 beginning.

 The problem?  The object.d file in my project folder was overriding  
 object.d in
 the Phobos directory.  I renamed it to "gameobject.d" and everything  
 works
 peachy-keen now.

 (I noticed this because after I uncommented some code in object.d, I  
 started
 getting some errors in that file while I tried to compile the file  
 test.d (which
 I posted) in the same folder.  test.d does not import object.d at all, so
 something had to be automatically importing it.  That's when it clicked.)

 This kind of name clash should probably be documented... =)

Ahh, of course. Yeah, at least one other person has had this exact same  
problem.

At the very least it should be documented. The compiler could error on  
compiling object.d, and/or refuse to create an object.o and/or refuse to  
link/see any object.o which is not in the main directory.

(cross posted to bugs, not sure if it needs a bugzilla entry?)

Regan

Don Clugston <dac nospam.com.au> writes:

Regan Heath wrote:
 On Thu, 6 Apr 2006 06:10:30 +0000 (UTC), Jeremy Gibson <jtgibson telus 
 net Jeremy_member pathlink.com> wrote:
 Found the problem, and it was completely irrelevant to everything -- I 
 had all
 of the environment variables set up correctly right from the very 
 beginning.

 The problem?  The object.d file in my project folder was overriding 
 object.d in
 the Phobos directory.  I renamed it to "gameobject.d" and everything 
 works
 peachy-keen now.

 (I noticed this because after I uncommented some code in object.d, I 
 started
 getting some errors in that file while I tried to compile the file 
 test.d (which
 I posted) in the same folder.  test.d does not import object.d at all, so
 something had to be automatically importing it.  That's when it clicked.)

 This kind of name clash should probably be documented... =)

 
 Ahh, of course. Yeah, at least one other person has had this exact same 
 problem.
 
 At the very least it should be documented. The compiler could error on 
 compiling object.d, and/or refuse to create an object.o and/or refuse to 
 link/see any object.o which is not in the main directory.
 
 (cross posted to bugs, not sure if it needs a bugzilla entry?)

Definitely. He got an internal compiler error!

Sean Kelly <sean f4.ca> writes:

Regan Heath wrote:
 On Thu, 6 Apr 2006 06:10:30 +0000 (UTC), Jeremy Gibson <jtgibson telus 
 net Jeremy_member pathlink.com> wrote:
 Found the problem, and it was completely irrelevant to everything -- I 
 had all
 of the environment variables set up correctly right from the very 
 beginning.

 The problem?  The object.d file in my project folder was overriding 
 object.d in
 the Phobos directory.  I renamed it to "gameobject.d" and everything 
 works
 peachy-keen now.

 (I noticed this because after I uncommented some code in object.d, I 
 started
 getting some errors in that file while I tried to compile the file 
 test.d (which
 I posted) in the same folder.  test.d does not import object.d at all, so
 something had to be automatically importing it.  That's when it clicked.)

 This kind of name clash should probably be documented... =)

 
 Ahh, of course. Yeah, at least one other person has had this exact same 
 problem.
 
 At the very least it should be documented. The compiler could error on 
 compiling object.d, and/or refuse to create an object.o and/or refuse to 
 link/see any object.o which is not in the main directory.

For what it's worth, I've run into this with Ares before.  DMD requires 
certain class definitions to be in object.d.  If it needs them and they 
aren't there, the compiler crashes.  But this should be reported, as the 
correct behavior would be to terminate with a helpful message.


Sean

James Dunne <james.jdunne gmail.com> writes:

Sean Kelly wrote:
 Regan Heath wrote:
 
 On Thu, 6 Apr 2006 06:10:30 +0000 (UTC), Jeremy Gibson <jtgibson telus 
 net Jeremy_member pathlink.com> wrote:

 Found the problem, and it was completely irrelevant to everything -- 
 I had all
 of the environment variables set up correctly right from the very 
 beginning.

 The problem?  The object.d file in my project folder was overriding 
 object.d in
 the Phobos directory.  I renamed it to "gameobject.d" and everything 
 works
 peachy-keen now.

 (I noticed this because after I uncommented some code in object.d, I 
 started
 getting some errors in that file while I tried to compile the file 
 test.d (which
 I posted) in the same folder.  test.d does not import object.d at 
 all, so
 something had to be automatically importing it.  That's when it 
 clicked.)

 This kind of name clash should probably be documented... =)


 Ahh, of course. Yeah, at least one other person has had this exact 
 same problem.

 At the very least it should be documented. The compiler could error on 
 compiling object.d, and/or refuse to create an object.o and/or refuse 
 to link/see any object.o which is not in the main directory.

 
 
 For what it's worth, I've run into this with Ares before.  DMD requires 
 certain class definitions to be in object.d.  If it needs them and they 
 aren't there, the compiler crashes.  But this should be reported, as the 
 correct behavior would be to terminate with a helpful message.
 
 
 Sean

DMD's phobos should rename the object module class to something 
inconspicuous like '_d_object' or something to avoid naming conflicts 
with new programmers. :) (I just thought naming conflicts with new 
programmers was kinda funny)

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O 
M--  V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e 
h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne

Hasan Aljudy <hasan.aljudy gmail.com> writes:

James Dunne wrote:
 Sean Kelly wrote:
 
 Regan Heath wrote:

 On Thu, 6 Apr 2006 06:10:30 +0000 (UTC), Jeremy Gibson <jtgibson 
 telus net Jeremy_member pathlink.com> wrote:

 Found the problem, and it was completely irrelevant to everything -- 
 I had all
 of the environment variables set up correctly right from the very 
 beginning.

 The problem?  The object.d file in my project folder was overriding 
 object.d in
 the Phobos directory.  I renamed it to "gameobject.d" and everything 
 works
 peachy-keen now.

 (I noticed this because after I uncommented some code in object.d, I 
 started
 getting some errors in that file while I tried to compile the file 
 test.d (which
 I posted) in the same folder.  test.d does not import object.d at 
 all, so
 something had to be automatically importing it.  That's when it 
 clicked.)

 This kind of name clash should probably be documented... =)



 Ahh, of course. Yeah, at least one other person has had this exact 
 same problem.

 At the very least it should be documented. The compiler could error 
 on compiling object.d, and/or refuse to create an object.o and/or 
 refuse to link/see any object.o which is not in the main directory.



 For what it's worth, I've run into this with Ares before.  DMD 
 requires certain class definitions to be in object.d.  If it needs 
 them and they aren't there, the compiler crashes.  But this should be 
 reported, as the correct behavior would be to terminate with a helpful 
 message.


 Sean

 
 
 DMD's phobos should rename the object module class to something 
 inconspicuous like '_d_object' or something to avoid naming conflicts 
 with new programmers. :) (I just thought naming conflicts with new 
 programmers was kinda funny)
 

I think it should just go into std package, making it std.object
This way it'll be very hard to make the above mentioned mistake without 
knowing what's going on.

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

Hasan Aljudy wrote:
 James Dunne wrote:
 
 Sean Kelly wrote:

 Regan Heath wrote:

 On Thu, 6 Apr 2006 06:10:30 +0000 (UTC), Jeremy Gibson <jtgibson 
 telus net Jeremy_member pathlink.com> wrote:

 Found the problem, and it was completely irrelevant to everything 
 -- I had all
 of the environment variables set up correctly right from the very 
 beginning.

 The problem?  The object.d file in my project folder was overriding 
 object.d in
 the Phobos directory.  I renamed it to "gameobject.d" and 
 everything works
 peachy-keen now.

 (I noticed this because after I uncommented some code in object.d, 
 I started
 getting some errors in that file while I tried to compile the file 
 test.d (which
 I posted) in the same folder.  test.d does not import object.d at 
 all, so
 something had to be automatically importing it.  That's when it 
 clicked.)

 This kind of name clash should probably be documented... =)




 Ahh, of course. Yeah, at least one other person has had this exact 
 same problem.

 At the very least it should be documented. The compiler could error 
 on compiling object.d, and/or refuse to create an object.o and/or 
 refuse to link/see any object.o which is not in the main directory.




 For what it's worth, I've run into this with Ares before.  DMD 
 requires certain class definitions to be in object.d.  If it needs 
 them and they aren't there, the compiler crashes.  But this should be 
 reported, as the correct behavior would be to terminate with a 
 helpful message.


 Sean



 DMD's phobos should rename the object module class to something 
 inconspicuous like '_d_object' or something to avoid naming conflicts 
 with new programmers. :) (I just thought naming conflicts with new 
 programmers was kinda funny)

 
 I think it should just go into std package, making it std.object
 This way it'll be very hard to make the above mentioned mistake without 
 knowing what's going on.

I'm all for this solution, for two reasons.  Reason 1, I've personally had a
project where 
I had a class whose most obvious natural name would be Object.  Of course, I
ended up 
calling it LObject, and renaming all its compliments with the L* prefix as
well, for 
consistancy.  It would've been nice not to have to.  Reason 2, it solves the
problem of 
what to do if I actually want to explicitly refer to the generic Object: just
call it 
std.object.Object (perhaps with an alias of _D_Object?)

-- Chris Nicholson-Sauls

Justin C Calvarese <technocrat7 gmail.com> writes:

Hasan Aljudy wrote:
 James Dunne wrote:
 Sean Kelly wrote:

 Regan Heath wrote:



<snip>

 At the very least it should be documented. The compiler could error 
 on compiling object.d, and/or refuse to create an object.o and/or 
 refuse to link/see any object.o which is not in the main directory.



 For what it's worth, I've run into this with Ares before.  DMD 
 requires certain class definitions to be in object.d.  If it needs 
 them and they aren't there, the compiler crashes.  But this should be 
 reported, as the correct behavior would be to terminate with a 
 helpful message.


 Sean


 DMD's phobos should rename the object module class to something 
 inconspicuous like '_d_object' or something to avoid naming conflicts 
 with new programmers. :) (I just thought naming conflicts with new 
 programmers was kinda funny)

 
 I think it should just go into std package, making it std.object
 This way it'll be very hard to make the above mentioned mistake without 
 knowing what's going on.

I asked Walter to put object into std.object a long time ago. I don't 
think he ever responded to that request (i.e. if there's a reason why he 
won't do this, I don't remember what it is).

I also think that gcstats.d, unittest.d, crc32.d, etc. should be moved 
into the std module (or into "internal" or "etc").

-- 
jcc7