Tag: lua

Update: Using Data::Lua 0.02 in 2021

MattPson

It looks like it is a no-go and doesn’t work as expected. At least not in the way I expected it to.

To test my recently installed perl module Data::Lua I wrote a very small test just to see if I could get the data from the file I wanted.

#!/usr/bin/env perl

use strict;
use warnings;

# enable perl 5.10 features
use v5.10;

# use these modules
use Carp;
use Data::Dumper;

use Data::Lua;

# === TEST

my $vars = Data::Lua->parse_file('data/indata.lua');
print Dumper($vars);

exit;

This should simply take the LUA indata.lua file and parse it into a perl variable, $vars, as described in the perldoc for Data::Lua. Then Data::Dumper will just print the resulting data structure. Easy. It does run without any errors but it produces a huge output:

$ ./parsetest.pl | wc -l
9773494

This can’t be right? My input file is rather small. Something like 10kBytes and a total of 526 lines:

$ wc -l data/indata.lua
526 data/indata.lua

A difference of over 9.7 million lines is a tad bit too much to write of easily. Examining the output there is a lot of ‘undef’ lines. Like 9.7 million of them with some data sprinkled in between. Removing these lines makes it look like there is a chance to have the data I want.

$ ./parsetest.pl | grep -v undef | wc -l
526

Maybe. There is no way to verify if it is in somewhat correct format etc. unless I put in more time into this. And my input files will be much larger than this test file so producing 99.9% output data that will have to be filtered away before further processing isn’t good.

So in the end I will have to write my own parser. Probably not a generic one but one that solves this particular problem I’m facing. Maybe I’ll write an update on that when I get somewhere.

Using Data::Lua 0.02 in 2021

MattPson

Today I ran into a small problem. I needed to parse some files with Lua data (not my choice!) into a database (generic, but think MySQL). Of course I probably could have done this using Lua directly but I didn’t want to spend more time on this than necessary so I went with what I’m most comfortable with; perl.

A quick look at CPAN and I found Data::Lua which should parse my Lua data quickly. Turning to my development system running Debian I quickly installed Lua and went to (locally, for my private user) install Inline::Lua and Data::Lua. That should do the trick. Except that I ran into 2 problem with the Data::Lua tests:

t/parse-file.t …… 1/8 error: [string "_INLINED_LUA"]:18: attempt to call a nil value (global 'setfenv')

and

t/parse.t ……….. 1/7 error: [string "_INLINED_LUA"]:3: attempt to call a nil value (global 'loadstring')

After examining this further I found out that these functions setfenv and loadstring was removed from Lua in version 5.2. My Debian system has version 5.3 (or was it 5.4?) installed as default.

Solution

To make this work I had to remove the default Lua version that was installed and replace it with and older 5.1.

# apt-get remove lua5.3 liblua5.3-dev
# apt-get install liblua5.1-0-dev lua5.1

Then I had to (force) rebuild Inline::Lua since it was built against the 5.3 libraries

$ cpan -f install Inline::Lua

After this Data::Lua passed all tests with no problems and installed smoothly. It remains to see if it solves my Lua data into a database via perl exercise.

Examining Data::Lua a bit

Looking into the single file that is Data::Lua it seems that adjusting the two available functions to for with modern Lua versions is a really easy fix. But from what I can make out it seems like that module is more or less abandoned by its’ author. Last update was in 2009 and it is version 0.02. I also see that my problem is reported as a bug over 2 years ago so I guess it is not getting any attention. Sad.