Remote Debugging Enhancement Idea

Remote Debugging in Xojo is perhaps one of my favorite features in Xojo because it lets me work in the environment of my choice (macOS) and run it on any Windows, Linux, or even another Mac on my network, or in my many VM environments.  One of the things that’s always bugged me about remote debugging is the cycle time.  Every time you do a remote debug the IDE sends everything (executable, libraries, resources), again, to the remote debugger.  Even a simple change requires that the entire package is transferred to the remote debugger.  Every.  Single.  Time.

Xojo improved the cycle time for deploying web apps to Xojo Cloud in 2016 Release 4.  They did this by caching the framework and plugin libraries on the Xojo Cloud server.  When connecting to the Xojo Cloud server it tells the IDE what frameworks and plugin libraries it has and the IDE then decides what to upload.  So your first upload may take four or five minutes but subsequent uploads using the same version of Xojo take considerably less time.  In my case it’s about a minute.  It’s a welcome speed up.

In remote debugging, large projects can often take a LONG time to send simply due to their size.  I find myself debating on whether to install the IDE in that environment (along with prerequisite plugins), or to simply wait through the remote debug cycle.  Sometimes it’s a wash, but, I’ll be honest, it’s irritating to spend the three minutes transmitting to the remote debugger only to have to quit almost right away and change a label or a single line of code, only to have to sit through the transmit time again.

Why can’t they do the same thing for Remote Debugging that they did for deploying to Xojo Cloud?  Think of the time savings this change could do for someone that does a LOT of remote debugging like I do!

Time savings aside, there ARE some drawbacks.  The first is that the Remote Debugger becomes a much more complicated mechanism than it already is.  Since much of the code is (presumably) portable from Xojo Cloud to the Remote Debugger this might be a moot issue.  However, converting from whatever they’re using on Xojo Cloud (presumably Xojo) to desktop use may not be trivial.  It’s hard to say without asking that question.

Secondly, it would have to store all of these libraries and frameworks in a cache and then what would you do for cleanup?  When it quits delete these caches or keep them around?  I could argue for both ways.  Perhaps that’s a preference setting with maybe a quick calculation on how large the current cache is?

Third, it distracts from 64-bit Remote Debugging.  Maybe.  If I had the choice I’d love both, but if it meant delaying 64-bit for six months I’d rather have 64-bit now.  This is a wish list item, after all.

I created Feedback ID 46848 to get this idea into circulation.

What do you think about this idea, Xojo Developers?  What other pain points do you have with Remote Debugging?

Remote Debugger Issue

One of the changes in Real Studio 2012 Release 2 was an improved Remote Debugger Stub.  It compresses the files it’s going to transfer which results in a significantly faster transfer to the remote machine.

I’ve been happy with it until today when I kept getting this error when trying Remote Debug into Windows in VMWare on my machine.

VMware FusionScreenSnapz001

 

Not a very helpful error message.  This occurred as soon as the first data packet reached the Debugger Stub.

After banging my head of against the wall for about an hour (and starting to panic a bit because of a deadline) I started poking around.  The stub has worked for me, without issue, for years.  Why now?  What changed?  I tried using an older stub, older IDE versions, and all sorts of things.  Since I had the older one, newest one, and even a new beta version I had renamed the folders so I could keep them in one folder.  Last week I consolidated and moved folders around so I could manage them batter.

Have you guessed what the problem is yet?  I finally went to options and that’s where I discovered that the Download Location I was putting the files into no longer existed.  A simple change fixed the error and I was able to use the Remote Debugger in Windows again.

Feedback report <feedback://showreport?report_id=23508> was submitted.  Ideally the Stub should check the location before a debugging session starts or if the location doesn’t exists uses a temporary location.  I suspect this one will get fixed rather soon.

So, there you go.  If you’ve been banging your head up against a wall trying to get Remote Debugging to work, you might want to check the Options/Preferences and see if the Download Location exists.  Hopefully this saves someone, somewhere along way, some time.  Happy Coding!