Debugging

Posted by Rynok on Mon 29 Mar 2010 11:15 PM — 6 posts, 27,632 views.

USA #0
I have my system setup to where it loads my main script, and I have an alias that sends all commands to the script and a trigger that sends all triggers to my script.
Both are set to: "Send to: World" but then I give them a Script name to actually call and I store %1 in the Clipboard to reference inside the function.

Triggers send to OnWorldReceive().

My problem that I've noticed is when my code has any issues at all (like syntax), the entire thing freaks out and says:
Unable to invoke script subroutine "OnWorldReceive" when processing trigger ""

Code wise, it says "Error context in script" and shows me the first 5 lines of my main script page.

(In the above example, I simulated an error by changing a function name from "info" to "Info" so it wouldn't recognize it when it tried to call it later on.)

So my question is if there is a way to have better debugging than that generic phrase? If I didn't know it was a simple typo like that, I could easily spend a ton of time looking for the real error.

Thanks!
USA #1
Another issue I see a lot:
There was a problem in script file "<main script>":

The trigger subroutine named "OnWorldReceive" could not be found.
Australia Forum Administrator #2
This may be a limitation of the Perl script engine. It tries to show 5 lines around the error, which it does with Lua and some other languages.

You shouldn't have to put %1 on the clipboard, the script function gets the matching line and wildcards as arguments.
USA #3
Yeah, I'm coming from Lua where you'd get 5 lines that were generally spot-on for debugging.

Switched to Perl this time though because I have a multicore processor now and wanted to be able to take advantage of that with multithreaded Perl code. (That and using perl to pull HTTP data from websites on demand)
Australia Forum Administrator #4
I'm not a Perl expert, maybe someone else can help.

You can pull stuff from websites with luasocket.
USA #5
Well, looks like you can't do multithreading using Perlscript anyways. Guess that's a good thing to know ahead of time before I start developing too much.

I'll look into some alternate options, like having Perl process running that Perlscript connects to as a sort of Proxy. I've done that before with Lua/C and it worked pretty well. Just adds a huge layer of complexity to the process.