Annoying Plugin Cache Bug

I’ve been having issues recently with Real Studio recompiling my plugin cache frequently.  For those of you not familiar with Real Studio plugins, the IDE will create cache files for all the plugins so it doesn’t have to do this every time it does a build.  If you change plugins, or update them, it rebuilds the cache.

If you don’t use plugins it’s no big deal but we have quite a few plugins.  We use the Monkeybread Software plugins, Einhugur controls, eSellerate, and even our plugins that we’ve created for own use and for various client projects.  Based on configuration I sort of expect a certain level of pain for recreating the plugin cache.

One has to wonder why there’s not a more elegant solution built-in to Real Studio to manage plugins other than moving them in and out of a certain directory and restarting.  And that doesn’t even begin to address version issue with projects that are a few years old.

If you are having the same problem, you can sign on to the Feedback report:  <feedback://showreport?report_id=16431>.  This is currently ranked 54th in the Feedback System.

I’m not entirely sure what the mechanism is that Real Studio uses to determine if a plugin has changed.  Has that changed recently?  Or could the problem be the Monkeybread plugin since that seems to be a common plugin?  Maybe a combination of both?  Regardless, it would be nice to shine some light on this particular bug so it can be fixed because even with a fast machine it can become very tiresome quickly.

Are you experiencing the same thing?

Real Studio 2011 R2 WE Bug

Real Software released 2011 Release 2 this morning.  It has the usual number of bug fixes (especially for Cocoa) and some new things (especially for Web Edition).

I haven’t compiled my list of the good, bad, and ugly yet, but in my initial testing of Web Edition there are some significant changes that may or may not affect you.  The way WebPages are handled is different and if you relied upon the Session.CreatePage event you now have to rewrite that portion of it.   This change is for the better (in my not so humble opinion) but it might make your life a little harder until you get used to it (and change existing code).

The one critical bug that I’ve discovered in my testing this morning is that the config.cfg file that is generated by Real Studio gets fragged for CGI applications.  So instead of this:

APPNAME=JCLogin

THREAD_COUNT=10

PORT=0

AUTO_PORT=1

After I try to run it one time I get this:

APPNAME=

Obviously my app no longer runs.  Chatter indicated that RS thought this was a Windows only bug but since I’m running on Debian Linux I think the problem goes deeper.  More info as I find it.

[Update]:  I should point out that I’m creating a Linux, CGI application with automatic port detection.  I’m building it on Mac OS X 10.6.7 on an i7 iMac.

[Update 2]: Feedback:  <feedback://showreport?report_id=17297>

Web Edition and Version Control Format

For those of you that use the Version Control Format (VCP) for your Real Studio projects you should be aware that I do not recommend using it for Web Edition projects.  I discovered (and logged) several bugs today in 2011 R1 that will bite you.

The first is subclassing a WebControl in VCP format results in it displaying in the IDE with a black triangle indicating that it doesn’t know what the control is.  Thankfully the control still works, it just looks funny in the IDE and doesn’t seem to affect the final build.

<feedback://showreport?report_id=16518>

The second is that WebStyles do not read properly after saved in VCP format.  This will result in controls not adhering to their styles after the project is loaded again.  This does affect final builds.

In both cases it could be a write or read failure.  Not my job to figure out which one.

If you use Web Edition and version control you should make these bugs part of your priority list.

<Rant>  This is the third release in a row with serious issues with the version control format that keep me from using it.  For my consulting business I need reliable version control.  The only way to do that is to have a rock solid version control format.  It has to work in EVERY release.

Binary format just isn’t acceptable for my business.  I need to track changes on a line by line basis – sometimes my livelihood depends on knowing what changed, and when.

It ‘s obvious, to me anyway, that RS doesn’t use Web Edition internally for anything big, important, or that requires multiple users working with it.  If they did, they would have spotted these problems a long time ago. </Rant>

We now return you to your normally scheduled broadcast.

Just Another Saturday

I feel like I’m repeating myself.  Yet another Saturday wasted where I started getting into the details on a new REAL Studio training video only to get stymied by a bug.  This bug is related to FileType UTI’s and has been reported, and verified and has been around since 2010 R2.

Unless you’re using REAL Studio creating document-type applications and forcing yourself to use UTI’s you’ll never get bitten by it.  This bug isn’t a particularly bad bug as far as bugs go but it does involve project file DATA LOSS which is one of the worst types of bugs in my opinion.

It furthers my belief that REAL Software doesn’t create enough new projects using REAL Studio that are full, complete, going to be used by end user type projects.  I’m not talking about examples because they’re generally too simple and only demonstrate how to use one thing.  What I’m talking about is making a complete project that does something real and useful in a way that exercises major portions of the REALbasic framework, coordinated such that it could be considered commercial quality (even if it does nothing real).

In my case, I had a need on several projects recently to use Virtual Volumes.  I searched for a utility and the one that’s been around for years was no longer available.  I ended up making a quick and dirty utility to make them which wasn’t all that hard.

After weeks of adding new functionality to it and getting it into good working condition I decided that it would make a good training video to show new developers how to use REAL Studio.  Of course, that’s where the real work began since I now had to look at every aspect in Mac OS X (drag and drop) and in Windows (non-MDI windows) and make some changes.  I also incorporated feedback from clients that were using the utility as well.

REAL Studio and REALbasic are huge – I don’t think I appreciated that until I started doing the training videos and started listing everything I need to discuss.  Even on the things that I’ve already done (that’s over 100 videos and close to 25 hours of training!) I feel like I’ve barely scratched the surface and my list keeps getting bigger and bigger.  So I understand that bugs happens and the Law of Unintended Consequences can hit for seemingly innocuous changes.

I talked about example projects earlier.  There is one example in the REAL Studio Examples folder that is a great example of what I wished RS would do more of:  The Database Example.  It is a more or less complete example of a database application that does reports.  It is pretty much how I go about my projects and it has copious comments.  It combines multiple techniques, classes, and controls together that is how real world users would do it. I wish there were more examples like it.

It’s a prime candidate to get updated with the new Segment control.  The new Prepared databased statements would be another fine thing to add to it.  It’s a good example project that should get updated with newest stuff.  It would also force the developer to use it in a real world situation and would probably expose some of the weaknesses we find in new stuff.

In general, I’m surprised that they don’t do more tutorial and sample projects showing how to do things in REAL Studio.  But then if they did that I’d have to find other things to complain about on Saturdays.  😉

It’s Not About the Release Schedule

There’s been a lot of chatter about my recent blog posts.  I am not really opposed to the 90 day release cycle – that’s not the problem (and as such the feedback request is poorly titled).  The real problem is the quality of the releases that happen every 90 days.

Each release cycle brings many bug fixes and that’s great, but it also introduces new bugs and changes in functionality.  This happens for new features and for other changes (including refactoring that’s going on for Cocoa).

I realize that there will always be bugs.  It’s next to impossible to ship a product that’s perfect – especially something as big as REAL Studio (that spans three and soon to be, hopefully, four platforms).  But, reporting easy-to-find bugs after the release gives the product an unnecessary black eye.

Part of the problem, I feel, is the beta program.  The mantra has been to test your projects with the beta build and ‘test everything’.  Since my time is valuable, that’s akin to saying “test nothing” because, like REAL Studio itself, my projects are rather large.  It either compiles or it doesn’t and that’s not testing the product, that’s smoke testing (electrical components work on smoke and if you let the smoke out of the component it fails – sorry, electrical engineering joke there).

No one tells the beta program to test “x” feature – we just get a list of bug fixes.  I know I would like something specific to test to get the most out of my time.  Harness the people that have already volunteered their time and effort!

The Feedback system has a lot of bugs and feature requests.  Many of them are very old (they predate this incarnation of feedback system).  Some of them should be closed and some need to be addressed.  Should feedback items older than 6 months get an automatic system vote and then get another vote every 6 months thereafter?  That fact that there are a lot of open bugs is worrisome.  Should bugs and feature requests get the same level of weighting?  Should they have separate areas so that priorities for feature requests are different than those for bugs?

As someone who has spent considerable amount of time and effort trying to reduce Windows flickering I feel I can say that Windows builds right now have some “issues”.  You can say anything you want about the individual controls, I think the issue is with the Window itself.  Put a background image into a window and you might as well put sunglasses on to avoid a headache.  I bring this up because you don’t see this issue in Mac OS X (because the OS double-buffers the window).

Does REAL Software need to spend more time using Studio in Windows?  I dunno, but Windows is not like Mac OS X.  There is quite a bit of inconsistency between platforms.  Some of that is the OS and some of it is REALbasic.  I’m not enough of a Windows expert to offer any hints, but I do know that if I run into problems it will inevitably be on the Windows side (see blog posts on memory leak issues).

I know some people are pretty upset with the new LLVM compiler for RBScript.  It doesn’t work for many causing them to stay with an old version of Studio.  The problem is that the beta program said it was broken and it was released anyway.  Again, I realize that you can’t fix 100% of the bugs before release but when the major users of RBScript are saying it doesn’t work – perhaps it should have been delayed.  Maybe there should have been an option to use the old compiler.  I have no idea how much work that would have been but it would have resulted in more testing and a happier bunch of RBScript users.

So rather than focusing on the 90 day release cycle, let’s focus on the root causes of our unhappiness.

These are just a few of my thoughts.  What do you think?  Did I miss anything major?

Those Who Fail to Plan, Plan to Fail

Yesterday I created a new Feedback item to stop the 90 Day Rapid Release Model.  <feedback://showreport?report_id=14252>

In less than 24 hours it’s gone from the 4,000-ish rank to #11.  Feel free to make it one of your priorities and let your voice be heard.  If the Feedback system is truly the way to get things to change then this is our opportunity to test it.

I think we’re all fed up with half-baked and incomplete new features.  Lack of documentation and examples aren’t helping us either.  It’s to the point where each new release brings it own new set of problems.  Each release causes anxiety rather than anticipation.

It makes using REAL Studio a pain.  During the 2010 Release 3 cycle, the huge memory leak issue in Windows was causing me to revert back to Release 2 which also had its share of issues in Windows.  I seriously debated if I had to go back to Release 1 or even earlier.  Thankfully, RS decided to do a dot release for R 3.1 and subsequently R 3.2 but testing those two releases kept me from testing R4.

To be honest, I’m not opposed to the 90 day release cycle per se. I have a huge objection to the way it’s currently handled.

There doesn’t seem to be much planning going in to each release. It seems that the RS engineers are told to develop something new. They start development in *that* cycle and it gets added and released in *that* cycle. This leads to a lack of examples, lack of documentation, and features that are half thought out with too many outright bugs.

Here’s an idea:  Anything added to the project *must* have an example project that exercises major functionality. Ideally it would tweak all properties to ensure proper functionality. This does several things:

1) Ensures that the feature works as it was intended by the RS engineer

2)  Gives the RS internal QA staff and management something to verify before it’s released

3) Gives beta testers a reasonable example to start from. It becomes the de-facto baseline project for the RS engineers

4) The project becomes part of the official release and gives end users an example to use  and learn from even if documentation is missing and/or incomplete

Let’s face an inconvenient truth here, shall we?  The 90 day cycle is too fast for PROFESSIONAL users.  There’s a reason why no other development tool uses that fast of a cycle.

RS needs to properly plan features out.  They are in the R5 release cycle now so any new features not already added for beta testing can NOT be added until the 2011 R1 release.  This also means that any major bugs found in a R5 feature be pulled from this release.

I don’t know if this can be done given current engineering leadership and personnel.  If certainly feels that the current release and feature schedule is *marketing* and *sales* driven and that quality is not “job 1”.

Personally, I’d be happier giving my money to RS knowing that each release is as solid as they can possibly make it.  I’m okay if that means that a release takes a mere 60 days or takes 180 days.  A solid release means more to me than incomplete new features.  Circling a date on the calendar as a drop-dead date is fine every now and then but it shouldn’t be an every release occurrence.

Some have asked why me, of all people, is forcing this discussion.  The answer is simple.  I use the product all day long, six days a week.  I really, really like it – it’s the only product I’ve found that’s quite like it.  It puts a roof over my head.  It’s a good product now but it has such great and awesome potential.  However, each release brings new problems and new pain.  I’m getting old enough to know that I need to stop banging my head up against a wall.

I either effect change or move on.  This is my attempt at changing RS for the better.  Maybe they will and maybe they won’t.  At least I can say I tried and I’ll have no regrets either way.

Quality Either Matters or it Doesn’t

My Saturday was supposed to be dedicated to a training video for the new Segmented Control introduced in REAL Studio 2010 Release 4 that was release this week.  Unfortunately, I stopped after about an hour after documenting bugs and becoming generally disgusted with it.  What’s the point of doing a training video for something that is THAT jacked up and must be fixed (to be really usable) in a future release of REAL Studio?  Why waste my time doing a video that I’ll have to do again?

I think it’s awesome that REAL Software creates REAL Studio and a handful of other projects using REAL Studio.  But they don’t use it like we do in two different ways:  Their testing process (and I wonder if they really have one sometimes) does not test the way a real world user creates projects.  Their usage of RB for the IDE isn’t a real world example of what anyone is trying to use RB for.  Saying “we build REAL Studio with REAL Studio” isn’t a valid metric for anyone except REAL Software.

I’m not an average REAL Studio user – I get that – I actually make my living off the product.  I use it eight to ten hours a day on average of six days a week.  When I do my testing, I start by creating a simple demonstration project showing the most basic usage of ‘X’ and then expand upon it by exercising most of the properties, methods and events.  Most of these demonstration projects end up being reused in real world consulting projects and in the twenty-plus hours of training videos I have on my website.

I rarely waste my time and, in my opinion, the new features in REAL Studio 2010 Release 4 was a complete waste of my time.  The documentation was late and incomplete and the new features have glaring bugs in them.  If I can document several in an hour what does that tell you?  Where were the example projects demonstrating the new features for Release 4?  There were none.

Have you ever perused the Examples folder?  There are a lot of example projects showing you how to use individual parts of the REALbasic framework.  Depending upon which release you look at, some of the examples don’t even compile.

I also think it fair to say that most of the examples (that are working) are watered down to the point where they only show the most basic usage of a component.  They are not complex examples and therefore don’t do most people much good when they get around to implementing it in their own projects.  Most are not written with best practices in mind or how average people will use them.  They were written with the intent of getting if off the developers, or documenters, plate as quickly as possible.  Comments?  Naming conventions?  Defensive coding?  Good luck.

REAL Software as a company does not create new cross-platform applications using their own product.  They don’t see the day-to-day deficiencies that we do.  They don’t feel my pain and that’s a problem because they’re trying to sell their product to people just like me – or at least that’s what they keep telling me.

I’m about ready to stop using REAL Studio for certain types of projects because they’ve lost control of the quality.  Quality either matters or it does not.  Decide which and let me know – I have better things to do until then.

Here’s my unsolicited advice for REAL Software:  For every new release build a new project that demonstrates EVERY new feature and exercises it.  Major changes to the framework get the same treatment.  These projects should be good enough so that if there is missing documentation, the code tips or autocomplete doesn’t work (all real world examples, by the way), anyone can still figure it out from the code.  It takes planning and a commitment and thinking about how real users will use the feature in Windows, Linux, Carbon and Cocoa applications.

Please, do this for upcoming Cocoa and Web Edition releases.  If you could do that, I’d guarantee you’d find more bugs, earlier, and I wouldn’t have to spend my Saturday writing an opinion piece.

What are your thoughts?

Ruminations on REAL Studio 2010 Release 3.2

REAL Studio released a point update to REALStudio this week and brought it up to version 3.2.  The only bug fix listed is a Windows-only memory leak that affected various controls.

I know that the leak affects the StaticText control and the timer.  The bug is simple to reproduce:  add a StaticText control and a timer to the window and change the text in the timer.action event.  Run it.  That’s it.

The memory leak memory was so bad that one of my Windows apps was gobbling up tons of RAM to the point where the app was unusable.  Though, to be honest, part of the huge memory leak I was experiencing was the fault of my networking code, but the StaticText and timer leaks weren’t helping matters any.

The bug was big and whether it was my ranting or enough customers complaining about it, RS fixed the leak and issued a 3.2 beta.  Which I tested and the same day logged another memory leak.  The original leaks were fixed but now just by putting window.refresh in the timer event caused a leak in the StaticText control.  I actually logged it improperly because I wasn’t sure where the leak was and speculated on several different possibilities.  The RS engineer in charge of it added a simpler example project into the Feedback report the same afternoon.  So, obviously, they knew about the issue.

And yet, Release 3.2 went out the door with that known memory leak in place.

I’m not sure how I feel about it.  I spent an awful lot of my own time (because I sure as hell can’t charge the client doing all this testing to fix a problem that’s not theirs).  I provided timely feedback (less than 12 hours from the beta release) to test and document the bug and it was released anyway.

R3.2 is better, but it still has a major hole in it that may or may not be acceptable for my Windows builds.  I’m very disappointed that R3.2 saw the light of day since it obviously wasn’t really fixed.  In many ways I feel like this was a “Let’s shut Bob up and give him a new build.”  I know that’s not the case or at least I hope not (not to mention that sounds sort of narcissistic).

I really am starting to question their commitment to the Windows environment given their current workload.  Cocoa is late but is getting closer to reality all the time.  The new Web Edition is generating lots of buzz and even though the Cocoa and Web Edition teams don’t overlap much, the keyword is ‘much’ so it means there is *some* distraction.

It’s been another miserable week of 12 hours days trying to debug my app AND Studio at the same time.  So, yeah, it’s not been a pleasant one.

What a !$&# Week

It’s not been a great week – even though it’s been a short week.  I’ve now seen two separate bugs that are HUGE and affecting me for Windows.  In REAL Studio Release 3.1 there is memory leak in the Timer Class and in the StaticText class.  The end result is that my app, in Windows, will eventually chew up all available memory and bog the entire machine down to the point of being unusable.

Not good at any time, but this mean that both 3 and 3.1 are not usable for me, at least for Windows builds.  R 3 has some issues and a memory leak as well.  Thankfully, the leak is not as bad. I would go back to R 2.1 but since *that* release also has a nasty Windows bug I can’t go back to it.  Dare I go back to R 2?

Initial indications are that RS will not be issuing an interim 3.2 release, however.  This is why I think their Rapid Release Model stinks.  I’ve got two bugs that keep me from using the latest and greatest release and now have to wait to get a fix.

Your plan runs out in the next 60 days or so?  Sorry.  You’re S.O.L.  It might be great for RS but the Rapid Release Model is becoming the Rapid Bug Model for me.  Pretty soon, it’s going to start costing me clients.

———-

A couple people have asked me what I think about Apple changing their stance on letting 3rd party development tools for developing iOS apps and what that means for REAL Software.  Meh.

Really, there are so many items RS has to get done before thinking about iOS that it’s not even a concern right now.  The only thing that would concern me is if they decided to jump both feet first and devote a lot of resources to it.  Cocoa has taken way longer than anyone ever dreamed of (I feel that personnel changes have bit them hard on that one) and now the highly anticipated Web Edition will distract them too.

Don’t get me wrong, I’m looking forward to the Web Edition.  I think being able to leverage all my RB knowledge for iOS apps is a great idea too.  But, as they say in Missouri, “Show Me!” – I’ll get excited when I see them and can work with them and keep my business in the black.

Serial Control in Windows Vista/7 Doesn’t Work Properly

I’ve had one of those weeks where I thought I was going crazy (crazier?).  My cross-platform application that works fine on Mac OS X was behaving very strangely in Windows but only sometimes.  This particular application talks to a hardware via a serial port.  My standard test platform is Windows 7 with Windows XP as the secondary and both of these are run in VMWare on my Mac.  So a bunch of things might be at fault but after trying this out on an old Windows XP laptop I quickly narrowed the problem down.

The data packet the hardware device sends is very small – 4 characters to be exact.  What I was experiencing was that RB captured the first character on the first send – but not the whole packet.  Then it would complete the first message on the 2nd message and only get part of the 2nd message.  It would go something like this:

  1. A
  2. B | A
  3. C | A
  4. D | A

Where A is common to all messages so they should be AB, AC, AD and so on.

These messages in the real world are sporadic and with the exception of a regular hardware pass message it might be days or weeks in between messages so as you can imagine, this problem mucks up the logic quite a bit.

If you are not familiar with the Serial control, the DataAvailable event fires when there is data available (duh) and there you can check what’s in the serial buffer by using the LookAhead function.  LookAhead in this case showed just the first character.  The other property to check is  BytesAvailable which should tell you how much is still in the buffer.  It simply returned zero so I should have a complete message.  Definitely something screwy going on there.

Invoking Serial.Poll via timer did not produce any different results.  Neither did forcing a ReadAll.

One other thing that I discovered was the Serial Port Monitors are worth their weight in gold.  Using one, you can at least verify that the data got to the computer.  A free 14 day trial was good enough but if I do any other serial projects it will be worth it.

The good news is that I wasn’t crazy.  The client is okay with Windows XP for now.  The bad news is that it might take a release cycle (or more) to get it fixed. Oh well, battles for another day….

For those that care, the Feedback id is 12723.