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/

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/
> 
> 
> 

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?

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.

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

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?

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

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/

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?

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?
> 
> 
> 
>