24 hours of Delphi

Starting this evening at “oh hundred” hours (that's 12 midnight Pacific Daylight Time), the event of the year will be starting.  That is when the “24 hours of Delphi” event kicks off.  I'll be “on the air” at around 9:30am PDT and possibly again around 11:00am PDT.  I sure don't envy David I, Anders Ohlsson, and John Kaster who have to stay up and ramble on in order to keep the “dead air” to a minimum.  However, based on the schedule I've seen, there doesn't look to be too much of that, if at all.  Be sure to “tune in.”  I may decide to take some breaks throughout the day and “crash” their little party periodically ;-)..

Shotguns vs. sniper rifles..

No this isn't really about firearms, but actually a response to a comment I received regarding this post.  The comment basically chastised me (or Borland in general) that I (we) should just fix the bugs and release more updates rather than “paint useless Powerpoint slides.”  Wow.  I thought that was what we're trying to do (fix the bugs, that is).  The comment seemed to suggest that we should simply take a “shotgun” approach to fixing bugs.  I'm sorry but that is a foolish approach.  If you don't have and use tools to help you prioritize your work, you'll almost always be doing the wrong thing.  You can't prioritize based on data you don't have or can't see.  So rather than attacking the problem with a shotgun we get out the sniper rifle.  The surgical nature of using the sniper rifle approach reduces the collateral damage.

Oh, and again, that post was merely intended to be a visual aid to describe what is currently a mental process.  Powerpoint was not used in its creation.. Excel was ;-).  It was also intended to potentially spark some discussion externally and, probably more important, internally.  It seems to have done that since John Kaster has responded that maybe this should be something that is added to Quality Central.

Bugs, spiders, and priorities

Steve Trefethen has been running a series of posts regarding the Delphi Development Process.  I thought I'd add a little salt to this post about how we handle bugs.  Then I started looking at some of my old posts and found that I'd already posted a rather long diatribe on how we prioritize the fixing of defects.  So rather than simply restating what I'd already said, I thought I'd provide a visual aid to explain my comments regard a defect's “surface area.”  I spent a few moments and created the following graph to illustrate this goofy idea I have regarding the use of a bug's “surface area” in determining its priority in the stack of things to be looked at. 

As you can see, by using a spider graph and picking various metrics that are the radial scales a quick glance at the data shows how much overall “surface area” a defect appears to have.  As I mentioned in my post referenced above, we don't actually spit out a spider graph for each defect.  This is merely a visual aid to help further illustrate my point.  Although, this may be a good thing to have our internal tools begin to actually provide....hmmm....  The number of metrics and their scales would probably be very different, but I hope this may help spark ideas, internally and externally.

In recognition of life beyond C/C++

In this blog post by Raymond Chen, I find it very interesting and also very comforting that they (MS) actually considers the case where their MSDN examples are going to be taken and translated to a myriad of languages beyond the world of C/C++.  In fact, according to Ramond, far more people use languages other than C/C++ to create applications for Windows.  Do I believe that?  Maybe.  If you consider the huge number of Visual Basic programmers out there, then it seems that this statement has some merit.  I know that we Delphi programmers are certainly included in that calculation as well.  I mean, we've all done it.  We've all looked up the documentation on some Windows API and took the example code and translated portions of it to Delphi.

As a side note, posts like this also seem to be fodder for the various “glory-seekers” to chime in a pick apart his statements with petty little pedantic tirades on how much more they know about the C/C++ idiosyncrasies.  Just look at the comments regarding the realization that ZeroMemory won't work if the structures have IEEE floating point fields, or if some system uses a value other than 0 to represent a NULL.  I call them “glory seekers” because it seems that their only goal is to somehow get their “props” by pointing out the little edge conditions in someone's statements.  Good for you... you are a programming god... meanwhile the rest of us will take comfort in the true intent of what Raymond was saying.

The Shadow?

Now that I've done a little catching up, and some blog reading, I noticed that Chee Wee's blog links to mine here.  OK, fine.  But the link is written as Allen “The Shadow” Bauer.  What's up with that?  So, Chee Wee, how'd I get that moniker?  For that matter how did Danny “Thunder” Thorpe get his?

Back in the saddle...

So, I've been a little out of it for the last couple of weeks. Two weeks ago, I was in a week long off-site (well... off-Scotts Valley-site, anyway) meeting in our Cupertino office. Then last week, I was on vacation... in Las Vegas. Now I'm back, catching up on emails, getting the latest build bits, and just getting back into the swing of things... So, while I was out it looks like Steve Trefethen has posted a couple of really good blog entries that give a little insight into the Delphi team's development process. Check them out here, here, and here. Then Danny got into a little shooting match with this provacative rebuttal to a mailing list post. Well... I need to catch up on more of the internal goings on and figure out how to switch off the "vacation mode" and switch back on the "work mode."

Glasses half full... Apple & Intel

I admit it.  I'm an incorrigible optimist.  In the recent announcement by Apple regarding their move to using Intel CPUs, I only saw it as a good thing for the industry.  I also see it as a potential opportunity for Borland.  I'll predicate all of this with a huge dose of speculation, wishful thinking and downright optimism on my part.  Nobody has a magical crystal ball and cannot predict the future.  Yet, unlike Danny's post, I have a more positive outlook.  Now, there are those that scoff at the notion of a Mac OS running on Intel hardware.  Generally, these are emotional responses, or the obligatory “oh no!  The Intel monopoly is expanding!” concerns.  Ever since the first release of OSX running on the BSD kernel, rumors have abounded about how easy or hard that it would be to get OSX running on an Intel platform.

How does this all relate to Borland?  Right now, it doesn't.  It's just an interesting development in the industry at large.  As Danny posits, if Apple is going to go totally for the EM64T/AMD64 side then the route to the Mac is certainly riddled with far more land mines.  However, according to Corbin Dunn (former Borlander and now on the Cocoa team at Apple) in a comment to Danny's post:

“The intel x86 machines are not limited to 64-bit (trust me on that one). So, in theory, it would be possible to port Delphi to Mac, since the compiler is already spitting out x86 code. But, as we know from the Linux port, it isn't as simple as it seems. But, it would be simpler since BSD isn't such a far stretch from Linux.”

I'm sure another one of the big questions on everyone's mind is this: “can I take a plain-Jane ASUS motherboard, throw on the latest Pentium, slap some memory in, drop in a decend graphics card, hard drives, cdrom, etc... stick in the OSX disk and install?”  Hm... I don't know.  I'd imagine that to almost be the case, but since Apple keeps such tight control on the hardware spec, there probably isn't too many graphics cards, or other esoteric types of hardware that it will support.  Now, if Apple opens up their video driver architecture, and other subsystems we may be able to install the latest ATI or nVidia hardware.

So there's that question.  Apple did try to go down the licensed hardware route back in the late 90s, only to eventually reneg on that whole endeavour.  There are some rays of light in this article about the move to Intel.  According to the article:

“The first challenge ended up not being much of one at all, as Jobs revealed that OS X has been running on x86 platforms for the past 5 years; every release of Mac OS X has been compiled for PowerPC and Intel.”

Hmmm.... Did they design some special hardware 5 years ago just to run this port of OSX?  I doubt it.  I imagine they bought some off the shelf Dells or built up some systems from stock mother-boards and components.  Even the Mac has a PCI bus (don't know if the newer Macs have AGP or PCI-Express), in which they could just put in one of their normal graphics cards.  So this might lend some credence to my supposition that you may be able to slap together some cheap hardware and boot up OSX.

Basically, if there is going to be a 32bit version and a 64bit version of OSX on x86 hardware (as Corbin seems to indicate), then we have at least one item covered... sort of..  There are some huge hurdles, like the linker, codegen ABI tweaks, executable format, VCL, IDE, etc.  As for x86-64... well I think we all know how high that hurdle is going to be... 

So why am I so optimistic in the face of all these challenges?  Simple.  I see this as a good move for Apple.  I think it will help boost their sales.  And if they can become a true competitive force in the industry at large, then maybe Borland would have no choice but to turn some attention to that platform.  So it remains to be seen and you can be certain that we'll keep an eye on all these developments as they continue to unfold.

 

Chewy-ness...

Looks like the venerable Chee Wee Chua has gone from being an outsider looking in to an insider looking out. Welcome to Borland!

Gnomes and Elves...

So I tasked some of my gnomes and elves to do a little more work on the problem of the editor gutter.  I gave them all the feedback received from this post just to see what they would come up with.  So here's the result:

And optionally:

Hmm.... Actually I kinda like it.  Who says you can't teach old dogs new tricks!  Of course this is still subject to change if my gnomes or elves start getting cocky..

Waking up in the gutter...

So, yesterday, Steve Trefethen, stopped by my office and had asked whether or not I'd gotten any internal feedback on what to do about the left gutter in the editor.  You see, we have an internal blog and an internal wiki that we use to communicate newsworthy items and to float around technical specs among the various teams.  Because we have teams spread across the globe, development is happening on Delphi almost 24-7, so it is usually much easier to dissiminate information via the internal blog than to spam everyone's email box.  The Delphi Welcome Page for developer's builds automatically points to the RSS feed for the internal blog so most folks don't miss the blog information.  Oh, things like meeting minutes, new feature status, build breakages, etc... are all published there, but I digress.  You're here for a discussion on the left gutter in the editor.

As Steve and I were talking about the dearth of feedback we'd gotten internally, we spent a few moments and brainstormed (OK. I did get one bit of feedback, thanks Jesper!).  I think we hit on an epiphany.  We determined that the main cause of “fear and loathing” regarding the Delphi 2005 gutter was that it was actually packed with too much information.  It was cluttered which lead to the general feeling of being disorganized.  Myself being somewhat ADD, that clutter is easily overlooked, or at least minimalized.  I knew something just didn't “click” with it, but couldn't quite put my finger on it.  So as we brainstormed, Steve hit upon an what could be characterized as a “duh!”.  What if we only painted every 10th line number and then placed little dots for the lines in between?  The same information is conveyed, but every 10th was too far apart to quickly see what lines were in between.  I didn't realize how much I relied on the line numbers in the gutter until we started changing things.  So we tried to paint only every 5th line lumber... nope, still too cluttered.    At first we painted '-' characters on the lines between the numbers... ick.. that made it look like a ruler.  So we went with the dots.  That was better, but every 5th line was still too many line numbers cluttering things up.  So, again, Steve, suggested we paint a '-' on the 5th line between the numbers and dots on all the rest.  Wow!  That is actually starting to look good.  Here's what we've go so far:

That's far less cluttered, don't you think?  The “-” character clearly deliniates the 5th line.  With just a little more effort, we think it will quickly become second nature to be able to glance at that and see what line number a particular line is.

Now that the line numbers are not so prominent and “out there,” let's tackle the “overlapping icons” issue...  The problem we're trying to solve here is that there is a lot of information we want to convey visually from the left gutter.  Things like breakpoints, bookmarks, breakpointable lines, current execution point, etc..  All of this information takes precious real estate from the really important information, the source code.  So we compromised and placed the icons over the line numbers and also tried to change the intensity of the line number to be less prominent.  The problem with playing with luminance and saturation is that many times those value tend to wrap around and actually create a much brigher color.  The reason for “dimming” the line number was an attempt at reducing the clutter I talked about above.  So we disabled that “feature.”  Now that the gutter is far less cluttered, lets look at what it would look like now with the infamous “blue balls.”

Hm..   That's getting there.  The breakpointable line icon is clearly visible and easily overshadows the line numbers making them very visible.  They also don't steal any more real estate.  So what about bookmarks and the current execution point?

Notice that the breakpoint glyph doesn't overlap the bookmark glyph.  However the excution point arrow does overlap.  This is on purpose.  Those are related items.  The breakpoint glyph and the execution point arrow glyph are all about debugging.  Notice that the blue ball is also covered up. Why continue showing that when it is clear that the breakpoint has been set there?  You can still see the breakpoint under the arrow, so there is no need to take up more real estate.  Notice that the line number has taken a complete back seat to all of this.  They're not as an important piece of information as the bookmark, breakpoint and execution point glyphs are.  Also since there are no line numbers painted on the adjacent lines, there is far less surrounding clutter to detract from where the real information lies.

Finally, lets look at what happens when the gutter is too narrow to display those two glyphs side-by-side without also spilling into the code folding information.  At this point, the glyphs will begin to overlap, but only to a certain point so that all the glyphs will be at least partially visible.  But we've rearranged the priority of them so that the bookmark is always on the bottom, then the breakpoint/breakpointable glyphs, finally the execution point is alway on the top.

As most source files tend to be more than the mere 30 lines we see here, the gutter will generally be wider and thus there'll be far less overlap between the glyphs.  Hopefully we'll see some derivative of the above changes in the next Delphi release.  Since this is only a start, I'm sure we'll be refining this even further, and since I have no delusions of pleasing everyone, I think we're on the right track.