Xojo 64-Bit Debugging

We’ve migrated a couple of projects to 64-bit and for the most part I’m pleased with how Xojo handles it.  It’s pretty seamless and it just works.  I can’t ask for anything more.  Additional observations:

The lack of Windows 64-bit debugging makes life difficult.  This appears to be corrected in 2018 R1 (in beta now) so that will be a most welcome change from having to go old-school and use logging to debug my Windows applications.  64-bit debugging in macOS and Linux works just like 32-bit applications.

There is no incremental compiling, yet, in Xojo.  This makes the debug cycle much longer than we’re used to with 32-bit applications.  When you debug a macOS or Linux application the dialog is quite clear that incremental compiling is off so there’s hope that the next step in this process is to get incremental compiling working.

The 2018 R1 beta cycle has taken a long time.  Presumably the level of effort to get the LLVM compiler working for Windows 64-bit debugging was painful.  And now that it appears to be solved hopefully all the other goodies on the plate (interops, Android, web 2.0) can all proceed at a good pace.

I had an instance the other day in 2017 R3 where Target64bit didn’t work.  After struggling with it for a while (because it should have worked) I deleted the plugin cache and restarted Xojo and voila!  It started working again.  I wish I had a better way of diagnosing stuff like this.

Miscellaneous:

I’m a big fan of the Einhugur Treeview control for several reasons.  First, it’s very fast with the ability to LockDrawing.  Second, since nodes are persistent you don’t have to go to extra lengths to manage your nodes as the user expands and collapses nodes.  Load them once and they’re there for the duration.  It’s a good option, in my opinion, for really fast development work.

The only drawback I have with the TreeView control is that it’s not compatible with Gtk3 yet.  According to Bjorn it won’t be until this summer.  This means any Linux projects using it will have to stick with Xojo 2017 R1.1 until it’s updated.

Happy Coding!

Xojo 64 Bit

Xojo will eventually be 64 bit capable. Xojo Inc said at last weeks developer conference that the 64 bit work for Cocoa is about 70% done and for Windows and Linux apps it’s complete except for the testing (they said specifically you could compile apps but that didn’t mean they ran properly). The next real trick is to get the compiler itself working in 64 bit.

iOS is causing a delay (naturally) and this is pushing back the release of the 64 bit compiler until summer of 2014. There will be betas before then with the option to compile in 32 bit or 64 bit. Eventually the 64 bit version will become the default and then at some point in the future you could presume that the old compiler will just go away.

64 bit has been promised for a while now. At last Real World (2012) they gave us this roadmap:

64 Bit Support: Early next year (2013) Mac OS X console applications will become 64 bit capable. Then Cocoa applications. By the summer of 2013 Linux and Windows apps will get converted.
LLVM: Real Software is upgrading the backend compiler to use LLVM. During the first quarter Mac OS X 32 bit applications will start using it. By second quarter 2013 Mac OS X 64 bit apps will use LLVM. Finally, by third quarter 2013 Windows and Linux will use the new compiler.

So I guess another delay won’t mean much.  Like any good sports fan I know the saying, “There’s always next year.”

REALbasic and LLVM

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.