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.
# enable perl 5.10 features
# use these modules
# === TEST
my $vars = Data::Lua->parse_file('data/indata.lua');
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
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
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
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.
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')
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.
To make this work I had to remove the default Lua version that was installed and replace it with and older 5.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.
This a re-post of old information that I’ve previously posted somewhere back in 2018 but I wanted it here too for easy linking. It should still be valid in MacOs Big Sur and an slightly updated UltraEdit (I use Version: 126.96.36.199) as I used it as late as yesterday for programming som small stuff.