Phew, thank goodness for Park Plaza's explanatory text on their fire escape route signs!

Now I know that the "alarm sounds like" Whoop, Whoop. Because.. you know.. if it went Beep, Beep or Buzzzzzz, I'd simply assume that it wasn't really an alarm, but was in fact something entirely else.

Back to SoCal tomorrow morning. Our flight (the first of three, anyway) takes off at 6:30am. BLEH!

What should the following REALbasic code do:

 #if Foobar
   Const Foobar = false
  
   MsgBox "Foobar!"
 #endif

If forward referencing is allowed, then this code should not exist in the resulting application (though it should compile). If forward referencing is not allowed, then this code should fail to compile entirely.

So if you're in the camp of people that claim the above code should fail to compile, then you've also placed yourselve in the camp that claims this code should fail to compile as well:

 Sub SomeMethod( test as Integer = kSomeConstant )
 

Without ubiquitous forward referencing, this code may or may not compile, depending on how your project is rendered out. Since you have no control over the order items are rendered, you cannot assume that constants have been rendered before methods in any given class. And it's not just limited to code items within a class -- what if kSomeConstant is a global constant that lives in a different module? You can't be assured that the module has been compiled before the method in another class.

Well, another year, another Christmas holiday. This year, I'm splitting Christmas day in half -- half the day is down in Texas, half the day at an airport, and half the day in Minnesota (it's a long day!). It's great to be able to see both families.

Lis' family celebrates on x-mas eve with the extended relatives. I had a blast, once I was done cooking the tenderloin. :-P Uncle Glenn brought a small portion of his impressive arsenal, which we went down to the pond and shot. I shot the 45 magnum handgun again, which is always cool. But this year I also shot a 357 magnum, and an AK-47. That's in addition to the 12 gauge Lawrence and I were skeet shooting with a few days earlier. Yee haw!

Every so often, there is talk about a community-driven content project that seems to come up in the REALbasic community. These ideas run the gambit from OSS projects (like the WFS and CDL) to repositories (think SourceForge for RB code), to content (like a documentation wiki), and more. They always have a huge push of "yeah, that's a great idea!" from the community when they are discussed in public forums. However, it's my personal prediction that 99.9% of them end up failing.

I know I sound really negative when I say that, but I have enough years of experience watching these projects to know. There is a common behavior which I have seen with almost every community-driven project in the RB community. Someone comes up with a good idea and pitches it in public (mailing lists, forums, REAL World, etc). A bunch of people say "that sounds great!" So some more research is done on the topic by the originator, and eventually the figure out that the project is possible. A varying amount of effort is put into the project (it varies from a mild amount of effort to an enormous amount of effort) by the originator. The project is announced in a more formal way, and there is a call for assistance in maintaining the project. There is a large flurry of people checking the project out (downloading it, reading it, whatever) and an fairly large amount of suggestions on how to improve it. There is a very small amount of actual contributions in the form of work. After a period of time, the contributions go to zero and it's up to the originator to either drag the project along, or kill it off entirely as a loss.

Wahoo! I'm done working until the end of the year (actually, I won't be back to work until Jan 3rd or 4th). I'm both looking forward to and dreading my vacation time. Lis and I are flying in to Austin on Saturday, and then we start the parade of vendors for the wedding. For three days, we have at least two vendors to meet and discuss things with. But the hope is that by Thur morning, we will have all of the vendors for the wedding picked out and lined up (with the possible exception of a DJ). While this will relieve much stress with both of us, neither of us is terribly excited about meeting them. Some meetings will be better than others (cake tasting is better than flowers, for instance). Once we're done meeting everyone though, then the fun begins. We'll be heading down to Lis' mom's house and spending time there.

While browsing around in the feedback system the other day, I ran across a feature request that caught my eye. It was asking for the ability to use arrays as the return type for computed properties. Once upon a time, I thought "hey, I really want that too!", but that was a long time ago. So I spent some time thinking about what it would actually mean to allow arrays as return types for computed properties, and I realized "ooh, that's not a good idea!" because of the aliasing problem.

Imagine, if you will, some code that looks like this:

someClass.someComputedProperty.Append( someItem )

Well, since the array is computed, that means that someItem is being appended to an array that will be immediately destroyed after the call ends because nothing else is holding a reference to it. Could you tell that from looking at the code? Probably not!

Wow, what a whirlwind of wackiness. Sorry, alliteration just isn't working for me today. ;-) What I really meant to say is that I've been super busy as of late, and so things like blog postings tend to be few and far between.

In no particular order:

I've been working several long days (including the entire weekend) on some really awesome new compiler features for the next beta. I'd tell you what they are, but then I'd have to kill you. But those of you who are in the betas program will probably know what I'm talking about when the next release comes out. But after doing 12-16 hour work days for the last four days, I can honestly say that my brain is full.

So I use Facebook as a way to keep in contact with friends from back home, as well as family members. But lately, Facebook has been sucking significantly due to it's "Applications" crap. Now, I like add-ons as much as the next person, so long as I can ignore them (which is something I do vehemently with FB). However, now the applications my *friends* install start showing up on my news feed. That's all well and fine, except I really don't care which friend won what movie trivia challenge, etc. I want my news feed to be nice and clean -- show me things I care about like status updates, new notes, etc.

Last time, we covered the basics behind what a REALbasic plugin was, and how they worked -- so if you didn't read that posting, you will want to go read it now. We put that knowledge to use with Microsoft Visual Studio 2005 and built the most basic plugin possible for Windows.

Today we're going to take our knowledge and apply it to g++ (a variation of gcc, really) on Linux for building a shared library object to act as our REALbasic plugin. At the end of the post, we'll have made the same empty shell that we did last time.

So I just stumbled across a very unlikely, but still possible, thing to watch out for when making plugins for REALbasic. On Windows, some compilers (like Visual Studio) support special functionality for thread local storage. Instead of requiring you to use the Tls APIs, Visual Studio exposes a special __declspec for TLS:

__declspec( thread ) int someVar;

This would declare a 4-byte piece of thread local storage (so each thread would get its own copy of someVar, even though it's global in scope).

REALbasic plugins cannot make use of this because it takes special magic from the system loader to make it work. The REALbasic plugin loader doesn't do the necessary fiddling with the TEB to make this magic work, and I highly doubt it ever will (just due to the fragility of it alone). If you really need thread local storage, use the Tls APIs provided by Microsoft like TlsAlloc, et al. However, TLS is so rarely used that 99% of plugin devs out there can simply ignore this gotcha.