Forums » Suggestions
Upgrade LUA
Please upgrade to a newer version of LUA
Dude, please post actual problems instead of just random stuff, okay?
Dude, this is a problem... if you care about the quality of the plugins that are being written for your pride and joy. Documentation for old outdated LUA is becoming more and more scarce..
What the @#$@# are you even talking about?!
Lua 5.1 is dead.. not supported anymore as you can see.. it is almost 20 years old.
"Supported anymore"? By whom? You think we care about what Puc-Rio is doing? Again, what the bloody hell are you talking about?
You're like someone reading the C++17 standard came out, so clearly everyone must immediately stop using the C++11 standard. Let alone K&R C.
No one cares. That's not how languages work.
I'm aware of some of the features in 5.2+, but none of them have ever been particularly relevant to us.
We're Lua 5.1, and we're likely to be Lua 5.1 until the end of time. This is a product that we develop and support, we are not supported by external entities.
To give you some idea of how this works in the game world, Roblox was also Lua 5.1, and then eventually expanded that into their own language, Luau.
The fact that we hacked up some IUP code does not mean we're ever going to "upgrade IUP". We basically use "VOIUP".
This is why I keep asking you to include the problem in your Suggestion, so we can come up with a solution that's a good fit within our environment.
We are not making some kind of web-forum software that stays in lockstep with "versions" of external libraries. We're a game company. And like all game companies, we mostly roll it ourselves. Lua 5.1 is extremely widely used in the (current) game industry, and probably still will be in decades.
Moreover, the most advanced and performant (and current) Lua interpreters are only supportive up to 5.1, and likely only ever will be. But.. all this is way outside scope.
Please stop asking us to "upgrade stuff". Instead explain what you want to do which would be enabled by "upgrading the thing", and we can look at options for how we might provide that.
Imagine VO as a proprietary environment.
You're like someone reading the C++17 standard came out, so clearly everyone must immediately stop using the C++11 standard. Let alone K&R C.
No one cares. That's not how languages work.
I'm aware of some of the features in 5.2+, but none of them have ever been particularly relevant to us.
We're Lua 5.1, and we're likely to be Lua 5.1 until the end of time. This is a product that we develop and support, we are not supported by external entities.
To give you some idea of how this works in the game world, Roblox was also Lua 5.1, and then eventually expanded that into their own language, Luau.
The fact that we hacked up some IUP code does not mean we're ever going to "upgrade IUP". We basically use "VOIUP".
This is why I keep asking you to include the problem in your Suggestion, so we can come up with a solution that's a good fit within our environment.
We are not making some kind of web-forum software that stays in lockstep with "versions" of external libraries. We're a game company. And like all game companies, we mostly roll it ourselves. Lua 5.1 is extremely widely used in the (current) game industry, and probably still will be in decades.
Moreover, the most advanced and performant (and current) Lua interpreters are only supportive up to 5.1, and likely only ever will be. But.. all this is way outside scope.
Please stop asking us to "upgrade stuff". Instead explain what you want to do which would be enabled by "upgrading the thing", and we can look at options for how we might provide that.
Imagine VO as a proprietary environment.
My goodness incarnate.. clearly you have been rubbed the wrong way some how.. but it feels insulting to actually explain all of that to you, since I know you already know, or should know why someone would ask for such a thing.. same with the fonts post.. I guess you want me to pen it all out for others to read? Shall I just cut and paste the release notes from the LUA website?.. I'm also not a fan of the unprofessional language, but it is of course your forum to behave however you wish.
On the other hand your response sounds very much like many old C coders I know.. "why all the new features".. etc.. I get it, or maybe I don't. Modern programming is not done the same way as it was when you first wrote this game. Libraries written by professionals cannot be used to bring more features to plugins by your user base because you don't want to upgrade (ok that's fine.. whatever.. just a suggestion).. not that most of them could be used anyway, without the very heart of LUA language anyway (meta-tables).
I would say I understand your responses today to several of my posts.. but I just don't. On one hand you say certain things are "too hard".. which is a labor/funding problem.. then on the other hand you reject the notion that you can't do it all. Personally I don't really care that much, but it's not very professional to talk to me this way. You haven't made any large improvements to the LUA interface or the IUP system in 20 years incarnate. I know it must not seem like it has been that long, but singular individuals have written entire operating systems in less than a year. It is not irrational that I or anyone else would request some of these things. We have also offered to help, but evidently you get offended by those offers as well. I'm just not sure how to interact with you these days.
On the other hand your response sounds very much like many old C coders I know.. "why all the new features".. etc.. I get it, or maybe I don't. Modern programming is not done the same way as it was when you first wrote this game. Libraries written by professionals cannot be used to bring more features to plugins by your user base because you don't want to upgrade (ok that's fine.. whatever.. just a suggestion).. not that most of them could be used anyway, without the very heart of LUA language anyway (meta-tables).
I would say I understand your responses today to several of my posts.. but I just don't. On one hand you say certain things are "too hard".. which is a labor/funding problem.. then on the other hand you reject the notion that you can't do it all. Personally I don't really care that much, but it's not very professional to talk to me this way. You haven't made any large improvements to the LUA interface or the IUP system in 20 years incarnate. I know it must not seem like it has been that long, but singular individuals have written entire operating systems in less than a year. It is not irrational that I or anyone else would request some of these things. We have also offered to help, but evidently you get offended by those offers as well. I'm just not sure how to interact with you these days.
(Double facepalm).
Yes, I find this super frustrating, and the language choice of my responses reflects my frustration. I am frustrated, because I keep asking you to do specific things, and instead you keep arguing with me.
I've asked you to specifically call out what actual problems you're solving that require new features, but you instead want to lecture me about how "new versions are always better".
In 30 years of operationally working in complex code environments, sometimes with uptime guarantees and Service Level Agreements, that has not been my experience.
Moreover, the things you are recommending are not in keeping with the best-practices of my entire industry (making games).
For instance, our primary interest is on not Lua at all, but in LuaJIT, which is far more performant than PUC-Rio Lua, both on an interpreter basis (~3x?), let alone as a JIT compiler (~10x? more?). We've been using LuaJIT in production on the server for several years now, and refining our specific internal version of LuaJIT for the cases that we care about.
LuaJIT only supports the Lua 5.1 version of the language. That is not particularly weird, or strange, or backwards. That is not "old" or "out of date" or "stupid". That is a completely reasonable tradeoff for the developer (of what is perhaps one of the most advanced Just In Time compilers on earth) to have made.
It isn't necessarily that "we hate Lua 5.2+", it's the performance of a JIT compiler is WILDLY MORE @#$$@#ING RELEVANT TO ME.
Why is it so hard for you to just do what I ask? I am, and have been, trying to help you.
Instead, you just keep posting with the self-evident assumption that I must be incompetent. But, that is not the case. For instance:
but it feels insulting to actually explain all of that to you, since I know you already know, or should know why someone would ask for such a thing
I guess you want me to pen it all out for others to read? Shall I just cut and paste the release notes from the LUA website?
You may be disappointed to learn that this thread is not quite the example you believe it to be.
Yes, I find this super frustrating, and the language choice of my responses reflects my frustration. I am frustrated, because I keep asking you to do specific things, and instead you keep arguing with me.
I've asked you to specifically call out what actual problems you're solving that require new features, but you instead want to lecture me about how "new versions are always better".
In 30 years of operationally working in complex code environments, sometimes with uptime guarantees and Service Level Agreements, that has not been my experience.
Moreover, the things you are recommending are not in keeping with the best-practices of my entire industry (making games).
For instance, our primary interest is on not Lua at all, but in LuaJIT, which is far more performant than PUC-Rio Lua, both on an interpreter basis (~3x?), let alone as a JIT compiler (~10x? more?). We've been using LuaJIT in production on the server for several years now, and refining our specific internal version of LuaJIT for the cases that we care about.
LuaJIT only supports the Lua 5.1 version of the language. That is not particularly weird, or strange, or backwards. That is not "old" or "out of date" or "stupid". That is a completely reasonable tradeoff for the developer (of what is perhaps one of the most advanced Just In Time compilers on earth) to have made.
It isn't necessarily that "we hate Lua 5.2+", it's the performance of a JIT compiler is WILDLY MORE @#$$@#ING RELEVANT TO ME.
Why is it so hard for you to just do what I ask? I am, and have been, trying to help you.
Instead, you just keep posting with the self-evident assumption that I must be incompetent. But, that is not the case. For instance:
but it feels insulting to actually explain all of that to you, since I know you already know, or should know why someone would ask for such a thing
I guess you want me to pen it all out for others to read? Shall I just cut and paste the release notes from the LUA website?
You may be disappointed to learn that this thread is not quite the example you believe it to be.
I was just hoping for better abstraction tools.. an upgrade of LUA seemed like a simple request that would capture all of that. I see that it is not ..
Currently most of the means of abstraction have broken pieces or are disabled entirely. Meta-tables are disabled, modules loaded will have a different PATH depending on from what part of start up they are loaded... We don't have have 5.1 at the plugin developer level, we have a subset with broken parts. I'm not sure how to express what I was hoping for better than that. Most of the early LUA API suggestions I made were specific abstractions I was hoping for like SSL support or encryption layers.. or other things at the bottom that would help move our work as plugin developers up the abstraction ladder a notch. Having a LUA that would allow the use of modules from the public domain seemed like a simple fix... but since it's not, I guess I should go back to suggesting an addition for every lower level module that guys like me just don't have the time or patience to write? I was actually more concerned that you would find that particular approach more irritating.
I hope you accept my apologies for being a bit frustrating on the issue.
Currently most of the means of abstraction have broken pieces or are disabled entirely. Meta-tables are disabled, modules loaded will have a different PATH depending on from what part of start up they are loaded... We don't have have 5.1 at the plugin developer level, we have a subset with broken parts. I'm not sure how to express what I was hoping for better than that. Most of the early LUA API suggestions I made were specific abstractions I was hoping for like SSL support or encryption layers.. or other things at the bottom that would help move our work as plugin developers up the abstraction ladder a notch. Having a LUA that would allow the use of modules from the public domain seemed like a simple fix... but since it's not, I guess I should go back to suggesting an addition for every lower level module that guys like me just don't have the time or patience to write? I was actually more concerned that you would find that particular approach more irritating.
I hope you accept my apologies for being a bit frustrating on the issue.
I was actually more concerned that you would find that particular approach more irritating.
No, not at all. That was my point when I said "Imagine VO as a proprietary environment."
I explicitly want to know what you're trying to do, then we will examine the solutions that work best for our particular environment and codebase.
Understand, the fact that the VO Lua API availability is a limited subset is completely intentional. It is called a "sandbox" for a reason.
It is best to express your needs the way draugath does. Express the issue, the goals, and an example case, as reasonably succinctly as possible.
I hope you accept my apologies for being a bit frustrating on the issue.
It definitely made my day worse, but I do accept your apology. I will note the following things though, just for your own growth as a developer:
- In a rigorous production service environment, like those that maintain substantial uptime goals, all code is heavily versioned. This includes outside contributions and libraries, not just code that is developed internally. This is to maintain consistency, and guarantee rigorous certainty of the codebase as a whole, including dependencies.
- "New / Updated" library features can be great, but they also mean more new bugs, more complexity in debugging, more potential for outages and unforeseen downtime, etc.
- Most developers in these environments are not neophobic, they have no problems with new solutions or features. I mean, I sit on an API board at Khronos, and new features are a core part of that mandate. But in practical usage: relative risk, code analysis and rigorous testing time of "new code" has to be offset against the "need" for new features or options.
- Going back to what I said in the first point, most serious shops (regardless of size or headcount) fork their own codebases. It's more obvious if you look at major outfits like FB, Google, Uber, Etsy, Lyft, Electronic Arts, whatever.. you will find completely open-source forks that they use, of famous projects. Some are maintained against the original project, and some are permanently divided, but still cross-contribute code occasionally (like, say, FreeBSD vs NetBSD vs OpenBSD). This is not because they're "big companies", this is because they run operationally uptime-aware infrastructure. There's probably just one or two people who interact with these forks at each company, so it isn't "developer headcount" that's the issue, it's attention to detail. Lots of small companies do this too, ourselves included.
- It is flawed to assume that any library is made by "professional developers" (regardless of whether it's open or closed source). Everyone does their best, and there's some great code out there, and some terrible code. Unfortunately, there are also some developers who are "feature-happy" and "terrible at testing".. I know, I've employed some of them. And, similarly, there are lots of open-source projects that are not very rigorous at testing outside of a limited usage-scope that they value. I know that too, because our usage tends to blow up everyone else's stuff (from GCC to the Linux IP stack to countless other cases).
Conclusion:
Don't ever make the assumption that someone chooses not to upgrade out of some kind of fear of modern features or better code.
Nor should you assume that all code that is 20 years old is somehow "worse" than its present-day counterpart. Many of the most-reliable services on earth are specifically run on old code that is rigorously maintained and well-understood, and is not the Newest, Shiniest Thing.
I guarantee you that NASA isn't concerned about 20-year-old code being "less great", but rather how rigorously it has all been tested.
I similarly don't have much patience with the "neophobic" (afraid of new methods, solutions, improvements), I work in a field that is far too technologically fast-moving to be gentle with that.
So, sitting in the middle of having to ride a bleeding technological edge, while also trying to maintain strong service availability, means that we have robust standards around what we upgrade, when, how and to what extent. The full breadth of which is way beyond this discussion.
That's all. Take care.
No, not at all. That was my point when I said "Imagine VO as a proprietary environment."
I explicitly want to know what you're trying to do, then we will examine the solutions that work best for our particular environment and codebase.
Understand, the fact that the VO Lua API availability is a limited subset is completely intentional. It is called a "sandbox" for a reason.
It is best to express your needs the way draugath does. Express the issue, the goals, and an example case, as reasonably succinctly as possible.
I hope you accept my apologies for being a bit frustrating on the issue.
It definitely made my day worse, but I do accept your apology. I will note the following things though, just for your own growth as a developer:
- In a rigorous production service environment, like those that maintain substantial uptime goals, all code is heavily versioned. This includes outside contributions and libraries, not just code that is developed internally. This is to maintain consistency, and guarantee rigorous certainty of the codebase as a whole, including dependencies.
- "New / Updated" library features can be great, but they also mean more new bugs, more complexity in debugging, more potential for outages and unforeseen downtime, etc.
- Most developers in these environments are not neophobic, they have no problems with new solutions or features. I mean, I sit on an API board at Khronos, and new features are a core part of that mandate. But in practical usage: relative risk, code analysis and rigorous testing time of "new code" has to be offset against the "need" for new features or options.
- Going back to what I said in the first point, most serious shops (regardless of size or headcount) fork their own codebases. It's more obvious if you look at major outfits like FB, Google, Uber, Etsy, Lyft, Electronic Arts, whatever.. you will find completely open-source forks that they use, of famous projects. Some are maintained against the original project, and some are permanently divided, but still cross-contribute code occasionally (like, say, FreeBSD vs NetBSD vs OpenBSD). This is not because they're "big companies", this is because they run operationally uptime-aware infrastructure. There's probably just one or two people who interact with these forks at each company, so it isn't "developer headcount" that's the issue, it's attention to detail. Lots of small companies do this too, ourselves included.
- It is flawed to assume that any library is made by "professional developers" (regardless of whether it's open or closed source). Everyone does their best, and there's some great code out there, and some terrible code. Unfortunately, there are also some developers who are "feature-happy" and "terrible at testing".. I know, I've employed some of them. And, similarly, there are lots of open-source projects that are not very rigorous at testing outside of a limited usage-scope that they value. I know that too, because our usage tends to blow up everyone else's stuff (from GCC to the Linux IP stack to countless other cases).
Conclusion:
Don't ever make the assumption that someone chooses not to upgrade out of some kind of fear of modern features or better code.
Nor should you assume that all code that is 20 years old is somehow "worse" than its present-day counterpart. Many of the most-reliable services on earth are specifically run on old code that is rigorously maintained and well-understood, and is not the Newest, Shiniest Thing.
I guarantee you that NASA isn't concerned about 20-year-old code being "less great", but rather how rigorously it has all been tested.
I similarly don't have much patience with the "neophobic" (afraid of new methods, solutions, improvements), I work in a field that is far too technologically fast-moving to be gentle with that.
So, sitting in the middle of having to ride a bleeding technological edge, while also trying to maintain strong service availability, means that we have robust standards around what we upgrade, when, how and to what extent. The full breadth of which is way beyond this discussion.
That's all. Take care.