shmuel (seymour j.) metz

In <DW8YHlQNAlue090yn@hotmai1.com>, on 12/15/2007
at 02:16 PM, spamgate@hotmai1.com (ML) said:

Wouldn't it be better to switch to open Object REXX and to submit back any
needed enhancements back to RexxUtil.DLL?

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org

spamgate

I don't think so. For many, many, many reasons. Talented developers
are a very, very, very limited resource, and earlier Rony indicated
that porting ooRexx isn't a no-brainer (anymore). Even having to do
a remake of RexxUtil.DLL is a no-brainer for such a programmer. It
can be modernized (add SysFileCopy() to it, for example). Optionally
many other functions can be added to it, amongst others in order to
avoid the problem of people not liking to extend Rexx's possibilities
because you cannot guarantee another random user has My.DLL installed
properly. Besides that, the RexxUtil.DLL can also be identified as an
independently updateble part of Rexx.

Honestly I haven't seen any public domain ORexx apps, so perhaps a
port of ooRexx comes down to an updated CRexx? "Nice to have", but
most likely the limited resource has more important things to do. If
you want (other people to port) an updated CRexx, Regina/2 probably
is/was a better starting point. If required, let it inherit CRexx's
bugs by default, for example. That may be a more reasonable request
than begging for a (one-off?) port of ooRexx, also keeping it mind
that I doubt a reasonable level of ooRexx-portability to e.g. OS/2
always was kept in ooRexx's mind, and I cannot recall any effort of
RexxLA w.r.t. "the furthering of Rexx". Unless that means it moves
further away by each release, without looking at probably the largest
pc installed base and most of the users of Rexx. Never mind, I think
(oo)Rexx/2 is not a demand-driven market (my Rexx interpreter works,
and updating that isn't a no-brainer) but that wouldn't stop an idea
of presenting a more attrictive project proposal to possible porters
of ooRexx. "The source is available" is an too easy escape, if they
truely want to achieve a real "furthering of (oo)Rexx". Rony already
mentioned that porting it has been tried before, but I also cannot
recall any mentioning of the specific problems encountered. That is
comming down to "the source is available, good luck with it, you're
on your own!". If ooRexx/2 did exist, I'ld love to install it, but I
do understand that our limited resource has better things to do, and
those limited resources don't have such a goal of "the furthering of
Rexx".

And if any memory leak of CRexx is hurting you, try Regina/2? That
one already exists and probably is/was the best formerly maintained
Rexx interpreter for OS/2. It isn't "embedded" in the OS/2, and it's
not included with the OS, but other than that it's both progress and
an easier starting point. Too bad ooRexx "killed" Regina somehow, it
sure ain't the best thing that ever happened to Rexx.

I have to say updating RexxUtil.DLL, the subject, isn't a major step
but it would at least update that part of Rexx, and allows for more
common functions to be added. Here too I'm not sure ooRexx/RexxLA
kept in mind that just RexxUtil.DLL could be ported to e.g. OS/2, for
one to keep that at a shared level. I also guess things were added
to that RexxUtil.DLL by slightly more than 1 person, fullfilling a
request of 1 user or because access to C's cos() was a no-brainer
too. I'm e.g. referring to the broken SysIsFileDirectory(), which is
just a "macro" replacing the parsing of SysFileTree()'s output. And
I think cos() has more to do with (a new group) "Math" than with a
"Sys"-group.

So, no matter how one thinks about it, porting ooRexx to OS/2 isn't
a no-brainer. If you decide to do so: thanks in advance! But so far
you're on your own. I'm quite sure it can be done, especially when
it's better presented and porting is made more attractive than just
"the source is available". And if you want an updated Rexx, why not
start with Regina/2 instead? After all, so far the most popular Rexx
app is Install.CMD and going OO adds about nothing to that. At least
not compared to (a generally available and installed) RexxUtil.DLL
with e.g. SysFileCopy(), with RexxUtil.DLL not being controlled by
a few people not focussing at OS/2.

I don't have a problem with your route, it's "nice to have"! But my
article intentionally distinguishes between the no-no-brainer and
the no-brainer by design.

Having a modernized, and possibly a large library of functions, does
not break anything, is an independent solution (other than having to
intergrate it in the OS, because otherwise it's just "yet another
Rexx DLL" with a very, very limited number of actual users, which
basicly is a shame and a waist of efforts).

So I did identify RexxUtil.DLL as an updateble part of eCS. Please
don't let that stop you porting ooRexx to OS/2! :-)

W.r.t. ooRexx itself, included in your scheme, I don't expect anyone
to write that for me. Limited resources, propably at both ends. But
if "the furthering of Rexx" really is a true goal, some more active
pushing may help, so the porter knows what the project involves and
is not on her/his own. If you want another kind soul to provide us
just an updated Rexx, "porting" Regina/2 ought to be a far better
starting point than the Windows-led ooRexx project, assuming the
limited resources, 3 Rexx/2 interpreters working just fine, and more
important things at hand (e.g. maintaining webbrowsers). I doubt a
significant demand for ooRexx; it's a kind of push instead of pull,
but so far the RexxLA doesn't seem to deal with that. Perhaps that
changes, which could (!) make ooRexx a better starting point. But
until that moment, it's easier to look at eachothers RexxUtil.DLLs
and improve just that relative no-brainer. With possible access to
API's, add common existing functions to it, and so on. But it won't
be improved in short notice if ooRexx/2 comes with the same deal,
and I don't know why having a slightly outdated CRexx interpreter
would stop the development of RexxUtil.DLL-updates, which breaks
nothing. Additionally it just has to be "embedded" in the OS, or it
will become the already mentioned "yet another Rexx DLL", without
the full potential number of users. If your My.DLL is good, adding
it to "the" Rexx DLL has added value. Just like looking at eachother
may show added value, it's possible and a relative no-brainer. That
doesn't depend on being able to share a Rexx interpreter, which IRL
is not much more than a buggyfixing "nice to have"-rated thingy.

Anyway, I appriciate the c.c.'ed reply. That's a possible step aiming
forwards. And thanks to Rony for his contributions in the past. I did
mention his name, but that's not an attempt to kill the messenger. He
knew that already, I think, but it's okay to state that again... :-)

---