Lua language

Galapagoose · 2021-12-01T20:44:08.801Z

in short no, and without some substantial redesign of the libraries i think it’d actually be very frustrating. primary reason is we’d need to run the fennel compiler on crow (on top of the lua VM) but the system is already pushed near it’s processing & memory limits.

but moreso, the aforementioned issue of crow & norns libraries being awkward when directly used in the lisp syntax would require a lot of rework. we use a lot of method-chain syntax which feels great in lua, but gets ugly in fennel, where it would be far more natural to use k-v tables etc. you can approximate a lot of this with threading macros but it’s still not as fluid as if the libs were written for fennel up front.

sixolet · 2021-12-27T23:34:48.290Z

Some helper functions that are all over a WIP script:

function mod_but_oneindex(x, m)
  local ret = x % m
  if ret == 0 then
    ret = m
  end
  return ret
end

function div_but_oneindex(x, d)
  return math.floor((x-1)/d) + 1
end

function mul_but_oneindex(x, m)
  return (x-1)*m + 1
end

I’m finding these to immensely soothe my brain when I am trying to do grid math. For example, in my wip I have 64 steps broken into 16-step sections, and the 16-step sections are broken into 8-step rows on the grid. For example: given the step among the 64, I can get the section it’s in using div_but_oneindex(step, 16). I can get the x-axis position in its row using mod_but_oneindex(step, 8).

toneburst · 2022-03-15T13:52:37.172Z

Hi All,

I’m trying to follow the Lua OOP docs here:

tutorialspoint.com

Lua - Object Oriented

Lua - Object Oriented, Object Oriented Programming (OOP), is one the most used programming technique that is used in the modern era of programming. There are a number of programming l

…and I’m confused. I have this ultra-simple code

Class = {
  val = 0
}

function Class:new(o, val)
  o = o or {}
  setmetatable(o, self)
  self.__index = self
  self.val = val
  return o
end

print("Create 'Obj1' instance with value of 10")
Obj1 = Class:new(nil, 10)

print("Create 'Obj2' instance with value of 12")
Obj2 = Class:new(nil, 12)

print("Obj1.val = " .. Obj1.val)
print("Obj2.val = " .. Obj2.val)

When I run it (in macOS Terminal), I get the following output:

Create 'Obj1' instance with value of 10
Create 'Obj2' instance with value of 12
Obj1.val = 12
Obj2.val = 12

… which confuses the hell out of me!

I’d assumed that when I created ‘Obj1’ and ‘Obj2’ and their ‘val’ property was set it would be maintained by the instance (ie Obj1 and Obj2 would have their own unique values for their ‘val’ property).

However it seems this is NOT the case. When the 2nd instance of “Class” is created, it changes the value of ‘val’ in both!

Am I just misunderstanding what OOP means? Or is there a bug in the code? What’s going on?

Sorry for the super-basic (probably stupid) question…

toneburst · 2022-03-15T14:14:15.858Z

This seems to work as I envisaged, but I’m unsure of the difference between the two approaches:

-- Different OOP approach:
-- https://stigmax.gitbook.io/lua-guide/concepts/object-oriented-programming

Class = {}

setmetatable(Class, {
	__call = function(self, val)
		local classData = {
			val = val
		}
		return setmetatable(classData, {__index = Class})
	end
})

function Class.getVal(self)
	return self.val
end

function Class.print(self, val)
	print("val = " .. self:getVal())
end

local Obj1 = Class(10)
local Obj2 = Class(12)

print("Obj1.val = " .. Obj1.val)
print("Obj2.val = " .. Obj2.val)

Output:

Obj1.val = 10
Obj2.val = 12

ngwese · 2022-03-15T14:15:18.251Z

Doing “objects” in Lua can be annoying since there are so many examples which have subtle differences. The Name:function syntax is just sugar for passing whatever is referred to by Name as the first argument to the function. In the case of Class:new the self parameter is the table assigned to Class. Inside Class:new a new table is created called o which will serve as the container for instance specific values. The setmetatable is effectively setting the “type” of the instance being constructed. The __index line is essentially saying that if a value is looked up in o which doesn’t exist don’t immediately fail, search in the table pointed to by __index as well. The __index value how methods are found when called using o:foo(…) style syntax.

That brings us to self.val = val, that line is assigning to the class prototype not the o instance. If you used o.val = val I would expect things to work.

toneburst · 2022-03-15T14:21:45.145Z

ngwese:

That brings us to self.val = val, that line is assigning to the class prototype not the o instance. If you used o.val = val I would expect things to work.

Oh, it DOES!

Class = {}

function Class:new(o, val)
  o = o or {}
  setmetatable(o, self)
  self.__index = self
  o.val = val
  return o
end

function Class:changeVal(newval)
  self.val = newval
end

print("Create 'Obj1' instance with value of 10")
Obj1 = Class:new(nil, 10)

print("Create 'Obj2' instance with value of 12")
Obj2 = Class:new(nil, 12)

print("Obj1.val = " .. Obj1.val)
print("Obj2.val = " .. Obj2.val)

Obj1:changeVal(400)
print("Obj1.val = " .. Obj1.val)

print("Obj2.val = " .. Obj2.val)

Output:

Create 'Obj1' instance with value of 10
Create 'Obj2' instance with value of 12
Obj1.val = 10
Obj2.val = 12
Obj1.val = 400
Obj2.val = 12

The Name:function syntax is just sugar for passing whatever is referred to by Name as the first argument to the function. In the case of Class:new the self parameter is the table assigned to Class.

So

function Class:changeVal(newval)

is equivalent to

function Class.changeVal(self, newval)

?

Inside Class:new a new table is created called o which will serve as the container for instance specific values.

I think I kind of understand now. I should be able to get it working with that small modification, thank you!

It’s frustrating the tutorialpoint article doesn’t make this clear. I’d have thought that unique instance properties is a big part of the point of OOP…

ngwese · 2022-03-15T15:28:53.210Z

toneburst:

It’s frustrating the tutorialpoint article doesn’t make this clear. I’d have thought that unique instance properties is a big part of the point of OOP…

FWIW I quickly scanned the tutorialpoint page before responding and I think their tutorial is frankly incorrect. In each new function they define they start with o = o or {} but then they assign all of the would be instance values to the class table. I tend to stick with the official Lua docs at the end of the day despite their shortcomings.

The : vs . syntax is a source confusion in my experience. Hopefully the following sheds some additional light:

Class = {}

function Class:new(val)
  o = {}
  setmetatable(o, self)
  self.__index = self
  o.val = val
  return o
end

function Class:changeValA(newval)
  self.val = newval
end

function Class.changeValB(self, newval)
	self.val = newval
end

function Class.changeValC(nothing_special, newval)
	nothing_special.val = newval
end

Class.changeValD = function(self, newval)
	self.val = newval
end


local obj = Class:new(1)
print(obj.val)

obj:changeValA(2)
print(obj.val)

-- calling a function defined with implicit self parameter via normal function invocation 
obj.changeValA(obj, 3)
print(obj.val)

obj:changeValB(4)
print(obj.val)

obj:changeValC(5)
print(obj.val)

obj:changeValD(6)
print(obj.val)

Notice that I’ve defined essentially the same method using three different syntactic styles. Defining a function/method with Class:func is shorthand for assign the func key in the Class table to the following function and implicitly add a self parameter.

The second definition is much like the first but uses . so I add the self parameter explicitly to allow the use of the : “method call” syntactic sugar.

The third changeValC is like the second but illustrates that the name of the first parameter is not special.

The fourth form de-sugars it completely showing that defining “methods” is nothing more than assigning a name within a table to a function value.

toneburst · 2022-03-15T16:03:22.576Z

Thanks very much for the explanation, @ngwese!

I will pick a method, and stick to it , but great to have some background.

Incidentally, for my current project, I’ve gone for a mixture of Lua modules (where multiple instances with their own properties are not needed) and the above OOP approach where multiple independent entities with identical functionality seems to make more sense.

I’m largely a hobby coder (though I’ve been doing it a long time), so I do tend to get hung up on syntactical and structural concerns (often at the expense of getting the basic functionality to work, sadly, time being limited), so this is all interesting stuff.

Here’s a weird one (or maybe not, and it’s just a symptom of my lack of understanding):

Class = {}

function Class:new(o, val)
  o = o or {}
  setmetatable(o, self)
  self.__index = self

  self.reset = false

  o.val = val
  o.table = {}
  return o
end

function Class:changeVal(newval)
  self.val = newval
end

function Class:printVal()
  print(self.val)
end

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

print("Create 'Obj1' instance with value of 10")
Obj1 = Class:new(nil, 10)

print("Create 'Obj2' instance with value of 12")
Obj2 = Class:new(nil, 12)

print("Obj1.val = " .. Obj1.val)
print("Obj2.val = " .. Obj2.val)

Obj1:changeVal(400)
Obj1:printVal()
Obj2:printVal()

Obj1:setReset()
print("Obj1 reset value: " .. tostring(Obj1.reset))
print("Obj2 reset value: " .. tostring(Obj2.reset))

produces the following output:

Create 'Obj1' instance with value of 10
Create 'Obj2' instance with value of 12
Obj1.val = 10
Obj2.val = 12
400
12
Obj1 reset value: true
Obj2 reset value: false

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.

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