Mail Archives: djgpp/2012/09/17/19:45:15
Hi,
(apologies for the weird formatting of this message)
On Saturday, July 28, 2012 3:59:21 PM UTC-5, Juan Manuel Guerrero wrote:
>
> This is a port of Lua 5.2.1 to MSDOS/DJGPP.
>
> To compile this port you will need to check out the libc sources from the
> CVS repository and compile your owm c library.
>
> DJGPP specific changes.
> =======================
>
> Please note that I have only ported this package. I do not use Lua at all so
> I will not be able to answer questions that are not related to porting issues.
>
> Send suggestions and bug reports concerning the DJGPP port
> to comp.os.msdos.djgpp or <djgpp_NOSPAM_delorie.com>.
I don't expect you to fix this or even worry about it. I'm not even sure why I'm messing with it. Color me curious. ;-)
Anyways, when talking to someone from FreeDOS the other day, I was mentioning BRexx (old 16-bit DOS compile) for potential use on a floppy, and he asked about Lua. So, while I don't really have a real-world use and don't know much, I did spend a few days dabbling with it. Mostly I just wanted to see if it would compile and run correctly for 16-bit DOS target. For that, I searched for some kind of a test suite.
http://www.lua.org/tests/5.2/lua-5.2.1-tests.tar.gz
Well, the "basic" test suite needs too much RAM for 16-bit DOS (without hacking to use EMS or XMS). I decided later to test your 32-bit DJGPP compile against this same test suite to see how it fares.
Your compile has a few so-called errors, but I wasn't sure which were compiler bugs or too aggressive optimizations or whatnot. So I rebuilt "stock" Lua (ANSI C part, aka "-DLUA_ANSI") with GCC 4.7.1 (DJGPP 2.04 /beta/) with -O1 to compare. Presumably trying other GCCs or switches might prove interesting too, but I haven't done so.
G:\LUA-5.2.1-TESTS> lua.exe -e "_U=true" all.lua
I commented out the ones that stopped it from completing with "final OK". I know that's not a fix, but I wanted to see how many (alleged) total errors there were. (And I'm not sure I 100% exactly understand what it's trying to do anyways.)
-----------------------------------
diff -warN LUA-5.2-1/files.lua juan.521/files.lua
199c199
< assert(r == nil and ismsg(m) and type(c) == "number")
---
> -- assert(r == nil and ismsg(m) and type(c) == "number")
209c209
< assert(r == false and ismsg(m))
---
> -- assert(r == false and ismsg(m))
455c455
< assert(fr:read("*all") == "x") -- `close' flushes it
---
> -- assert(fr:read("*all") == "x") -- `close' flushes it
460c460
< assert(fr:read("*all") == "x") -- no buffer; output is ready
---
> -- assert(fr:read("*all") == "x") -- no buffer; output is ready
468c468
< assert(fr:read("*all") == "xa\n") -- now we have a whole line
---
> -- assert(fr:read("*all") == "xa\n") -- now we have a whole line
diff -warN LUA-5.2-1/math.lua juan.521/math.lua
53,55c53,55
< assert(tonumber'+ 0.01' == nil and tonumber'+.e1' == nil and
< tonumber'1e' == nil and tonumber'1.0e+' == nil and
< tonumber'.' == nil)
---
> --assert(tonumber'+ 0.01' == nil and tonumber'+.e1' == nil and
> -- tonumber'1e' == nil and tonumber'1.0e+' == nil and
> -- tonumber'.' == nil)
60c60
< assert(tonumber("0x"..string.rep("f", 150)) == 2^(4*150) - 1)
---
> --assert(tonumber("0x"..string.rep("f", 150)) == 2^(4*150) - 1)
96c96
< assert(f(tonumber(' ')) == nil)
---
> --assert(f(tonumber(' ')) == nil)
-----------------------------------
My own 4.7.1 -O1 compile had the same errors in files.lua but none of the ones from math.lua (just FYI if you find that curious).
- Raw text -