LÖVE

Puzzlem00n wrote: If I put it at the top like that, you mean? It doesn't print any errors, it just plain stops working. I wish I could put it like that so I'd only have to require linen and then the other two would be automatic, but it just doesn't fly, apparently.

1) Yes, it's working now. 2) To be honest, I have no idea, I'm just running under the assumption that it's faster. 3) Not really.

if you never noticed lag spikes/jitters you probably won't see any differences. my laptop sits nicely at 60fps now, instead of dropping to ~30 every time lurker.scan() runs.

also, i'm working on another library that allows auto-reloading of middleclass entities. i'll have a demo up later on

love.threaderror can catch thread errors if you need that. But! It is a callback so if the user is using threads and calls that function then it would override yours.

also it would be great if you could reload a thread with lurker/linen/lume... I don't know if that works right now but would be awesome

and the last thing is if you require a file, it is stored in the cache so the next time you require the same file, you don't need to reload it (bartbes said it in some other post)

Lume updates

Since the last "updates" post: (version 1.2.0 -> 1.4.0)

• Adds lume.memoize()
• Adds lume.combine()
• Adds lume.match()
• Adds lume.count()
• Adds lume.uuid()
• Adds lume.chain()
• Adds lume.weightedchoice()
• Changes lume.smooth()'s easing from cosine to cubic
• lume.combine() now ignores nil arguments
• lume.trace() now rounds numbers to 2 decimal places
• lume.fn() now type checks argument
• Adds proper handling of nil values passed to lume.trace()
• Changes lume.split() to mimic python's str.split()
• Fixes negative-index arguments in lume.slice()
• Fixes error checking of invalid callable arguments which lack metatables
• Fixes compatibility with Lua5.2 by using table.unpack() when unpack() is not available
• Fixes use of lua pattern special characters in lume.split() and lume.trim()
• Minor optimisation to lume.rgba()

Just started looking at lume.
A little late to the party but isn't there an error in lume.each? Shouldn't the code in 'each' be: Could be way off but this works for me.

Ref wrote:Just started looking at lume.
A little late to the party but isn't there an error in lume.each?

Code: Select all

function lume.each(t, fn, ...)
  if type(fn) == "string" then
    for _, v in pairs(t) do v[fn](v, ...) end
  else
    for _, v in pairs(t) do fn(v, ...) end
  end
  return t
end

Shouldn't the code in 'each' be:

Code: Select all

    for k, v in pairs(t) do t[k] = fn(v, ...) end

Could be way off but this works for me.

Actually, I'd go for the Great rxi's implementation. I am no reference here, but as far as I could notice, each iterator is a common pattern in functionnal programming. And most of the time, the purpose is to apply a tranformation function on every element in a given collection (here, the table t).

What you proposed, Great Ref, behaves similarly to another common pattern in functional programming, which is called "mapping". The main difference between "map" and "each" is that map collects the result of each function call on every single argument of the original collection, and creates a new collection which is returned at the end. In your implementation, the new ollection is just overwritten over the original one.

I have similar patterns implemented in moses.lua: see (_.each and _.map)

Ref wrote:Just started looking at lume.
A little late to the party but isn't there an error in lume.each?
[...]
Shouldn't the code in 'each' be:

Code: Select all

    for k, v in pairs(t) do t[k] = fn(v, ...) end

Could be way off but this works for me.

You may want to take another look at lume.each()'s section in the README.md.

What you described was closer to lume.map(), though map creates a new table rather than changing the table in place.

Edit: Looks like Roland_Yonaba snook in a response while I was writing mine! Hopefully it all makes double sense now.

Well aware of the difference between 'each' and 'map'.
My only point is that: does nothing as 'each' only returns the original, unmodified table.

Edit: Appears that I'm trying to use 'each' in a way that it was not intended. Looks like 'each' is just a way to feed parameters into a function, not to modify the contents of a table - My Bad!

Ref wrote:Well aware of the difference between 'each' and 'map'.
[snip]
Edit: Appears that I'm trying to use 'each' in a way that it was not intended. Looks like 'each' is just a way to feed parameters into a function, not to modify the contents of a table - My Bad!

But that is the difference between each and map!

More people need to know about this! It's so useful!