Jascha Wetzel wrote:
> it does when i try dickl's example.
> can you give an example where it doesn't work?
> 
> vanh wrote:
>> Jascha Wetzel wrote:
>>> oh - bug! :) fixed in 0.0.4.1 which i just put on the website.
>>> pointers didn't get handled correctly by the expression evaluator and
>>> therefore the "this" reference wasn't interpreted correctly.
>>> thanks for the report!
>>>
>>> dickl wrote:
>>>> Jascha Wetzel wrote:
>>>>> Ddbg is a Win32 D Debugger
>>>>>
>>>>> http://ddbg.mainia.de/releases.html
>>>>>
>>>>> This release mainly adds support for type cast and associative arrays.
>>>>> Type casts can be used to workaround the missing array and enum support
>>>>> in DMD's debug symbols.
>>>> dbbg is turning into a great tool !
>>>>
>>>> I took it from the docs that I should now be able to view contents of
>>>> strings. This doesn't seem to be the case, at least for class members.
>>>>
>>>> Test program
>>>> ---------------------
>>>> import std.stdio;
>>>>
>>>> int main(char[][] args)
>>>> {
>>>>     FOO foo = new FOO;
>>>>
>>>>     return 0;
>>>> }
>>>>
>>>> class FOO
>>>> {
>>>>     private char [] str = "Hello";
>>>>
>>>>     this()
>>>>     {
>>>>         writefln(str);
>>>>     }
>>>> }
>>>>
>>>> Debug results. Note ddbg reports str as null
>>>> -------------------
>>>>> M:\D-projects\TEST1>ddbg test.exe
>>>>> Ddbg v0.0.4 alpha - D Debugger
>>>>> Copyright (c) 2007 Jascha Wetzel
>>>>> http://ddbg.mainia.de/
>>>>>
>>>>> ->bp test.d:1
>>>>> Breakpoint set: test.d:4 0x402010
>>>>> ->r
>>>>> ntdll.dll  loaded
>>>>> KERNEL32.dll  loaded
>>>>> USER32.dll  loaded
>>>>> GDI32.dll  loaded
>>>>> Breakpoint 0 hit
>>>>> test.d:4 0x402010
>>>>> int main(char[][] args)
>>>>> ->in
>>>>> test.d:6 0x402014
>>>>>     FOO foo = new FOO;
>>>>> ->
>>>>> test.d:15 0x402030
>>>>>     this()
>>>>> ->
>>>>> test.d:17 0x402037
>>>>>         writefln(str);
>>>>> ->lsv
>>>>> Scope: MFZC4test3FOO test.FOO._ctor
>>>>> class test.FOO* this [ebp-4]    = {str = 0x0041409800000005}
>>>>> ->= (cast(char[])this.str)
>>>>> null
>>>>> ->
>>>>>
>> Well, I got the latest 0.0.4.1 or at least I thought I did. It's still
>> didn't show the content of the str
>> only the address of the string.
>>
>> vtp

I just copy and past the above code into codeblock and check the watch window while
stepping through it. All I see is str=0x0041408000000005

vtp

you need to add a watch with a cast manually: cast(char[])this.str DMD doesn't add the full type to array symbols, yet, that's why ddbg can't find out that this.str is a char[] by itself. therefore you have to help out with the cast.

vanh wrote:
> Jascha Wetzel wrote:
>> it does when i try dickl's example.
>> can you give an example where it doesn't work?
>>
>> vanh wrote:
>>> Jascha Wetzel wrote:
>>>> oh - bug! :) fixed in 0.0.4.1 which i just put on the website.
>>>> pointers didn't get handled correctly by the expression evaluator and
>>>> therefore the "this" reference wasn't interpreted correctly.
>>>> thanks for the report!
>>>>
>>>> dickl wrote:
>>>>> Jascha Wetzel wrote:
>>>>>> Ddbg is a Win32 D Debugger
>>>>>>
>>>>>> http://ddbg.mainia.de/releases.html
>>>>>>
>>>>>> This release mainly adds support for type cast and associative
>>>>>> arrays.
>>>>>> Type casts can be used to workaround the missing array and enum
>>>>>> support
>>>>>> in DMD's debug symbols.
>>>>> dbbg is turning into a great tool !
>>>>>
>>>>> I took it from the docs that I should now be able to view contents of strings. This doesn't seem to be the case, at least for class members.
>>>>>
>>>>> Test program
>>>>> ---------------------
>>>>> import std.stdio;
>>>>>
>>>>> int main(char[][] args)
>>>>> {
>>>>>     FOO foo = new FOO;
>>>>>
>>>>>     return 0;
>>>>> }
>>>>>
>>>>> class FOO
>>>>> {
>>>>>     private char [] str = "Hello";
>>>>>
>>>>>     this()
>>>>>     {
>>>>>         writefln(str);
>>>>>     }
>>>>> }
>>>>>
>>>>> Debug results. Note ddbg reports str as null
>>>>> -------------------
>>>>>> M:\D-projects\TEST1>ddbg test.exe
>>>>>> Ddbg v0.0.4 alpha - D Debugger
>>>>>> Copyright (c) 2007 Jascha Wetzel
>>>>>> http://ddbg.mainia.de/
>>>>>>
>>>>>> ->bp test.d:1
>>>>>> Breakpoint set: test.d:4 0x402010
>>>>>> ->r
>>>>>> ntdll.dll  loaded
>>>>>> KERNEL32.dll  loaded
>>>>>> USER32.dll  loaded
>>>>>> GDI32.dll  loaded
>>>>>> Breakpoint 0 hit
>>>>>> test.d:4 0x402010
>>>>>> int main(char[][] args)
>>>>>> ->in
>>>>>> test.d:6 0x402014
>>>>>>     FOO foo = new FOO;
>>>>>> ->
>>>>>> test.d:15 0x402030
>>>>>>     this()
>>>>>> ->
>>>>>> test.d:17 0x402037
>>>>>>         writefln(str);
>>>>>> ->lsv
>>>>>> Scope: MFZC4test3FOO test.FOO._ctor
>>>>>> class test.FOO* this [ebp-4]    = {str = 0x0041409800000005}
>>>>>> ->= (cast(char[])this.str)
>>>>>> null
>>>>>> ->
>>>>>>
>>> Well, I got the latest 0.0.4.1 or at least I thought I did. It's still
>>> didn't show the content of the str
>>> only the address of the string.
>>>
>>> vtp
> 
> I just copy and past the above code into codeblock and check the watch
> window while
> stepping through it. All I see is str=0x0041408000000005
> 
> vtp

0.0.4.1 seems to have fixed the problem for me

Can't wait to uninstall Visual Studio from my computer  :-)

Jascha Wetzel wrote:
> oh - bug! :) fixed in 0.0.4.1 which i just put on the website.
> pointers didn't get handled correctly by the expression evaluator and
> therefore the "this" reference wasn't interpreted correctly.
> thanks for the report!
>
> dickl wrote:
>   
>> Jascha Wetzel wrote:
>>     
>>> Ddbg is a Win32 D Debugger
>>>
>>> http://ddbg.mainia.de/releases.html
>>>
>>> This release mainly adds support for type cast and associative arrays.
>>> Type casts can be used to workaround the missing array and enum support
>>> in DMD's debug symbols.
>>>       
>> dbbg is turning into a great tool !
>>
>> I took it from the docs that I should now be able to view contents of
>> strings. This doesn't seem to be the case, at least for class members.
>>
>> Test program
>> ---------------------
>> import std.stdio;
>>
>> int main(char[][] args)
>> {
>>     FOO foo = new FOO;
>>
>>     return 0;
>> }
>>
>> class FOO
>> {
>>     private char [] str = "Hello";
>>
>>     this()
>>     {
>>         writefln(str);
>>     }
>> }
>>
>> Debug results. Note ddbg reports str as null
>> -------------------
>>     
>>> M:\D-projects\TEST1>ddbg test.exe
>>> Ddbg v0.0.4 alpha - D Debugger
>>> Copyright (c) 2007 Jascha Wetzel
>>> http://ddbg.mainia.de/
>>>
>>> ->bp test.d:1
>>> Breakpoint set: test.d:4 0x402010
>>> ->r
>>> ntdll.dll  loaded
>>> KERNEL32.dll  loaded
>>> USER32.dll  loaded
>>> GDI32.dll  loaded
>>> Breakpoint 0 hit
>>> test.d:4 0x402010
>>> int main(char[][] args)
>>> ->in
>>> test.d:6 0x402014
>>>     FOO foo = new FOO;
>>> ->
>>> test.d:15 0x402030
>>>     this()
>>> ->
>>> test.d:17 0x402037
>>>         writefln(str);
>>> ->lsv
>>> Scope: MFZC4test3FOO test.FOO._ctor
>>> class test.FOO* this [ebp-4]    = {str = 0x0041409800000005}
>>> ->= (cast(char[])this.str)
>>> null
>>> ->
>>>
>>>       

> to do the latter, you can
> adjust the syntax to identify bracketed terms as casts if they're
> followed by an identifier and identify them as expressions if they're
> followed by an operator or nothing.

oh - it's even worse than i thought. even those little ddbg expressions
can't be parsed *at all* without semantic information:
is (asdf.qwer)(yxcv.fghj) a valid expression?
you can only tell if you know what asdf.qwer and yxcv.fghj are. it might
by (cast)(expr), (cast)(cast) or (expr)(expr). the first is ok, the
latter two are invalid in ddbg.

correct me if i'm wrong here, but these casts are also one root of evil
in c++, since expressions like (foo)(bar) aren't parseable without
semantic information about the identifiers involved. foo could evaluate
to an object that has the () operator overwritten, then (bar) is an
argument list. it could also be a class name, then (foo) is a cast and
(bar) is another expression.

this stuff is pandora's box - i won't open it ;)
we can have the {cast} syntax though, if you like. i can't possibly
think of anything else ddbg could ever need the curly brackets for. to
be sure we could also use something else:
§cast§
#cast#
:)

Jascha Wetzel wrote:
> the main reason i used the cast keyword is that it's faster and easier
> to parse.
> (asdf.qwer) can be interpreted as class/struct access or a cast to the
> type qwer in package asdf. to tell them apart you either need to know
> semantics, namely whether asdf and qwer are variables, types or
> packages, or you need arbitrary lookahead. to do the latter, you can
> adjust the syntax to identify bracketed terms as casts if they're
> followed by an identifier and identify them as expressions if they're
> followed by an operator or nothing.
> 
> atm the parser is a recursive descent LL(k) parser and not very fast.
> it's not even working in linear time. using syntax that makes use of
> arbitrary lookaheads will make it worse.
> considering that expressions will potentially have to be evaluated very
> often (open watch window while stepping through the code), i really want
> this to be as fast as possible and therefore use a LALR parser in some
> of the next releases, which doesn't allow arbitrary lookaheads.
> 
> so if you don't like the cast keyword for it's length, then i could add
> an alternative, shorthand syntax, that doesn't require arbitrary lookahead.
> for example: {char[][]}args. i guess ddbg expressions will never need
> the D meaning of curly brackets, so this will not collide at some point.
> 
> Bill Baxter wrote:
>> Jascha Wetzel wrote:
>>> slices are supported. in your example, the cast needs to be in brackets,
>>> though: (cast(int[])hugelist)[200..210]
>> Ah, ok.  I didn't think to try that for some reason.
>>
>> So what do you think about allowing C-style (or even better -- c++
>> style) casts?
>>
>> I think the various reasons they are not allowed in D do not really apply to an interactive debugger.  The main thing you want in a debugger is just something easy to type and read.  I think C++ function-style casts fit the bill very nicely there.
>>
>> In Visual Studio for instance I find I often end up with ridiculous looking watch expressions that are hard to read because of the cast syntax.
>>
>> Just a thought.  Basically idea is that the debugger cast syntax doesn't *have* to look like the language syntax.  (Note that in Visual Studio, for example, C cast syntax is all that's supported whether you're debugging C or C++).
>>
>> --bb

Another bug report...

Debugger crashes when trying to list the class variables. The variable is a struct which contains an array of stuff.

Source
--------------------

 import std.stdio;
 int main()
 {
     Foo f = new Foo;
     return 0;
 }//end int main()

 enum Stuff:ubyte
 {
 	Item1=0,
 	Item2,
 	Item3,
 	Item4,
 }//end enum Stuff:ubyte

 const uint Num=Stuff.max;

 struct Table
 {
 	bool [Num]TableStuff;
 }//end struct Table


 class Foo
 {

    char [] FileName="Somefile.txt";

 	Table t1;
    this()
     {
        writefln(FileName);
     }
 }//end class F00

Debug results
-------------------------------
> Ddbg v0.0.4.1 alpha - D Debugger
> Copyright (c) 2007 Jascha Wetzel
> http://ddbg.mainia.de/
> 
> ->bp test.d:1
> Breakpoint set: test.d:4 0x402010
> ->r
> ntdll.dll  loaded
> KERNEL32.dll  loaded
> USER32.dll  loaded
> GDI32.dll  loaded
> Breakpoint 0 hit
> test.d:4 0x402010
> int main()
> ->in
> test.d:6 0x402014
>     Foo f = new Foo;
> ->
> test.d:33 0x402030
>    this()
> ->
> test.d:35 0x402037
>        writefln(FileName);
> ->lsv
> Scope: MFZC4test3Foo test.Foo._ctor
> this [ebp-4]    = Error: array cast misalignment

_____________________________________________________



Jascha Wetzel wrote:
> Ddbg is a Win32 D Debugger
> 
> http://ddbg.mainia.de/releases.html
> 
> This release mainly adds support for type cast and associative arrays.
> Type casts can be used to workaround the missing array and enum support
> in DMD's debug symbols.

thanks!
fixed in 0.0.4.2

dickl wrote:
> Another bug report...
> 
> Debugger crashes when trying to list the class variables. The variable is a struct which contains an array of stuff.
> 
> Source
> --------------------
> 
>  import std.stdio;
>  int main()
>  {
>      Foo f = new Foo;
>      return 0;
>  }//end int main()
> 
>  enum Stuff:ubyte
>  {
>      Item1=0,
>      Item2,
>      Item3,
>      Item4,
>  }//end enum Stuff:ubyte
> 
>  const uint Num=Stuff.max;
> 
>  struct Table
>  {
>      bool [Num]TableStuff;
>  }//end struct Table
> 
> 
>  class Foo
>  {
> 
>     char [] FileName="Somefile.txt";
> 
>      Table t1;
>     this()
>      {
>         writefln(FileName);
>      }
>  }//end class F00
> 
> Debug results
> -------------------------------
>> Ddbg v0.0.4.1 alpha - D Debugger
>> Copyright (c) 2007 Jascha Wetzel
>> http://ddbg.mainia.de/
>>
>> ->bp test.d:1
>> Breakpoint set: test.d:4 0x402010
>> ->r
>> ntdll.dll  loaded
>> KERNEL32.dll  loaded
>> USER32.dll  loaded
>> GDI32.dll  loaded
>> Breakpoint 0 hit
>> test.d:4 0x402010
>> int main()
>> ->in
>> test.d:6 0x402014
>>     Foo f = new Foo;
>> ->
>> test.d:33 0x402030
>>    this()
>> ->
>> test.d:35 0x402037
>>        writefln(FileName);
>> ->lsv
>> Scope: MFZC4test3Foo test.Foo._ctor
>> this [ebp-4]    = Error: array cast misalignment
> 
> _____________________________________________________
> 
> 
> 
> Jascha Wetzel wrote:
>> Ddbg is a Win32 D Debugger
>>
>> http://ddbg.mainia.de/releases.html
>>
>> This release mainly adds support for type cast and associative arrays. Type casts can be used to workaround the missing array and enum support in DMD's debug symbols.

Found another one... The debugger doesn't always seems to single step correctly. Happens with "in" and "ov" stepping. Steps correctly up to a point then the app runs to completion.

Source
----------------------
import std.stdio;
import std.c.string;
int main()
{
    //QSettings f = new QSettings;
    char [1024] Cmd;
    strcpy(Cmd.ptr, "Hello");
    printf("%s\n",Cmd.ptr); // have to printf 'cos writefln throws
    writefln("Finis");
    return 0;
}//end int main()

Debug Results
---------------------
Ddbg v0.0.4.2 alpha - D Debugger
Copyright (c) 2007 Jascha Wetzel
http://ddbg.mainia.de/

->bp test.d:1
Breakpoint set: test.d:4 0x402010
->r
ntdll.dll  loaded
KERNEL32.dll  loaded
USER32.dll  loaded
GDI32.dll  loaded
Breakpoint 0 hit
test.d:4 0x402010
int main()
->in
test.d:7 0x402015
    char [1024] Cmd;
->
test.d:8 0x402027
    strcpy(Cmd.ptr, "Hello");
->
Hello
Finis
Process terminated
->

more thanks :)
fixed in 0.0.4.3

dickl wrote:
> Found another one... The debugger doesn't always seems to single step correctly. Happens with "in" and "ov" stepping. Steps correctly up to a point then the app runs to completion.
> 
> Source
> ----------------------
> import std.stdio;
> import std.c.string;
> int main()
> {
>     //QSettings f = new QSettings;
>     char [1024] Cmd;
>     strcpy(Cmd.ptr, "Hello");
>     printf("%s\n",Cmd.ptr); // have to printf 'cos writefln throws
>     writefln("Finis");
>     return 0;
> }//end int main()
> 
> Debug Results
> ---------------------
> Ddbg v0.0.4.2 alpha - D Debugger
> Copyright (c) 2007 Jascha Wetzel
> http://ddbg.mainia.de/
> 
> ->bp test.d:1
> Breakpoint set: test.d:4 0x402010
> ->r
> ntdll.dll  loaded
> KERNEL32.dll  loaded
> USER32.dll  loaded
> GDI32.dll  loaded
> Breakpoint 0 hit
> test.d:4 0x402010
> int main()
> ->in
> test.d:7 0x402015
>     char [1024] Cmd;
> ->
> test.d:8 0x402027
>     strcpy(Cmd.ptr, "Hello");
> ->
> Hello
> Finis
> Process terminated
> ->

Awesome..

Unfortunately I forgot to look at that local variable Cmd (same test case). The debugger has a problem evaluating it:

 Ddbg v0.0.4.3 alpha - D Debugger
 Copyright (c) 2007 Jascha Wetzel
 http://ddbg.mainia.de/

 ->bp test.d:1
 Breakpoint set: test.d:3 0x402010
 ->
 Breakpoint set: test.d:3 0x402010
 ->r
 ntdll.dll  loaded
 KERNEL32.dll  loaded
 USER32.dll  loaded
 GDI32.dll  loaded
 Breakpoint 0 hit
 test.d:3 0x402010
 int main()
 ->in
 test.d:6 0x402015
     char [1024] Cmd;
 test.d:7 0x402027
     strcpy(Cmd.ptr, "Hello");
 test.d:8 0x402038
     printf("%s\n",Cmd.ptr);
 ->= cast(char[])Cmd
 Expression evaluated to empty data
 ->
--------------------------------------

Jascha Wetzel wrote:
> more thanks :)
> fixed in 0.0.4.3
> 
> dickl wrote:
>> Found another one... The debugger doesn't always seems to single step
>> correctly. Happens with "in" and "ov" stepping. Steps correctly up to a
>> point then the app runs to completion.
>>
>> Source
>> ----------------------
>> import std.stdio;
>> import std.c.string;
>> int main()
>> {
>>     //QSettings f = new QSettings;
>>     char [1024] Cmd;
>>     strcpy(Cmd.ptr, "Hello");
>>     printf("%s\n",Cmd.ptr); // have to printf 'cos writefln throws
>>     writefln("Finis");
>>     return 0;
>> }//end int main()
>>
>> Debug Results
>> ---------------------
>> Ddbg v0.0.4.2 alpha - D Debugger
>> Copyright (c) 2007 Jascha Wetzel
>> http://ddbg.mainia.de/
>>
>> ->bp test.d:1
>> Breakpoint set: test.d:4 0x402010
>> ->r
>> ntdll.dll  loaded
>> KERNEL32.dll  loaded
>> USER32.dll  loaded
>> GDI32.dll  loaded
>> Breakpoint 0 hit
>> test.d:4 0x402010
>> int main()
>> ->in
>> test.d:7 0x402015
>>     char [1024] Cmd;
>> ->
>> test.d:8 0x402027
>>     strcpy(Cmd.ptr, "Hello");
>> ->
>> Hello
>> Finis
>> Process terminated
>> ->

one thing is, that you can't cast a static array to a dynamic array in
ddbg, yet.
but not casting the expression gives the same result. this is a bug in
DMD's codeview symbols, though. the array is marked as having length 0.
i can't tell when exactly that happens, since it worked in your other
example (the TableStuff array).

dickl wrote:
> Awesome..
> 
> Unfortunately I forgot to look at that local variable Cmd (same test case). The debugger has a problem evaluating it:
> 
>  Ddbg v0.0.4.3 alpha - D Debugger
>  Copyright (c) 2007 Jascha Wetzel
>  http://ddbg.mainia.de/
> 
>  ->bp test.d:1
>  Breakpoint set: test.d:3 0x402010
>  ->
>  Breakpoint set: test.d:3 0x402010
>  ->r
>  ntdll.dll  loaded
>  KERNEL32.dll  loaded
>  USER32.dll  loaded
>  GDI32.dll  loaded
>  Breakpoint 0 hit
>  test.d:3 0x402010
>  int main()
>  ->in
>  test.d:6 0x402015
>      char [1024] Cmd;
>  test.d:7 0x402027
>      strcpy(Cmd.ptr, "Hello");
>  test.d:8 0x402038
>      printf("%s\n",Cmd.ptr);
>  ->= cast(char[])Cmd
>  Expression evaluated to empty data
>  ->
> --------------------------------------
> 
> Jascha Wetzel wrote:
>> more thanks :)
>> fixed in 0.0.4.3
>>
>> dickl wrote:
>>> Found another one... The debugger doesn't always seems to single step correctly. Happens with "in" and "ov" stepping. Steps correctly up to a point then the app runs to completion.
>>>
>>> Source
>>> ----------------------
>>> import std.stdio;
>>> import std.c.string;
>>> int main()
>>> {
>>>     //QSettings f = new QSettings;
>>>     char [1024] Cmd;
>>>     strcpy(Cmd.ptr, "Hello");
>>>     printf("%s\n",Cmd.ptr); // have to printf 'cos writefln throws
>>>     writefln("Finis");
>>>     return 0;
>>> }//end int main()
>>>
>>> Debug Results
>>> ---------------------
>>> Ddbg v0.0.4.2 alpha - D Debugger
>>> Copyright (c) 2007 Jascha Wetzel
>>> http://ddbg.mainia.de/
>>>
>>> ->bp test.d:1
>>> Breakpoint set: test.d:4 0x402010
>>> ->r
>>> ntdll.dll  loaded
>>> KERNEL32.dll  loaded
>>> USER32.dll  loaded
>>> GDI32.dll  loaded
>>> Breakpoint 0 hit
>>> test.d:4 0x402010
>>> int main()
>>> ->in
>>> test.d:7 0x402015
>>>     char [1024] Cmd;
>>> ->
>>> test.d:8 0x402027
>>>     strcpy(Cmd.ptr, "Hello");
>>> ->
>>> Hello
>>> Finis
>>> Process terminated
>>> ->