Gammon Forum : MUSHclient : Plugins : Line numbers in plugins

Entire forum ➜ MUSHclient ➜ Plugins ➜ Line numbers in plugins

Line numbers in plugins

It is now over 60 days since the last post. This thread is closed. Refresh page

Posted by Ked Russia (524 posts) Bio

Date

Wed 12 Mar 2003 11:13 AM (UTC)

Amended on Wed 12 Mar 2003 11:14 AM (UTC) by Ked

Message

I have a small ... a large problem with debugging a plugin.
The problem is this: the plugin in question is 847 lines of text long. When trying to install it I get 2 error screens. The first one (VBscript one) says that an instruction is expected at line 540. After closing that screen I get one in Muclient proper (the pinkish colored window with pluging parsing errors), that one says it has encountered a script error at line 327.

Now, I've tried scrolling directly to line 540 in the plugin, but there's no

 end if

anywhere around there (which is what VBS is complaining about). Line 327 looks like the one with the

<script>

tag. So I thought that maybe I need to find line 540 starting from line 327 :) But 327 + 540 = 867, which is greater than the total number of lines in the plugin.

I'd really hate to go line by line through the script, which is rather confusing, so maybe there exists a simple explanation for how lines are numbered in plugin files and how those numbers are referenced by the two error messages - the VBS one and Muclient one? In short - how do I find the actual number of the error line in the text file that contains the plugin from those error messages?

Top

Posted by

Meerclar USA (733 posts) Bio

Date

Reply #1 on Wed 12 Mar 2003 06:52 PM (UTC)

Message

Code is counted at each line starting from the top of the file and including blank lines. You could, as this is a VB script, get a VB compiler and run the script thru it to find the errors.

Meerclar - Lord of Cats
Coder, Builder, and Tormenter of Mortals
Stormbringer: Rebirth
storm-bringer.org:4500
www.storm-bringer.org

Top

Posted by

Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #2 on Thu 13 Mar 2003 06:42 AM (UTC)

Message

The line count in the VB error message would be from the start of the <script> tag, assuming you have only one.

The line count for the plugin should be the end of the <script> section, hopefully.

If you email me the plugin I would hopefully be able to tie them together mathematically. :)

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Ked Russia (524 posts) Bio

Date

Reply #3 on Thu 13 Mar 2003 09:41 AM (UTC)

Message

Ok, problem solved. Using Meerclar suggestion I saved the script in a separate file and loaded that under Scripting in MC. That gave the correct line number.

I am guessing that when compiling the script in the plugin, VBS is adding something to the beginning of it - in between the <script> tag and the first line of the script - perhaps the contents of the <include> file. That would explain those 100 something extra lines, if counting from the <script>.

Anyway, thanks Nick and Meerclar. And I'll be posting the plugin here as soon as I get it tested and cram some more things into it. Really hope it works - I already have a hard time figuring out what exactly it does myself, so if it starts acting up I'll be in serious trouble with debugging it :)

Top

Posted by

Magnum Canada (580 posts) Bio

Date

Reply #4 on Thu 13 Mar 2003 02:10 PM (UTC)

Message

As someone who writes rather large plugins, I have been frustrated by this problem as well.

My plugin scripts are broken up repeatedly as I organize related aliases, triggers and script into different sections of my plugin file. To top it off, I also use "include" files which throw off the line count too.

Sometimes I try and remedy the problem by using: /World.Debug "Plugins"

The problem is, it's still not easy to calculate the line number, especially with multiple plugins installed, and that command prints the code for ALL of them to the output window.

So, I have a suggestion:

Modify World.Debug, or create new Debug option(s) which:

-Allows for specific plugin or main file debugging only.
-Redirects output to an external notepad window.

For example:

World.DebugToNote "Plugins"
World.DebugPlugin "AOD_EQ"
World.DebugPluginToNote "AOD_EQ"

I assume the filename would be generated automatically, perhaps something like "AOD_EQ-Debug.txt" or something like that.

Heh, it just occured to me now, as a workaround, I could use the current /World.Debug "Plugins", then copy the entire section related to my plugin to a blank notepad, and then use the notepad's line counter to easily find the line I need. The suggestions I just mentioned above would simplify the process somewhat. (I don't know why I didn't think of that before - Duh!)

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.

Top

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #5 on Thu 13 Mar 2003 07:55 PM (UTC)

Amended on Thu 13 Mar 2003 07:57 PM (UTC) by Shadowfyr

Message

Hmm. I use SciTE as an editor and I know it has built in debug support for attempting to execute scripts and such. When it runs one, it displays errors and I think hilights the line with the problem. The difficulty is that since the normal engine hasn't a clue what 'world.' objects are, I haven't really been able to test it.

However... It occures to me that since SciTE is available under Linux, PC and probably MAC, it is user modifiable (though I have been to lazy to change and recompile the XML lexer in it to color scripts right) and it does have a way to display error information, that it could be a helpful thing to let Mushclient interact more directly with.

The issues for doing this though are:

1. Mushclient needs to be more aware of when scripts use includes, so it can accurately report the right error line in the right file.
2. I am not sure you can call SciTE externally and pass it both a file 'and' the error line. The file yes, but that is useless without hilighting the error.
3. If Mushclient was more aware of such things, there is nothing to prevent making the notepad do basic stuff like showing the included lines with a different background and hilighting the error line itself. This wouldn't be as good as a full editor like SciTE, but would definitely be an inprovement over the current "guess where the real line is" method. ;)

However, it would mean having Mushclient parse the script, at least enough to find included code and VBScript's method of doing so leaves a lot to be desired, as in being nearly impossible compared to java, which I believe actually has a real include directive of some sort. They really short changed VBScript in a lot of ways. :p The only solution to this would be to actually make a function within the constants file (or some other common file) that impliments the loading of includes for VB, so Mushclient would simply look for instances of 'include("Filename")' or 'Variable = include("Filename")' when finding the places where such code blocks start.

There may be other useful things to add to that common set of routines as well, like 'sort', which VBScript also doesn't have.

Anyway, there is not much point of returning the line number in error, if the line is never right, but the solution definitely requires a bit of work, no matter how you look at it.

Top

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #6 on Thu 13 Mar 2003 08:15 PM (UTC)

Amended on Thu 13 Mar 2003 08:17 PM (UTC) by Shadowfyr

Message

Hmm. Actually, thinking on it, another solution for VB would be a directive that the XML parser would see while counting lines. It isn't as though you could load this XML into a browser and it would work after all, so no need to be 100% complient with the implimentation. Basically usinng something like a compiler directive you could use #include ("Filename") and have the XML automatically incorperate the included script into the main body as it loaded. Both the engine and Mushclient would then have a complete copy and you could show the code in the #include block colored like I suggested, to differenciate it in an debug window (i.e. see the error and 'where' it is, but not edit.)

Besides coloring the included blocks, you could also have a right click menu item for 'open selected file in editor', to let them select the file name in the #include line (displayed in the debugger to show where the code block came from) and open that file. This would still create problems for java then, though...

There has to be a simple solution to this... Would a world.include command allow a running script to load new code maybe and use that in the parse step to get the right number of lines?? Then you would be back to the same situation again though. Sigh... Up to you I guess Nick, I don't have access to the programs code, so it isn't like I can do more than guess at solutions. ;)

If you did use the #include method though, then since Mushclient does load and parse all scripts, it would be removed and replaced with the actual included file anyway, even in pure vbs, js, etc, so it could be a good solution. Would have been nice if VBScipt didn't have this issue though and you could just look for the built in language specific lines for including such things... Serious mess.

Top

Posted by

Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #7 on Thu 13 Mar 2003 10:21 PM (UTC)

Message

Although I haven't seen the plugin the arithmetic would be like this - it isn't too hard.

You get a error line X (eg. 327 from your post).

You need two other things:

The offset of the <script> tag - use your editor to find that (eg. line 68) - call this A.
The number of lines in your constants.vbs file (or the file appropriate to your language). (eg. 122) - call this B.

Thus the line reported as an error would be X + A - B in your plugin. In my example that would be 327 + 68 - 122, that is, line 273 in the plugin file.

That is, subtract out the number of constants in the include file, as VBscript saw them, but they don't take up room in the plugin, and add in the offset of the <script> tag. Give or take 1 or 2, this should be the correct line.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #8 on Thu 13 Mar 2003 11:21 PM (UTC)

Message

It is a bit more complicated than that. Magnum for instance uses, I believe, multiple includes and since all of these 'probably' change the line the engine thinks it is executing... Then again, I don't use those, so I have no idea of that is true.

Top

Posted by

Magnum Canada (580 posts) Bio

Date

Reply #9 on Fri 14 Mar 2003 11:08 PM (UTC)

Message

The solution I mentioned above is the best workaround. When you /World.Debug "plugins", the output includes your script fully assembled with all includes, etc. I get the feeling my post was skimmed over... sigh.

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.

Top

Posted by

Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #10 on Fri 14 Mar 2003 11:29 PM (UTC)

Message

Would I do that?

Yes, your idea will give the best representation of which line is which.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

26,847 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top