1bardesign / batteries Goto Github PK

#52 adds testing, and a few other recent prs from @idbrii have also added other CI functionality.

I'm torn on adding this stuff to the repo, especially in the main branch. At the very least we should move them under an easily deleted directory, probably .test or similar so it's ignored by utilities that ignore dotfiles.

The various alternatives, as i see them:

• keep them in main branch, move to a directory, and don't worry about it beyond that.
• move them to a test branch that CI can still use, with the caveat that we'll need to merge main into test often (some friction)
• move them to a separate repo that uses batteries as a submodule (highest friction)

Some discussion from here onwards in discord

See here. It's used to make sure we can create an instance of the superclass if needed and then overlay our table onto that. Inline overlay might be ok compromise.

Example in vec2 module:

local pos = vec2:new()
print(pos:type()) -- error

most love libraries and even love userdata use type as a function instead of string, so maybe change it to

local pos = vec2:new()
print(pos:type()) --vec2
print(pos.__type) -vec2

This is probably more of a design choice, I'll be glad to know the your reasons behind it.

Todo:

see

Some basic set operations would be super handy:

• Intersection
• Difference
• Union (this is already possible with append + dedupe)

Use this snippet instead.

local has_table_clear
has_table_clear, tablex.clear = pcall(require, "table.clear")

if not has_table_clear then
  -- your tablex.clear implementation
end

Description

It would be neat if the function tablex.print_r (or similarly named) was added to batteries. The function would recursively go into a table and print out all the values.

Details

Often I want to print out what is contained in a table. Not really just a specific value, but if I want to validate that multiple items are correct in it.

There's a lot of approaches to doing it, but I'm not sure about their efficiency, which is why I'm raising an issue instead of a pull request. For example, I tend to use the print_r function from mari0.

I think it would generally be beneficial to add this, as it's useful to use when the right time comes.

Other

If there's any questions or clarifications needed, please let me know and I'll do my best to answer them.

Hey,

I feel like my code is 99% correct, but for some strange reason, it isn't working properly. I have a subclass which extends a parent class, calls super for the necessary details, and then I try to move it around and allow the parent's draw method to handle rendering. However, it doesn't move. The only way for it to move is if I override the draw method and use the subclass's position variables. This doesn't make sense to me, since it should still be able to render at the position of the parent class, though. Here is the code I am using:

local peg = class()

peg.texture = love.graphics.newImage("graphics/objects.png")
peg.quads = {}
for index  = 1, 7 do
    peg.quads[index] = love.graphics.newQuad((index - 1) * 17, 0, 16, 16, peg.texture)
end

function peg:new(type, x, y)
    self.x = x
    self.y = y

    self.width = 16
    self.height = 16

    self.type = type
end

function peg:draw()
    love.graphics.draw(peg.texture, peg.quads[self.type], self.x * 16, self.y * 16)
end

function peg:move(x, y)
    self.x = self.x + x
    self.y = self.y + y
end

function peg:position()
    return self.x, self.y
end

function peg:__eq(other)
    return self.type == other.type
end

return peg

local peg = require((...):gsub("player", "peg"))
local player = class({extends = peg})

function player:new(x, y)
    self:super(1, x, y)
end

function player:movement(button)
    if button == "dpright" then
        self:move(1, 0)
    elseif button == "dpleft" then
        self:move(-1, 0)
    elseif button == "dpup" then
        self:move(0, -1)
    elseif button == "dpdown" then
        self:move(0, 1)
    end
    print(self:position(), self.x, self.y)
end

return player

Unless I'm meant to use the implements config, but that makes more sense for interfaced objects, which is not what I'm doing here. Hopefully I can get pointed to the right direction as to what is wrong.

To clarify a bit: printing the position in peg:draw() does show the initial values I load the player from, but they do not update from player:movement(). The values only change if I check inside the player class.

The existing shift/push method touches every element in the table once per step. The triple reverse method touches every element exactly twice.

function tablex.rotate(t, n)
    local tlen = #t
    local mid = -n % tlen
    tablex.reverse(t)
    tablex.reverse(t, 1, mid)
    tablex.reverse(t, mid+1, tlen)
end

For this to work your tablex.reverse needs to take optional bound arguments. Note that tablex.reverse should also be caching the length value rather than recalculating it in the loop.

At the moment, the vector modules have a naming pattern which is fairly user unfriendly. This is affecting uptake.

There are two issues, both basically lead to "hungarian style" names which are hard to understand at a glance.

Type Prefix:

Problem:
Currently, the operation type (scalar or vector) is specified with a "hungarian notation" style single letter prefix.
This avoids type dependent dynamic dispatch and keeps code fast but also is pretty unfriendly to a beginner.

Fix:
fully specified names could be provided for each operation, with hungarian style aliases preserved for writing terse code if preferred. vector_add and vadd both available, but the former canonicalised as the initial definition.

Immediate/Modifying Suffix:

Problem:
Currently, if an operation modifies its operand or not is specified with an "immediate" suffix on the method, eg vaddi for "vector add immediate". This looks a lot more like an assembly instruction than a lua method 😄

Fix:
A different naming convention could be adopted. Current candidate is verb for modifying and verbed for copying - eg normalise and normalised for modifying and copying normalisation respectively.

Note that this would break existing code. It definitely needs to be communicated well to existing users!

I do think both are worth doing though to make the incredibly useful vector modules more likely to get use in the wider community.

Line 147 in the assert function in table.lua (table.clear)

Sent from my HUAWEI GR5 2017 using FastHub

h is unassigned in this statement

See https://github.com/1bardesign/batteries/blob/master/mathx.lua#L178

Should probably be changed for the long term but will cause issues anywhere the current behaviour is expected. Needs to be documented if it changes.

Easy fix of course.

Thoughts from users welcome; if noone has any comments I'll likely just go ahead with this in the next week or two.

Splitting a string into a table by a separator character/string is handy.

split("Hi there, mister", ",") -> { "Hi there", " mister" }

Not sure if I'm doing this right, but I pulled batteries to my project and require("batteries"):export() would fail because love couldn't be found. I added a check for love at capture_callstacks part of async.lua and that did the trick.

Is it expected you pull in love for batteries to work?

set() used here, but not required in?

functional.reduce(seq, f, init) has the annoying property of the initial value coming after the function, often several lines removed from the start of the call. This would be a breaking api change, however.

It would be nice if the find family of functions also gave the index into the table.

I submitted !31 for this. At the moment, generate_2d is returning r, but the result set is called result.

On windows, using the basic lua5.1 interpreter, I had to add package.path = package.path .. ";./?/init.lua" before require("ext.batteries"):export(); to get it to work. Could mention this on the Installation section?

Im using the latest version if batteries

require("batteries"):export()
print(mathx)
print(tablex)
print(stringx)

All outputs nil

Something I noticed that could be useful in the colour namespace is a way to convert hex colors to rgb(a). Although not entirely common to do, it would be helpful as there's lots of predefined web colors, etc that use hex. Converting these to a float format [0, 1] is a pain.

For example, I often use this color tool when making a UI. It would be nice to say colour.hex_to_rgba("#eeeeee") and get the float values off of that.

Edit: I noticed there is unpack_rgb which takes a numerical value, although a string variant might be nice as well. Feel free to close, though, if you think it's not needed.

here:

The file colour.lua uses the "bit" library which I assume is a luajit built-in? It would be nice to have instructions on how to use this without luajit.

Some of the variable names used inside state_machine interfere with understanding what's going on (particularly current_state being a state name)

This should be straightforward to implement but I am not sure if the class' internal name, i.e. .__name should be modified too in the process.
Currently the :type() and the provided default __tostring accesses the class' name as a closure and the closure's value can not be changed from :camelCase afaik.

About

Discussed on Discord briefly, it would be nice to have a simple path module. These could also be appended to the existing stringx module instead, specifying they operate on file paths/file names.

Functions

1. {module}.extractFilename - get the filename of a file
   • Useful for when iterating and requiring lua files
2. {module}.extract(File)Extension - get the extension of a file
3. Some function that wraps around doing this for the init.lua path

While the first two functions are simple to do, I think it would still be beneficial to have them. Maybe have a function that would also return both pieces of information, should the user want both from one function call.