Cross Platform Programming Languages

David Lloyd lloy0076 at adam.com.au
Wed Jan 17 09:18:20 CST 2007


Tim,

> If you can get over the fact that it's not free, and it's basic,
> consider Real Basic (the Linux standard edition is free apparently).

RealBasic uses an object oriented version of BASIC not unlike Visual 
Basic (at least in VB 6.X days). Its OS X GUI is very easy to use and 
its debugger is highly effective. It's not too rare that a developer 
will be able to answer your questions if something goes wrong.

> I had a bit of a play with it last year (on Linux and Windows) and
> they also have a MAC version as well, and the code is generally
> cross-platform.

RealBasic is a Mac product. Because it runs atop its own virtual 
machine, it's able to port to other operating systems as you have found out.

> In fact from speaking to their CEO you can actually
> deploy to other platforms from a single "professional edition" version
> of the product.

Here is the crux of the matter. The core material, developed by Real 
Software, is truly cross platform. However, as Real Software isn't the 
largest software developer not all things one might require are an 
official part of RealBasic.

I probably should say that I've had extensive experience working with a 
Real Basic POS application which initially communicated via a 
"proprietary" API to a PHP backend. Realising that the communication was 
becoming cumbersome, we took a slight digression:

1. I implemented a Perl SOAP server
2. The other person used RealBasic's SOAP plugin/libraries
3. ...and threads

Here is where trouble started.

Firstly, the virtual machine that RB uses is like the old Windows 3.1 
scheduler. It's co-operative; it cannot be preempted. In order to hide 
the delays caused by the SOAP method calls, we put the SOAP calls into a 
n RB thread and then called it in the thread.

But the threads run on the RB virtual machine and they can't be 
preempted. So, the SOAP thread would land on the RB virtual machine and 
would sit and wait for the SOAP server. Of course, the GUI thread would 
get blocked and suddenly the application would appear to freeze.

This got to be a total pain. We took another path. RB would write to an 
SQLITE backend and a Perl client would read from the local database and 
send the messages via SOAP to the server. This proved to be a winner, or 
so we thought...

At some stage we noticed that messages were mysteriously dropped. We 
couldn't quite work out what it was except we knew that it would happen 
if I set the Perl SOAP client to send data too fast.

I came to the conclusion that it wasn't the Perl stuff alone. I could 
put that on four different machines and run it as fast as Perl would 
loop it all at once and the Perl client/server would stay in sync. 
However...

We discovered that RealBasic doesn't implement non-blocking writes to 
SQLITE3. Perl, on the other hand, would grab a lock on the database 
while it was writing to it as it was possible that RB and Perl could 
clash with each other...and we discovered that if the Perl client was 
accessing the SQLITE3 database at the same time as the RB client, then 
the Perl client would take precedence and the RB client would do "random 
stuff".

"Random stuff" usually equated to dropping whatever statement it was 
doing, but occasionally it would corrupt the SQLITE3 file.

Whilst we looked and asked, we came up with no sensible answer to this 
dilemma. As far as I currently know, RB will always do a blocking read 
if it's trying to access a database that is locked for some reason and 
that this block will also have the same effect as blocking the 
non-preempitble scheduler.

I think I would still recommend RealBasic but only with careful 
investigation as to:

  a) Its handling of databases, transactions and locks
  b) Its handling of threads
  c) Its handling of SOAP / XML-RPC if you plan to use it

To be useful in the application I suspect Evan wants it to be, you need 
to be able to do have a virtual machine where you can't block the GUI 
from doing things.

At best you'll look unprofessional - at worst you'll get a hung application.


DSL


More information about the linuxsa mailing list