NilObject

Aaron had a wonderful, creative post this morning on his blog titled You Know You’re a Compiler Writer When…

I must admit, I got them all. A very funny piece.

No Comments yet »

Chances are, most of you haven’t heard of the framework I’m going to dedicate this week to posting how to use it from REALbasic. It’s called the Accelerate framework. Inside of it, there are two wonderful frameworks: vecLib and vImage. An unnamed project (perhaps later it will become public knowledge) asked me to help them optimize some median image convolution code that operated on 1 byte-per-pixel grayscale images. A little light turned on in my head, and I recalled seeing vImage. I looked quickly, and saw immediately what I was looking for: vImageConvolve_Planar8. Beautiful.

So, I wrapped it up in some declares (only dealing with MemoryBlocks, because that’s what they had). The result? For a 1024×1024 grayscale image with a 15×15 convolution filter? Less than 4 ticks on my 1.42 GHz Mac Mini. Wonderful. Nice and speedy.

I’ve worked on creating a small module that will let you do this with any image, but since I didn’t feel like giving everyone a plugin, I created a module, “HackThatWillBreak” that I will encrypt and send along with this project. Unfortunately, I must head into work shortly, so it won’t be posted until this evening at the earliest.

For those of you who are on Mac OS X 10.3, check out /System/Library/Frameworks/Accelerate.framework, and let me know what functionality you would like to see utilized from REALbasic. I’ll hook up the declares

4 Comments »

Sorry for those on RSS feeds, this is going to be kind of crazy I’m going to start importing examples, too. What used to be on realbasic.maccoding.com is now moving directly to this website in a new category “Examples”. I’ve also added a category “Articles” to have all of my full-length articles (only two at the moment, but there are more in works), and also created a section on the side that will always show the latest articles. I plan on having a similar thing for the 5 latest examples, too.

Hmm… I wonder if those on RSS feeds can still hear me If you do, let me know by leaving a comment! Gracias!

No Comments yet »

Published by O’Reilly on November 19, 2004: http://www.macdevcenter.com/pub/a/mac/2004/11/19/realbasic.html

No Comments yet »

This tutorial explains how to use Xcode to create a dylib, and then use REALbasic to declare into it. Dylib is short for Dynamic Library, which is a file that contains code that can be linked against at runtime. This means that it isn’t built directly into your application, like a static library is, but you can still load it up and call methods in it.
This is mainly useful for C/C++ or Objective-C programmers to create a library that may do something not possible from REALbasic.

Creating the dylib

1. Launch Xcode
   This tutorial assumes that you are using the latest Xcode from Apple.
2. Choose “File->New Project”, or type Command-Shift-N.
3. Select Empty Project, and click “Next”.
4. Choose a project name. For this example, we’ll call it “SampleDylib”.
5. Click “Finished”.
6. Choose “Project->New Target…”
7. Select “Dynamic Library”, from within the “Carbon” section. Click “Next”.
8. Name the target. For this example, we’ll call it “SampleDylib”, just like the project’s name. When finished, click “Finish”.
9. Choose “File->New File…”
10. Choose “C File”, from within the “Carbon” section, and click “Next”.
11. Name the file. For this example, we’ll call it “SampleDylib.c”. The default settings are generally correct, but if you have multiple projects open with multiple targets, make sure the proper project and target is selected. When done, click “Finish”.
12. Open the SampleDylib.c source file.
13. Add the code below:

      #include <string.h>
    
      int addFunction( int a, int b ) {
          return a + b;
      }
    
      int stringLength( char *str ) {
          return strlen(str);
      }

14. Save the file, then click the Build button, or press Command-B.
15. If there were build errors, ensure that the code you entered looks exactly like it does above. Once the build is successful, continue to step 16.
16. Find where the build was saved. If the builds folder location hasn’t been changed, it will be located in a “build” folder, next to your project file. It will be named SampleDylib.dylib.

Another way to locate the file is to locate the target by going to the project window, expanding SampleDylib, then expanding Products. Select SampleDylib.dylib, and control-click (or right-click, for those with two-button mice), and chose Reveal in Finder.

17. Copy the SampleDylib.dylib file to your documents folder.

Creating the REALbasic project

1. Launch REALbasic 5.5.x (Mach-O was introduced in 5.5). Create a new project, and choose “Desktop Application.
2. Choose “File->Build Settings…”
3. From the popup that says “Version Information”, choose “Mac OS Settings”.
4. Near the bottom, there is a label that reads “Compatibility”. Next to it, select “Mac OS X only (Mach-O)”.
5. Click OK.
6. Save the project to your documents folder (so that it is next to the dylib file). For this example, we’ll name it, “Test Dylib.rb”
7. Double click on “App” in the project window.
8. Expand the “Events” section, and select “Open”
9. Add the code below:
   

   #If DebugBuild Then
     Const dylibLocation = "@executable_path/../../../SampleDylib.dylib"
   #Else
     Const dylibLocation = "@executable_path/SampleDylib.dylib"
   #EndIf
   
   Declare Function addFunction Lib dylibLocation (a As Integer, b As Integer) As Integer
   Declare Function stringLength Lib dylibLocation (s As CString) As Integer
   
   msgBox "5 + 2 = " + str(AddFunction(5,2))
   
   msgBox "The length of ""asdf"" is " + str(stringLength("asdf"))
   

10. Run by choosing Debug->Run, or by pressing Command-R. (Don’t worry, a more in-depth explanation of the dylibLocation constant and declares are below).
11. Notice that it correctly adds, and also correctly computes the length of the string.

What is it doing?

Mach-O is actually a pretty archaic file format, despite what Apple is claiming. One example is that the loader (aka Dynamic Linker) doesn’t search for a dynamic library very well. It relies on either having a full path to the library, or having it relative to the executable path. Since we want the dylib to be installed in the bundle, we use “@executable_path/SampleDylib.dylib” as the path for non-debug builds. This means that when you build your application, you will need to copy the SampleDylib.dylib file into your Contents/MacOS/ directory, next to your actual executable file.

However, since the application is regenerated every time REALbasic builds it, the same path won’t work for debug builds. To make something that works easily with debugging, we traverse up from the @executable_path to be next to the application. The final path for this is “@executable_path/../../../SampleDylib.dylib”.

This can be combined into one constant declaration in a global module for ease of use among many methods and classes.

What about the native types in REALbasic?

Using REALbasic, you can do almost anything through declares. Here are a few tips on how to handle different types in REALbasic:

• Passing a float into your dylib, or returning a float: In REALbasic, use “Single” as the data type. Singles are the exact same as a float — a single precision floating point, to be specific.
• Passing a double into your dylib, or returning a double: Doubles are the exact same in both languages.
• Passing a c-string (null-terminated string) into your dylib: In REALbasic, declare the type for the parameter as CString.
• Passing a pascal-string (one byte length specifier) into your dylib: In REALbasic declare the type for the parameter as PString.
• Passing a void* (arbitrary data) into your dylib, or returning it: In REALbasic, declare the type for the parameter as Ptr, and pass in a MemoryBlock. Also declare the return type as Ptr, and it will automatically be converted to a MemoryBlock on return.
• Passing a pointer to a struct into your dylib: The same as above. Set up the memoryblock to contain the different fields, and pass it in as a Ptr.
• Limitation: It isn’t currently possible to pass in a struct inline.

7 Comments »

Well, I love WordPress. Things that weren’t that easy in b2evolution are very easy in WordPress, such as static pages that aren’t really blog entries. So, here I am after my migration. A few things to note, especially those on RSS feeds. I temporarily made a symbolic link from the old location of the RSS feed, but please update your subscription to the new location.

Now, time to try to spam-proof my WordPress installation. That is one thing I didn’t have to worry about with b2evolution as much — I think security through obscurity there. Anyways, the links (As well as some new ones) have been added again, and so has the events section. I also rewrote the About the Author section. Don’t worry, after I finish my REAL World slides for my talk, I’ll try to post a good tip or something

2 Comments »

Well, that wasn’t painful Worked rather smoothly actually.

No Comments yet »

I’ve decided to switch to WordPress. This is mainly because it’s more popular, and seems to be better for the type of thing I do. b2evolution is nice, but it’s more suited to multi-language, multi-blogger which is not what I really need. Plus, it doesn’t cooperate with Safari very well. So, bear with me as I make this transfer. The site’s template will be plain for a while

1 Comment »

Consider for a moment these two methods:
Sub Foo( p1 As Object, p2 As ClassA )
Sub Foo( p1 As ClassA, p2 As ClassA )

The compiler has a very simple algorithm right now that is very easy to understand. Take this example:

Dim a As New ClassA
Dim o As Object = New Dictionary
Foo( o, a )

In this case, the compiler will look at both versions of Foo. It will see that there are no conversions necessary for the first variation of Foo. Since there is an exact match, the compiler will use that call.

Next, let’s consider:

Dim a As New ClassA
Dim bar As New ClassA
Foo( a, bar )

In this case, the compiler will again look at both versions of Foo. It will see that the second signature this time matches perfectly. It will use that variation.

Finally, let’s consider this snippet, and assume ClassB isa ClassA:

Dim a As New ClassA
Dim b As New ClassB
Foo( a, b )

In this case, the compiler will evaluate both versions as before. It will see that the first variation requires at least one conversion (ClassA upcasted to Object), and the second variation requires at least one conversion also (ClassB upcasted to ClassA). Since both require a conversion of some sort, it is deemed ambiguous.

Now, why am I posting this? Firstly, to explain the compiler’s current logic. Secondly, to ask this question:

1) Do you think that the last example should be valid?
2) Why do you feel that way? (Ie, what logic are you using to determine that it should match)

I ask this not because I don’t feel a certain way on the subject, but because I want to understand what other people are thinking and why they are thinking that. Sure, we can change the compiler to be smarter, but is this an example of a slippery slope? If we make it smarter such that it knows to prefer functions with a more exact match, will people then ask more of it in the future (Ie, preferring up-casts as opposed to Operator_Convert, etc)?

This is a valid concern, because a compiler should not be smart. The user of the language should be able to understand exactly what the compiler is doing, and why it deems something is an error.

(Note, me posting about this has no relevance to whether or not we are doing anything about this whatsoever. It’s just on my mind. Don’t expect anything.)

9 Comments »

I put an events section in the bar on the right. This is simply because I am going to both of them, and also have an interest in helping promote it. I’m going to be speaking at both conferences (although what I’m speaking about at ADHOC is TBD).

First, there’s REAL World 2005 which is scheduled for March 23-25. Last year was a lot of fun, and I am really looking forward to this year. The ability to talk with users of REALbasic is great, and the experience and information gained makes it worth the trip. Even though I help make the product, there’s always so much interesting things that people use the product for and how they use it that even us at REAL Software learn something new. I hope to see all of my readers there!

Secondly, there’s ADHOC. The Advanced Developers Hands-On Conference is scheduled for July 27-31. If you’re a Macintosh developer, this is a conference you must go to. While WWDC is a great conference, ADHOC puts you face to face with other developers who face the same challenges you do from day to day. Sure, using REALbasic makes life a lot easier than using C/C++ with Carbon or even using Cocoa, but there are great sessions that even those who are unfamiliar with declares will find interesting. I’m the sessions chair this year, so if you’re interested in speaking, check out our Call for Sessions on our website here. I also look forward to seeing some of you there!

If you are a REALbasic developer or are interested in a great cross-platform RAD tool, I highly recommend the REAL World conference. If you’re a Mac developer who doesn’t know REALbasic, I highly recommend ADHOC (there might even be some introductory talks on REALbasic). If you’re a Mac REALbasic developer, I highly recommend coming to both They’re extremely fun conferences that will broaden your knowledge no matter what your skillset is. Who would have thought that learning could be so fun?

No Comments yet »