RE: little LfW debugger and lanes module incompatibility

[Benoit Germain <bgermain@...>]

Yes, but the behaviour I observe is situated in the main thread. At no point am I trying to debug/break into the created thread (and it wont work anyway since SciTE doesn't know about the other threads I created with the lane). From the main thread point of view, this lane is just some userdata it attempts to display. I can step the debugger until after the creation of the lane and leave it there as long as I want, it won't abort until I attempt to display the contents of the lane variable. So I guess what I have to do now is debug the debugger while being used to debug that code snippet. How can I do this?


-----Message d'origine-----
De : lua-bounces@bazar2.conectiva.com.br [mailto:lua-bounces@bazar2.conectiva.com.br] De la part de Linker
Envoyé : jeudi 10 décembre 2009 12:56
À : Lua list
Objet : Re: little LfW debugger and lanes module incompatibility

Lanes is a multi-threads module. Normal lua debuger cannot debug
multi-thread program.

On 12/10/09, Benoit Germain <bgermain@ubisoft.fr> wrote:
> Oh, I forgot : I've tried adding this
>
>                 __tostring = function( me)
>                                return "I'm a lane"
>                 end
>
> to the lane_mt metatable, but to no avail. It gets called when calling print
> on the lane, but the debugger still breaks.
>
> De : lua-bounces@bazar2.conectiva.com.br
> [mailto:lua-bounces@bazar2.conectiva.com.br] De la part de Benoit Germain
> Envoyé : jeudi 10 décembre 2009 11:48
> À : Lua list
> Objet : little LfW debugger and lanes module incompatibility
>
> Hello,
>
> Open the editor, and copy the attached code snippet :
>
> local laneFunc = function()
> ...
> end
>
> require "lanes"
> local lane_gen = lanes.gen(laneFunc)
> local lane_h = lane_gen()
> return true
>
> Then start the debugger, step until after the lane_h variable is assigned,
> and hover the mouse cursor over the lane_h variable, and the debugger will
> terminate itself with «quitting debugger » in the log. It would seem that
> this happens because the userdata contained in lane_h doesn't have a
> __tostring() metamethod. At least when considering this trace from a more
> complex app :
>
> ...a\5.1\SciTE\scite-debug\lua_clidebugger\debugger.lua:776: C:\Program
> Files\Lua\5.1\lua\lanes.lua:189: Unknown key: __tostring
> stack traceback:
>
> ...a\5.1\SciTE\scite-debug\lua_clidebugger\debugger.lua:1485: in function
> <...a\5.1\SciTE\scite-debug\lua_clidebugger\debugger.lua:1484>
>                 [C]: ?
>                 [C]: in function 'assert'
>                 ...a\5.1\SciTE\scite-debug\lua_clidebugger\debugger.lua:776:
> in function <...a\5.1\SciTE\scite-debug\lua_clidebugger\debugger.lua:701>
>                 Launcher_ConsolesPanel.wlua:84: in function
> 'refreshFromNeighborhood'
>                 Launcher_ConsolesPanel.wlua:648: in function
> <Launcher_ConsolesPanel.wlua:646>
>                 (tail call): ?
>                 [C]: in function 'MainLoop'
>                 Launcher.wlua:87: in main chunk
>                 [C]: ?
>
>                 local lane_h_MT= getmetatable( lane_h)
>                 lane_h_MT.__tostring = function() return "hello" end
>
> before inspecting the variable doesn't solve the problem. What can I do to
> fix this ?
>
>
> Thanks,
>
> B. Germain
>
>

-- 
Sent from my mobile device

Regards,
Linker Lin
linker.m.lin@gmail.com