Lua language

juhbuba · 2022-03-15T20:03:49.777Z

toneburst:

I’d have expected both instances to end up with the same values for ‘reset’, in this case, but that doesn’t seem to be the case.

Unless I’m missing something, I don’t see a line where ‘setReset’ is called for Obj2.

Because Obj1 and Obj2 reference different data, Obj2 retains the values assigned when it’s instantiated (self.reset = false), consistent with your output.

toneburst · 2022-03-15T20:37:22.765Z

That’s the thing; I declared ‘reset’ on the class, not the instance table (as I did in my original code copied from the incorrect Tutorialpoint example).

When I did this before, changing the value of a property on one instance also changed it on the other. Not so, in this case, for some reason…

Anyway, my project is working fine now, so I’ll stick with the method I have

Thanks again.

ngwese · 2022-03-16T00:38:33.247Z

toneburst:

Obj1 = Class:new(nil, 10)
-- versus
Obj1:setReset()

The key to this mystry is paying close attention to what self is getting set to in each of these function invocations. Both Class:new and Class:setReset contain self.reset = ....

With Class:new(nil, 10) what is really happening is Class.new(Class, nil, 10), in other words self is pointing at the Class table so the reset value is being assigned in that table.

With Obj1:setReset() what is really happing is Obj1.setReset(Obj1) so in this case self is pointing at the Obj1 table. Lua doesn’t have any notion of a class variable vs instance variable. If the desire was to have reset act like a class variable then it has to be explicitly implemented as such:

function Class:setReset()
  Class.reset = true
end

In Lua setting values in tables is not influenced by the existence of __index. The table chaining behavior provided by __index only applies to getting values out of a table.

toneburst:

That’s the thing; I declared ‘reset’ on the class, not the instance table (as I did in my original code copied from the incorrect Tutorialpoint example).

Just to emphasize the above - Lua has no notion of instances and classes. As far as the Lua runtime is concerned the Class table no different from any other table. We are treating the Class table as a “prototype” for new instances (also tables) by defining values and functions in the Class table which we’d like to avoid having to redefine in each instance tables. The way we get Lua to find those shared values is by establishing a relationship between the instance table and the “class” table using __index.

toneburst · 2022-03-16T11:07:49.381Z

ngwese:

We are treating the Class table as a “prototype” for new instances

I’m vaguely familiar with the concept of “prototypes” from JavaScript.

Do you have an idea for a better name for Lua “pseudo-classes” and “objects”?

awwaiid · 2022-04-03T13:14:03.286Z

The two positions I rotate between is thinking of them as classes/objects (bags of state and methods that operate on that state, which mostly works fine if you squint) and thinking of them as tables.

The idea with embracing “tables” is that I say ok - this is a table with a bunch of key/values. Some are values, some are functions. The method “:” syntax is nice sugar to hand functions their current table. If an entry is missing it runs the stuff in metatable. Or in other words, I try to stop myself from making analogies and instead embrace the language as-is. YMMV

toneburst · 2022-04-03T14:07:04.577Z

I think “tables” is a bit too non-specific, though, given that tables are used for so many different things in Lua.

There has to be some name for the kind of table use that allows something very like classes and instantiation of objects with their own independent properties and methods.

I do tend to get hung up on these kind of terminology issues though. It’s a prevarication thing, I think

Incidentally, does anyone have any thoughts for or against using anonymous functions as clock callbacks, rather than calling a named function as in the docs?

==========================

Here’s another one: when writing modules, what are the relative benefits and drawbacks of using local variables declared at the top of the module file, over vars rolled into the module table?

local may_var = true

local Module = {}

-- Module functions etc.

return Module

vs.

local Module = {}

Module.myVar = true

-- Module functions etc.

return Module

I’ve been using a mixture of the two, but without any particular logic to my choice of one or the other, in any given case.

sixolet · 2023-01-13T17:42:40.748Z

I’m gonna necro this thread for something I’ve discovered to be quite useful in lua scripting that I want to share:

EDIT: I was wrong, as Trent pointed out below!

Here’s a stack overflow answer explaining:

stackoverflow.com

What are the correct semantics of a closure over a loop variable?

c#, javascript, lua, closures

asked by Panda Pajama on 04:02AM - 15 Jan 13 UTC

Original post

When you’re writing a loop in which you set a callback, like so:

for i=1,16 do
  things[i].action = function()
     do_things_with(i)
  end
end

It’s very tempting to do what I did above and reference the loop index in the callback, and hope that the callback “closes over” its value so that each thing’s callback has a different index it works upon. It does not work that way. The reason is that there is one single loop variable, and its value changes with every iteration of the loop.

Instead, do this:

for i=1,16 do
  (function(i)
    things[i].action = function()
      do_things_with(i)
    end
  end)(i)
end

The extra layer of function which you call immediately below with the loop index traps the loop index and lets the inner callback “close over” it, preserving the value within the callback.

Galapagoose · 2023-01-13T18:09:18.879Z

i’ve absolutely seen things like this in the past, but i just tested a simple example (lua 5.3.4) and it worked fine? perhaps there’s some finer point that makes it not work? the reason i was even testing was to suggest an alternative fix – you can just copy i into a local variable inside the for loop to allow closing over it.

anyway, my test case that seems to work fine:

t={ {}, {} }
for i=1,2 do
  t[i].action = function() print(i) end
end
t[1].action() --> 1
t[1].action() --> 1
t[2].action() --> 2

what i was going to suggest for your example is:

for i=1,16 do
  local i = i -- makes a copy of the loop variable which can be closed over
  things[i].action = function()
     do_things_with(i) -- uses the local copy of i
  end
end

but it seems in this simple example it actually isn’t necessary. i guess i’m writing to see if we can figure out the precise situation where this happens (because it absolutely does… sometimes).

sixolet · 2023-01-13T18:16:01.663Z

Wow you are right. I know I have been doing this for months because I had a hard-to-find bug in closing over loop indexes in norns param callbacks. I really do wonder where it comes up!

ampism · 2023-10-11T09:00:40.177Z

I have only ever added a script to my shield via maiden.
I now have a lua file that I want to put on there but don’t know how.
Could some kind soul please explain?

Update: sorted this now - thanks

xmacex · 2023-10-11T15:18:46.064Z

Create new file and copy+paste content is one way which isn’t away from Maiden, and there are a number of ways to connect to norns over SMB and SSH (scp) which work great. See the docs section transfer under WiFi / update / files.

ampism · 2023-10-11T15:21:53.820Z

Thanks- have sorted it now

XHG · 2024-02-26T06:26:25.817Z

I don’t know if this fits here but someone created a 542 byte Tetris in Lua, which I find pretty impressive.

The code is explained here:
https://www.gamelab.ch/?p=9218

andrew · 2024-09-06T22:53:05.834Z

lua is a perfect language with 0 flaws

local message = 'hello world',

print('my message:', message)
-- > my message: nil

robbie · 2024-09-07T09:22:20.167Z

andrew:

local message = 'hello world',

Ooof. That’s a frustrating one.

alanza · 2024-09-07T10:34:47.360Z

interesting that that’s the effect of the comma there

xmacex · 2024-09-07T10:44:59.856Z

That’s what I figured too, but trying it without the comma

Lua 5.3.6  Copyright (C) 1994-2020 Lua.org, PUC-Rio
> local message = 'hello world'
> print('my message:', message)
my message:     nil

alanza · 2024-09-07T11:04:32.166Z

oh, i see.

just never use local in the REPL… bc how is the REPL supposed to preserve scope, right? local to what?

awwaiid · 2024-09-07T14:04:32.172Z

Well it could pretend that all of the REPL commands are in one file scope.

There are alternative REPLS and hacks and things. Here is a hack that lifts locals to globals, though it looks specific to trepl. I see some alternate REPLs with a variety of capabilities. Croissant looks pretty interesting, though I failed to get it to install on the first try just now.

robbie · 2024-09-07T14:14:15.121Z

alanza:

interesting that that’s the effect of the comma

I suspect that interpreter reads that code as:

local message = 'hello world',print('my message:', message)

Which means message isn’t actually assigned until after the print. (The print is evaluated before the assignment – otherwise how could you grab the result of a function?)

local message = 'hello world',print('my message:', message)
print('my real message:', message)
my message:	nil
my real message:	hello world

But, yeah, also right that it’ll fail anyway in a REPL.

More

In the REPL I believe each line is executed a separate chunk, so the local scope only lasts until the end of the line (or multiline).

So this would work:

Lua 5.4.7  Copyright (C) 1994-2024 Lua.org, PUC-Rio
> local message = 'hello world'; print('my message:', message)
my message:	hello world

And also this:

Lua 5.4.7  Copyright (C) 1994-2024 Lua.org, PUC-Rio
> do
>> local message = 'hello world'
>> print('my message:', message)
>> end
my message:	hello world

etc.