Sunday, June 26, 2005

That's the name of the class that does most of the heavy lifting for the newer, more robust implementation of member select, complete word, and hopefully the other future actions that are part of a language service's parsing. I've refactored a lot of code; the end result is a faster-better-cleaner implementation of parsing services so far.

Still on my todo list:

Cache the AST tree for the 'autos' and 'locals' function of the debugger.

Project support. A biggie, obviously.

Debugger support. Another biggie.

Integrate Boo's keywords and macros into code completion. I'll be honest: macros and builtins seem kind of difficult to do dynamically without hard-coding them all. Macros like "print" are really expanded to PrintMacro - how should I handle this?

Tuesday, June 21, 2005

As you can tell from the screen-shot, its a bit broken because I'm dealing with scope issues - z shouldn't be in the complete word list, for example.

Also, typing with the list open is dog slow - I'm not sure why. It might be a flaw in my IScanner implementation. C# doesn't exhibit this, so its definitely wrecked on my end.

Another issue I have to deal with is sentinels -- they're currently a randomly generated GUID so they will not collide with any simiarily named elements in someone else's code. The tricky part is, Boo won't parse 'STRING LITERAL' as a string literal if it is not *exactly to the character* on the tab-space as the rest of the code.

I'm using sentinels in the AST because I cannot camp out the lexical information and wait for it to pass the line and column that was passed to me by Visual Studio. There's no "start" and "end" information available, so I don't want to jump the gun too early -- you know how that is.

To solve the issue of 'z' not being in scope, I'll have to temporarily "stop" the parser when I hit the sentinel, and traverse up the parent nodes until I'm out of any methods. I can't just hit the first ParentNode, because if the sentinel is in a closure, then there will be two methods - the closure, and the parent method of the closure. Yeah, that can be problematic, can't it? So I'll have to navigate upwards until I'm clear of all methods, and perhaps mark that node as the parent node instead of the way I am doing it now.

Well, my kinda-broken but kinda-not CompleteWord functionality was my feature for the day.

Monday, June 20, 2005

If the character before the caret is a '.' (or has non-whitespace characters leading up to a '.') then do a regular member look-up.

However, if not, then insert a new string literal based on a randomly selected GUID (so you never hit a 'valid' string literal), and once you hit that string literal start working your way back up the chain.

If you're in a method, grab the locals first.

If not, go up to the parent node, grab its INamespace and probe it for its members. Go up (again) and probe, et all, until there is no more (aka, something explodes).

Always make sure that OnImport is passed through cleanly (mark'em to grab their members later).

There's just one problem: this does not allow for 'context sensative' code completion like C# does. I think I can work around this by checking to see if the parent node is a generator, class definition, struct definition or etc, then doing the special voodoo magick.

I freaking love that Boo has its own AST available like this: I know *nothing* about this sort of programming work but Boo makes it a FREAKING BREEZE.

Because I just spent a day working on a problem that did not exist - specifically I was finding that there were methods that were "slipping" through the filter I had designed to hide out-of-scope members. The irony? I had it all wrong.

I was looking at the list of .NET 1.1 System.String members in comparison to those that slipped through the filter, when my eyes should have been on .NET 2.0's System.String members. Although Boo was developed under .NET 1.1, since I was running VS2005 on .NET 2.0... yeah, I was using the 2.0 version of System.String. Totally screwed me up - for AN ENTIRE DAY.

Like all good ideas, the thought to check came after I had been away from the computer for an hour or so.

Saturday, June 18, 2005

The grind continues. I just got "basic" code completion working. To be honest, I had it working awhile ago, but due to some basic but important information that was not in the document about LanguagePreferences that was in the Managed Package Framework SDK, I fumbled around for almost an hour looking for a problem that was a one line solution.

Basically, although you can enable CodeSense by using the ProvideLanguageService attribute, its not really "enabled" until you return a LanguagePreferences object that has "EnableCodeSense = true." Let's face it: that's not very obvious, and it makes me wonder if I even need the named parameter in ProvideLanguageService in the first place.

Anyway, I still have to recognize "overloaded" operators and provide quick information similar to C#'s intellisense: method signature, overloads available, etc. Hopefully there's a method somewhere in the Managed Package Framework that will allow me to probe the .xml documentation format.

I've been able, so far, to stick to my "feature a day" goal for the package.Basic code completion ;)

Thursday, June 16, 2005

After finishing up my given / when patch for Boo, which adds a construct like

given value:

when "hello":

print "Value found!

to the language. Its essentially an enhanced "switch" construct. The patch has a few flaws that I think are due to bugs in the Boo compiler, but Rodrigo hasn't been around lately, so I can't prod him for information. I just submitted the patch in hopes that someone else can diagonse the problem. Rodrigo is the lead developer for the Boo language. ;)

I got my Visual Studio 2005 Team Suite DVDs two days ago, and since then I've been working on a Boo plug-in. I have intentions to make it open-source (BSD/MIT license) since nothing in the EULA explicitly states that I cannot - the only clause that comes close is the boilerplate "You can't do anything that requires the source of this product to be delievered," which is A-OK: I wouldn't want to put someone in that position anyway, which is why all my code is BSD/MIT. BSD/MIT? The licenses are so similar I can barely differentiate between them anymore.

So far I have syntax colorization "kinda sorta" working. I don't know how to handle nested comments or nested triple-quoted strings since there's really no way to keep track of rank - the class that apparently calls IScanner implementations, which handle finding tokens in the current file, does so in a line-by-line way. This means there's no guarntee that the next line you evaluated is right after the line you last evaluated.

I posted on forums.microsoft.com about possible work-arounds, but no answer yet.