dmd support for IDEs

Walter Bright newshound1 at digitalmars.com
Sat Oct 10 22:57:08 PDT 2009


Jeremie Pelletier wrote:
> The IDE usually keeps the files in memory and could therefore just call 
> something like getSemantics(char** fileBuffers, int* fileSizes, int 
> nFiles, ParseNode* parseTree) and have its parse nodes already allocated 
> in process memory ready for use.
> 
> Considering a lot of IDEs like to re-parse the current file every time 
> the keyboard is idle for a few seconds, this could really help 
> performance, nothing is more annoying than an IDE that feels unresponsive.

I understand and agree, but we are operating under severe manpower 
constraints. I don't have a 100 million dollar budget! (I'm sure MS 
spends more than that on VS.)

You're certainly welcome to take the compiler front end and try and make 
a dll out of it or integrate it directly into an IDE. But what I 
suggested would probably get a lot of results for a minimal investment 
in the front end and a minimal investment in existing IDEs.



My experience with making responsive interactive apps on slow machines 
suggests that using a multithreaded approach would make the IDE 
responsive even if the underlying parsing process is slow. What you do 
is, every time the source file changes, fire off a background thread at 
a low priority to reparse. If the source changes before it finishes, 
restart that thread. When the IDE actually needs the results, it uses 
the results of the most recently finished parse.

With this approach, there won't be any hangs where the keyboard is 
unresponsive.


Experience also suggests that using fork/exec rather than a shared dll 
approach is much more robust and easier to develop. The reason is that 
the former uses separate processes, which cannot step on each other. The 
latter puts everything in one process space, where you've got all the 
lovely, time-consuming, hair-pulling concurrency problems. The utter 
failure of the parse process also cannot bring down the IDE.



More information about the Digitalmars-d mailing list