View previous topic :: View next topic |
Author |
Message |
AgentOrange
Joined: 21 Jul 2005 Posts: 61
|
Posted: Wed Sep 28, 2005 5:10 pm Post subject: Status Log |
|
|
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 |
|
|
AgentOrange
Joined: 21 Jul 2005 Posts: 61
|
Posted: Sat Oct 08, 2005 4:40 am Post subject: |
|
|
latest version has a variable watch window - currently only works with basic types that are on the stack |
|
Back to top |
|
|
AgentOrange
Joined: 21 Jul 2005 Posts: 61
|
Posted: Tue Oct 11, 2005 10:57 am Post subject: |
|
|
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 |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Tue Oct 11, 2005 12:06 pm Post subject: |
|
|
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. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
AgentOrange
Joined: 21 Jul 2005 Posts: 61
|
Posted: Tue Oct 11, 2005 12:19 pm Post subject: |
|
|
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. |
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 |
|
|
AgentOrange
Joined: 21 Jul 2005 Posts: 61
|
Posted: Wed Nov 16, 2005 1:49 am Post subject: |
|
|
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 |
|
|
jcc7
Joined: 22 Feb 2004 Posts: 657 Location: Muskogee, OK, USA
|
Posted: Wed Nov 16, 2005 12:34 pm Post subject: |
|
|
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.
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 |
|
|
AgentOrange
Joined: 21 Jul 2005 Posts: 61
|
Posted: Wed Nov 16, 2005 1:09 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
|