The game of the year was written in Lua - YouTube
@vidak @50htz @akkartik Lua's hard to use for type-ins because it's block-structured, not easy to keep focus in, AND it has fussy, awful syntax. Did you type : or ::? There's way too many ways to do similar things in it.
#Lua is what a C++ developer thinks is "easy enough for a level designer".
#BASIC has the virtues of being trivial to read, write, and only has two data types, plus arrays of those. No classes, no function pointers. If you add named labels or functions, it's "modern" enough.
Hi, people! ✌️
I've build "Cat a shooter 😼" for Android, and this is the last thing that I have to do for a while.
And now you can download this game for your Android device 📱 from Gamejolt: https://gamejolt.com/games/cat-a-shooter/1007868
or from itch.io: https://xolatgames.itch.io/cat-a-shooter
Also I've add instructions for building to it GitLab page 👉 https://gitlab.com/xolatgames/cat-a-shooter
So, I think that it's all, and see ya later.
Have a good day! 😉 😜 ✌️
#opensource #games #gamedev #android #arcade #spaceinvaders #lua #devlog #love2d
🦾 Why Lua Beats MicroPython for Serious Embedded Devs
｢ Lua isn’t just compatible with embedded systems; the Lua ANSI C library was designed for them. Its architecture is clean, compact, and deterministic.
MicroPython, on the other hand, is a reimplementation of Python 3. It works well for many embedded use cases, but it inherits assumptions from a desktop-oriented language ｣
https://www.embedded.com/why-lua-beats-micropython-for-serious-embedded-devs
I'm currently writing #Fennel examples, and this is delightful. I even managed to make the decide function even more beautiful than it was!
(local ruleset [is-in-ai-robots-txt?
default])
(fn decide [request]
(accumulate [outcome nil
_ f (ipairs ruleset)
&until (not= outcome nil)]
(f request)))
This is perfection.
Getting started with iocaine is now online.
From nothing to running iocaine + Caddy with ai.robots.txt's robots.json and a few metrics as a starting point.
Contains #Roto, #Lua, and #Fennel - and a few tests too, for each.
I'm on a bit of a roll lately, and have released #iocaine version 2.4.0 just a few moments ago.
This does not bring that many significant changes as 2.3.0 did, but it does introduce #Lua and #Fennel as languages you can script its decision making with, on top of #Roto, which was introduced in 2.2.0.
While these languages run slower than Roto, they're still very fast, and are not going to be a bottleneck - they do provide a more familiar language to write the decision making in!
Oh, and metrics can now be persisted across restarts.
"What is acceptable?", you may ask.
Well, anything faster than ~40k req/sec in release mode will do. Why ~40k req/sec? Because that's my reverse proxy's bottleneck.
I also expect a very naive implementation of return false to run at at least at 1k req/sec in release mode.
What's a naive implementation? Creating the runtime environment on every request, and compiling the trivial program on every request.
In other #iocaine news, I'm doing some final polishing on #Lua scripting support, to make it as convenient as #Roto.
Right now, there's a differenc between how Lua and Roto scripts are loaded: with Roto, one needs to give a path to a directory, and pkg.roto will be loaded from there, and any imports will be relative to that directory.
With Lua, one gives iocaine a file path, and - currently - needs to set up the package.path search path manually.
So here's what I'll do: I'll make iocaine require a directory for Lua too, and it will add it to package.path, and will require("main"). The required module will also have to return a table with at least a decide key, and an optional run_tests key. This will simplify finding the functions to run, and will greatly reduce the number of special cases.
Today, I'm writing tests. Originally, I planned to write a bunch of tests in Rust to exercise the request handlers, but that felt like a huge pain in the backside, and would've involved a lot of repetition and boilerplate.
Then, I figured: I'll write the tests in #Roto and #Lua! Test the things from that side. Much less boilerplate, but still a lot of repetition.
Instead, I'll be writing a test suite to verify the decisions of a request handler. I'll run it for both engines, #Roto and #Lua. I will still have to write the scripts twice, but I will only write the verification once.
Weekend goal: a #Lua chunk (script) to help sighted users review #Braille. It's a great way to understand how visually impaired users interact with a computer using a screen reader and a Braille display. The script is simple and easy to configure. Currently, it offers a learning mode; in the future, a challenge mode will be added, along with a blog post explaining how to set it up.
Link: https://gitlab.com/-/snippets/4858299
On #FreeBSD it should be executable via flua:
% flua learnbraille.lua
after installing liblouis:
# pkg install liblouis
[edit] % /usr/libexec/flua learnbraille.lua
｢ Teal is a statically-typed dialect of Lua. It extends Lua with type annotations, allowing you to specify arrays, maps and records, as well as interfaces, union types and generics.
It aims to fill a niche similar to that of TypeScript in the JavaScript world ｣
I am in urgent job search mode, so I'm gonna throw this out here and see if anything comes of it.
I am a #Canadian, fluent in both #English and #French. I have experience with several programming languages. My strongest proficiency is with #Haskell and #C. I also have a reasonable grasp of #HTML, #JavaScript, #SQL, #Python, #Lua, #Linux system administration, #bash scripting, #Perl, #AWK, some #Lisp (common, scheme, and emacs), and probably several others I've forgotten to mention.
I am not necessarily looking for something in tech. I just need something stable. I have done everything from software development, to customer support, to factory work, though my current circumstances make in-person work more difficult than remote work. I have been regarded as a hard worker in every job I have ever held.