Any way to debug easily ?

Feb 1, 2010 at 11:10 PM

To clarify : I'm not trying to debug the lua code (I use decoda for this) but the LuaLanguage project itself while it is running in Visual Studio

Hello,

Since I started to use VSLua, I decided to give a look at the source to see what I can do to improve it. In particular, I'd like to see some intellisense features working.

I'm new to Irony but I think I could so something for Intellisense. Looking all the function xxxx() shouldn't be _that_ hard, I guess ;-)

My main problem now is the workflow to build, start and debug the application. The only process I found till now is :

- Build the app

- Launch the "%VSSDK90Install%\VisualStudioIntegration\Tools\Bin\regpkg.exe" manually, since it fails to find the binary in visual for a reason I ignore

- Close visual studio, so the LuaLanguage.dll is freed

- Copy the bin/Debug/LuaLanguage.dll to overwrite C:\Program Files\Salec.net\Lua Language Service (VS 2008)\LuaLanguage.dll

- Start my lua project, test the newly compiled VSLua

- Close the lua project, and open the LuaLanguage solution

- Goto 1

 

What I didn't try, for now, is to attach the devenv.exe running the lua project (hence, the lualanguage.dll) to the lualanguage project. Maybe is it possible to break in the C# project.

Did you find a more handy way to work ?

Anyway, thanks for your work !

Regards,

Tom

Coordinator
Feb 1, 2010 at 11:47 PM

Hey Tom,

   I'm glad you want to contribute to the project :)  Here are the steps I use to debug the package on my local machine:

  1. Uninstall VS Lua from your system.  If you don't do this, you'll have the installed version and working version fighting with each other.
  2. Open the solution and make sure the LuaLanguage project is selected as the Startup Project (right click and select "Set As Startup Project" if it's not)
  3. Make sure you are building Debug and not Release
  4. Right click LuaLanguage and Select Properties, then to to the Debug section.
  5. Select "Start External Program" and browse to VS 2008 (C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe was my path)
  6. Under Command Line Aguments, add "/RANU /RootSuffix Exp" without the quotes to the edit box. 

You should then be able to run the project and have the experimental VS 2008 hive open.  Once the shell is up and running, just open a .lua script and the package should initialize.

Intellisense is a tricky beast and I welcome any help you have to offer :)  I'd really like to clean up the Lua Grammar as a cleaner syntax tree will make any intellisense operations far easier to implement.  I'm presently migrating the project to better support VS 2010 as it recently became a higher priority but will hit the grammar once I've got more time.

-Shaun

Feb 2, 2010 at 9:37 AM
Hi Shaun,
Thanks for the fast reply !
Well, starting devenv in debug is a very good idea. Does it load, and use the LuaLanguage.dll automatically ? I didn't understand where to tell visual to load and use VS lua, but maybe the existence of the dll makes it automatically.
I don't know what is your opinion, but I would personally prefer too much suggestions (for example, suggestions that are out of the current scope) than too few. Regarding the dynamic aspect of Lua, I don't think it is possible to make very accurate suggestions based on the current scope (without executing the code itself I mean).
What I think is possible, at least, to extract is :

globalvar = ...
function globalfunction()...
function globaltable.somefunction() ...

And maybe things like :

table = {
    subtable = {
       subsubtable = {...}
    }
}

And it is possible to keep a simple and flat hashmap (a C# Dictionary<string, string>)  to keep all the symbols found, only to make the typing of already existing variables easier, even if we don't know the scope. For example, if I have already used a table.bullets_number somewhere, and I am currently typing "bullets_n...", chances are that I'm trying to type bullets_number as well. Even if it's not 100% sure, suggesting it would not harm.
These hypothetical suggestions could be displayed after the more accurate ones in the suggestions list.

What is still not clear to me is when do you parse the file or the current line to extract all this.
What do you think ?




-------- Message original --------
Sujet : Re: Any way to debug easily ? [vslua:82789]
De : salec <notifications@codeplex.com>
Pour : tom.rethaller@free.fr
Date : 02/02/2010 00:47

From: salec

Hey Tom,

   I'm glad you want to contribute to the project :)  Here are the steps I use to debug the package on my local machine:

  1. Uninstall VS Lua from your system.  If you don't do this, you'll have the installed version and working version fighting with each other.
  2. Open the solution and make sure the LuaLanguage project is selected as the Startup Project (right click and select "Set As Startup Project" if it's not)
  3. Make sure you are building Debug and not Release
  4. Right click LuaLanguage and Select Properties, then to to the Debug section.
  5. Select "Start External Program" and browse to VS 2008 (C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe was my path)
  6. Under Command Line Aguments, add "/RANU /RootSuffix Exp" without the quotes to the edit box. 

You should then be able to run the project and have the experimental VS 2008 hive open.  Once the shell is up and running, just open a .lua script and the package should initialize.

Intellisense is a tricky beast and I welcome any help you have to offer :)  I'd really like to clean up the Lua Grammar as a cleaner syntax tree will make any intellisense operations far easier to implement.  I'm presently migrating the project to better support VS 2010 as it recently became a higher priority but will hit the grammar once I've got more time.

-Shaun


Coordinator
Feb 2, 2010 at 6:23 PM

In Debug builds, the LuaLanguage project is set to register the output w/ Visual Studio automatically.  This is why you don't have to worry about copying the DLL and what not.  When you specified "/RootSuffix Exp" you were just telling Visual Studio to use the experimental hive which is kinda like a separate installation of visual studio (it's not technically, but it appears that way).

I agree that more suggestions is better than fewer :)  It's both a blessing and a curse that Lua is so flexible in how methods are accessed.  On top of scope, the current environment table being used will play a strong role in figuring out which functions are available.  This gets really rough..  Enumerating every function created in the script is a healthy start though.

The script is parsed in two methods.  The first method parses the entire script.  This method is rarely called though.  The most common method and the one that will give you the quickest feedback is the linescanner.  This parser is very tricky!  It will give you a single line and an integer reference to control state.  Each time a line of script is modified, the line parser is executed and if the state changes, the following lines are changed after.  In my opinion this is a poor way of parsing as it's impossible to colorize other areas of the document based on scope or context changes further up.  The line scanner is run on a separate thread and you do not have access to the entire script when this is running.

I plan on removing the line scanner all together and instead create a custom implementation of Colorizer that will grant access to the entire script if necessary :)

Feb 3, 2010 at 10:46 AM
Thanks, it works perfectly.
I managed to add a very primitive member suggestions, which is triggered when you type mytable, then "." or ":". I did it very dirty without fully using the parsetree (for example, the only way I found to extract the "mytable" before the dot is to parse the right line with a regex ^^) but it was  only a quick test.
I am going to tests some stuffs by my own, and see how it feels while working on my Lua project. I'll keep you informed if I come out with interesting stuffs.
Being able to share symbols between several files would be great, I'll take a look at this.

I hope you'll keep on working on this project :-), because being able to work with C++ and Lua in the same IDE is really great, especially with the help of Visual Assist.
Regards,
Tom


-------- Message original --------
Sujet : Re: Any way to debug easily ? [vslua:82789]
De : salec <notifications@codeplex.com>
Pour : tom.rethaller@free.fr
Date : 02/02/2010 19:24

From: salec

In Debug builds, the LuaLanguage project is set to register the output w/ Visual Studio automatically.  This is why you don't have to worry about copying the DLL and what not.  When you specified "/RootSuffix Exp" you were just telling Visual Studio to use the experimental hive which is kinda like a separate installation of visual studio (it's not technically, but it appears that way).

I agree that more suggestions is better than fewer :)  It's both a blessing and a curse that Lua is so flexible in how methods are accessed.  On top of scope, the current environment table being used will play a strong role in figuring out which functions are available.  This gets really rough..  Enumerating every function created in the script is a healthy start though.

The script is parsed in two methods.  The first method parses the entire script.  This method is rarely called though.  The most common method and the one that will give you the quickest feedback is the linescanner.  This parser is very tricky!  It will give you a single line and an integer reference to control state.  Each time a line of script is modified, the line parser is executed and if the state changes, the following lines are changed after.  In my opinion this is a poor way of parsing as it's impossible to colorize other areas of the document based on scope or context changes further up.  The line scanner is run on a separate thread and you do not have access to the entire script when this is running.

I plan on removing the line scanner all together and instead create a custom implementation of Colorizer that will grant access to the entire script if necessary :)


Coordinator
Feb 3, 2010 at 7:26 PM

Excellent :)  as always if you have any changes you'd like to see in, just send me a patch and I'll apply it to the code :)

I will be working on this for a while :)  My goal is for this project to be the goto project for adding Lua support to Visual Studio :)  Alas, time constraints prevent me from getting much in as fast as I'd like, but with help like yours and others we can get this project working really well :)

As a side project, I also have a custom debug engine for Visual Studio to debug and break at Lua break points :)   It's not open source yet but I am hoping to make some announcements about it in the next few months :)