In article <du4l8c$16mh$1@digitaldaemon.com>, AgentOrange says...
>
>In article <du4ipa$135d$1@digitaldaemon.com>, bls says...
>>
>>
>>bobef :
>>> Seems that there are currently three IDEs for D in development (your one, Poseidon, akide) that needs the above features. Maybe we don't need to do this work three times?
>>
>>Indeed! Just forgot to mention that Ben Hinkle allready has enhanced the
>>dmd frontend with stubs. (in C++). Unfortunately Ben offers not much
>>intro-material. Hint. Hint....
>>Björn
>
>Ive been thinking about this, but A major difference between dmdfe in C++ and dparser in D is that 'stub' class methods cant be broken out of the class module into a seperate file. hes got all the stubs in one place... I think I could mangle some identifiers to do it, or just implement some sort of external callback system with global functions or delegates.... If anyone has a clean solution to this Id love to hear it....
>
>And yes one of the reasons Ive done this is to support a whole range of D tools, including an IDE/debugger Im working with. Id like to have some sort of clean interface for higher level tools which dont need to deal with the internals for dparser. I chose using the front end because it can easily be kept current to the language just by following diffs between dmd releases, It also offers a rich symbol and object heirarchy (ast) which a simple lexer parser doesnt. It also lends itself well to experimenting with the languge, which ive recently begun playing with now that dparser is updated (for example the new scope guards are just symbols that rewrite themselves as try..catch blocks). I currently just access dparser DSymbols etc in my code, but Im thinking of creating some sort of independent class hierarchy which dparser can generate. This secondary symbol hierarchy could be used in tools such as IDEs and class browsers and wouldnt have to cary around parse and semantic analysis code. (it might even be useful for reflection;)..... Any ideas?

I, for one, would love to use dparser to generate better DDOC output; especially for cross-references and class-tree diagram generation.  Your work seems to get the job mostly done, but it's unclear how to hook into the DDOC generation parts (they seem to be mostly commented out).

As for a clean solution for hooking into dparser, I think you're on the right track with the class/symbol tree.  It would be by far the most useful representation of what the compiler generates.  The current lookup scheme (that was added on for the IDE) seems usable enough, but its difficult knowing where to start.  Reducing the entire scheme to "get me the class tree for this source file" would be a godsend. :)

- EricAnderton at yahoo

In article <du9jar$2scq$1@digitaldaemon.com>, pragma says...
>
>In article <du4l8c$16mh$1@digitaldaemon.com>, AgentOrange says...
>>
>>In article <du4ipa$135d$1@digitaldaemon.com>, bls says...
>>>
>>>
>>>bobef :
>>>> Seems that there are currently three IDEs for D in development (your one, Poseidon, akide) that needs the above features. Maybe we don't need to do this work three times?
>>>
>>>Indeed! Just forgot to mention that Ben Hinkle allready has enhanced the
>>>dmd frontend with stubs. (in C++). Unfortunately Ben offers not much
>>>intro-material. Hint. Hint....
>>>Björn
>>
>>Ive been thinking about this, but A major difference between dmdfe in C++ and dparser in D is that 'stub' class methods cant be broken out of the class module into a seperate file. hes got all the stubs in one place... I think I could mangle some identifiers to do it, or just implement some sort of external callback system with global functions or delegates.... If anyone has a clean solution to this Id love to hear it....
>>
>>And yes one of the reasons Ive done this is to support a whole range of D tools, including an IDE/debugger Im working with. Id like to have some sort of clean interface for higher level tools which dont need to deal with the internals for dparser. I chose using the front end because it can easily be kept current to the language just by following diffs between dmd releases, It also offers a rich symbol and object heirarchy (ast) which a simple lexer parser doesnt. It also lends itself well to experimenting with the languge, which ive recently begun playing with now that dparser is updated (for example the new scope guards are just symbols that rewrite themselves as try..catch blocks). I currently just access dparser DSymbols etc in my code, but Im thinking of creating some sort of independent class hierarchy which dparser can generate. This secondary symbol hierarchy could be used in tools such as IDEs and class browsers and wouldnt have to cary around parse and semantic analysis code. (it might even be useful for reflection;)..... Any ideas?
>
>I, for one, would love to use dparser to generate better DDOC output; especially for cross-references and class-tree diagram generation.  Your work seems to get the job mostly done, but it's unclear how to hook into the DDOC generation parts (they seem to be mostly commented out).
>
>As for a clean solution for hooking into dparser, I think you're on the right track with the class/symbol tree.  It would be by far the most useful representation of what the compiler generates.  The current lookup scheme (that was added on for the IDE) seems usable enough, but its difficult knowing where to start.  Reducing the entire scheme to "get me the class tree for this source file" would be a godsend. :)
>
>- EricAnderton at yahoo

I agree, its pretty raw still and mostly unusable unless you know the dmd front end. I added those symbollistings from poseidon just for the heck of it. But my main goal up till now was to get the parser up to date with the current compiler. Ive been kind of afraid to touch it until I had it updated because of the way ive managed converting the code. But Ive done some extensive testing lately with parsing then generating code and verifying binaries are identicle, which has been successfull. Yes I have completely avoided ddoc until this point, but my next goal is to get ddoc.c converted to D and then I will work out an interface for dparser. Yeah there has been some discussions around #D about docs and someone even mentioned going back to doxygen (shudder), so I figure a ddoc implementation we can get our hands dirty with can be pretty usefull......

In article <du9p97$6rf$1@digitaldaemon.com>, AgentOrange says...
>
>
>I agree, its pretty raw still and mostly unusable unless you know the dmd front end. I added those symbollistings from poseidon just for the heck of it. But my main goal up till now was to get the parser up to date with the current compiler. Ive been kind of afraid to touch it until I had it updated because of the way ive managed converting the code. But Ive done some extensive testing lately with parsing then generating code and verifying binaries are identicle, which has been successfull. Yes I have completely avoided ddoc until this point, but my next goal is to get ddoc.c converted to D and then I will work out an interface for dparser. Yeah there has been some discussions around #D about docs and someone even mentioned going back to doxygen (shudder), so I figure a ddoc implementation we can get our hands dirty with can be pretty usefull......

Awesome.  I'm glad to hear that you're heavily into hacking this thing (amoung other things).  DMD's doc generation is adequate for basic stuff, but I really want to get first-class documentation going.  Its time to swim in the deep end of the pool, and this looks like the fastest way to get there.

- EricAnderton at yahoo

I just downloaded the source and tried to build it. I got errors about things which are defined in std.c.string;

Adding:
  import std.c.string;

to dparser.Root fixes those and it compiles. Now however test_dparser.exe crashes, it's crashing on:

foreach( SymbolListing l ; dparser.symbolRegistry.allListings )

because dparser.symbolRegistry is null. The code that seems to create it is commented out:

/*		
		// generate package list
		sortPackages();

		// generate alphabetized symbol list registry
		if( modules.length )
		{
			symbolRegistry = new SymbolRegistry( modules );
		}
*/

I was just wondering what's going on.

Regan