This cases (I think) a compilation error.

Code:
           void [] str;
           try  { str = std.file.read (filename); }
           catch (std.file.FileException) {printf("There was a file error. I will quit now."); /*run away*/}

Compiler
Internal error: ..\ztc\cod1.c 2240

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:br851g$1v00$1@digitaldaemon.com...
> This cases (I think) a compilation error.
>
> Code:
>             void [] str;
>             try  { str = std.file.read (filename); }
>             catch (std.file.FileException) {printf("There was a file
> error. I will quit now."); /*run away*/}
>
> Compiler
> Internal error: ..\ztc\cod1.c 2240

The example was incomplete. I fleshed it out a bit:

---------------------------------
import std.file;

void test(char[] filename)
{
    void [] str;
    try  { str = std.file.read (filename); }
    catch (std.file.FileException)
    {printf("There was a file error. I will quit now.");
    }
}
------------------------------------
and it compiles without error.

Walter wrote:

>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:br851g$1v00$1@digitaldaemon.com...
> 
>
>>This cases (I think) a compilation error.
>>
>>Code:
>>            void [] str;
>>            try  { str = std.file.read (filename); }
>>            catch (std.file.FileException) {printf("There was a file
>>error. I will quit now."); /*run away*/}
>>
>>Compiler
>>Internal error: ..\ztc\cod1.c 2240
>> 
>>
>
>The example was incomplete. I fleshed it out a bit:
>
>---------------------------------
>import std.file;
>
>void test(char[] filename)
>{
>    void [] str;
>    try  { str = std.file.read (filename); }
>    catch (std.file.FileException)
>    {printf("There was a file error. I will quit now.");
>    }
>}
>------------------------------------
>and it compiles without error.
>
> 
>
Sorry about that. Anyway I looked at the code again and killed all the code that had no affect on the error, to come up with the attachment.

import c.stdio; //For debug output
import net.BurtonRadons.dig.main;
import net.BurtonRadons.dig.gl;
import std.file;

class GLFrame : public CanvasGL
{

    this (Control parent)
    {
        super (parent);
    }

    void loadData(ubyte [] data)     {     }
}

class Program : public Frame
{
    GLFrame frame;

    this ()
    {
        super();

        //Register frame
       with (frame = new GLFrame (this))
        {
            char[] filename = "maze.MBS"; //For now
            try  {  loadData((ubyte []) std.file.read (filename)); }
            catch (std.file.FileException) {printf("There was a file
error. I will quit now."); /*run away*/}
        }

    }

}

int main( char [] [] args )
{
    (new Program ());
    return 1;
}

My
C:\dmd\bin\dmd.exe -g -gt -debug -I\dig\
-odC:\PROGRA~1\DIDE\Projects\Engine2 -version=WindowsXP  Engine2.exe
"C:\Program Files\DIDE\Projects\Engine2\Engine2.d" "dig.lib"
"advapi32.lib" "comdlg32.lib" "gdi32.lib" "comctl32.lib" "shell32.lib"
"diggl.lib" "opengl32.lib" -I\dmd\src digc_manifest.res -Idigc_temp

I'm using my own dig mod (to get it to work for 0.76). I also noted the problem within dig itself.

If I just go

  loadData((ubyte []) std.file.read (filename));
instead of :
  try  {  loadData((ubyte []) std.file.read (filename)); }
  catch (std.file.FileException) {printf("There was a file error. I will
quit now."); /*run away*/}

It works.

-Anderson

J Anderson wrote:

> Walter wrote:
>
>> "J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>> news:br851g$1v00$1@digitaldaemon.com...
>>  
>>
>>> This cases (I think) a compilation error.
>>>
>>> Code:
>>>            void [] str;
>>>            try  { str = std.file.read (filename); }
>>>            catch (std.file.FileException) {printf("There was a file
>>> error. I will quit now."); /*run away*/}
>>>
>>> Compiler
>>> Internal error: ..\ztc\cod1.c 2240
>>>   
>>
>>
>> The example was incomplete. I fleshed it out a bit:
>>
>> ---------------------------------
>> import std.file;
>>
>> void test(char[] filename)
>> {
>>    void [] str;
>>    try  { str = std.file.read (filename); }
>>    catch (std.file.FileException)
>>    {printf("There was a file error. I will quit now.");
>>    }
>> }
>> ------------------------------------
>> and it compiles without error.
>>
>>  
>>
> Sorry about that. Anyway I looked at the code again and killed all the code that had no affect on the error, to come up with the attachment.
>
> import c.stdio; //For debug output
> import net.BurtonRadons.dig.main;
> import net.BurtonRadons.dig.gl;
> import std.file;
>
> class GLFrame : public CanvasGL
> {
>      this (Control parent)
>    {
>        super (parent);
>    }
>
>    void loadData(ubyte [] data)     {     }
> }
>
> class Program : public Frame
> {
>    GLFrame frame;
>      this ()
>    {
>        super();
>              //Register frame
>       with (frame = new GLFrame (this))
>        {
>            char[] filename = "maze.MBS"; //For now
>            try  {  loadData((ubyte []) std.file.read (filename)); }
>            catch (std.file.FileException) {printf("There was a file error. I will quit now."); /*run away*/}
>        }
>
>    }
>
> }
>
> int main( char [] [] args )
> {
>    (new Program ());
>    return 1;
> }
>
> My
> C:\dmd\bin\dmd.exe -g -gt -debug -I\dig\ -odC:\PROGRA~1\DIDE\Projects\Engine2 -version=WindowsXP  Engine2.exe "C:\Program Files\DIDE\Projects\Engine2\Engine2.d" "dig.lib" "advapi32.lib" "comdlg32.lib" "gdi32.lib" "comctl32.lib" "shell32.lib" "diggl.lib" "opengl32.lib" -I\dmd\src digc_manifest.res -Idigc_temp
>
> I'm using my own dig mod (to get it to work for 0.76). I also noted the problem within dig itself.
>
> If I just go
>
>  loadData((ubyte []) std.file.read (filename));
> instead of :
>  try  {  loadData((ubyte []) std.file.read (filename)); }
>  catch (std.file.FileException) {printf("There was a file error. I will quit now."); /*run away*/}
>
> It works.
>
> -Anderson
>
>------------------------------------------------------------------------
>
>// **************************************************
>//
>// Project Created 12 / 11 / 2003
>// Created By Joel Anderson
>//
>// **************************************************
>
>import c.stdio; //For debug output
>import net.BurtonRadons.dig.main;
>import net.BurtonRadons.dig.gl;
>import std.file;
>
>class GLFrame : public CanvasGL
>{
>	
>    this (Control parent)
>	{
>		super (parent);
>	}
>
>	void loadData(ubyte [] data) 	{ 	}
>} 
>
>class Program : public Frame
>{
>	GLFrame frame;
>	
>    this ()
>    {
>		super();
>		
>		//Register frame
>       with (frame = new GLFrame (this))
>        {
>			char[] filename = "maze.MBS"; //For now
>			try  {  loadData((ubyte []) std.file.read (filename)); }
>			catch (std.file.FileException) {printf("There was a file error. I will quit now."); /*run away*/}
>        }
>
>	}
>
>}
>
>int main( char [] [] args ) { 	(new Program ());
>	return 1;
>}
>
It appears to be with the "with statement":

import c.stdio;
import net.BurtonRadons.dig.main;
import net.BurtonRadons.dig.gl;

class GLFrame : public CanvasGL
{
   this () { super(null); }
     this (Control parent)
   {
       super (parent);
   }
}

GLFrame frame;

int main( char [] [] args )
{
   with (frame = new GLFrame())
   {
       printf("Hi");
   }
   return 1;
}
int main( char [] [] args )
{
   (new Program ());
   return 1;
}

J Anderson wrote:
> J Anderson wrote:
> 
>> Walter wrote:
>>
>>> "J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>>> news:br851g$1v00$1@digitaldaemon.com...
>>>  
>>>
>>>> This cases (I think) a compilation error.
>>>>
>>>> Code:
>>>>            void [] str;
>>>>            try  { str = std.file.read (filename); }
>>>>            catch (std.file.FileException) {printf("There was a file
>>>> error. I will quit now."); /*run away*/}
>>>>
>>>> Compiler
>>>> Internal error: ..\ztc\cod1.c 2240
>>>>   
>>>
>>>
>>>
>>> The example was incomplete. I fleshed it out a bit:
>>>
>>> ---------------------------------
>>> import std.file;
>>>
>>> void test(char[] filename)
>>> {
>>>    void [] str;
>>>    try  { str = std.file.read (filename); }
>>>    catch (std.file.FileException)
>>>    {printf("There was a file error. I will quit now.");
>>>    }
>>> }
>>> ------------------------------------
>>> and it compiles without error.
>>>
>>>  
>>>
>> Sorry about that. Anyway I looked at the code again and killed all the code that had no affect on the error, to come up with the attachment.
>>
>> import c.stdio; //For debug output
>> import net.BurtonRadons.dig.main;
>> import net.BurtonRadons.dig.gl;
>> import std.file;
>>
>> class GLFrame : public CanvasGL
>> {
>>      this (Control parent)
>>    {
>>        super (parent);
>>    }
>>
>>    void loadData(ubyte [] data)     {     }
>> }
>>
>> class Program : public Frame
>> {
>>    GLFrame frame;
>>      this ()
>>    {
>>        super();
>>              //Register frame
>>       with (frame = new GLFrame (this))
>>        {
>>            char[] filename = "maze.MBS"; //For now
>>            try  {  loadData((ubyte []) std.file.read (filename)); }
>>            catch (std.file.FileException) {printf("There was a file error. I will quit now."); /*run away*/}
>>        }
>>
>>    }
>>
>> }
>>
>> int main( char [] [] args )
>> {
>>    (new Program ());
>>    return 1;
>> }
>>
>> My
>> C:\dmd\bin\dmd.exe -g -gt -debug -I\dig\ -odC:\PROGRA~1\DIDE\Projects\Engine2 -version=WindowsXP  Engine2.exe "C:\Program Files\DIDE\Projects\Engine2\Engine2.d" "dig.lib" "advapi32.lib" "comdlg32.lib" "gdi32.lib" "comctl32.lib" "shell32.lib" "diggl.lib" "opengl32.lib" -I\dmd\src digc_manifest.res -Idigc_temp
>>
>> I'm using my own dig mod (to get it to work for 0.76). I also noted the problem within dig itself.
>>
>> If I just go
>>
>>  loadData((ubyte []) std.file.read (filename));
>> instead of :
>>  try  {  loadData((ubyte []) std.file.read (filename)); }
>>  catch (std.file.FileException) {printf("There was a file error. I will quit now."); /*run away*/}
>>
>> It works.
>>
>> -Anderson
>>
>> ------------------------------------------------------------------------
>>
>> // **************************************************
>> //
>> // Project Created 12 / 11 / 2003
>> // Created By Joel Anderson
>> //
>> // **************************************************
>>
>> import c.stdio; //For debug output
>> import net.BurtonRadons.dig.main;
>> import net.BurtonRadons.dig.gl;
>> import std.file;
>>
>> class GLFrame : public CanvasGL
>> {
>>        this (Control parent)
>>     {
>>         super (parent);
>>     }
>>
>>     void loadData(ubyte [] data)     {     }
>> }
>> class Program : public Frame
>> {
>>     GLFrame frame;
>>        this ()
>>    {
>>         super();
>>                //Register frame
>>       with (frame = new GLFrame (this))
>>        {
>>             char[] filename = "maze.MBS"; //For now
>>             try  {  loadData((ubyte []) std.file.read (filename)); }
>>             catch (std.file.FileException) {printf("There was a file error. I will quit now."); /*run away*/}
>>        }
>>
>>     }
>>
>> }
>>
>> int main( char [] [] args ) {     (new Program ());
>>     return 1;
>> }
>>
> It appears to be with the "with statement":
> 

I'm afraid this problem is seems to be either a flaw in dig or a problem in DMD that is much removed from your example.  When I remove the reliance on dig, the problem goes away.

The following code (which is similar to your troublesome code) seems to compile correctly.

Justin


import std.c.stdio;

class Whatever
{
	int an_integer;
	void something() {  }
	this (Object o) {  }	
}

class GLFrame : public Whatever
{
   this () { super(null); }

   this (Object o, int i)
   {
       super (o);
   }

   void loadData(ubyte [] data)     {     }
}


GLFrame frame;

int main( char [] [] args )
{
   with (frame = new GLFrame())
   {
       printf("Hi");
   }
   return 1;
}

J C Calvarese wrote:

>> It appears to be with the "with statement":
>>
>
> I'm afraid this problem is seems to be either a flaw in dig or a problem in DMD that is much removed from your example.  When I remove the reliance on dig, the problem goes away.
>
> The following code (which is similar to your troublesome code) seems to compile correctly.
>
> Justin
>
>
> import std.c.stdio;
>
> class Whatever
> {
>     int an_integer;
>     void something() {  }
>     this (Object o) {  }   }
>
> class GLFrame : public Whatever
> {
>    this () { super(null); }
>
>    this (Object o, int i)
>    {
>        super (o);
>    }
>
>    void loadData(ubyte [] data)     {     }
> }
>
>
> GLFrame frame;
>
> int main( char [] [] args )
> {
>    with (frame = new GLFrame())
>    {
>        printf("Hi");
>    }
>    return 1;
> }
>
>
I still think that the compiler should either report where dig is faulty, if it's a dig bug.

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
news:brm9mr$2n1h$1@digitaldaemon.com...
| I still think that the compiler should either report where dig is
| faulty, if it's a dig bug.
|

Why don't you compile dig and your program with "-g" and trace where the problem is?

-------------------------
Carlos Santander
"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
news:brm9mr$2n1h$1@digitaldaemon.com...
| I still think that the compiler should either report where dig is
| faulty, if it's a dig bug.
|

Why don't you compile dig and your program with "-g" and trace where the problem is?

-------------------------
Carlos Santander

Carlos Santander B. wrote:

>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>news:brm9mr$2n1h$1@digitaldaemon.com...
>| I still think that the compiler should either report where dig is
>| faulty, if it's a dig bug.
>|
>
>Why don't you compile dig and your program with "-g" and trace where the
>problem is?
>
>-------------------------
>Carlos Santander
>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>news:brm9mr$2n1h$1@digitaldaemon.com...
>| I still think that the compiler should either report where dig is
>| faulty, if it's a dig bug.
>|
>
>Why don't you compile dig and your program with "-g" and trace where the
>problem is?
>
>-------------------------
>Carlos Santander
>
>
>  
>
Thanks, I tried that,  I still get the compilation error:
Internal error: ..\ztc\cod1.c 2240

J Anderson wrote:

> J C Calvarese wrote:
> 
>>> It appears to be with the "with statement":
>>>
>>
>> I'm afraid this problem is seems to be either a flaw in dig or a problem in DMD that is much removed from your example.  When I remove the reliance on dig, the problem goes away.
>>
>> The following code (which is similar to your troublesome code) seems to compile correctly.
>>
>> Justin
>>
>>
>> import std.c.stdio;
>>
>> class Whatever
>> {
>>     int an_integer;
>>     void something() {  }
>>     this (Object o) {  }   }
>>
>> class GLFrame : public Whatever
>> {
>>    this () { super(null); }
>>
>>    this (Object o, int i)
>>    {
>>        super (o);
>>    }
>>
>>    void loadData(ubyte [] data)     {     }
>> }
>>
>>
>> GLFrame frame;
>>
>> int main( char [] [] args )
>> {
>>    with (frame = new GLFrame())
>>    {
>>        printf("Hi");
>>    }
>>    return 1;
>> }
>>
>>
> I still think that the compiler should either report where dig is faulty, if it's a dig bug.
> 

Yes, I agree.  The compiler should give a helpful error message.

I meant to make the point that if Walter doesn't know what the problem is, he can't fix it.  When I reduced down the sample so that it didn't include dig, the problem disappeared.  So it sounds like something in the thousands of lines of dig modules throws the compiler for a loop. The way I see it there are two possibilities:

1) It's valid code and the compiler should compile it without complaint (but there's a bug in the compiler).

2) It's invalid code, but the compiler fails to give a helpful message.  (This is still what I'd consider a compiler bug, but it's probably harder for a compiler writer to find because I'd guess there's more emphasis on testing the compiler with correct code than with broken code.)

Either way it seems that this particular error is a needle in a haystack of dig code.  The more you can narrow down the problem (by decreasing the amount of code that it takes to throw off the compiler), the more likely it is that Walter will fix it.

I'm sorry that this probably doesn't help you any.  I just wanted to clarify my point.

Good luck with everything.

Justin

J C Calvarese wrote:

> J Anderson wrote:
>
>> J C Calvarese wrote:
>>
>>>> It appears to be with the "with statement":
>>>>
>>>
>>> I'm afraid this problem is seems to be either a flaw in dig or a problem in DMD that is much removed from your example.  When I remove the reliance on dig, the problem goes away.
>>>
>>> The following code (which is similar to your troublesome code) seems to compile correctly.
>>>
>>> Justin
>>>
>>>
>>> import std.c.stdio;
>>>
>>> class Whatever
>>> {
>>>     int an_integer;
>>>     void something() {  }
>>>     this (Object o) {  }   }
>>>
>>> class GLFrame : public Whatever
>>> {
>>>    this () { super(null); }
>>>
>>>    this (Object o, int i)
>>>    {
>>>        super (o);
>>>    }
>>>
>>>    void loadData(ubyte [] data)     {     }
>>> }
>>>
>>>
>>> GLFrame frame;
>>>
>>> int main( char [] [] args )
>>> {
>>>    with (frame = new GLFrame())
>>>    {
>>>        printf("Hi");
>>>    }
>>>    return 1;
>>> }
>>>
>>>
>> I still think that the compiler should either report where dig is faulty, if it's a dig bug.
>>
>
> Yes, I agree.  The compiler should give a helpful error message.
>
> I meant to make the point that if Walter doesn't know what the problem is, he can't fix it.  When I reduced down the sample so that it didn't include dig, the problem disappeared.  So it sounds like something in the thousands of lines of dig modules throws the compiler for a loop. The way I see it there are two possibilities:
>
> 1) It's valid code and the compiler should compile it without complaint (but there's a bug in the compiler).
>
> 2) It's invalid code, but the compiler fails to give a helpful message.  (This is still what I'd consider a compiler bug, but it's probably harder for a compiler writer to find because I'd guess there's more emphasis on testing the compiler with correct code than with broken code.)
>
> Either way it seems that this particular error is a needle in a haystack of dig code.  The more you can narrow down the problem (by decreasing the amount of code that it takes to throw off the compiler), the more likely it is that Walter will fix it.
>
> I'm sorry that this probably doesn't help you any.  I just wanted to clarify my point.
>
> Good luck with everything.
>
> Justin

Yeah, I did look into dig before you said that, but as you say it's a thousand lines of code.  At least I can get around it by not using "with".

-Anderson