www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dparser 0.148

reply AgentOrange <AgentOrange_member pathlink.com> writes:
Ive updated dparser with dmd 0.148. 
dparser is a D port of the dmd front end.

its up for svn here: http://svn.dsource.org/projects/dparser/trunk/
Feb 28 2006
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Any hints on compilation and usage?

AgentOrange wrote:
 Ive updated dparser with dmd 0.148. 
 dparser is a D port of the dmd front end.
 
 its up for svn here: http://svn.dsource.org/projects/dparser/trunk/
 
 
 

Feb 28 2006
prev sibling next sibling parent bobef <bobef lessequal.com> writes:
AgentOrange wrote:
 Ive updated dparser with dmd 0.148. 
 dparser is a D port of the dmd front end.
 
 its up for svn here: http://svn.dsource.org/projects/dparser/trunk/
 
 
 

I was wondering what about the d parser in dsource/bingings project. It is only few files so it looks lighter. On other hand we all know that DMD is blazing fast... Someone used these things? I mean which one is faster and which one is easier. I saw that dparser is being used on Poiseidon, so maybe you guys can tell something about it?
Mar 01 2006
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
AgentOrange wrote:
 Ive updated dparser with dmd 0.148. 
 dparser is a D port of the dmd front end.
 
 its up for svn here: http://svn.dsource.org/projects/dparser/trunk/

Interesting idea. Is this a direct conversion that's supposed to be functionally identical, or do you fix the odd bug here and there in the process? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 01 2006
prev sibling parent reply bls <lietz wanadoo.fr> writes:
Hi ,
Due to the fact that I am working on an D IDE it would be nice to do
some semantic analysis. Means concreate :

I would like to know wether it is possible to create a tool ( in fact a 
DLL that I would like to create on top of your work) which enables me to 
do :


-- Error checking during editing time.
-- Creating an Outline (not a class diagramm) just a "current code tree"
-- Implementing "intellisense" (or something better)

I do not ask for a concrete implementation, I ask for a kind of guide to 
"getting started ..."
Björn
Mar 01 2006
parent reply bobef <bobef lessequal.com> writes:
bls wrote:
 Hi ,
 Due to the fact that I am working on an D IDE it would be nice to do
 some semantic analysis. Means concreate :
 
 I would like to know wether it is possible to create a tool ( in fact a 
 DLL that I would like to create on top of your work) which enables me to 
 do :
 
 
 -- Error checking during editing time.
 -- Creating an Outline (not a class diagramm) just a "current code tree"
 -- Implementing "intellisense" (or something better)
 
 I do not ask for a concrete implementation, I ask for a kind of guide to 
 "getting started ..."
 Björn

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?
Mar 01 2006
parent reply bls <lietz wanadoo.fr> writes:
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
Mar 01 2006
next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
bls wrote:
 
 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

I have a "code analyzer" project on dsource.org, essentially it _aims_ to perform what you mentioned above
 -- Error checking during editing time.
 -- Creating an Outline (not a class diagramm) just a "current code tree"
 -- Implementing "intellisense" (or something better)

and hopefully more. BUT .. it's still a work-in-progress and is far far from being complete. Hell I'm still not finished with the parser part yet!! but just so you know, there /is/ such a project. http://trac.dsource.org/projects/codeanalyzer/
Mar 01 2006
prev sibling parent reply AgentOrange <AgentOrange_member pathlink.com> writes:
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?
Mar 01 2006
next sibling parent Agent Orange <no spam.com> writes:
another option is to just strip out all the semantic analysis code from 
dparser, which 99% of the users probably wont need.... i mostly ported 
this code out of intellectual curiosity about how the compiler works.


AgentOrange wrote:
 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?

Mar 01 2006
prev sibling parent reply pragma <pragma_member pathlink.com> writes:
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
Mar 03 2006
parent reply AgentOrange <AgentOrange_member pathlink.com> writes:
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......
Mar 03 2006
parent reply pragma <pragma_member pathlink.com> writes:
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
Mar 03 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
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
Mar 19 2006