On 4/10/2013 10:30 AM, John McKown wrote:
BTW,
I have successfully compiled and tested the basic lua 5.2.2 which I
downloaded from http://lua.org/download.html . It was basically just
download, unwind the tar using pax and converting from ISO8859-1 to
IBM-1047, then doing a "make posix". But I don't know what else I should
really look at trying to port. Or exactly how to do it. On Linux, I use git
as an SCM. But I don't having anything like that for z/OS on the system
that I'm using (not my employer's).
Most Lua libraries are compatible with Lua 5.1.5. I've stuck with that.
I ported luarocks which is a package installer similar to apt-get.
I find these days I mostly use github which is the center of the
universe for open source. I just scripted curl commands to download
tarballs and the pax them.
There is secret sauce to the build wrt co-routines and exception
handling. If you optimize your code it will abend. I've given the secret
away
in another thread. Lua is a very small language (200k) and comes with a
minimal runtime. That' is by design so it can run on micro-controllers etc.
Very different to Python which is big and heavy. Lua blows Python away
for speed and has equivalent libraries (list comprehension etc).
I am not one iota interested in compiling in ASCII. I've tried that
before and it's full of holes. I always end up having to manually covert
code pages to do
simple stuff like write log output to sysout from a batch job.
You need to sort out the Lua string library patterns for EBCDIC. XML
uses expat so you need to EBCDIC patch that. Lots of EBCDIC patching.
Porting and building a useful runtime library is where the work is.
That's where I've spent all my time. For example, to run the web-server
stuff in kepler you need to
convert to/from ASCII/EBCDIC at the socket level. Same for the SSL
socket stuff. z/OS Unix has some peculiar differences to other Unix
systems. As the majority of
packages are built for Linux you will need to fix a lot of the C code to
compile it. Then you need to write z/OS specific libraries for TSO/ISPF
so it can be a
drop in replacement for REXX. A Locale library to convert code pages.
Patch the I/O library to support VSAM.
You need to be a pretty sharp C programmer to do all that.
I don't know lua and don't have any test suite, unfortunately. And I've
just not been "with it" so far this week as far as just messing around with
it myself. I don't know how much use having the basic lua would be. I could
probably package it up for the CBTTape and give it to Mr. Golob to put on
the CBTTape web site.
CBTTape is fine but I would prefer to put my stuff on github. It's got
great tooling.
On Thu, Oct 3, 2013 at 8:27 PM, David Crayford <[email protected]> wrote:
On 4/10/2013 8:31 AM, Shane Ginnane wrote:
Good thread.
I like Kirks ideas, but I can't see it flying. IIRC even Dave has alluded
to employer resistance to releasing his efforts on the Lua port.
The issue wrt me releasing Lua is because of our contract with IBM. I work
for a vendor who develops software that's badged and marketed by IBM. The
deal we signed for our
machine had a clause that states that we can only use it to develop
software for IBM products. There are options, such as a zPDT laptop or
Dallas. I've had discussions with the management
team about it and they're a good bunch of guys. I'm sure something will
happen sooner rather than later.
I don't port software for the fun of it. I do it because it's going to be
useful. The other day my colleague was trying to write a web application
for a test case in Java, deploying to Websphere. It
took him almost a week, trying to understand the frameworks. It wasn't
easy to the neophyte with the EAR and WAR and all that stuff. I could have
knocked that up in a couple of hours in Lua in
200 lines of code. That's a real life use case. It's not going into one of
our products but it saves time and money.
Every employment contract I've seen includes ownership of code developed
- and isn't limited to the employment duration. There have even been
suggestions that this may include ideas conceived as a result of (paid)
work, even if not coded/developed there/then.
Shane ...
------------------------------**------------------------------**
----------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
------------------------------**------------------------------**----------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
