a weird bug with pack & unpack

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

a weird bug with pack & unpack

spir ☣

Hello,

Sorry to bother you with such an unimportant issue, but it drives me crazy:

I have a set of everyday tools, mainly tiny funcs one of which uses table pack &
unpack. This func works very fine, it is exhaustively tested --locally. When I
use it from other program files, I often get an error telling that Lua does not
find the field (or global) 'pack' --
_sometimes_; and all works fine, _sometimes_. If I replace pack with a
workaround, then I get the same issue about unpack. I cannot find any logic.

The same happens (works or not) whether pack & unpack are denoted on the table
'table' or under aliases (just the 'table.' prefix removed). I have checked
several times that nothing in my present project files uses such names, or
modifies table, except for adding a few 'methods' like table copy. Dunno. I'm
highly frustrated of not getting the logic and annoyed because the func in
question is a very practicle debugging tool I constantly use.

Lua 5.2.1 on linux (lubuntu)

Thank you,
Denis

Reply | Threaded
Open this post in threaded view
|

Re: a weird bug with pack & unpack

Matthew Wild
On 12 November 2012 16:41, spir <[hidden email]> wrote:

> I have a set of everyday tools, mainly tiny funcs one of which uses table
> pack & unpack. This func works very fine, it is exhaustively tested
> --locally. When I use it from other program files, I often get an error
> telling that Lua does not find the field (or global) 'pack' --
> _sometimes_; and all works fine, _sometimes_. If I replace pack with a
> workaround, then I get the same issue about unpack. I cannot find any logic.
>
> The same happens (works or not) whether pack & unpack are denoted on the
> table 'table' or under aliases (just the 'table.' prefix removed). I have
> checked several times that nothing in my present project files uses such
> names, or modifies table, except for adding a few 'methods' like table copy.
> Dunno. I'm highly frustrated of not getting the logic and annoyed because
> the func in question is a very practicle debugging tool I constantly use.
>
> Lua 5.2.1 on linux (lubuntu)

Any chance it's a case of accidentally using Lua 5.1 or LuaJIT in the
cases where it doesn't exist? I doubt the existence of a bug in Lua
itself where functions can go missing from tables :)

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: a weird bug with pack & unpack

spir ☣
On 12/11/2012 18:15, Matthew Wild wrote:

> On 12 November 2012 16:41, spir <[hidden email]> wrote:
>> I have a set of everyday tools, mainly tiny funcs one of which uses table
>> pack & unpack. This func works very fine, it is exhaustively tested
>> --locally. When I use it from other program files, I often get an error
>> telling that Lua does not find the field (or global) 'pack' --
>> _sometimes_; and all works fine, _sometimes_. If I replace pack with a
>> workaround, then I get the same issue about unpack. I cannot find any logic.
>>
>> The same happens (works or not) whether pack & unpack are denoted on the
>> table 'table' or under aliases (just the 'table.' prefix removed). I have
>> checked several times that nothing in my present project files uses such
>> names, or modifies table, except for adding a few 'methods' like table copy.
>> Dunno. I'm highly frustrated of not getting the logic and annoyed because
>> the func in question is a very practicle debugging tool I constantly use.
>>
>> Lua 5.2.1 on linux (lubuntu)
>
> Any chance it's a case of accidentally using Lua 5.1 or LuaJIT in the
> cases where it doesn't exist? I doubt the existence of a bug in Lua
> itself where functions can go missing from tables :)
>
> Regards,
> Matthew

I doubt as well! I would not even suggest it, if only by experience (the
benefits of age, you know).
I have no luajit and only one lua, no 5.1 afaik. My exec command for lua code is
just lua "%f". /usr/bin/lua is well a symlink (to another symlink, I guess, in
etc/alternatives/, don't know more).

spir@ospir:~$ which lua
/usr/bin/lua
spir@ospir:~$ lua -v
Lua 5.2.0  Copyright (C) 1994-2011 Lua.org, PUC-Rio

Anyway:

spir@ospir:~$ which lua5.2
/usr/bin/lua5.2
spir@ospir:~$ which lua5.1
spir@ospir:~$

So, I guess it's safe to say we're talking about 5.2.
Also (which also shows it's well 5.2), when just creating a test file and typing
the above, all works fine. It's only in given circumstances I find myself unable
to diagnose and distinguish (reason for my post for help) that the bug happens.
There is certainly, thus, something on my side, in my code.

Denis

Reply | Threaded
Open this post in threaded view
|

Re: a weird bug with pack & unpack

Dirk Laurie-2
2012/11/12 spir <[hidden email]>:

> I have no luajit and only one lua, no 5.1 afaik. My exec command for lua
> code is just lua "%f". /usr/bin/lua is well a symlink (to another symlink, I
> guess, in etc/alternatives/, don't know more).
>
> spir@ospir:~$ which lua
> /usr/bin/lua
> spir@ospir:~$ lua -v
> Lua 5.2.0  Copyright (C) 1994-2011 Lua.org, PUC-Rio

Lua 5.2 has only table.pack and table.unpack.

Lua 5.1 has only unpack.  Instead of table.pack(...)
5.1 prgrams use {...}.  Only difference is that table.pack
sets a field `n` telling how many things (including nils)
were packed.  You can't get that info from {...}.  However,
programs written for 5.1 do not rely on this feature.

I usually put

   unpack = unpack or table.unpack

when I am about to run old code under 5.2.
It may work, or it may stutter at a different incompatibility.

Reply | Threaded
Open this post in threaded view
|

Re: a weird bug with pack & unpack

Rena

On 2012-11-12 2:38 PM, "Dirk Laurie" <[hidden email]> wrote:
>
> 2012/11/12 spir <[hidden email]>:
>
> > I have no luajit and only one lua, no 5.1 afaik. My exec command for lua
> > code is just lua "%f". /usr/bin/lua is well a symlink (to another symlink, I
> > guess, in etc/alternatives/, don't know more).
> >
> > spir@ospir:~$ which lua
> > /usr/bin/lua
> > spir@ospir:~$ lua -v
> > Lua 5.2.0  Copyright (C) 1994-2011 Lua.org, PUC-Rio
>
> Lua 5.2 has only table.pack and table.unpack.
>
> Lua 5.1 has only unpack.  Instead of table.pack(...)
> 5.1 prgrams use {...}.  Only difference is that table.pack
> sets a field `n` telling how many things (including nils)
> were packed.  You can't get that info from {...}.  However,
> programs written for 5.1 do not rely on this feature.

A common idiom is t = {n=select('#', ...), ...}
Though I suspect if you're doing this in a speed-critical section, a dedicated function may be faster, since it only need evaluate ... once (at least a C function could do n = lua_gettop() instead of any counting). But you should probably avoid doing this in a speed-critical section anyway...

Reply | Threaded
Open this post in threaded view
|

Re: a weird bug with pack & unpack

spir ☣
In reply to this post by Dirk Laurie-2
On 12/11/2012 20:38, Dirk Laurie wrote:

> 2012/11/12 spir <[hidden email]>:
>
>> I have no luajit and only one lua, no 5.1 afaik. My exec command for lua
>> code is just lua "%f". /usr/bin/lua is well a symlink (to another symlink, I
>> guess, in etc/alternatives/, don't know more).
>>
>> spir@ospir:~$ which lua
>> /usr/bin/lua
>> spir@ospir:~$ lua -v
>> Lua 5.2.0  Copyright (C) 1994-2011 Lua.org, PUC-Rio
>
> Lua 5.2 has only table.pack and table.unpack.
>
> Lua 5.1 has only unpack.  Instead of table.pack(...)
> 5.1 prgrams use {...}.  Only difference is that table.pack
> sets a field `n` telling how many things (including nils)
> were packed.  You can't get that info from {...}.  However,
> programs written for 5.1 do not rely on this feature.
>
> I usually put
>
>     unpack = unpack or table.unpack
>
> when I am about to run old code under 5.2.
> It may work, or it may stutter at a different incompatibility.

Thank you for the trick about unpack! Anyway, it does not solve my present issue
because, when lua does not find pack, and I try using {...} as a workaround, it
also does not find unpack (under either name). If it finds pack, it finds both
(again, under either name)...
I'm blocked on the issue. In the meantime, I removed a pair of tricks I did to
"modularise" and "environ" my code files, in case it would help (but then, why?)
but it did not help at all.
Hum, I'm just thinking both projects presently working at use Löve. Maybe its
libs play some tricks with
Lua builtins which would cause the errors I observe; probably not in purpose,
since we have full use of standard lua even on points (like filesystem) where it
recommanded to use Löve modules, but possibly if ever it is not completely
lua5.2-aware. Let us sees, I will ask on the forum (there are very competent lua
programmers there).

Denis