More BlitzMax experiments

I'm currently working on a new appstub module...


The box on the left (green on black) is a small console app, stopped at a DebugStop.
On the left is the IDE console. The app running in the IDE is a "debugger", which connects to the other app over TCP, and sends the "h" (help) command.
The running app responds by sending the help list.

I know... it's not very exciting, and at the moment is slow as hell for some reason, but it's a start...

Wouldn't it be nice to be able to debug a remote app? ;-)

A little more technical stuff...

I've created a debugger.tcp.bmx (instead of debugger.stdio.bmx), which assumes responsibility for managing the TCP gubbins, rather than pushing it through stdio/pipes.

The running app polls for incoming connections, so in theory it can quite happily run without a debugger connected to it. Once connected the two would be able to converse - just as the IDE and debug app currently do.

:-)

The polling is the issue - I was running the "debugger" in debug mode, so it too was polling for a debugger... which it does once per statement - ie. often!!
Running the debugger in release mode, it's sweeeeeeet :-)

This rocks!
Now, to see if it is possible to plug it into the IDE ?

I give you... Cross network debugging in BlitzMax ;-)




Left window is test debug app running on Linux box.
Right window is the "debugger" running on my Mac.

You can see on left side, interpreting my commands.
And on the right side, we display the responses...

:o)

Fascinating... well. I guess there might be uses for this :)

What could be the advantages of using a remote debugger ?
Is there a specific area where you need such tool ?
I'm just curious of what can be done with this :)

Now all I need are Linux and Mac systems and I'm off =]

Cross-network compiling? =p

I think it would be cool to have dedicated servers specifically for blitz-community remote cross-platform compiling/debugging. VM, dual booting (the setup for the most part), or otherwise having 3+ computers in one room, is a pain. Having a folder for each user to upload their source/modules to for compiling, etc....but i'm dreaming.

Nice tool anyhow.

Well done Brucey! This is a fantastic step forward.

For me there's nothing worse than that sense of helplessness you feel when your client's app is crashing (and cleverly bypassing your error logger in the process) but it works perfectly at home.

So I'd *love* to be able to remote debug my app over the net; accessing a client's machine *in-situ* as it were, as it's often impossible to replicate the context that your app is being run in. Very exciting!

Since I'm coming from an app/server environment, I suppose I can more easily see how cool it is to have the ability to be able to plug into a running application and see what's going on - eg. using Eclipse to remote debug an instance of JBoss on a customer server on another continent.

Although obviously not so useful for your latest platform game ;-)

... but you know me... I have a tendency to dabble outside of the BlitzMax-is-a-gaming-language zone :-p

Hmmm... examples? Dunno really. How's about :

* One of your beta testers is running your game, but for some reason it crashes at a certain point when they perform a certain function. But, when you try it on your dev machine, it works. Now you send them your debugged version, let them play the game up to that point. You connect your debugger to their running game, and "break" into the code - on-the-fly breakpoint ;-)
You proceed to step through the code and realise that a variable hasn't a value you expect at that point - maybe their locale is to blame?
Anyway... now you know what to fix....

It's either that, or you line your code with LOTS of logging stuff... or something similar.

I suppose if you are used to using remote debugging it's "obvious" why it would be useful? Otherwise, perhaps not so?
:-)

This is an example session of on-the-fly DebugStop - that is, there is no DebugStop in the code... we choose when we "stop" the app while it is running ;-)

Bruceys-Mac-Mini:remote_debugging brucey$ ./test_01.debug
sock = 3
1
2
3
4
5
6
7
debug session connected
8
9
10
reading : 120
reading : 10
data = x

reading : 104
reading : 10
data = h

reading : 115
reading : 10
data = s

reading : 116
reading : 10
data = t

reading : 114
reading : 10
data = r

11
12
13
14
15
16
^C

Some notes :
* The example app prints a counter once per second.
* The debugger "connects" to the app at '7'.
* The "break" (x) is called at '10'. ("reading : xxx" is just my debug of the bytes coming from the debugger into the app)
* following that, (h)elp is called, then (s)tep, then a stack (t)race.
* finally, (r)un is called (to restart the app and take us out of Debug mode)

Here's the test app source :

' remote debug test
SuperStrict

Framework brl.standardio

Local count:Int = 0

While count < 100000

	count:+ 1
	
	Delay 1000
	
	WriteStdout count + "~n"
Wend

DebugStop not required :-)

Break when you want... grab a snapshot of the stack... continue...

Except that you could run both the app and debugger on the same PC - think of it as a replacement for the current system which uses stdout and stderr. Platform is irrelevant.

Brucey,

very cool - like the sound of stopping the debugger when you want to.

Yes, I like that bit too and I start to see the use of it... Well done.

Brucey,

the breakpoint thing you mention in the other post would be great too. Make it a bit more like Visual Studio.

You're such a hard worker!

Another demonstration of breaking a running app - this time a graphics application.


App code:

SuperStrict

Framework brl.glmax2d

Graphics 640, 480, 0

Local count:Int = 0
Local fps:Int, ms:Int, _msec:Int, c:Int

While Not KeyDown(key_escape)

	count:+ 1


	If count > 100000
		count = 0
	End If

	Cls
	
	DrawText count, 300, 230

	ms = MilliSecs()
	c:+ 1
	If _msec + 1000 <= ms
		_msec = ms
		fps = c
		c = 0
	EndIf

	DrawText fps + " (FPS)", 10, 10
	
	Flip

Wend

Note where it happened to break - inside the Flip method. Of course, when you stop it like this, you'll never know where you are in the code... But it works.

When the debugger is connected to the app, on each statement we are checking the TCP connection for new data - that is a lot of checks... so perhaps on a very intensive app you may see a slowdown. The other way to go would be to multi-thread the testing of the socket, and set an application flag, which could be checked instead. If this route were used I would rather the threaded code was in C to avoid having to build the app threaded.

For the live breakpoints, I think it would be possible to register lines with the debugged app at runtime which it could check against and if the current line matches.. stop. In theory you could also un-register at the same time...

Just some ideas.

There's certainly no reason why we can't have BlitzMax capable of some half-decent debugging.

This is awesome.

Thank you for these enlightenments.
It was more or less what I was expecting from a remote debugger.
Effectively this isn't crucial for the things I'm doing right now but who knows the possibilities of this in the future :)

Interesting as always.