Extension syntax for Boo

I was thinking about the proposals for expanded extensions for Boo -- I would rather call them mixins, since this is what they seem like in my mind, with their syntactic sugar. Its also easier to type mixin.

I've been thinking about properties and mixins. Take the following example, with my completely made-up syntax.

mixin System.String:
Words as (string):
return self.Split(' ', ';', '.', '!') #Doesn't work, no implict conversion to char

As far as code goes, its pretty simple. Infact, this could easily be a method.

def Words(target as string):
return self.Split(' ', ';', '.', '!')

Then you, know, Words("Hello, world!") is just as effective as "Hello, world!".Words.

But sometimes, being able to do something one way doesn't necessarily mean its better than doing it another way. This kind of syntax blends very well with the way of the OOP, and allows for a better visual recognition of what object is being manipulated.

The flip side is, of course, "Is Words part of System.String, or an extension?"

My answer is, "Does it matter?" Do you really need to know wheither its an external function or an instance function? Well, that would be my answer in an ideal system, where extensions showed up when you used reflection on a type. Right now, they don't, though, so knowing the difference between an extension and instance members is important if you plan on doing reflection-based operations on a type at runtime - you'll have to root around in some namespaces for those extensions rather than just checking the members of a type.

Hey, you!

Rodrigo B de Oliveira, why the hell are you syndicated by Monologue?! You post like once a month, you lazy bastard. ;)

Thanks, Blogger.

Thanks for saying, "Hey, you can't post this because it has unclosed HTML tags!" to my face but secretly going behind my back and posting the entry anyway, generating at least 10 half-assed blogposts because I think none of my posts are showing up on my blog: people tend to assume that when you tell them, anyway.

Ugh. I think I should get a new blog somewhere else. That's ridiculiously pathetic.

Attack of the WinFX December CTP!

http://blogs.msdn.com/tomarcher/archive/2005/12/19/505502.aspx

The WinFX December CTP has been dropped to the public at large. The one big change I'm sure everyone has noticed by now is that, aside from a few minor tweaks, the "mini language" of XAML has been removed entirely. Bits and chunks have been removed piece by piece, but the December CTP finally sees the removal of the last straggling hold-outs.

If you're not sure what I'm talking about, here's a snippet from Chris Sells' blog:

Or, rather, you would be seeing a snippet, if Blogger's posting control what's it didn't suck an incredible amount of ass. Infact, I just had to copy and paste the text here to note-pad and back, because Blogger's state of the art RTF control forgot to close a tag. Thanks, bitch. Anyway:

http://www.sellsbrothers.com/writing/avbook/changenotes/Wpf09-05CtpTo11-05CtpChangeNotes.htm

Its under the general section.

Anyway, thank God.

By making the format more rigid in terms of syntax it means that XAML won't become the kind of mess the SVG spec turned out to be; and as someone who once wrote a SVG-to-VG transformer, I know exactly the kind of pains in that spec. Taking the "convenience" out of the spec means that there's no ambiguity or multiple ways to parse one attribute.

These file formats aren't meant to be written by hand, damn it. Tweaked? Sure. WRITTEN? No. Its harder to automate this junk when there are seven different *valid* ways to write something. The easier it is to programmatically consume XAML the more tools will crop up that can read/write XAML and modify it.

No, sorry, VIM is not a good example of a tool. I mean *REAL* tools, like Sparkle, Cider, #develop.

Wikipedia founder 'shot by friend of Siegenthaler' | The Register

Andrew Orlowski apparently spent several hours on Wikipedia today trying to track down something to make Wikipedia look bad. Took him awhile, but he finally found something in the revision log: vandalism claiming that the Wikipedia founder was murdered by a friend. Like all incredibly bad journalists, he cropped out of the revert time, so even though the vandalism was corrected within minutes, he decided to "only" take a screenshot of the edits, rather than the edit times.

Ahh, quality journalism from The Register strikes again. Tell me why I shouldn't trust Wikipedia more than those guys, again?

Read more at www.theregister.com/200...

Nemerle, a hybrid functional / OO langauge for .NET

With my itchy, twitchy fingers, I have been checking out other languages that run on top of the .NET platform. Nemerle is one I checked out over the weekend. The language has a lot of features - a nuclear silo's worth. A powerful matching construct, a readable syntax (compared to any other functional language I've seen), and generic support. Mmm, generics. Those who know me all too well know I yearn for generics in Boo, and the lack of support causes me to stray and check out other languages from time to time.

For the sake of brevity, I'll model this blog post after the things I don't like about the language, and modifications I would make. There are too many things about the language I really like, so starting off like that would really eat up some time.

To get one thing straight, I'll pop up this disclaimer: I know nothing about functional programming. At all. I just tend to drill into a language, ignoring the design methodologies that went into and whatever. So, make no mistake: I have no idea what I'm talking about.

Things I would change:

• The match construct throws an exception if there is an unmatched item. This is suprisingly useful in theory; in practice however the exception provides so little detail that its barely worth it. It should at least spit out what the match variable was. C'mon man, gimme a hint or something, Christ.
• The match construct syntax. The match construct is powerful - it is easily the sweetest thing I've laid eyes on. But the syntax is the ugliest I've ever seen. Personally, I would just totally rip Boo's "given when" syntax and call it "match when" and whistle innocently. The problem with the match syntax is that its completely foreign to everything else in the language for no apparent reason. I cannot think of one reason for the syntax to be laid out in such a hard to type (finger acrobatics, maximum!) and hard to stare at manner. It looks like a twitchy, "shit, let's just do what the old guys did" implementation. I'd 21st century-ize that sucka.
  
• Explicit return statements. Recently, a pattern I've developed is using return statements to avoid processing the rest of a method without having to drop an exception. This is extremely handy for methods that can return null, or a default object. This seems thoroughly impossible with Nemerle, unless you're willing to use the match construct at the very beginning of a method. This of course means two or three relatively small match bodies, and then one huge match body for the "rest" of the method. I like implict returns, but I wanna be able to be explicit, too.
  
• N10005. The reason Nemerle sample code is littered with ignore() functions. The reason sample code scrolls an entire screen of N10005's because nobody wanted to type ignore() everywhere. Man, that might be cool or hip when you're running on a framework where every return value is important, but some of the time all it this return data is, is extracellnous information that we don't need. I don't really wanna type ignore(). I'm sorry. I don't. I'm lazy.
• Fuse braces and indentation. Boo/Python really turned me on to indentation based syntax. Hell, I was going to indent anyway. I would fuse'em in Nemerle: start a block with a brace, end a block with a brace. Otherwise, use indentation for syntax. There we go. Kung-fu with both syntaxes, now. Nemerle offers an -i switch, but that's almost as good as not offering indentation-based syntax at all.

Yep, that's about it, doc. Otherwise, its a really swell language that doesn't have decent IDE support. They've got a Corsavy addin, but it takes too much effort to get working: why they bundled a .sh script with it I'll never know. Copying the relatively simple instructions from the shell script do no good, since something in the plugin or the architecture of #develop 2.0 have changed, so you have to do some kind of wobbly dance to make the addin work. I can't remember what I did the first time to make it work.

Anyway, that's it. There. I posted a blog entry. Now, don't expect another one for awhile.

A Boo survival guide.

Over at boo-contrib, I've begun work on the Boo Survival Guide. Its not for newbies, and at the moment its pretty disorganized; its meant to be mainly a compedium of information on how to do things in Boo, rather than the basic mechanics of how a programming language works. That's why its called a survival guide, I guess. ;) There's a pregenerated PDF included and the OpenDocument files I used to build it in the same download.

Me vs my professor.

I had to do a little verbal kung-fu in front of my Linux Security/PHP class in order to save face a little over an hour ago. Here's my story:

A little introduction
Recently, it became required curriculum to take a "PHP and Linux Security" course. Never-you-mind the fact that we never had enough time to either go indepth in PHP or Linux Security very much during the session aside from a very broad and ultimately useless overview of both concepts. I'm not sure whose clever idea it was, but it wasn't a very good one to combine two completely different subjects into one amalgamation that can barely be taught in a semester.

So, the course has gone as I expected - slow, meandering, and without any real substance since its been divided between "Here's Linux" and "Here's PHP," and it comes time for final exams - except they're final projects instead, for some as of yet unnamed reason.

The Project
The professor seems very laid back, and in the beginning that was alright -we were verbally instructed to create a "PHP and MySQL" webpage, and then at the end he mentioned something randomly about homework. Yes, he gave homework the same day he told us about our final project, assigning them both to be due on the same day, which is of course an immediate priority conflict: one of them has to take precedence. They're not hard, per-say, but they are time consuming, an issue compounded by the fact that this isn't the only class I have to take. He is of course the only teacher still giving out homework so late in the term.

So, today was one of the alloted days to give presentations. Two people, who were obviously basing their presentation of existing PHP projects, went first: one smart foreign fellow was creating a CMS for the commpany he worked at to handle task tracking, and one other dude who had developed forum software for use with his associates. The rest of the projects were obviously from scratch and incomplete, judging by the quality of the one other I saw, and the people shaking their head and saying, "I'm not done yet" or "its not presentation quality." Hey, no sweat. We all have other classes, too, right?

The Presentation
Me? I volunteer. I'm done. I did the smart thing: I based my website off an existing template that came with the book for the course, whose author gave his blessing for modifications. I transformed one of the template sites to an ad-hoc image gallery, nothing really fancy but to be honest that's all I had time for, between those magical things called other classes.

So, when I'm done, what's the first thing he calls me on? You got it: the template. Well, that's great, except in his verbal "I-didn't-write-it-down-so-there's-no-proof" instructions he said we should consider using the examples in the book as templates. I can't quite tell him this to his face of course, because its incredibly insulting to call him out like that in front of the class, and the project is worth 35% of the final grade. I'm no sucker.

Gotta retaliate though (I have an ego), so I start quipping good development practices, like "a good programmer knows how to reuse code" and the typical, as the polite conversation almost turns into a debate. I had already queued up a logical argument on the issue of web development in general, when he suddenly distracts me with a copyright question. I hadn't removed the template author's copyright from the HTML page. I tell him its OK, since the author gave permission. He said I should have taken out the copyright notice. In hindsight I should have probably made a seperate 'credits' section and named him there, but I had more important stuff to do.

wtf?
Still, totally caught by suprise by the nature of his comment, I mumble the knee-jerk, "Uh, questionably legal area?*" and the class starts an ad-hoc discussion about it. By then I had lost my opportunity to argue the issue of using a template in my favor, though the professor still looked pretty displeased when I got up to go back to my seat.

I believe I saved quite a bit of face, though.

Sheesh.

In only two hours I'm probably going to have this same situation with another professor: the assignment didn't say to create our own data structures, so I logically used the tried-and-true STL data structures instead.

I've made a grave mistake assuming my professor's are all aboard the logic train.

*This is the only thing I remember from my CyberEthics class, even though the semester hasn't ended yet.

Boodle news update

I've finally updated Boodle's news page with something a little bit more concrete about the project.

I've been watching (and using) #develop 2.0 for awhile, and there's no beating it for IDE-style Boo support: at all. Or, at least, not with Boodle (on Windows) anyway, so I won't hold any delusions of grandeur. Its pretty obvious though that the Boo community now has an awesome IDE to take advantage of, since extending #develop 2.0 (as opposed to 1.1) is awesomely easy, and its got a rock-solid core that hasn't crashed on me since rev 5-something.

Hence, I'm "downgrading" Boodle to a very neat, tight text editor for Boo files with code completion and pleasant syntax colorization.

I'm not the type to look directly into the sun and pretend its a galaxy away.

Migeul de Icaza on a "web aware" Gnome.

I was browsing Planet Gnome earlier and managed to catch a blog post by Miguel de Icaza on a web aware desktop.

As a follow up to yesterday's web-based desktop communication engine, I wanted to comment on a few ideas that we have been bouncing around.

Clearly the HTTP end-points on desktop applications would be useful to invoke an arbitrary set of methods on each application. I envision a system in which we can remotely manipulate desktop applications through HTTP. The same idea that I pitched a few years ago on top of CORBA.

The difference this time is that writing the client code is trivial, unlike the previous attempt where writing the client code to talk to a CORBA server was very difficult.

But in addition to this HTTP-based RPC interface, it would be nice to make the GNOME desktop Web-Aware.

Miguel de Icaza

It sounds like a pretty rocking concept, but I think he's missing the logical jump from a lot of seperate little webservers to one unified interface for working with your desktop.

How does he want picture sharing to work?

Here is where the problem arises: people want to look at the pictures right away, or they want copies of the pictures, or they want me to tag them or annotate them. All of those at once.

Miguel de Icaza

The Solution: F-Spot coult have a "File/Web Share" which would basically run an HTTP server. In the particular case of F-Spot it can just embed our embeddable web server and expose the pictures with an ASP.NET application.

Miguel de Icaza

Every application embed a webserver? That's going a bit overboard.

I think a web-enabled Gnome desktop would do better to have simply *one* web interface that other applications could plug into. Surfing to http://localhost/web could bring up a user interface that would have the most common modules visible by default - pictures, video, audio, files - with applications registering and providing their own modules on demand.

I think that would be a bit better than every application doing their own thing and getting it half-assed. It also lowers the barrier of entry from "embed webserver, design webpage, ..." to "register a module in the Gnome web interface and just start sending out HTML on demand."

Hell, it could even use REST for communicating user actions back to individual applications that've registered with the Gnome web interface.

stupid website splash

Awesome. http://nintendowifi.com/ has a huge global map, this stylish image that stretches almost 600 pixels wide with all the major locations on the world present, and you can't use it to pick your region.


NO NO NO.

You click on the drop-down bar instead. That's innovative, huh?

You know what the best part is? When you click on a drop down item, instead of going to the site, you're presented with a button to click instead.

Do you know where it goes? To nintendowifi.com, HAR HAR HAR JOKES ON YOU.

Rwarr, attack!

As you can tell, I've been trying to crush Grunwald under a wall of bugs lately.

He closes most of them the same day or the very next. The guy's got to get a new past-time hobby or something!

I'll have to admit I'm kind of disappointed with Boodle in comparison: #develop 2.0 is way more feature-packed than I had ever expected it to be. Aside from it not being able to do debugging - some kind of bug in the way Boo generates.pdb files when running under .NET 2.0 - its a pretty powerful development platform. Now its a project that's wedged between MonoDevelop (s'alright) and #develop 2.0 (the BFG of free .NET IDEs), and I'm not sure what to do with it.

As I expected, botty still hasn't delievered on the NAnt backend, so we're still stuck playing with SQL for the backend, which was just a temporary hack that was supposed to hold a few days so I could implement some stuff around the basic project model, but its held for almost three weeks now.

So, pretending to know what I'm doing for a moment, I've been thinking the past week if we should reposition Boodle as a simple Boo source editor with basic project support. Once you start reaching out for advanced features like NAnt and debugging, then its time to go to #dev or MonoDev. Its really no contest between Boodle vs #dev 2.0 or Boodle vs the newest MonoDevelop SVN releases, and I don't see it happening any time soon.

The only niche' it seems to really occupy is 'simple source editor,' and even in there its already got competition: Sciboo was announced on the Boo Lang list a few days ago! I think in its current form Boodle is better than Sciboo, for now, though. ;)

I've still got time to think things through before I start hacking on Boodle again. Its been another one of "those weeks" where everything is due on either Monday, Tuesday, or Wensday. Again. They were synchronized when they gave out assignments, and synchronized when those assignments were due, it seems.

Clever bastards.

What the hell is Flock?

I just saw this on Slashdot today:

daria42 writes "The much-hyped Flock, a new browser based on Mozilla Firefox and integrating features like RSS feeds, blogging tools, the del.icio.us social bookmarking and Flickr photo sharing services has just launched a public developer preview to the world. Flock is being driven by a team of developers being led by Bart Decrem, a well-known open source developer who co-founded the ill-fated Eazel project back in 1999 and has been involved with both the Mozilla and GNOME foundations. On his blog this week he says Flock won't be forking the Firefox codebase."

Slashdot | Firefox-based Social Browser Flock Launches

So I went to the Flock site.

Our code couldn't wait any longer to be free!

But! This preview ain't for the faint of heart! If you're the bleeding-edge type and don't mind a few scrapes and busted knees from time to time, feel free to give it a whirl.

We've got interesting ideas in this thing. We want to know what we've done right how we could improve. And we've got a lot of work ahead of us!

So if a bucket of source code and developer binaries sound enticing, head over to our Developer page now.

Flock

Ok. But the website doesn't explain what the hell thsi thing is, so there was only one thing to do: download and install.

Its apparently just a heavily modified version of Firefox, built around social blogging and stuff. Weird. Whatever. I'm posting this using the builtin blog editor, though. There's not a lot of options here, to be honest. The AJAX-based Blogger posting system seems a little bit better.

Here's some amusing quotes from Channel9 and Slashdot:

It looks pretty, but I'm not sure what the hell it is or its supposed to do. They don't explain it on their site, either.



Worst marketing ever. =D

Flock, who's gonna use it?

Re:cutting edge?
(Score:5, Insightful)

by TeacherOfHeroes (892498)
on Thursday October 20, @11:07PM (#13841874)

Every once in a while someone makes a +5 Insightful comment about how there should be a version of Firefox with the more popular extentions built in so that the average user gets more functionality and doesn't have to do all the work themselves.

Finally someone does it, and people are quick to start belittling it for not being something fantastic and earth shattering. It said straight up that it was based on Firefox.

It's not doing anything nasty like Netscape did, so this just means that there are more alternatives out there. Last time I checked, that was considered to be good around here.

Slashdot | Firefox-based Social Browser Flock Launches

I could see this being extra handy if I blogged more options. We'll see what happens.

(two minutes later, and I'm still trying to figure out why Flock won't post to my blog even though it autodetects the settings.)

I've just given up on getting Flock to post it and just cut-pasted the HTML code directly into Blogger's interface. *shrugs*

A boodle screenshot.

Nothing new here to most of us, but some people aren't using Boodle very much, so here is a screenshot of revision 80.

My Windows Vista Wishlist (half-assed)

Things I would like to see in Windows Vista.

• Integrated Smart Upgrade technology:
• Right now applications are so disorganized with the way they check for updates. Some plunk something in the start menu's "Startup" that checks for updates, some applications have it coded right into their core, and other applications... sheesh. Its a pain.
• Some applications just say, "hey, wtf, there's a new app, now why don't you GO ALL THE WAY TO MY HOMEPAGE AND DOWNLOAD/INSTALL IT ALL YOURSELF, K THX" Yeah. Thanks, you lazy bastard.
  
• I want to see a unified control panel for all this: I want an API to code against to register my application, and then the user can set how and when he wants Windows Vista to check for updates to my application. Then Vista prompts him to download and run an installer executable specified by an update.ini (or whatever) file located on a remote webserver. Hell, if it could be done, it would automate the install/upgrade process silently, and allow the user to degrade back a version by keeping around old .msi install scripts for X many versions.
  
• Someone has to shepard this update madness into one less than insane bundle. Windows Vista is the perfect opportunity to do this.
• I have like a kajillion fucking Java WebStart app entries in my Control Panel Add / Remove thingy. Fuck. Thanks, Java. Thanks a lot.
  
• A better way to navigate through the "Start" menu Application Folders.
• *Anything*. Seriously. Maybe just a better way to navigate through application folders in general.
• I would like a better way to manage how applications and what applications are run at start-up. Every application does this in a little bit different way: some are in the 'Start' menu, some use the registry, some... some... agh. I 'specially hate applications that are auto-start but I can't track down how to stop the functionality due to the application's bad UI or whatever.
• The start menu's "most recently used application" list doesn't notice if a short-cut no longer points to a file. I broke jEdit awhile ago (thanks for installing into a new directory, you bastards), and haven't bothered with it since, but the icon is still there.
• Nothing bothers me more than the naming scheme, "Corporation --> Product Name" used in start menu entries. Damn it, that's metadata stuff right there. Half the time I barely know who wrote what application, so I'm constantly popping through 'new' corporation entries looking for the app I just installed.

Rant, off!

Boodle improvements.

Finally got around to doing some optimization on BooStyler to make it run faster. A lot faster.

I spent a few hours staring at the code and tweaking it a little. Completely worthless adjustments. Couldn't find out why it was still so slow.

Finally got a REAL profiler - I normally just insert timer functions, but Boodle is a growing project, gettin' big, and that was gonna be a no-no.












So I download JetBrains dotTrace, have a little look-see, and wtf? Magic. I see I'm spending a bulk of the time during styling in a duck-typed closure I never even bothered checking out. I alter the closure to use static typing and wham, instant speed-up by an order of 2 magnitudes. Boodle doesn't choke on medium-sized files anymore! The profiler actually pointed out a few more hotspots that should be looked at, non-styler related, so I should get around to doing that before the profiler expires.

Its a nice piece of work that JetBrains has here, but its a bit lacking on features and it only shows .cs / .vb source files - kinda sucks. I'd rather it show any source file, sans colorization, or allow for colorization using syntax files. Seriously, anything is better than nothing.

Its way out of my price range, though - like a kajillion dollars too much. I'll be sad to see it go once the trial expires, but I couldn't justify the cash spent when I've got so little of it.

His worse day tops mine by like 10x

[23:01] the first was because we have to use this stupid graphing software that to my knowledge is only in the physics computer lab, and it turns out that lab requires you to pay money to print. so i go there the morning before the lab, and i have no cash on me. but i cant pay cash anyways, i have to pay "bevo bucks", which i can purchase online, except they dont take visa online
[23:01] i had enough change to print, but they dont take cash, they require bevo bucks
[23:01] so that assignment was late

... some minutes later ...

[23:05] we do the lab on computers, so hypothetically i could just email / put it on a floppy drive, right?
[23:05] wrong, because they dont have internet or floppy drives
[23:05] they DO have usb drives, but it is a mac and it wont take my usb stick
[23:05] FUCK THIS SHIT
[23:06] its like an island of stupidity, cut off from contact with the rest of the world

More work on Boodle; mysterious Boo bugs.

Some more work on Boodle has been done - its mostly under the hood stuff, like an SQL-based back-end for project support. Hopefully this means project support in general once a user interface can be hooked up to it.

In doing a project the "size" of Boodle I've noticed what appear to be deep, lurking bugs in Boo that I'm unable to reproduce as simple test cases: many of them appear to be caused by the interaction between the modules that Boo generates. I've been trying to keep track of them by marking them as "BOOBUG," but I've only been doing that sparingly - when I'm pretty sure that it isn't just part of my bad code.

Here's one of the more annoying one that crops up occasionally (across two or three seperate projects):

for item in input:
#BOOBUG: Another one I can't reproduce.
#Accessing anything in "item" causes null ref exception.
print item.LexicalInfo

Its not that LexicalInfo is null and I'm trying to manipulate it; its that accessing any member of "item" causes an abrupt null reference exception. I believe I worked around it last time by simply declaring item as duck, but its still a pretty disconcerting thing. In the case of Boodle it wasn't necessary because that code block is obsoleted - I never got around to checking it into SVN 0 but its still there so I can keep track of those BOOBUGs in case I ever figure out what's going on.

#BOOBUG - something to do with interacting with other classes that use private stuff.
#Can't track it down right now, sorry.
buffer = main.GetBufferInfo(main.GetSelectedTextControl()) as BoodleBufferInfo

This one bothers me quite a bit, because its a situation where Boo's type inference fails completely: instead of assigning "System.Object" to buffer it actually assigned a type of "unknown" to buffer, which is a mystery that is beyond me. The cast apparently makes things work, so its nothing impassable, but it is annoying.

The hard part about debugging these kinds of problems is the way the compiler fails - there's not enough detail in the exception, like where it occured, or what kind of node it occured on, or where in the *BOO* source code the exception was emitted. If you *really* want to debug it you have to start sliding Console.WriteLines everywhere in the main Boo source. Well, that's what I do, considering I've never gotten dbgclr to load up the Boo assemblies and show its source code properly.

I'm just kind of hoping most of these issues "magically" go away, and that metaboo has a stronger foundation than the current Boo implementation.

The magic of open source.

There are already *four* developers working on Boodle now: myself, Michael Hansen, Daniel Newton, and "Bot Builder."

For a project less than 2 (3?) weeks old, that is pretty rocking. It is also why I wanted any kind of Boo integration project to be open source as well: it is very easy to foster a community of developers. Daniel? He submitted like 3 patches to the list before he even joined the project. Sweet. It takes pressure off the rest of us if the load is distributed evenly.

Syntax colorization and code completion finally got threaded; I crafted a "saferunner" class out of the threaded UI code that Michael contributed. Its a lot more "Boo" without any sticky work-arounds, which is *TOTALLY AWESOME*. First class functions rock.

Boodle-dev, the mailing list, is getting pretty active now. Good stuff, this Boodle thing.

Pfheh, college.

Instead of spending time with my dear dear Boodle instead I was forced to write a 6-10 page paper critiquing someone else's critique of copyright ethics. What the hell?

Oh well, I managed to bang out two pages, and it stinks of desperation and boredom. I should stick to doing things I'm good at, but if I only did that, I would never get to program.

What's next for Boodle?

Here's my little TODO list:

• Bug Mike to replace the textbox on the bottom of boodle with a tabbed interface that has console output, and a "task-list" where I can put errors. That will of course require a 'TaskManagerService' to do all the dirty under the hood work, which brings up the next point:
• Why am I suffixing everything with "Service" ? I have like three -Service files I haven't committed to SVN yet simply because they're pretty worthless, but the fact that I do it is weird.
• I have hazy thoughts of refactoring: a treeview showing each place the refactoring will occur, and a code block for each treeview to show the changes. Hopefully BooStyler will be able to colorize it properly. ;)
• I need to optimize the styler; right now it re-styles on every keystroke. There is a property, EndStyled, that tells me where the last styled position was... but since I'm using the Boo Lexer (Boo.Lang.Parser), 'publ' would be marked as an IDentifier, though it can easily become 'public' - and thus a keyword - seconds later. I simply cannot ignore that, but I have not thought up any good strategies yet. I have considered simply re-styling anything marked as an "identifier" each keystroke instead; that might be more efficient. I should probably look to see what other people are doing, but won't.
• Boodle's coming to the point where it can easily replace Boo Explorer. This is good, and was my original goal in the first place. ;) There is still much more to do after that point, though.
• I need someone with a better eye for colors than me to pick out some sane colors for syntax colorization.
• Don't let BooStyler get too muddled; in the future I'm going to want it to mark those mysterious 'ID's as fields, types, etc.
• I still haven't figured out how to make wxStyledTextCtrl bitmasks and stuff. Its just not something I do on a day-to-day level... and am mildly suprised they exposed implementation-level details in an API, but whatever - it wraps C/++ code, what can I expect?

*mumble mumble* Once I turn in this stupid paper I can get back to rocking.

Like a melding of the minds...

Boodle's coming together quite nicely.

You can't see it, but there's a neat firefox-esque "find" bar that pops up when you ctrl-f.

You can jam over to The Boodle Project Page and grab a SVN copy if you're desperate, but its still got a boat-load of bugs lurking, plus a like of spaghetti code. (Make it work, then make it work fast).

Yes, those colors *need* to be changed. =D

Update:
Careful, the setup exe is out of date - we've made quite a bit of progress in the past four days. ;)

Boodle on Novell Forge.

Boodle has a home on Novell Forge now thanks to their awesome hosting with SVN access.

There's already a few SVN commits and an installer (!), because Mike Hansen is apparently one very busy dude. For those of you not engrossed in reading the comments section, I'm working with him on Boodle. He's very good at compositing the UI elements together in a fashion that doesn't suck -- too bad my code isn't as elegant. ;)

I just checked in very raw code completion / compiling / running of single files. Still haven't found a way to work with the StyledTextCtrl yet, though, without dipping into C - something I don't wanna do. At all. Ever. (colorize me lazy). Not sure how to handle the situation yet.

*Update: made link point to right project, sorry. ^.^

*thump* Ow, watch your feet, GTK#!

I spent a couple of hours yesterday prototyping up a UI in GTK#. My real problems started once I started doing anything beyond 'the basics' - scary exceptions that were being thrown from the bowles of gtk itself. I gave it another whack today and stopped immediately because I just ran into an error where the application crashed when I unsubscribed from an event. Not so unexpected is the fact that everything works fine when running under Mono (in Windows). 'cept I don't want to use Mono on Windows.

So, today, I was toying with wx.NET. It seems promising, but there's a lot of rough edges. A lot. There are many, many fields that take integers instead of enums, and practically everything is undocumented. Its a bit unwieldly, like using MFC, but the API is simplier and does not require the herculean efforts of strength required to make simple stuff 'go.' Still, its unmaintained - they only update the library to keep it in sync with wxWidgets, and I hate programming against dead-end APIs. 'specially ones that are not particularily polished.

I'm not sure what to do now. The main reason for using GTK# was because, although its chock full of annoyances when dealing with simple stuff, it is powerful enough to let me do some pretty cool things with a little less effort than the equivilent using S.W.F. Same goes for wx.NET.

I'm not sure what I should do now; I obviously can't continue with GTK#, but I'm hesitant to pick wx.NET. I don't know of any other crossplatform .NET UIs, and using S.W.F would be a pain in the ass and require some P/Invoking, I think.

Should I take another look at booclipse and try to integrate some of my ideas into it? I hate Java.

Boodle!

Boodle is a GTK# application I've just started working on: essentially, its meant to be what IDLE is to Python.

I definitely plan on doing code completion, colorization, and launching the interpreter in a seperate appdomain or thread - having the interpreter hang is a real pet peeve of mine. Hopefully I will be able to move Boo Explorer out of my daily routine and replace it with Boodle. ;)

Ah, Boo, where's your killer IDE?

Was playing a bit with #develop 2.0 again, and it makes me crave a Boo addin. I use the term "playing" loosely, since I have not really had much time to do anything yet.

I believe Daniel Grunwald is holding off until Boo gets generics support, which could be sometime in the far, far future.

booclipse is nice, and I hacked a little on it today, but immediately reverted the changes - I don't know if I just don't like the language, or I'm rusty, or what, but it was damn unpleasant and not really something I want to spend my spare time on.

MonoDevelop of course is not an option, since I spend a lot of time on windows, and boo explorer is only good for simple scripts.

I wonder if its possible to wrap the generics exposed in #develop addins with C#, then expose plain-jane arraylists to Boo? Still don't know much about the architecture, and I would be duplicating efforts by Grunwald, but if he really is waiting for Boo to get generics, I would have a quasi working addin a lot sooner than that, to be sure.

SharpDevelop 2.0: The Next Generation

Corsavy, the codename for SharpDevelop 2.0, one of the most anticipated (and easily most hated) .NET IDEs available, has opened its source code repository for contributors. Well, I'm not really a contributor, but someone gave me the link and I downloaded and installed Corsavy before I realized this. ;)

After the clusterfuck that was SharpDevelop 1.1 (you know what I'm talking about if you've tried to use it for any serious projects), the constant pushbacks for Corsavy, and a forum post indicating that Corsavy hadn't been touched in months, it seemed like SharpDevelop was R.I.P.

It comes as bit of a suprise then that out of the blue the repository for Corsavy was opened for public consumption, and to be honest, I'm a bit amazed: SharpDevelop 2.0 is very, very good for what they consider alpha quality code.

Its got some pretty sweet features; when you find all references for a type, for instance, they appear in a little search window at the bottom, colorized by syntax and divided by columns. If you've had to deal with Visual Studio 2005's "let's cram everything onto one line in the same color and hope it works out" this is going to be sweet, sweet relief to you.

By default they ship supporting NUnit, MbUnit, and SVN support. You'll find SVN support under "Tools" which doesn't make as much sense as if first sounds when you think of it, but that's a minor problem.

Also nice to find was that if you right click on a project you have the option of deploying it via ClickOnce, although it seems that functionality for assembly signing hasn't been completed yet: ever see a ListBox with the words "TODO" in it before? Scary.

Generics support is just as you'd expect: generics in code completion. There's a minor annoyance when creating a generic type, as when you type List the cursor automagically highlights the 'T' so you can supply your own type, but when you press '>' you actually create another bracket, so your code comes out looking like "List>." Smarter behavior would be nice.

Did I mention that the debugger works? We all know that's what you were waiting for. Long awaited, long requested feature, but its here.

Corsavy is snappy - the IDE loaded quickly, only briefly showing the new splash-screen, and hasn't crashed on me yet. They seem to have locked down the memory consumption bug concerning the UI in SharpDevelop 1.1, so now you can actually hack for a couple of hours without having to restart the IDE or have it crash then refuse to load the project file next start-up. ;)

Oodles of small goodies, but they're like the little mints you find on your pillow at night: you don't notice them until you're there, and when you do, you smile. ;)

There are still some missing features, though:

• No background compiliation to check for errors. After having used Visual Studio 2005 and Eclipse for quite a bit, its become a *must.*
• No contextual help for error messages. This removes quite a few short-cuts that Eclipse and VS2005 made possible: you can't instanize a new type, click on the error message, and automagically import the namespace that holds the type.
• Weak refactoring. You can't refactor local variables, apparently, and the refactorings for methods and classes are pretty weak, as there are no convience refactorings like "explicitly/implicitly implement members" for interfaces and abstract classes.
• 
• You can't "go to definition" or "find references" arbitrarily by left clicking in the source code; you have to use the little class/interface/property/field icons that appear to the left of the screen if you want to find references for a class. I cannot click on a local variable that is an interface and go to that interface's definition. I can't even "find references" for a varaible, which is sometimes uber useful!

With some serious polish as Corsavy moves into beta, this could seriously put SharpDevelop into the same competitive ring as Visual Studio and X-Develop.

Definitely something to keep my eyes on.

Eclipse Boo Integration?

I just finished and posted my first cut of Boo.Lang.CodeDom; its still missing some features, and I should perhaps implement the parser so it supports reading Boo files, too.

And what do I find to my suprise as I go onto IRC but Rodrigo (The Boo Creator) showing off work on Eclipse integration, by himself and Georges -- a mysterious, unknown contributor who is likely lurking in the shadows to murderize us all.

It looks really sweet; once it gets checked into SVN and I clean up CodeDom to an acceptable level I hopefully have the time to incorporate code completion for the editor and some other stuff. ;)

Screenshots here.

A Boo code generator in Boo ;)

Its most commonly known to .NET developers as "CodeDom", a language abstracted way to generate code in another language. ;)

I started rewriting Boo.Lang.CodeDom in Boo; the original was in C#, and had numerous bugs. I'm actually kind of suprised that it worked at all, but it seems the samples that shipped with Boo never really touched the broken functionality. To make sure this doesn't happen I've written a unit test for each and every expression and statement that can be generated by System.CodeDom, and about 34 of 39 unit tests are working.

I've been using the Boo.Lang.Compiler API to 'bind' CodeDom elements to Boo's AST, so it will always generate proper Boo syntax.

I'm a bit of the way there, and when I'm done, well... .... eh.

And to think, all this came out of me trying to fix an annoying bug in the C# version of Boo.Lang.CodeDom ;)

Hey, it happens.

Looks like there isn't going to be an easy answer dealing with the Visual Studio 2005 SDK distribution EULA. I guess we'll see what happens when VS2005 is RTM, but honestly, I just saw one screenshot of the Resharper IDE from JetBeans...

JetBean's IntelliJ allows for open source plugins, so I can say with strong hope that the Resharper IDE will, also.

That's probably where I'll set my sights for a real IDE-integrated Boo addin. Its true that I could use Java and do one for Eclipse or X-Develop, but to be honest I want real .NET integration. Automatic adding of web references. Automatic winforms designer. ClickOnce deployment.

All that stuff is only going to be possible with a "real" .NET IDE, rather than me having to recreate all that from scratch because the host platform didn't support it.

The guys at JetBrains seem really smart, so the API might be just what I'm looking for... managed and loving it. ;)

And so, he scratched his beard and said...

...this is going to be different.

I will admit that I am suprised that *two* people responded this time about the issue of the distribution EULA suddenly popping up barring our (someone else; they're freakishly secretive about their project at the moment) way.

I know its a totally glib attitude to take, but I ain't gettin' paid in money, so I was hoping to get paid in fun and source code. ;)

Well, we'll see how this all plays out.

I think I thunk a thought.

I'm starting to wonder if I should abandon the Visual Studio 2005 package: I'm not sure I will get a response without lots of hoping and hollaring and blog-linking. Its not that there's been no reply yet; that's understandable, as its the 4th of July week, and people are busy. Hell, I'm not even in state anymore, and I won't be for another few days.

What worries me is the simple lack of communication between the VS2005 SDK team and the rest of reality. The Visual Studio Extensibility Forum, for instance, is a very good indication of their lack of participation: the documentation is pretty poor, so the forum is the first place people go to ask questions, which are completely ignored by the VS2005 SDK team. They're not easy 'oh, don't be a newb' questions, either; they're the kind of tough stuff you either slough through the heaviest of documentation to scrabble for tiny tidbits of information for, or you need an SDK developer to give you a quick leg-up.

The Microsoft MVPs are doing their best, though, but they can't do it all themselves, and the many forum posts that have no reply is testament to that. Hell, most of my forum threads have replies only because I replied to myself for the sheer benefit of other people. You know, keeping them up to date on the information I've found about the particular subject.

However, the issue about the old EULA being applied to the new Visual Studio SDKs is something that cannot be ignored simply because I can't work around it. This issue has to have definite action taken to it or I simply cannot work on the project any longer. Naturally I don't want to work on the project until the issue is cleared up, as it might be much wasted time and energy if I'm met with silence all the way up until the release of the SDK in conjunction with VS2005 gold releases, at which point I realize they're going to stick with the old EULA and I've got a large but relatively worthless code-base.

Its not even entirely the issue of open source here, either: the license is fucking crazy. It looks like a strange composite of marketing - MARKETING - and a bunch of random demands that go with it.

1. You shall ensure the quality of reproduced Licensed Software is equivalent to the quality of the Licensed Software as provided by Us. We shall be entitled to periodically, upon reasonable notice, inspect the quality of Your reproduction. Should we be dissatisfied with the quality, We shall notify You in writing and You shall promptly correct such deficiencies;

What? WHAT? Are you fucking serious? How the fuck am I supposed to do that? Given that there's been no proper competition to Visual Studio until X-Develop showed up, I'm going to go off on a wild tangent and assume that it takes many years and many developers to even begin to make something like that happen. The EULA gets worse the more you read of it.

But back on topic:

I am honestly sort of suprised: creating an SDK is not instant magic, and you would think that someone working at Microsoft would know that best. Sooner or later you're going to have to interact with people when the documentation isn't cutting it or other issues pop up. The lack of visible interaction from the group is astounding. Your product has its own forum that nobody from the product team posts in. Crazy.

I mean, at least the guys at SharpDevelop fake it: they'll post a completely worthless URL ('check out this three year out of date ebook on Addin architecture!') or babble something incoherent ('SharpDevelop's codebase is self-documentating!') but at least they pretend.

C'mon. Fake it. Fake it for me, baby.

Exploiting SharpDevelop.

"If it goes badly, I'll have to drop back down to SharpDevelop; basically, mutilating BooBinding and exploiting the text editor to do refactoring stuff (things it was NEVER meant to do)."

Let me expand on why I view this as a Very Bad Thing:

Documentation:

SharpDevelop's Addin interface is not poorly documented: it is completely undocumented. No, sorry, your three year old completely out of date book does not count. It is ironic that they have the time to churn out Addin after Addin after Addin, but can't take the time to documentation the interfaces: something that opens up SharpDevelop to a much wider audience of plugin makers rather than the few that already know how to do it.

There have been many posts on the forum about 'how to get started' with Addins. They're all pointed to the ridiculiously out of date eBook or told to browse the source code. Source code is not documentation.

This is a hobby, not some bizarre obsession: I've got stuff to do, and browsing through your source code because you're lazy is not one of them. I'm sorry if that was harsh, but its the truth. SharpDevelop isn't popular or good enough to attract hard-core developers like those. It is the best free .NET IDE available at the moment, but its not that good. It is not a rock-star application; people are not willing to struggle through bad/poor documentation to make magic happen.

SharpDevelop 2.0: Codename 'Corsavy.'

Here is a serious, serious problem the Sharpdevelop team has made for themselves: these are all the features SharpDevelop 2.0 are supposed to support:

• Refactoring support.
• 'Go to Definition' and 'Find all References' support.
• Built-in debugging support.
• Slick user interface.
• Better Addin API.

Sounds great, right? Oh, it sounds great. But here's the deal, cats and kittens: SharpDevelop 2.0 isn't out yet. The time-frame for a beta release keeps slipping and slipping. They keep promising it'll be 'Real Soon Now,' but beyond the feature list there's no information about Corsavy at all.

So, why would I want to do a refactoring plug-in for an already obsoleted SharpDevelop 1.1? The minute 2.0 comes out it will support these features out of the box, and propbably in a nice integrated manner. You can rest assured that almost everyone will upgrade, because SharpDevelop is trailing edge and about to fall from that fine line. I'm not willing to invest effort in something that will be completely depreciated a few months later.

Concrete information about SharpDevelop 2.0 needs to hit the newstands before its something I'll even begin to consider seriously again.

Keeping a careful eye on Microsoft.

Keeping a careful eye on Microsoft.

Announced on the Extensibility forums, a new "tech preview" for the VS2005 SDK has been released. However, this release heralds a new problem: it links to the old, old, very old version of the EULA that explicitly forbids open source along with a myriad of other stupid restrictions - I mean that in the most literal sense. They are pretty odd-ball restrictions, and I'm not sure who was smoking what when they were written. I can't "agree" with the this new-old EULA, so I can't produce any valuable feedback on the tech preview. I don't want to invalidate the Novell Forge project for this.

So now I've got a problem: if this situation isn't rectified and remains in place for the duration of the SDK's lifetime, then that immediately aborts this Boo package (VS2005 SDK's call plugins 'packages'), because I'm not interested in maintaining this chunk of software by myself till the end of time. God forbid something happen to me and then someone has to start over from scratch for no particular reason.

I'm just one guy: I'm not a friggin' army of coders. I need to leverage the ad-hoc nature of open source to deal with the 'long run' issues: maintence, etc.

We'll see how Microsoft handles this.

If it goes badly, I'll have to drop back down to SharpDevelop; basically, mutilating BooBinding and exploiting the text editor to do refactoring stuff (things it was NEVER meant to do).

CodeCompletionService!

CodeCompletionService!

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?

Well, that's it for today.

Scope-based complete word!

I finally got scope-based complete-word functionality in. Thankfully it seems to work 9/10 times. ;)

Quasi-working code completion

Quasi-working code completion.

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.

Ah, jeeves, you've gotten it!

I think I've finally figured out the strategy for Visual Studio's 'complete word' functionality.

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.

Why pay attention?

...

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.

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 ;)

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.