Updated Python Debug Console [v1.5]

[another_commander]

The Oolite JavaScript Console v1.3 for Windows has now been released on Berlios.

[Capt. Murphy]

A wholehearted thank-you to Kaks and another_commander for this version.

I can't tell you how frustrated I used to get mistyping commands or having to scroll up and down to copy and paste a complex command previously used. I love you both.... (in a manly bear-hug kind of way of course )

[Svengali]

A wholehearted thank-you to Kaks and another_commander for this version.

Seconded .-)

[Kaks]

Thank you for your thank yous!

One thing that I suddenly remembered: there's always been the possibility to change the default port from inside Basic-Debug.oxp/Config/debugConfig.plist, but the compiled .exe was always 'stuck' on the default port (8563).

Version 1.4 now allows the .exe to listen to any port (1 to 65535) by just adding one line to the .cfg file. To listen to port 8564 the setting is

Code: Select all

Port = 8564

This way - in windows - you can have multiple copies of the console (in different directories), each connected to a different copy of Oolite!

Edit:You can do the same in linux if you set up separate AddOns directories for each copy of Oolite, but there's no precompiled executable for linux.

However, if you already have a working DebugConsole in linux, you can grab the latest drop-in DebugConsole.py from here: http://svn.berlios.de/viewcvs/oolite-li ... Console.py and just replace your older (1.0,1.2 or 1.3) version with that.


Switeck, I've looked into the matter of the dropped packets, but unfortunately the js engine inside Oolite it's faster than the 'compiled' python inside OoDebugConsole (it's actually still interpreted, but packed inside an .exe archive that self-extracts to a temp directory, then launches the specified python text file to be interpreted inside the tmp directory, plus a few interesting tricks...)

When Oolite sends too many messages for the python library to cope with (the one provided inside the twisted package) the console disconnects. Just like in a classic denial-of-service attack!

I'm afraid it can't be 'repaired' as such, unless I manage to source & compile in a much faster version of the twisted library than the one I'm using already...

Anyway, if you always wanted to have 2 versions of Oolite running, each with its own personal JS Console, get it while it's hot!

[Thargoid]

Could the config file also perhaps be used as a repository for user-created macros (from :setM)? So that they can be saved and be persistent from run to run without having to go file-hacking.

[Kaks]

Hmmm, I suppose it could, at a stretch. However, Oolite itself should be taking care of them :setM macros, like what happens with macs... I'll see if I can figure out why it's not working as planned under windows...

[Kaks]

Ok, I've got Oolite to save all the console macros in windows & linux, like it should!

Unfortunately I also couldn't stop tinkering with the Debug console to make it look better/more functional.

The result is version 1.4.1 - I hope I'm done with it for a while!

Edit: I also noticed a couple of other problems, one of them nested inside (basic-)debug.oxp.
Contrary to what it says on the wiki, :listM wasn't showing any of the default macros for quite a number of months.
Still, it is now, at least in trunk!

You'll have to grab Debug.oxp / Basic-Debug.oxp from tonight's nightly builds to get a more fully working debug environment.

PS: I'm probably repeating myself now, but I'm fairly pleased with the shape (& colours) of OoDebugConsole.exe & DebugConsole.py right now.

PPS: Please don't find bugs in there!

[Kaks]

Nope, I couldn't let it lie. I've done yet more tinkering, and now we've got
Oolite Javascript Console v1.4.4, available at a download location near you.

Now it's a really good time to go after other pursuits, I reckon!

[Kaks]

Switeck, I've looked into the matter of the dropped packets, but unfortunately the js engine inside Oolite it's faster than the 'compiled' python inside OoDebugConsole

<snip>

I'm afraid it can't be 'repaired' as such, unless I manage to source & compile in a much faster version of the twisted library than the one I'm using already...

Well, I kept thinking about this issue, and as of rev4811, Oolite's own TCP protocol is more fault tolerant than before.
What has been happening so far is that any time the debug console refused/dropped a TCP packet Oolite would disconnect.

From now on (or from tonight's nightly build on, depending! ), instead of breaking off the connection as before, Oolite will wait a few milliseconds, then it'll try to send the dropped packet again. It'll try at least 3 times before giving up.
Every time it tries to resend a packet, a warning is written to the log, to give a better idea of what's happening under the - apparently trouble free - surface.

This reduces the likelyhood of disconnects, but doesn't eliminate them completely.
Since some bugs might be really hard to replicate, and it's 'quite annoying' if you're trying to debug Oolite with a just-now-dead debug console, I've added a new read/write console related setting:

console.ignoreDroppedPackets

if set to true (it's false by default - dropped packets are a bad thing), Oolite will try and stay connected to the console at all costs. However, the actual functionality of your debug console will be impaired: how much depending on exactly which packet is dropped. As with all console debug settings, like pedanticMode & debugFlags, it only applies to the current session, so if Oolite dies horribly in the middle of your debugging, you'll have to set it again after the new 'Opened connection with Oolite' message.

In any case, a copy of the data within each dropped packet is now written to the log, regardless.
Hopefully these two changes will improve the mileage you're getting out of your debugging!

Cheers,

Kaks.

PS: I seem to be the one person constantly writing to this thread of late... I should really stop talking to myself!

[Svengali]

PS: I seem to be the one person constantly writing to this thread of late... I should really stop talking to myself!

Are you kidding? We carefully follow each of your words!

[Kaks]

You're too kind!

[Switeck]

Switeck, I've looked into the matter of the dropped packets, but unfortunately the js engine inside Oolite it's faster than the 'compiled' python inside OoDebugConsole

<snip>

I'm afraid it can't be 'repaired' as such, unless I manage to source & compile in a much faster version of the twisted library than the one I'm using already...

Well, I kept thinking about this issue, and as of rev4811, Oolite's own TCP protocol is more fault tolerant than before.
What has been happening so far is that any time the debug console refused/dropped a TCP packet Oolite would disconnect.
...
PS: I seem to be the one person constantly writing to this thread of late... I should really stop talking to myself!

Thank you!

I will continue to find new and better ways to break Oolite to keep you amused.
...I mean this will let me continue coding and debugging my next Oolite disaster.
...I mean my next Oolite OXP.

My debug disconnect was because I was trying to log all 256 possible system checks in a tight loop to find closest one. It might be easier to use the existing command to do this, ( SystemInfo.systemsInRange(7) ) but the start location is interstellar space. For SystemInfo.systemsInRange(7), there's a little warning: "Note: will not produce correct results if used in interstellar space." ...which I take to mean it calculates systems in range from the nearest system to your present interstellar space location or the starting system you used to get to interstellar space, neither of which is what I want.

I don't reply as much as I maybe should because I don't know what to say. The inner workings of Oolite is still "Greek" to me -- I'm picking up javascript the "hard" way (by trial and error, mostly error) so any changes you made I may be able to understand the results but not always the methods.

[Kaks]

Hmm, don't quote me on that, but I've got the vague feeling it may produce the correct results in interstellar space now.
That note was written a long time ago, and there has been some interstellar fixing going on in the meantime...

About the debug disconnect, the main problem there is consoleMessage() - while the python program is busy both figuring out which text is being printed & actually printing the message on the screen it's kind of - well, too distracted to listen to any new stuff coming from Oolite, I suppose. The twisted library has got a bit of a buffer, but there are a lot of factors making life difficult for that poor console, not least  the protocol itself...

As an example, I've created 2 macros to enumerate all the properties of any and each js object. Their functionality is pretty similar:

> :showM enum
> showMacro("enum")
:enum = var r=[],n=PARAM.split(' ',1);consoleMessage('warning',n);for (i in eval('global.'+n)) r.push(i); r.sort();consoleMessage ('warning',' -\n'+r.join(' | '));
> :showM enumerate
> showMacro("enumerate")
:enumerate = var n=PARAM.split(' ',1);consoleMessage('warning',n);for (i in eval('global.'+n)) consoleMessage ('warning','. '+i);

The main difference is that the first one waits until it's finished, then displays all the properties at once, while the second one displays each property one at a time, in the middle of a pretty fast loop.

If you try to enumerate an object that has got many, many properties with the second macro, sooner or later you'll disconnect.
With the first one, you just won't!

my own test cases:

Code: Select all

:enum player.ship

&

Code: Select all

:enumerate player.ship

As an added bonus, the first one also lists all those properties in alphabetical order, something the second one can't possibly do!

Btw, if you want to discover all the js objects accessible within Oolite, you can start by

Code: Select all

:enum global

and work your way down

I will continue to find new and better ways to break Oolite to keep you amused.

'Great'!

[Eric Walch]

Hmmm, I suppose it could, at a stretch. However, Oolite itself should be taking care of them :setM macros, like what happens with macs... I'll see if I can figure out why it's not working as planned under windows...

Now that this all works, we should probably have a wiki page for the use of the console. Most of the oxp developers know only a fraction of what is possible.
We currently only have the page [wiki]Oolite_debug_console_TCP_protocol[/wiki] were is explained how the console works technically under windows/linux. Am I right that we have not yet a page for its use? If so (I couldn't find one), it should probably become a new page about its use.

[Capt. Murphy]

Hmm, don't quote me on that, but I've got the vague feeling it may produce the correct results in interstellar space now.
That note was written a long time ago, and there has been some interstellar fixing going on in the meantime...

It does appear to be working fine in Interstellar space - I've got a script that uses it there and it does what I want it to do.

Edit - I took that warning to mean that the construction

System.infoForSystem(galaxyNumber, system.ID).systemsInRange() doesn't work from Interstellar space...never actually tried that....

Another edit - just tried that and it does work fine as well...