FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Status Log

 
Post new topic   Reply to topic     Forum Index -> DBug
View previous topic :: View next topic  
Author Message
AgentOrange



Joined: 21 Jul 2005
Posts: 61

PostPosted: Wed Sep 28, 2005 5:10 pm    Post subject: Status Log Reply with quote

ok I fixed whatever was sending the compiler into an infinite loop. I tried to isolate whatever caused this but I couldnt begin to tell you. I just had to start adding imports as private until it worked. it was weird. anyway the latest codebase builds everything fine.
Back to top
View user's profile Send private message
AgentOrange



Joined: 21 Jul 2005
Posts: 61

PostPosted: Sat Oct 08, 2005 4:40 am    Post subject: Reply with quote

latest version has a variable watch window - currently only works with basic types that are on the stack
Back to top
View user's profile Send private message
AgentOrange



Joined: 21 Jul 2005
Posts: 61

PostPosted: Tue Oct 11, 2005 10:57 am    Post subject: Reply with quote

Ok the latest code has a toolbar and a few fixes etc.

Ive been kind of feeling my way along so far because I wasnt sure yet what codeview supplied nor what was available in the DMD apps. The CodeView debug symbol info has some problems. Its missing bits of information here and there which makes it difficult to browse complex data types such as arrays. Its near futile to get walter to help with anything like this - which is fine because hes busy anyway. so...

Ive decided to move forward with one of my other projects to create a custom DMD front end to generate reflection data. in this case to generate a source browser database to be used in conjunction with the codeview data to enable complete D debugging. My first step is to complete a library out of the DMD front end code that exposes a parsed symbol tree. Im also creating a D module to transform this C data into a D API. This is about 50? done and mostly just grunt work. From there I will add this api and library to dbug and be able to "see" all D application data.

eventually I hope to extend this front end library to create a refactoring code browser - which should be pretty easy given Ds mechanical simplicity.

anyone have any thoughts on all this?
Back to top
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Tue Oct 11, 2005 12:06 pm    Post subject: Reply with quote

AgentOrange wrote:
Ive decided to move forward with one of my other projects to create a custom DMD front end to generate reflection data.

...

anyone have any thoughts on all this?


Go for it. As you already know, I'm still shopping for a better solution than .map file loading for DDL, so I'm keenly interested. Since there's no front-end out there that lets me see all the symbols currently installed in the running process (exe), I pretty much stuck with the aforementioned (and non-portable?) solution.

The only gotcha with writing a D parser is: are you prepared to keep up with specification changes with D? AFAIK, you might succeed where others have failed here largely because it looks like the language spec is finally congealing; the addition of the $ token, for example was the kiss of death for a whole bunch of projects a while back.

Also, I have some ideas for what might make a better reflection interface than the current TypeInfo mess we have right now. 6 weeks ago, I jotted down a class tree that makes more sense (to me anyway), and would open the door for a possible "code generation" mirror set of classes (like .NET reflection.emit). Just msg me or post here if you're interested. Smile
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
AgentOrange



Joined: 21 Jul 2005
Posts: 61

PostPosted: Tue Oct 11, 2005 12:19 pm    Post subject: Reply with quote

pragma wrote:
The only gotcha with writing a D parser is: are you prepared to keep up with specification changes with D? AFAIK, you might succeed where others have failed here largely because it looks like the language spec is finally congealing; the addition of the $ token, for example was the kiss of death for a whole bunch of projects a while back.

Also, I have some ideas for what might make a better reflection interface than the current TypeInfo mess we have right now. 6 weeks ago, I jotted down a class tree that makes more sense (to me anyway), and would open the door for a possible "code generation" mirror set of classes (like .NET reflection.emit). Just msg me or post here if you're interested. Smile


Im using the actual front-end code released by walter with the compiler. It has all the back end stubbed out and thats where my code plugs in and generates symbols. the only hastle is the front end is written in C, thats why im creating a C library with a D API built on top.

I would definately like to see your design ideas - thats the only real questions I have. Im not sure what the best way to handle the symbols are. Ive written about 3 different symols systems now between these projects and it can be done a few different ways. Id like to find a nice system that can work with everything. And I can see how this would help with DDL.
Back to top
View user's profile Send private message
AgentOrange



Joined: 21 Jul 2005
Posts: 61

PostPosted: Wed Nov 16, 2005 1:49 am    Post subject: Reply with quote

Ive begun porting the DMD front end code into D. I have just checked in the first pass with much of the code ported. Its not completely working yet as I still have some stuff commented out and some features disabled.
Back to top
View user's profile Send private message
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Wed Nov 16, 2005 12:34 pm    Post subject: Reply with quote

AgentOrange wrote:
Ive begun porting the DMD front end code into D. I have just checked in the first pass with much of the code ported. Its not completely working yet as I still have some stuff commented out and some features disabled.
That sounds like a good idea. How are you planning to keep up with compiler changes? Even though D is changing slower than it used to, it still seems to be evolving as it moves towards 1.0. Have you been using a lot of automation in your porting effort?

I've been maintaining and even slowly extending Pavel Minayev D2HTML tool for quite a while now, but I think I'd drop that effort if someone ported Ddoc from the DMD front end into D. I didn't notice doc.d in the svn, but I'm crossing me fingers that it's on your To-Do list. Wink

Even if you don't go that far, I might consider doing that much myself (even with my limited C/C++ skills) if I can figure your style of porting. (Someone else has mentioned that Walter's style of writing C++ brings to mind how D is designed. Hopefully, that'd make it easier to port to D than the style of C++ that others might write.)
Back to top
View user's profile Send private message AIM Address
AgentOrange



Joined: 21 Jul 2005
Posts: 61

PostPosted: Wed Nov 16, 2005 1:09 pm    Post subject: Reply with quote

Nah I didnt bother automating it since so much depended on contex which I wasnt sure of. I ran some global string replacements then went through each module by hand. Some fundamental things changed when i went from a structure (pointers) to a class (reference). Also some of the code is not used since more functionality is supplied by D itself, and some of the code will change alltogether. I dont think maintaining it will be an issue as I can just do a diff between each DMD release and implement whatever changes by hand. I doubt its going to be too bad. I currently have no plans to implement any of the DDoc stuff since Im more interested in parsing the code itself. I will say I have learned some things about D by doing this, it is quite an interesting design.

Ive currently got it parsing basic declarations as im going through it verifying and testing. Ive got some of the complex number and UTF stuff disabled right now since these will be handled by D and I am currently unexperienced in these areas. But so far Im extremely happy with the results. We are going to be able to produce a very nice compiler representation of the code, in D, and about as close to the actual compiler as one can get. I think this can be a pretty powerfull tool for D development. Im going to feed this into a code refactoring browser and a debugger, plus we can use it to generate our reflection data, or handle the 'auto header system' people have been discussing. We can even create a compile time metaprotocol for altering code programatically, which im pretty excited about myself.

good stuff Very Happy
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> DBug All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group