When lua_load parses a binary chunk, it ignores the chunkname in the argument 
and uses the chunkname in the binary chunk. E.g

> load(string.dump(loadfile 'button.lua'), '=button.lua')

Its chunkname is `@button.lua` instead of `=button.lua`.

So bin2c.lua needs to change `loadfile(filename)` to 
`load(io.open(filename,'rb'):read 'a', '='..filename)`.

--actboy168

发件人: Antonio Scuri
发送时间: 2018年8月21日 4:57
收件人: IUP discussion list.
主题: Re: [Iup-users] 答复: 答复: Debugger couldn't locate the lua source code for 
iup.

  Just committed to the SVN:
• Changed: added "=" prefix to chunk name in iuplua_dobuffer and 
iuplua_dostring calls to improve debugging of IupLua strings.
Best,
Scuri

Em sáb, 21 de jul de 2018 às 02:24, actboy168 <actboy...@gmail.com> escreveu:
I make a patch in attachment.
 
I added '=' before the chunkname of the lua code built into iup. The debugger 
can ignore this code correctly. 
 
-- actboy168
 
发件人: Antonio Scuri
发送时间: 2018年7月21日 0:12
收件人: IUP discussion list.
主题: Re: [Iup-users] 答复: Debugger couldn't locate the lua source code for iup.
 
  Sorry I don't get where you are trying to get.  
 
  Now do you think I should change the IUP code to improve it? Where/how 
exactly?
 
Best,
Scuri
 
 
Em sex, 20 de jul de 2018 às 11:51, actboy168 <actboy...@gmail.com> escreveu:
The chunkname only affects the debug api and traceback. Lua does not force 
users to follow this rule, but the debugger needs to use this rule to locate 
the source code. In fact, debug.traceback and error messages also take 
advantage of this rule. If you call debug.traceback in the lua code inside iup, 
you will see the location is `[string "iup/xxx.lua"]:1`, because lua thinks it 
is a string of source code.
 
For the lua documentation, it provides a rule, and Lua's internal 
implementation also follows this rule. But lua does not force others to follow 
this rule, which may be a problem.
 
For the debugger, it is very much needed for this rule. Lua does not provide 
other ways to get source code information, which is the only clue that can be 
traced back to the source code.
 
-- actboy168
 

发件人: Antonio Scuri <antonio.sc...@gmail.com>
发送时间: Friday, July 20, 2018 9:23:00 PM
收件人: IUP discussion list.
主题: Re: [Iup-users] Debugger couldn't locate the lua source code for iup. 
 
  Hi, 
 
  Those prefix are added internally by the Lua interpreter. 
iuplua_dostring/iuplua_dobuffer simply call luaL_loadbuffer. If I add that 
prefix it will not find the file or incorrectly interpret the string.
 
  The problem in debugger I already reported to the Lua team (in the Lua list), 
but I got no result. 
 
============================================================
 
  In lua_Debug documentation, "source" description states that if the function 
was defined in a string then "source" is that string.
 
  I may misunderstood it but it seems that in this case source is the 
chunkname, not the string. If chunkname is not used in load, then chunkname is 
the string, which results in what is described. But if chunkname is used then 
"source" is not the string where the function was defined.
 
  I tested in Lua 5.1, 5.2 and 5.3 and they all behave the same.
 
  So, is there a problem in the documentation or in the debugger?
 
  Assuming it is just a problem in the documentation, during debug how can we 
retrieve the original string given the chunkname?
 
============================================================
 
  If anyone has a light on this please let me know.
 
Best,
Scuri
 
 
Em sex, 20 de jul de 2018 às 03:54, actboy168 <actboy...@gmail.com> escreveu:
The debugger uses debug.info(1, 'S').source to determine the mapping between 
function and source code.Please see lua's docs
 
https://www.lua.org/manual/5.3/manual.html#lua_Debug
 
> source: the name of the chunk that created the function. If source starts 
> with a '@', it means that the function was defined in a file where the file 
> name follows the '@'. If source starts with a '=', the remainder of its 
> contents describe the source in a user-dependent manner. Otherwise, the 
> function was defined in a string where source is that string.
 
When the `source` starts with neither '@' nor '=', the content in the `source` 
is the source code. And the fourth parameter of luaL_loadbuffer determines the 
`source` of the loaded function.
 
But now iuplua_dostring/iuplua_dobuffer does not comply with this rule. The 
function loaded by iuplua_dostring, the `source` starts with neither '@' nor 
'=', so the debugger thinks it is the source code itself, but this is wrong.
 
Can iup make iuplua_dostring use the correct `source`? Add '=' before name or 
use 's' instead of 'name'.
 
-- actboy168
 
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
 
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users

Reply via email to