BKeeney Briefs

In my previous blog, one of the commenters asked me about my thoughts on the new LLVM backend compiler that RS is implementing for REAL Studio.  I’ll first start by saying that I am not a backend compiler expert, nor want to be.  Much of what I’ll write about I’m getting from sources that are in the know, as they say.

What exactly is LLVM other than a fancy acronym?  It stands for Low Level Virtual Machine and is a compiler infrastructure.  It was started in 2000 at the University of Illinois and in 2005 Apple hired some of those original authors for their development system.

RB currently uses a custom written backend compiler.  As you can imagine, maintaining a compiler is a lot of work and writing optimizations is not easy.  LLVM was designed for multiple layers of optimization including compile-time, link-time, run-time and even idle-time.

What does LLVM mean for REALbasic applications?  It means that applications should be smaller and faster.  Code that isn’t used will be removed (dead-stripping code).  Currently RB can do this but it’s not exceptionally efficient (but really not all that bad either) as it which leaves some unused code compiled into your application.  For most of us this isn’t a big deal, but for many that start a project with a standard toolset, they might be introducing some inefficiencies into the final product.

Switching to LLVM is great news, though.  Smaller, faster, better are all things to strive for.  Without giving away too much information, the RBScript compiler is being reworked to use LLVM.  It’s a good first step.

But that’s all it is.  If you’ve not used RBScript, let me tell you, it’s not REALbasic.  One of the most powerful features of REALbasic is the cross-platform debugger.  Run in one environment while debugging in the other.  Even when you are debugging locally (on the same machine in the same environment) you’re ‘remote debugging’.  If my source is correct, switching to LLVM will require rewriting the entire debugger because the LLVM metadata system is different than RB’s debugger map system.

Since LLVM uses different metadata properties the current introspection system will break and have to rewritten.  Plugins will also break.  The IDE, the plugin system and even the reporting engine are a heavy consumers of introspection.  So going to LLVM means a huge portion of the product needs to get updated.

Rewriting the debugger is not a trivial task.  To do this the RIGHT way is a huge job that could take a couple of strong backend compiler developers 6 to 12 months to fully implement.  Even hacking it together is probably a 4 to 8 month project and it would still take some time getting the remote debugger to work properly.

If all this sounds daunting and kind of scary, well, it is.  Switching backend compilers is not something to do on a whim.  It has to be well thought out and resources have to be allocated properly.  The roadmap for features that will not be added during the transition time need to be thought out properly as well since limited resources are a fact of life in all organizations.  A small organization needs smart long-term planning.

Make no mistake, though, the backend compiler switch promises to be take a while.  It basically rewrites major portions of the product which will lead to some subtle and not-so-subtle changes.  The risk is high and it will affect EVERYONE.

There’s been some talk about all the ‘freebies’ we will get when using LLVM (such as 64 bit support).  Not true.  Using LLVM gets you ‘closer’ but it still won’t be free.  Switching to LLVM removes one of the many tasks involved with such support.

With all that said, I think moving to LLVM is a must.  If RS wants to support different platforms it’s a smart move going forward.  The optimization capabilities look very promising and will be welcome to many users.  It IS the right thing to do.  Just be prepared for some bumps along the way.

One final word.  I’m a passionate RB user.  I’ve also been a project manager where I think about the bumps in the road before they happen.  I’m not an expert at this stuff, though, so any misconceptions or mistakes are entirely my own.

The number of bug reporting systems REAL Software has implemented in my time using REALbasic has been astounding.  Of course, some of the changes revolved around the emergence of the internet, but still, I’m amused at the iterations.

There was REALbugs (?) that was a standalone app that I never really used because I was a newbie. It memory serves, it was very much a Mac OS 9-type application.  As to how well it worked – I couldn’t tell you.

Then there was the feedback web site that allowed you to sign on to a bug to ‘vote’ for it.  It was nice, but people would literally sign on to EVERYTHING which defeated the purpose of the voting system to begin with.

Then RS switched to FogBugz and abandoned all of the old feedback items.  Supposedly, it would make life easier on them and they’d be able to fix bugs easier and faster.  Unfortunately, it made bug reporters life much harder since we couldn’t search the database.  RS was inundated with duplicate items and it was hard to tell the good reports from the bad.

So, now, in the current iteration we’ve come full circle and we’re back to an application called Feedback and is part of the download package.  It’s better in most respects to the previous system other than that it’s an application which just seems….odd in today’s internet world.  But I understand why they did it and for the most part it works.

It’s user interface forces you to search for an existing bug before you can add a new one (that’s good!).  You can see the newest cases (handy if you’re evaluating a new version of REAL Studio), My Cases, Participating In, and My Favorites.

You can add cases to your favorites list by clicking the star at the bottom of the cases listbox.  But a not so well documented feature is the Priority List.

The Priority List allows us to prioritize our bug fixes and feature requests.  This supposedly gives RS some feedback into what we want fixed or implemented sooner rather than later.  It’s also weighted in favor of the Professional and Enterprise users (we can argue whether that’s a good or bad thing in another post).  There is an algorithm to it but when I had my conversation with an RS employee I didn’t take notes so I might be off on the actual numbers.

A Personal license gets a weight of 1.  A professional user vote gets a weight of 10 and Enterprise has a weight of 20.  So Enterprise users are 20 times more powerful than Personal licenses.  That doesn’t strike me as too off base since a Personal license is $99 and the Enterprise is $995 (again we can argue the logic of the weighting another time).

Perhaps the smartest thing they did with the priority system is that you only get five votes and if my memory serves (forgive me, this is the day I got the flu), I believe a #1 rank gets 5 points and the last vote only gets 1.  So you have to be smart with your priority list and to edit it, go to My Cases and click the Edit Priorities button at the bottom of the list.  A separate list of all the cases you have some interest in are presented and you drag reorder the cases as you see fit but only the top five are counted and in the list are bold.

You can find the current list by clicking on Top Cases which brings up the current list.  If you double click on the list item you can see the internal rank in the upper left hand corner of the report.  And this, in my opinion, is where this system breaks down.

The current #1 item is case 9433 (iPhone support).  While it sounds good at first blush, iPhone development is a big break from how REAL Studio works currently, and it requires a lot of intermediate changes and there’s no evaluation from REAL Software on how long it would take to implement iPhone support or what we would have to give up during that time frame.

For example, the current #2 item is case 738 (Controls and Window Backgrounds Flicker in Windows) and is a huge problem for Windows application and my guess is that it hurts RS when Windows users evaluate REAL Studio more than they know.  Would you rather fix this gaping bug or have iPhone support?  Me, I want and need, this bug fixed.

Unfortunately, there’s no way to vote an item ‘down’.  The current system is rigged to only tell how many people think it’s a good idea.  There’s no way for RS to get a feel for how many think the top item is a BAD idea, or don’t think it should be a high priority item.

I personally think iPhone support is a rabbit hole of time and money that RS could use to adding some nice features and cleaning up long standing bugs.  To support the iPhone REAL Studio has to add a number of very important things before it can begin to *start* development:  Cocoa (currently in beta), LLVM compiler support (currently in beta for RBScript) only, new editors, and untold engineering problems on three platforms (is that even possible?).

Cocoa has taken close to two years to implement and ‘new features’ have slowed down (partially from Cocoa and partially from our requests for more bug fixes).  RS has talked about LLVM compiler support – first with RBScript and then for the entire app and who knows how long that will take to get working 100%.  The other items?  Only the Universe knows.

I urge all of you to play around with the Feedback application and find your high priority bugs and mark them as such.  This is the only way (currently) to tell REAL Software on what your priorities are.  If you want iPhone support, that’s great, but I caution you to be careful with what you wish for.

Happy coding!

Fellow REALbasic developer, Christian Miller penned an interesting blog post at http://www.pariahware.com/blog/?p=248&utm_source=rss&utm_medium=rss&utm_campaign=real-software-the-opposite-of-love-is-not-hate-it-is-indifference.  I suggest you read it.

The stage that Christian didn’t add was what happens after acceptance.  This is the point where you ask yourself, “So what am I going to do about it?”  As I see it, there are only three options that are worth talking about.

Deal with it.  Accept the fact that RB is a flawed product and learn to work around its many deficiencies.  We all know that RS is a small company and can’t devote as much resources to it as say an Apple or Microsoft can to their respective development environments.

Leave.  Move on and use the tool(s) that work for you.  I’ve said this to many people:  If you expect RB to make a great Mac OS X only, Windows only, or Linux only application you might be very disappointed.  If you’re looking for a good cross-platform application using one code base it’s one of the few tools available.  The other dev tools available wouldn’t be considered Rapid Application Development tools in my opinion.

Try to change the situation.  This is the approach that I took.  One of my goals with the Association of REALbasic Professionals was to bring the conversation out and be more vocal with what we, the professional developers, need and want.  I found the training materials wanting so I started my own video series available on my website.  I blog regularly about RB here and on the ARBP website.  I’ve written tutorials, answered questions in the RB forums, talked at RB conferences and, written articles.

Without patting myself too hard on the back and injuring myself, I have been a pretty vocal supporter of REAL Software.  Hopefully you all have read the posts where I’ve been just as critical of REAL Software.  I’ve hitched my wagon, so to say, to the REAL Software bandwagon because I like the product, like the people that work there and, it has satisfied the requirements of my company and my clients for a decade.  I’ve been called a shill for the company and I’ve received hate mail for my anti-REAL Software stances.  My point is that I’m not a mindless cheerleader for the product because that does no one any good.  My family and my employees families fates are intertwined with the fate of REALbasic so I need it to be a viable product.

From my perspective the constant focus on new hobbyist users does absolutely no good for my business.  Too often new features are implemented that are ‘good enough’ for the hobbyist but suck for me (think toolbars, the report generator, htmlviewer and Windows flickering to name a few).  The hobbyists can’t pay for advanced features.  Businesses can, and will, if it makes sense for them.

RS is right to be proud that they ‘eat their own dogfood’ and that the RB IDE is made in RB.  That’s great, but making an IDE/compiler isn’t what I make.  Its obvious, at times, that there is a disconnect between what RS perceives we need and what we really need.  I’ve been using RB since the 3.5 days and yet there’s only one Date control, one Calendar control and one alternative to the listbox (i.e. grid).  In the corporate environments I used to work in that’s unacceptable.

I’ve long advocated that REAL Software create an internal consulting group.  Start with one person.  That group bids on potential projects like all the other developers in the network (to make it fair to existing developers, their rate must be HIGH).  When they’re not bidding or working on projects they do two things:  1)  they create real world examples and check each one for each release to make sure they still work; 2) They create training videos and tutorials, and answer tech support issues.

Having an internal consulting group does a couple of things:  1)  they quickly learn the pain of making real world applications in REALbasic; 2) provide valuable feedback to the powers-that-be in RS on what needs to be fixed and in what priority; 3)  it’s a (potential) revenue stream; 4) Makes sure that the documentation and examples really work; 5) Makes corporate users feel better knowing that if their own development team gets into trouble RS can back them up.

The truest definition of insanity is doing the same things over and over again and expecting a different result.  As we’ve seen with some very vocal criticisms (like Christian’s) and others, the perspective is that RS is doing the same thing over and over again and failing.  Unfortunately, so are we, the users.

Paul has an excellent blog post on the new name change of REALbasic to REAL Studio at http://www.rbdevzone.com/2010/02/real-studio-about-the-name-change/.

I don’t have a whole lot to add because I agree with most of his suggestions.  I do have one bone to pick with the use of ‘Enterprise’ as the top of the line REAL Studio product.  REAL Studio isn’t big in the ‘Enterprise’ market and naming it such doesn’t give you an automatic ticket into it.  If anything, it limits the current Pro owners who say, “I’m not an enterprise developer so why should I pony up the money?”  Perhaps, ‘Premier’ or ‘Ultimate’ might have been a better term.

Thinking back over the years at all the of the ‘hot’ programming languages, they’ve all had interesting names.  Java, Python, Perl, Ruby on Rails all have one thing in common:  They don’t say a damn thing about what they are or do.  But, boy, do the names stick with you and sound cool when you talk to a group of people.  ‘REALbasic’ not so much.  Like BASIC would be anything but real?

Enough griping.  Changing the name of the product or company is a huge gamble it’s not one to be done lightly.  One would hope that a name change with the product could invoke images of coolness, power, imagination, something hidden slightly out of view, and something mysterious enough for folks to check it out just because it sounds like those things.

Maybe something that gives you a hint of the cross-platform capabilities of what it can do.  How does “Crossbow” sound?  I can see the marketing campaigns now.  “Hit your cross-platform targets with Crossbow!”, “Crossbow is powerful enough for three platforms, but easy-enough for the mere mortal to use.”  The IDE icon changes to a Crossbow or Arrow sticking out of a target.  “Introducing Crossbow by REAL Software” sounds better (to me) then saying, “Introducing REAL Studio by REAL Software”.  Too many ‘reals’ in there for my taste.

Anyway, random thoughts on a Friday.  What say you?

Since REALbasic (now REAL Studio) 2009 R5.1 updated the SQLite database engine the RB Forums have had more than a few RB users complaining that the database no longer works.  Thankfully the community has been able to get the message out that the AutoCommit property of the REAL SQL Database is now, by default, false.  I think it should be true by default and the RS did the users a disservice by forcing this change on us.

As an advanced user I understand completely why autocommit should be false.  However, as someone who has fielded some of the forum questions and have even have this bite me in an old project I can’t imagine why this change was considered a good idea.

I’m not sure if the change fixed a bug or the RS engineers realized that it wasn’t working the way they expected it to but setting the AutoCommit to false, however, breaks a lot of existing programs.  That all by itself, in my opinion, was a big mistake – even if it ‘fixed’ a bug.  Someone evaluating RB for their DB application now sees a spate of “The database doesn’t work for me anymore” messages in the forums.  Are they going to really look much further even if the solution is as simple as db.autocommit = true?

Second, because the change is silent and subtle, a lot of developers were pretty mystified (and pissed off).  Heck, I didn’t spot it until I was doing the REALbasic training videos and realized that data wasn’t being saved.  I’ve been using RB for for over eight years and I spent more than a few minutes scratching my head.  How does that make a beginner feel about REAL Studio?

I know that I should be checking the error condition of the database after every transaction.  I know that I should be handling the commit and rollback on my own.  I know all this and do those very things (most of the time) and yet still I got bit.  I can’t imagine how the rest of the RB universe felt when they finally found out why their db apps weren’t working properly any more.

What’s worse is the Language Reference for AutoCommit is lacking anything close to an appropriate example.  The AutoCommit entry has this to say:

The default is False: Changes open implicit transactions that you must close explicitly. If you set AutoCommit to True, then the database will no longer open implicit transactions for you, and instead, will automatically commit each database change immediately. It is recommended that you leave AutoCommit set to False unless you understand the implications of setting it to True.

How about a little discussion on the implications?  And of course there’s no example of how to properly do this unless you’re smart enough to check out the examples in the parent REALSQLDatabase  entry and smart enough to realize that you also need to read the examples in the Recordset entry.

Let’s be brutally honest for a minute.  Most RB users want their changes to be committed automatically because they’re not SQL guru’s.  They just want their application to work and don’t care about what the ‘best practices’ are for databases.  It’s been a while since I’ve used VB6 and ADO but I don’t ever remember having to tell my data to commit.  I do remember having to add code to start a transaction and commit and rollback my transactions.  So why was this RB change a good one?

Unfortunately, now that AutoCommit has been like this for a few releases we can’t put the genie back in the bottle.  I would ask that in the future that REAL Software deprecate ‘broken’ methods and replace them with a new one so that it’s obvious that something has changed.

Did the AutoCommit change affect you at all?  Did it make sense right away or did you have to hunt the reason down?  Was the change necessary and a good change?

Over on the Association of REALbasic Professionals website, I wrote up a short review of REAL Studio 2010 R1.  Look in the Blogs and Opinions section or follow this link.

Summary:  Smallish interim release with not a whole lot of new features.  Bunch of bug fixes.  A couple of new bugs introduced that may or may not affect you.

REAL Studio 2010 Release 1 is now available.  Note that that IDE is now called REAL Studio instead of REALbasic.  The language is still REALbasic.  So in other words, RS announced RS 2010 R1 (now won’t that be fun until we get it straight?)

Perhaps the biggest change is that now the documentation is now online at http://docs.realsoftware.com.  Yippee!  It’s about time.  At the last REAL World conference in 2008 (!?  has it really been that long since RW!?) there was much talk about doing this.  Nice to know that it only took 2 years and it being #10 in the new Feedback list for it happen.  Sorry for being pessimistic but, in my opinion, this should have been done a very long time ago.

This doesn’t replace the built-in Language Reference or PDF documentation so you don’t need to be online to access it.  Hopefully this means that the Language Reference gets better as we users can start adding usage notes to make it more clear on how the various pieces should work.  How will the online changes affect the built-in Language Reference?  No idea, but hopefully the content changes based on user entries in the online version.

Unfortunately, there is no word (yet) on who can edit the content.  I have no doubt that RS (the company and not the IDE) will limit who can edit the content simply because that was their number one concern in various discussions at REAL World.

The 2010 R1 release still does not support Cocoa builds.  More in-depth review of Studio 2010 R1 later in the week depending upon work load….

Thoughts about the online documentation?  Good, bad, indifferent?

Normally I run REALbasic on Mac OS X and remote debug in Windows.  This works 99.9% of the time but late last week I ran into a situation where I wanted the IDE on the Windows side as well.  So I installed RB and downloaded the plugins that I needed.  Then I started to use RB.

Using RB for Windows was…different.  I’m not sure that I can quantify it other than that it seemed less polished.  It just doesn’t feel like a normal Windows app and it certainly was not as smooth as the Mac OS X version.

The reason I was in Windows to begin with was of tracking down a printing bug that was affecting my product.  Turned out it was the Application.UseGDIPlus property that had been set to true.  The end result was that my reports were ‘blown up’ about 10 times bigger than they should have been.  This has been documented and is <feedback://showreport?report_id=10399>.  Turning off the property fixed the problem.  Some fix, eh?

I don’t think that Windows gets as much attention as the Mac OS X.  Why do I believe this?  The ARBP surveys consistently show Mac users being about 80% of the membership.  Likewise, traffic to this website is roughly 80% Macintosh.  What this means is that beta testers are predominantly Mac based.  I believe that most of the developers at RS are Mac users as well.

Currently, RS is in the transition to get Cocoa out.  It won’t be happening for 2010 R1…so it’s obviously a much tougher nut to crack than they originally thought.  Honestly, I’m not surprised.  Going from Carbon to Cocoa is like creating an entire new platform.  Eighteen months to two years isn’t out of the question for such a big undertaking.

I’m hoping that when Cocoa is out and working great (you think it won’t have some bugs in the first release?) that RS pays a lot of attention to Windows.  They’ve said in the past (sorry no reference for this) that a vast majority of new licenses are Windows users.  But yet, based on observation, the professionals and beta testers are mainly Mac users.  Does that not say something?  Would better Windows support translate into more Professional and Studio licenses?  I don’t know, but I suspect so.

Perhaps it’s time to kill support for Windows 2000.  I’d even suggest killing off XP but I know a lot of places in the world are still actively using it so that’s probably a non-starter.  I believe Cocoa support will effectively kill support for anything less than Mac OS X 10.4 so why not for Windows too?

I suggest that everyone that has a Studio license do a bulk of their work in Windows for a couple of weeks.  More Windows-specific bug reports will (hopefully) get some of the more obvious (and painful) bugs fixed.

What are your feelings about this?  Am I right, wrong, or somewhere in-between?

The Association of REALbasic Professionals did a survey late last year about the REAL Software beta program.  You can see their writeup here.

There was nothing earth-shattering in the results.   With a self-selecting group (via the survey name) they found that roughly half of all the respondents participated in the beta program in some form or fashion.    Of those that didn’t participate, most ARBP members didn’t even know it existed.  I’m shocked that people didn’t know about it.  I guess that just shows how long I’ve been part of the RB collective. 

Unsurprisingly, the Non-ARBP folks that were not part of the group, when asked why they weren’t part of the beta program, responded most often with some form of “I’m a newbie.”  It would be nice to get more of these folks into the beta program but given their timidity with RB to begin with I’m not sure they’re confident enough to know what a bug is and what it isn’t.

Just for the record, the way to sign up for the beta program is simple.  Log into your account on the REALbasic website and select “Beta Program” from the menu options.  You have to have a current, valid license for any version of REALbasic.  That’s it!  You then start receiving the beta list emails and get access to any current alpha, beta, or final candidate downloads.

A lot of the survey respondents said they participated in the beta program to test their product before it was released as well as making REALbasic better.  This makes sense as most of the participants are using REALbasic professionally and don’t want to be surprised with a new version and know (mostly) what the current bugs are.

The survey asked a question about having some form of compensation for beta testers.  Among the ARBP members it was 50% yes and 49% no.  Non-ARBP members said no 66% of the time.

I’m the one that suggested this question because I’ve probably logged around 50 RB bugs in the past couple of months.  Some of this because of my high level of interest in the new reporting system and some of it from producing many hours of REALbasic training videos.  I sometimes feel like I’m being asked to do my own job and then RS’ and the only reward I get is a better product (not that that’s a bad thing).  From the mixed results, the professionals have similar issues.

Finally we asked the question, “Do you feel the beta program is improving REALbasic?”  Both groups were overwhelmingly Yes with 70% of ARBP members with 90% of the non-ARBP members.  I think the interesting part lies in the 30% that didn’t say yes in the ARBP group.  What are they unhappy about?

From my own experience in the beta program, too many things are being changed when the product goes to Final Candidate status.  Final Candidate should mean that they think there are no more changes to be made and therefore this build is going to be THE release unless a show-stopper bug is found.  Unfortunately, we saw the results of last minute changes with RB 2009 R5 when a change late in the cycle caused reporting and the database to be broken.  The result was RB 2009 5.1.

So what are your thoughts about the beta program?  Do you like it?  Is it flawed, or is it just the nature of a product that’s always changing?

Making a screencast video presentation is more difficult that you image.  First you figure out the script, then you do the recording (perhaps more than once), then do any editing (cut the coughs and um’s, speed up long typing sequences, etc), add any callouts or special effects, then convert to the appropriate video format, upload the video and finally create an accompanying article to go along with it.

Whew!  That’s a lot of work.  I’ve done this for over nine hours worth of material so far!

We, BKeeney Software, are now offering streaming videos for REALbasic training with over an hours worth of free video (you do have to sign up for an account though).  To say that this has been a labor of love is understating the scope of the project.  With nine hours of video we’ve barely scratched the surface of all that REALbasic has to offer.  We have many, many things still left on the plate. I look at this as a never ending stream of videos as REALbasic is always evolving (on a 90 day basis!) so the work will never be done.

With nine hours available now, what’s it mean for a month or year from now?  I don’t honestly know, but as I’m writing this I’m encoding and updating another twenty-six minutes of video.

Since this is REALbasic I spend a lot of time working in one environment, Mac OS X, and doing debug runs in Windows 7 and Linux (Ubunutu) and show you the big, little and sometimes subtle differences between the platforms.  You’re seeing how I approach a project from the ‘what I’m going to do’ to implementing it and doing final testing.  And yes, you get to see me make some mistakes (hey, don’t we all?) and through the magic of post editing I’ll point those out when I do them so you’re not confused and then we show the correction process.

This is not a typical video training program.  We have five hours of video just on the basic controls available for REALbasic.  Not only do we describe what it does and some of the things to be aware of, we use the control in a project and examine what it does in Mac OS X, Windows, and Linux when there are differences.

My goal is to make you a better REALbasic programmer.  I name EVERYTHING from RB objects to my variables in source code so that they mean something.  At a glance you should be able to tell what your source code is doing because you’re not just writing code for right now, but you’re writing code for six months and six years from now.

Sign up for an account and automatically get a free Guest Pass.  Poke around and take a look at the free videos.  We’d love it if you’d sign up for a subscription.  With our introductory pricing, a three month subscription costs $45.  A year subscription is $150 which is a 20% savings.

What’s great about the video training?  You can help direct what videos are done next.  REALbasic has thousands of classes – some with poor documentation and examples.  We can create the video training that helps you out sooner rather than later.

That’s it for now.  Happy coding!