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