the source isn't in best shape. but i've put it here for you:
http://ddbg.mainia.de/Ddbg-0.0.4.1-alpha-src.zip
the license is proprietary, so it's just food for curiosity.

J Duncan 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.
> 
> Just curious when you are going to release the source code?

Jascha Wetzel wrote:
> the source isn't in best shape. but i've put it here for you:
> http://ddbg.mainia.de/Ddbg-0.0.4.1-alpha-src.zip
> the license is proprietary, so it's just food for curiosity.
> 

Very cool, thank you very much.

Jascha Wetzel wrote:
> the source isn't in best shape. but i've put it here for you:
> http://ddbg.mainia.de/Ddbg-0.0.4.1-alpha-src.zip
> the license is proprietary, so it's just food for curiosity.

Did you attach the right license.txt file?  Because this doesn't seem very proprietary to me:

"""
Ddbg is Copyright (C) 2007 Jascha Wetzel
Official website: http://ddbg.mainia.de

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to redistribute it, subject to
the following restrictions:

* The origin of this software must not be misrepresented; you must not
  claim that you wrote the original software.
* You may only redistribute the software unmodified, in the form and
  prepackaging it is available from the official website.
"""

If that's the license you meant to include, then boffo!  That's great news.

--bb

Bill Baxter wrote:
> Jascha Wetzel wrote:
>> the source isn't in best shape. but i've put it here for you:
>> http://ddbg.mainia.de/Ddbg-0.0.4.1-alpha-src.zip
>> the license is proprietary, so it's just food for curiosity.
> 
> Did you attach the right license.txt file?  Because this doesn't seem very proprietary to me:
> 
> """
> Ddbg is Copyright (C) 2007 Jascha Wetzel
> Official website: http://ddbg.mainia.de
> 
> This software is provided 'as-is', without any express or implied
> warranty. In no event will the authors be held liable for any damages
> arising from the use of this software.
> 
> Permission is granted to anyone to use this software for any purpose,
> including commercial applications, and to redistribute it, subject to
> the following restrictions:
> 
> * The origin of this software must not be misrepresented; you must not
>   claim that you wrote the original software.
> * You may only redistribute the software unmodified, in the form and
>   prepackaging it is available from the official website.
> """

Oh, wait... I see.  I didn't look closely enough at the fine print.  You can use it for any purpose, except for <huge category of potential purposes>.

Oh well.  Thanks for putting the source code out anyway.

--bb

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

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

i will probably loosen that at some point. but i'm still not sure how i want to deal with this beyond the fact that ddbg will be free of charge.

Bill Baxter wrote:
> Bill Baxter wrote:
>> Jascha Wetzel wrote:
>>> the source isn't in best shape. but i've put it here for you:
>>> http://ddbg.mainia.de/Ddbg-0.0.4.1-alpha-src.zip
>>> the license is proprietary, so it's just food for curiosity.
>>
>> Did you attach the right license.txt file?  Because this doesn't seem very proprietary to me:
>>
>> """
>> Ddbg is Copyright (C) 2007 Jascha Wetzel
>> Official website: http://ddbg.mainia.de
>>
>> This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.
>>
>> Permission is granted to anyone to use this software for any purpose, including commercial applications, and to redistribute it, subject to the following restrictions:
>>
>> * The origin of this software must not be misrepresented; you must not
>>   claim that you wrote the original software.
>> * You may only redistribute the software unmodified, in the form and
>>   prepackaging it is available from the official website.
>> """
> 
> Oh, wait... I see.  I didn't look closely enough at the fine print.  You can use it for any purpose, except for <huge category of potential purposes>.
> 
> Oh well.  Thanks for putting the source code out anyway.
> 
> --bb

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

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

oh wait, you're one of the ddl.coff authors, right?
if you happen to be interested in the codeview stuff from ddbg or
something, i'll donate this to the ddl project anytime...

J Duncan wrote:
> Jascha Wetzel wrote:
>> the source isn't in best shape. but i've put it here for you:
>> http://ddbg.mainia.de/Ddbg-0.0.4.1-alpha-src.zip
>> the license is proprietary, so it's just food for curiosity.
>>
> 
> Very cool, thank you very much.