1. Luarocks.
2. I regularly carry these little enumerables around with me and use it so frequently I found it quaint to be reminded of the 'hole problem':
--- get all packed entries, until gap
-- func on the provided list
-- @param list table to be inspected
-- @param func do func what you func want
table.each = function(list, func)
for i,v in ipairs(list) do
func(v, i)
end
end
--- get all entries, packed or not, until completion
-- func on the provided list, completely
-- @param list table to be inspected
-- @param func do func what you func want
table.all = function(list, func)
if (list ~= nil) then
for i,v in pairs(list) do
func(v, i)
end
end
end
Disclaimer: I love Lua and would us it for everything if I could.
Do you also carry a table deepcopy with you? What about string.trim?
And LuaRocks is a trash fire that doesn't integrate well with Lua's primary role as an embedded plugin engine and leaves you to waste your time in endless discovery of a slew of unmaintained packages that all do the same thing in different ways and with different bugs. Want to collaborate? I hope everyone is familiar with "classy" and not "oops" or "objectlua" or "Luaoop" or "lobject" or "classyng" or "klesi" or "halo" or "lua-c3class" or "pool" or "middleclass" or "Sunclass" or any other module that implements one of the half dozen official recommendations for faking classes with metatables or closures. It also becomes a huge "left-pad" risk.
Table deepcopy: table.unpack() does pretty much everything I've ever needed it to do, but for those tricker tables, there's always https://gist.github.com/tylerneylon/81333721109155b2d244 - and I freely admit that yes, the link to that gist is in my "Lua dev notes" bookmarks file, which I refer to often.
Hmmm ... string.trim: umm, not really something I find I need, a lot of times.. but as usual, Lua-users provides some incite into why, exactly, its not always as simple as one might think. (http://lua-users.org/wiki/StringTrim)
As for your brilliant discourse on Luarocks, ok. Not gonna get any resistance from me on that. I know the pain you describe. But I have had success with using it to copy environments on other machines 99% of the time .. which is not what I could say about the hell that python has put me through, at times. But I guess that's par for the course.
> as usual, Lua-users provides some incite into...
(insight)
It makes me sad that Lua's refusal to standardize good ways to do things led to the language's primary resource being a community message board filled with back-and-forth postcard essays saying "I tried this and it didn't work. Then I tried this and it didn't work." followed by someone else responding "Have you tried this?" and then yet another person saying "No, that doesn't work either." It's absolutely awful, and I hate myself every time I land on the Lua-users site.
I linked to it in another comment, but http://lua-users.org/wiki/SplitJoin is a perfect example. The document starts with "split and join are two common string operators". Note the word "common"! Then it promptly throws up its hands at declaring a reasonable interface and proceeds to plow ahead for literally pages of failed attempts that don't work right!
Even your link to StringTrim, which at least doesn't dick around with a ream of implementations that don't even work, provides _15_ different obscure as hell implementations, many of which only differ meaningfully in performance on really stupid cases, and the clearly superior one is in C, not Lua, so you can't even use it! But Lua itself could have used it and saved everyone the headache!
People shouldn't have to deal with this mess for "common operations".
As the one who wrote the C version (which I haven't had a need to use once I wrote it), why can't it be used? Not allowed to use modules written in C? Or lack a C compiler?
Also, please define "common operations" for me. I suspect that this is similar to the problem Microsoft has with Word---the features you find "useful" and the features that someone else find "useful" may be quite small, thus the large number of features. Not once have I reached for a "split" function, nor a join function (besides, that's the builtin operator "..", unless I'm missing some subtle functionality that "join" has).
And isn't the saying in the Python community "the standard library is where modules go to die"?
It's not Lua. This is not a thread about things missing from C. It's a thread about things missing from Lua. Suggesting to just use an entirely different language is bizarrely mishandling the issue.
I feel like the question is humorously akin to asking why a plain text reader can't portray a jpeg. It can, of course, if you write a description of the jpeg in a text file. Naturally, I should have been more clear.
> Not allowed to use modules written in C? Or lack a C compiler?
Often. The moment you start writing things like plugins for lay people, you stop being able to say "you should just grab a compiler".
> And isn't the saying in the Python community "the standard library is where modules go to die"?
People say dumb things all the time. We shouldn't begrudge them.
.
[edit] HN doesn't want to let me reply to your reply. I guess it doesn't like conversations. :(
> But doesn't Python also support modules written in C?
Whether a language _allows_ you to implement libraries in other languages is orthogonal to whether it should have standard implementations of basic things that are both extremely common and also often nontrivial to implement correctly and performantly for the person who needs the functionality right now.
> Or is it because the standard Python library is so large that it's not needed as often?
The Python standard library being so complete is probably the biggest reason why people love Python. Also, Python libraries get written in C exclusively for performance in cases where performance is paramount because Python is rather slow and frivolous with RAM. It's only done for things that are computationally intense (numpy, pytorch, etc). If Python were as fast as LuaJIT, nobody would write any Python libraries in C (excluding thin interfaces).
I think that's a big part of the problem - the perception of Lua as a language, and not as an execution/runtime environment that happens to have a scripting language at its core.
I get your point thought - it is frustrating to have to find these things to glom into a Lua project - but on the other hand, this is a language you can embed in anything, so tacking a standard library - which may not be useful in the "anything" application - is counterproductive to the goals of Lua, which is to be a simple and easy language to embed into anything.
But doesn't Python also support modules written in C? Does Python get a pass for that? Or is it because the standard Python library is so large that it's not needed as often?
