Ter, Just to keep adding:
>Refactoring No complaints on this system. It does the most common things. >displaying decision DFA (well, one person mentioned to say that sometimes it >gets stuck) Do you mean the syntax diagram side? I don't recall seeing it get stuck. I do, however, use the syntax diagrams constantly and find having the visualization one of the best features of using AW. Again an auto-hide like "pin" interface might be nice. Another feature that could be potentially helpful, although not a huge priority perhaps, would be to full screen it. That would be nice for class demonstrations. >only one person mentioned showing the generated code Since it's pretty straightforward to generate the code, it's not a huge deal for me either way. >group/ungroup rules, rule collapsing No real preference. Many IDEs have this and it's useful for certain kinds of boiler plate code (e.g., generated forms). IF there's a use that's helpful, it "might" include collapsing sections, like options/members/boilerplate stuff, or just semantic actions, or something else. I don't use this a whole lot in large scale code though in other IDEs either, though. A few other thoughts after reading your post: 1. I definitely agree that the syntax diagram, interpreter, console, and debugger are sort of odd as tabs. Having them all as pinned windows is more common in an IDE and has the advantage of letting you see more than one at a time (if you wish). 2. It might be nice if you could have (on mac) a tabbed interface for multiple grammars instead of multiple floating windows. My most common use case is switching back and forth between a tree walker and a parser. Managing multiple tabs on multiple windows is somewhat more tedious than having one window where you can click on a new file and the syntax/interpreter, etc windows auto-respond accordingly. There's a few more thoughts, for what it's worth, Stefik On Fri, Sep 2, 2011 at 12:32 PM, Andreas Stefik <[email protected]> wrote: > On Fri, Sep 2, 2011 at 11:58 AM, Terence Parr <[email protected]> wrote: >> >> On Sep 1, 2011, at 1:20 PM, Andreas Stefik wrote: >>> Debugger: >>> >>> I'll admit that I don't really use the debugger. I have before and I >>> really like it, but most of the projects I do require that you >>> integrate into the build cycle of projects in the NetBeans development >>> environment. In practice, I've never found a way I can really run the >>> debugger, with all of my complicated build information set together >>> (e.g., tricky dependencies, ant scripts) in such a way that it is >>> worth the effort. >> >> hi Andreas,So it's hard to use the remote debug feature whereby AW you can >> listen to socket events from the parser? All I do is turn on -debug, >> recompile and start my project. when that parser starts up, it blocks >> waiting for a connection from AW. > > > Hmm, the honest answer is that I'm not sure, as I haven't tried it > that way. When I debug the parser on my bigger projects, I'm usually > touching the semantics/other phases anyway, so I usually fire up > NetBeans, set a breakpoint in the generated code, and fire up the > NetBeans debugger. So I don't know. What you mentioned certainly > doesn't sound difficult, although I don't know for sure if it would > help me in my most common use cases. > > Honestly, though, like I said, I use the rest of AW far more often > than I use the debugger, so I'm not the best judge on that side. > > Stefik > List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
