What happened to version 13?

During the RAD Studio 2010 field test and now out in the Delphi non-tech newsgroups, there had been a lot of discussion, speculation and even some angst about the mysterious lack of version 13. Chill folks. The story is simple with no real conspiracies involved. In fact, the only conspiracy involved was that we knew from the outset that it would spark discussion and conspiracies.

After each product release there is a period of time where the internal developer builds overlap with the released product and the next release. This can cause confusion among the team and phantom errors if a developer build were to ever meet up with a released build. To limit this overlap, we try and bump the version number as early in the next release cycle as possible. The scene went like this:

Rewind to September 24th of 2008. I’m sitting at my desk reading emails, writing emails, surfing the interwebs, waiting for a build to complete, etc… There’s a knock on the door frame of my office (my door is always open). I turn around and Dave Wilhelm is standing there.

“I’m about ready bump the version number.”

“So the next version would be, uh, 13, right?”, I said with a pondering look.

“Yep. And, yes, that’s an interesting number”, Dave said with a wry smirk. A mischievous smile appeared on my face. Dave chuckled. Then he added, “I think we have two choices here. We can defiantly embrace it, or just skip it. What does our release schedule look like next year?”

“Why?”

“If we were to release in October, having a version 13 would be clearly embracing that whole mystique. You know, Halloween, black cats, zombies, ghouls, yadda yadda…”

I chuckled. “That could be a whole sub theme of the release! However, it looks like we’re slated to release about the same time next year. So that won’t work. We should just skip it. I don’t think there is a Friday the 13th around that time either.”

“I’ll ask a few folks on the team if they have any strong opinions one way or another.”

“Yep. Just like many buildings don’t have a floor 13 and go from floor 12 to 14. It will also be a fun trivia question down the road. Besides, I can see the community going into wild, random speculation and conspiracies as to why did they skip 13.”, I said with a slight smirk and a muted chuckle.

“Exactly. I also understand it is mostly a western superstition. It will certainly be fun to watch all the newsgroups get spun up.”

“Well, we live in the west. We are the ones checking in the changes. So I guess we get to decide.”, I commented defiantly.

“Yep. I’ll check with a few folks and get back to you.”, Dave said as he walked off.

About an hour later, there was another knock on my door. Dave was back.

“The comments among the team ranged from, ‘I don’t care one way or another’ to ‘Sure, go ahead and skip 13’”

“Then it’s decided. Bump it to 14, and check it in. Let the wild, random speculation begin. Explaining this conversation in a blog post will also be fun.”

We both let out a slight chortle and then proceeded to get on with our day.

There you have it. It was a largely unilateral decision. Nothing was ever mentioned about it until fairly deep into the field-test cycle and now after the release it seems to have gotten a decent amount of attention. Psych!

The Life and Times of a Thread Pool

As promised in this post, I've uploaded a demo project to Code Central. This is an implementation of Conway's Game of Life using a thread pool and a parallel loop. It uses a 500x500 wrapping grid in which only a portion is displayed in the UI. No calculations of the next generation are done in the UI thread in either parallel or serial mode. While the implementation of the life algorithm is interesting, that is not the intent of this demo. The Parallel.pas unit is the main focus of this demo. This unit contains the thread pool and a couple of parallel for loop implementations. One implementation takes a method pointer as a callback and the other uses an old trick where you can pass in the address of a nested procedure. This is the technique used by default, but a simple modification will allow it to use the other version. This was developed using Delphi 2007+ (internal developer build). It should work fine with shipping D2007. It is also Win32 only.
Here's a simple screen-shot:

You can check and uncheck the "Parallel" check box while the application is processing generations to see the effect of going parallel. For those of you with single core systems, you will not see much improvement by checking or unchecking Parallel.
For more information on Conway's life and information of various other algorithms here's a few links:
http://psoup.math.wisc.edu/mcell/ca_files_formats.html
http://www.radicaleye.com/lifepage/
Finally, here is a very good implementation of Life written in Delphi:
http://psoup.math.wisc.edu/Life32.html

Super editor zoom - proof of concept.

David Clegg mentions in this post a new super secret, "super zoom" feature.  First of all the reason this "feature" isn't on by default is that it was implemented as a very quick hack to more or less simply be a proof of concept for the team to play with.  As such, it is riddled with problems that if you start using it you may encounter.  It is actually somewhat ironic that this comes up now because for the last couple of days I've been looking at this feature and how it should actually be implemented.

The way it is currently implemented is to simply hide/show the dock sites on the editor form.  This causes a couple of major issues.  First of all, when in the zoomed mode, you cannot easily get back to the other views without unzooming first (and you must to use the mouse for this operation).  Zoom the editor, then select View|Project Manager... nothing happens.  That is because the form is visible, but the site into which it is docked is not.  Try switching desktop states, by starting the debugger or manually from the desktop state dropdown... then it gets really interesting.  Again, it was only for some internal research and a proof of concept.

Similar to my post about adding auto-save and recovery of files to the IDE, I'll go through and outline the behavior I'd expect this feature to adhere to.  As I mentioned in the previous paragraph, this feature takes the somewhat naive approach of hiding and showing the dock sites.

The first modification to this code is to iterate through all the dock sites on the editor form and then go through all the docked clients within each side and hide them individually.  This will allow the docking system to properly track their state.  It will also allow you to still selectively re-show specific views.  Selecting View|Project Manager will now properly display the Project Manager view in its properly docked position.   The next change is how the "unzoom" is handled.  As there can be several views that are not visible when the view is zoomed, you want to make sure they remain hidden when unzoomed unless they were explicitly shown while zoomed.  Another requirement is that for all "unpinned" views, they should remain unpinned and accessible.  So there could still be a thin strip on the sides and bottom where the views can still pop up.  Finally, any large desktop changes, such as switching states, loading a new project with a saved desktop, etc should cancel the zoom state.

I'm sure the next question on everyone's mind is why wasn't this feature just finished and done right for RAD Studio?  The simple truth is that it fell too low on the priority list to make it into the product.  Things like this are always going to happen where good intentions just sometimes don't make it because of the reality of the schedule and other priorities.  Another side effect of this is that we can also get some direct feedback from the field as to the overall usefulness of the concept (irrespective of the implementation) before devoting actual resources to it.  By all means, follow the instructions from David and play with it.  Even given its limitations and shortcomings there is enough there to get the idea of what it would do.