Oye! I don't think I can handle much more in the way of travel. It's about all I've done for the last month. Lis and I went from CA to TX to visit her family and take care of wedding stuff in the middle of Dec. Then we went from TX to MN to visit my family at the end of Dec. We went from MN back to CA for a few days. Then there was a death in the family, and so we drove from CA back to TX. Then we turned around and drove back. And then a few days later, I find myself on a plane back to Austin for work stuff. For a guy who hates to go anywhere, I sure go places! Outside of traveling, there's not that much new in Aaronland.

I never knew this before, so I figured that it's entirely likely no one else knew about it either. REALbasic has a single-line if construct for "pre-compiler" #if statements! In order to use this, you have to do: #if someConstant then expression It's not something I expect most people will be using, but it does have one very handy use: debugging statements. Instead of having to do:

 #if DebugBuild   Log( "Some Debugging message" ) #endif 

You can instead do: #if DebugBuild then Log( "Some debugging message" ) which is much more succinct! There are some cases where the single-line #if doesn't behave in an entirely expected fashion.

I never knew this before, so I figured that it's entirely likely no one else knew about it either. REALbasic has a single-line if construct for "pre-compiler" #if statements! In order to use this, you have to do:

#if someConstant then expression

It's not something I expect most people will be using, but it does have one very handy use: debugging statements. Instead of having to do:

 #if DebugBuild
   Log( "Some Debugging message" )
 #endif
 

You can instead do:

#if DebugBuild then Log( "Some debugging message" )

which is much more succinct!

This is a blog posting about the current behavior of the REALbasic compiler. This information isn't documented anywhere else because it's liable to change at a whim. As such, you should take this information with a grain of salt. Don't assume this will always be the case.

I've seen a few bug reports about this particular issue, and so I feel it'd be a good idea to warn people: do not mix signed and unsigned integer operations without careful thought. REALbasic doesn't have a warning system (for good or for bad, that's the way it is currently) and so the compiler will just try to be as helpful as it can. However, the compiler isn't a mind reader, and sometimes it is wrong (though it is always consistent). Whenever the compiler has to pick a common datatype between two choices, it prefers signed over unsigned datatypes. This means that if you compare an Int32 and a UInt32, it does a signed integer comparison.

 if someBigUInt32 > 0 then
   MsgBox "Uh oh!"
 end if
 

If someBigUInt32's value is > 2^31, then that comparison will fail even though it seems like it shouldn't. The reason is that the constant 0 is considered to be a signed 32-bit integer, and so the common type is Int32.

This is a blog posting about the current behavior of the REALbasic compiler. This information isn't documented anywhere else because it's liable to change at a whim. As such, you should take this information with a grain of salt. Don't assume this will always be the case. I've seen a few bug reports about this particular issue, and so I feel it'd be a good idea to warn people: do not mix signed and unsigned integer operations without careful thought. REALbasic doesn't have a warning system (for good or for bad, that's the way it is currently) and so the compiler will just try to be as helpful as it can.

Earlier, I challenged everyone to write a bug-free program that appears to be trivial. All it has to do is raise one number to an arbitrary power and display the results. However, bug-free is a very difficult thing to achieve, as anyone with experience in software can agree to. Here's a set of of the most common bugs that this particular project suffers from: 1) Since it's meant to provide *arbitrary* exponents, you cannot assume that an Integer input is sufficient. What if the user really wanted to do a square root by passing in .5? So you need accept floating point arguements as well as return a floating point result.

Earlier, I challenged everyone to write a bug-free program that appears to be trivial. All it has to do is raise one number to an arbitrary power and display the results. However, bug-free is a very difficult thing to achieve, as anyone with experience in software can agree to.

Here's a set of of the most common bugs that this particular project suffers from:

1) Since it's meant to provide *arbitrary* exponents, you cannot assume that an Integer input is sufficient. What if the user really wanted to do a square root by passing in .5? So you need accept floating point arguements as well as return a floating point result.

Here's a fun little challenge I came up with while on my flight back to California: create a simple application that is bug free. This is a demonstration of the fact that "bug free" is a very difficult thing to achieve, if not out-right impossible. I came up with this challenge because I was reading yet another diatribe on the forums from some users who don't seem to reside in the same world as the rest of us. ;-) So here's the challenge: you are to write an application which calculates arbitrary exponents in pure REALbasic code.

Here's a fun little challenge I came up with while on my flight back to California: create a simple application that is bug free. This is a demonstration of the fact that "bug free" is a very difficult thing to achieve, if not out-right impossible. I came up with this challenge because I was reading yet another diatribe on the forums from some users who don't seem to reside in the same world as the rest of us. ;-)

So here's the challenge: you are to write an application which calculates arbitrary exponents in pure REALbasic code. It should accept two inputs, and display the output. I don't care how you accept input (EditField, StdIn, etc) or display output (MsgBox, StdOut, etc). We will assume that any form of input and output are considered out of the scope of the challenge. The calculation algorithm should be purely of your own creation (you can't cop out and use the Pow function in REALbasic, or a declare, plugin, etc).

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!