[bug#46231] Add emilua

["Vinícius dos Santos Oliveira" <vini.ipsmaker@gmail.com>]

Em sáb., 20 de fev. de 2021 às 22:21, Nicolas Goaziou
<mail@nicolasgoaziou.fr> escreveu:
> There are some issue to fix:
> - the name of the custom luajit2 package should be changed. Maybe
>   openresty-luajit?
> - that package should have a proper version and build tag out of it.

I've used "define" instead "define-public" so it wouldn't be really
available elsewhere in the system. However after some thought I do
agree that this dependency can be generally useful to more people and
should have a proper name.

What do you think about the name openresty-luajit-lua52?

> - I see that emilua uses #:recursive? set to #true. Could some
>   submodules could be unbundled by any chance?

Some, yes, but not all. A Debian packager asked me the same and I
already started to unbundle the dependencies where it can make sense
to use the one found in the system. I can offer more details on why a
few dependencies still must be provided as submodules if requested.
Next emilua version (a couple of weeks away) should use more
dependencies from the system and less bundled dependencies, but you'll
still need #:recursive? set to #true for the bundled dependencies that
will remain.

> - You disabled tests. I would be nice to provide a reason for that.

This is how the tests are run:

1. The emilua binary is generated.
2. The emilua binary is executed against every *.lua file inside the test dir.
3. An output is generated and compared against the matching *.out file
inside the same dir.
4. If they differ, the test fails.

There are two types of tests:

* Good test cases. No error expected.
* Bad test cases. Buggy code is feeded to the runtime to see if it is
able to detect the error.

On exceptions (the bad test cases), Lua throws an error string and
Emilua will print the stacktrace. The stacktrace is generated by the
Lua VM and contains paths to the files involved. This path will be
different in every machine you run the tests as you probably will
store the source code in different paths. Here's an example:

$ emilua test/interrupt7.lua
Main fiber from VM 0x7f1f133d1380 panicked: 'Invalid argument'
stack traceback:
  /home/me/emilua/test/interrupt7.lua:5: in main chunk
  [C]: in function ''
  [string "?"]: in function <[string "?"]:0>

So I filter the test output using an AWK script that replaces the
filename by "input.lua". Here's the translation line:
https://gitlab.com/emilua/emilua/-/blob/ded59fa9d4bb8977aed40fb7b683c6403b462f28/test/run_test.awk#L60

This filter ensures that a path in the likes of
"/home/me/emilua/test/interrupt7.lua" will be spit as "input.lua".
That makes the output predictable so I can write the *.out files that
reference input.lua. Here's the matching test/interrupt7.out from the
previous run:

Main fiber from VM 0x1 panicked: 'Invalid argument'
stack traceback:
  input.lua:5: in main chunk
  [C]: in function ''
  [string "?"]: in function <[string "?"]:0>

Unfortunately this strategy is not enough. The Lua VM will shorten
paths by excluding some of its parts and replace them by "..." when
they are too long. That's why the script has this rule:
https://gitlab.com/emilua/emilua/-/blob/ded59fa9d4bb8977aed40fb7b683c6403b462f28/test/run_test.awk#L4

However running the tests from the guix build unveiled yet another
problem with this script. If even longer paths are at play (as in the
guix build), the Lua VM will apply a different shortening algorithm to
the paths sometimes. So the tests run, the emilua binary will do the
right thing, but the translation script won't work on one of the test
cases and will raise a false negative. I intend to solve this issue
and I already started to investigate so it'll eventually be solved,
but in the meantime I just disabled the tests. I don't control the
paths the Lua VM generates so improving the AWK script is really my
only choice here.

> - You don't need `string-append' in the description. Just write the full
>   textin a single string.

Okay.

> Could you split this into two patches and send them here, for easier review?

Sure. Let's get the openresty-luajit-lua52 package in first and then
I'll work on the second patch.

Here's the patch for openresty-luajit-lua52 alone:
https://gitlab.com/emilua/emilua/-/snippets/2079960


-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/