Hash as a table key in release builds

Questions
1

I read in many topics what we can’t use hashes as a table keys in release builds.
If Project->Bundle->iOS Application… (set Release Mode checkbox) is the way to make a release build, then code below works in this build.

function init(self)
    local h = hash("key")
    print(h, type(h))

    self.t = {}
    self.t[h] = "value"
    pprint(self.t)
end

function update(self, dt)
    post("@render:", "draw_text", { text = self.t[hash("key")], position = vector3(100, 100, 0) } )
end

Where hashes as table keys NOT working?

2

This will not work in any build (release or dev)

 local tbl = {}
    tbl[hash("hi")] = "mee"
    
    msg.post(".", "test", tbl)

Another thing to remember is that there is no string representation of an hash in release. So don’t use tostring(some_hash) as it will differ from dev/release versions.

2 Likes
3

Is there any way to disable to_string in testing builds? I imagine it’s disabled in release due to performance problems - it might be useful to some people to leave out the lookup system for debug builds of intensive projects.

4

I think it’s possible to overwrite functions, but haven’t tested it myself yet (link)

5

Ok, thanks. I think error description explains it even best:
ERROR:SCRIPT: keys in table must be of type number or string

1 Like
6

You can modify anything in Lua. So you don’t like randomness? Try:

 math.random = function(m, n) return 12345 end

To few cats?

local _oldprint = print
print = function(...) _oldprint("Meow", ....) end

Anything goes…

It’s usually referred to as monkey patching. But remember, with great power comes great responsibility. If you’re writing code that you intend to share with others then it’s really bad if your code introduces side effects. And what if you expect a function to work in a certain way, and both you and some other library would try to modify the same function? On the other hand, it is super useful when writing unit tests and you wish to mock some behaviour, for instance replacing http.request with a static response or something like that.

1 Like
7

http://lua-users.org/wiki/OverloadedFunctions

This is a safer method for this kind of thing.

8

Sorry to necro an old thread, but i’d just like to clarify:

[quote=“Andreas_Jirenius, post:2, topic:2344”]```lua
local tbl = {}
tbl[hash(“hi”)] = “mee"
msg.post(”.", “test”, tbl)



In your example, is the only issue the `msg.post`? as in, the messaging process performs dark magic which breaks hash keys?

or

Is the usage of hashes as table keys in general a no no and there are other cases where it will explode?
2 Likes
9

Yes, it’s a limitation in the serialisation of the message data caused by how lua deal with table keys. They can be stored as values though. We should fix this at some point.

2 Likes
10

I could clean up some of my logic in Pie Squares if this got fixed so I am really interested in this happening.

1 Like