www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - DMD compiler choking?

reply 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?
Apr 05 2006
parent reply "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
Apr 05 2006
parent reply 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; }
Apr 05 2006
next sibling parent 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)
Apr 05 2006
prev sibling parent reply 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
Apr 05 2006
parent reply 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
Apr 05 2006
parent reply "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
Apr 05 2006
next sibling parent "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
Apr 05 2006
prev sibling parent reply 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
Apr 05 2006
next sibling parent 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
Apr 05 2006
prev sibling parent reply 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
Apr 05 2006
parent reply "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
Apr 06 2006
next sibling parent 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!
Apr 06 2006
prev sibling parent reply 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
Apr 06 2006
parent reply 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
Apr 06 2006
parent reply 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.
Apr 06 2006
next sibling parent 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
Apr 07 2006
prev sibling parent 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
Apr 07 2006