DGrok 0.3 released
Halfway there! DGrok can now parse 46 of the 91 Delphi RTL source files — a hair over half.
Except that, of course, it’s way more than halfway; it took a lot of work to get this far. Most of what’s left is the various statements like repeat, with, try..finally, etc.
And then, of course, there’s the fact that it’s probably way less than halfway. Include files ({$I} / {$INCLUDE}) aren’t working, and I haven’t figured out how they’ll fit into the demo app yet. And there’s the whole issue around symbol tables, which I’ll need to do anything useful like refactoring.
Still, it’s a major milestone, so I figured I’d do a release. DGrok 0.3 is now available for download. Major new stuff in this release:
- If you double-click a file that’s failing because of a compiler directive, it will now take you to the error location rather than showing a .NET “unhandled exception” dialog.
- Began adding statement handling. Currently it can’t handle much — mostly method calls, assignments, and if statements. This is my main area of focus right now.
- Parsing of method implementations, including the smarts to not expect a method body if the method is declared “forward” or “external”.
- Parsing of unit implementation sections.
- Parsing of “program” and “library” files.
- Fixed parsing of “const” sections that come inside a class or record. (When the const section was followed by another visibility section, it was getting confused and thinking the “public” was the name of another constant; it doesn’t anymore.)
- Many minor tweaks to the grammar (it turns out that semicolons are optional after field declarations; I didn’t have threadvar in the grammar yet; initialized record-type variables; operator overloads; that sort of thing).
- Lots of exciting behind-the-scenes stuff that you wouldn’t recognize as cool unless you’d already been working with the code: strongly-typed node properties, generic ListNode and DelimitedItemNode, and partial classes.
September 25th, 2007 at 1:57 pm
I’m a little confused as to what DGrok is trying to do…. perhaps I missed an earlier post?
Since this is all C#, it is presumably a .net project, in which case why not simply leverage the CodeDOM and the Delphi provider? I have an on-going "background task" where I’m working on a similar - but at this stage less comprehensive - thing for native Delphi (dealing with code structure, but not going as far as actual implementation code - initially at least) but don’t understand the need for it in .NET.
Unless it’s just for fun?
I am only an egg, after all.
September 25th, 2007 at 5:38 pm
The Delphi CodeDom only supports a fraction of the legal Delphi syntax (only enough to get the old WinForms designer working). For example, in a CodeDom, every statement inside a with is ignored. Also, since CodeGear has removed WinForms support from the IDE, the limited CodeDom support we had in BDS 2006 may completely disappear in the future.
September 25th, 2007 at 7:43 pm
Ah OK, makes sense.
FTR, I’m not a huge fan of CodeDOM, not least because the model it abstracts doesn’t actually "fit" Delphi very well, and have oft wondered why Borland didn’t do a "proper job" of their own.
Your comments about it just make it even more puzzling. Maybe, as you say, the dropping of Winforms might lead them down that path after all.