RexxUtil.DLL - OS2

This is a discussion on RexxUtil.DLL - OS2 ; Can eCS ship with an updated, backwards compatible RexxUtil.DLL? There's no reason to follow the one(s) shipped with ooRexx as such, but an update may offer a possiblity to add more functions. Besides that, many functions in stand-alone Rexx DLL's ...

+ Reply to Thread
Page 1 of 6 1 2 3 ... LastLast
Results 1 to 20 of 110

Thread: RexxUtil.DLL

  1. RexxUtil.DLL


    Can eCS ship with an updated, backwards compatible RexxUtil.DLL?

    There's no reason to follow the one(s) shipped with ooRexx as such,
    but an update may offer a possiblity to add more functions. Besides
    that, many functions in stand-alone Rexx DLL's (functionality) could
    be added. So e.g. no more MyPi(), RxPi() and/or SysPi(), but instead
    Math[group]Pi(). Well-designed, actually usefull functions only,
    obviously.

    Theoretically it may mean a rewrite of old Rexx apps, albeit the old
    Rexx DLL can be kept installed and still can be used. Besides that,
    many old Rexx apps can be "patched", if needed, to use RexxUtil.DLL
    instead of the former MyDLL.DLL.

    Shipping an updated Rexx DLL with eCS isn't a requirement, but it is
    probably an updatable component which doesn't break existing apps as
    long as compatibility (with pre-eCS OS versions too) is kept in mind.



    ---

  2. Re: RexxUtil.DLL

    ML wrote:
    > Can eCS ship with an updated, backwards compatible RexxUtil.DLL?


    I think the eCS developers would be flexible in that way.

    However, coming up with the source for the latest RexxUtil for both CRexx and ORexx on OS/2 would be the trouble.

    The OS/2 SDK shipped with part of it, but not all of it.

    Several years ago I ported to RexxUtl2 various API's that were contributed to ooRexx. Possibly the same sort of thing could be done so as to maintain the integrity of the official RexxUtil. Adrian
    Suri I hear has been tinkering around with that code, getting it to compile correctly on the Open Watcom compiler. I am CC'ing him on this posting.

    --
    Michael Lueck
    Lueck Data Systems
    http://www.lueckdatasystems.com/

  3. Re: RexxUtil.DLL

    ML wrote:
    > Can eCS ship with an updated, backwards compatible RexxUtil.DLL?


    I think the eCS developers would be flexible in that way.

    However, coming up with the source for the latest RexxUtil for both CRexx and ORexx on OS/2 would be the trouble.

    The OS/2 SDK shipped with part of it, but not all of it.

    Several years ago I ported to RexxUtl2 various API's that were contributed to ooRexx. Possibly the same sort of thing could be done so as to maintain the integrity of the official RexxUtil. Adrian
    Suri I hear has been tinkering around with that code, getting it to compile correctly on the Open Watcom compiler. I am CC'ing him on this posting.

    --
    Michael Lueck
    Lueck Data Systems
    http://www.lueckdatasystems.com/

  4. Re: RexxUtil.DLL

    On Sat, 15 Dec 2007 12:16:03 UTC, spamgate@hotmai1.com (ML) wrote:

    > Can eCS ship with an updated, backwards compatible RexxUtil.DLL?


    I'm pretty certain we don't have the source code, so no, probably not.
    In any case...


    > There's no reason to follow the one(s) shipped with ooRexx as such,
    > but an update may offer a possiblity to add more functions. Besides
    > that, many functions in stand-alone Rexx DLL's (functionality) could
    > be added. So e.g. no more MyPi(), RxPi() and/or SysPi(), but instead
    > Math[group]Pi(). Well-designed, actually usefull functions only,
    > obviously.


    ....what advantage would it have over providing new functions in
    another DLL? (As, in fact, we do to a certain extent already -
    see ECSRXLIB.DLL, which contains only a few functions now but
    can be expanded easily enough... which we do from time to time.)

    --
    Alex Taylor
    http://www.cs-club.org/~alex

    Please take off hat when replying.

  5. Re: RexxUtil.DLL

    On Sat, 15 Dec 2007 12:16:03 UTC, spamgate@hotmai1.com (ML) wrote:

    > Can eCS ship with an updated, backwards compatible RexxUtil.DLL?


    I'm pretty certain we don't have the source code, so no, probably not.
    In any case...


    > There's no reason to follow the one(s) shipped with ooRexx as such,
    > but an update may offer a possiblity to add more functions. Besides
    > that, many functions in stand-alone Rexx DLL's (functionality) could
    > be added. So e.g. no more MyPi(), RxPi() and/or SysPi(), but instead
    > Math[group]Pi(). Well-designed, actually usefull functions only,
    > obviously.


    ....what advantage would it have over providing new functions in
    another DLL? (As, in fact, we do to a certain extent already -
    see ECSRXLIB.DLL, which contains only a few functions now but
    can be expanded easily enough... which we do from time to time.)

    --
    Alex Taylor
    http://www.cs-club.org/~alex

    Please take off hat when replying.

  6. Re: RexxUtil.DLL


    >> Can eCS ship with an updated, backwards compatible RexxUtil.DLL?


    > I'm pretty certain we don't have the source code, so no, probably
    > not. In any case...


    There are multiple copies of RexxUtil.C floating arround. If those
    are not usable, a remake should be possible.

    > ...what advantage would it have over providing new functions in
    > another DLL?


    A disadvantage of more than a minimum number of DLLs is that those
    extra DLLs are used far less frequently, starting with RxFtp.DLL,
    while RexxUtil.DLL already is used in the typical app: Install.CMD

    > see ECSRXLIB.DLL, which contains only a few functions now but
    > can be expanded easily enough... which we do from time to time.


    More than one already increases the minimum number of DLLs, but I
    do agree that it doesn't have to be limited to 1. And it does imply
    that eCSRxLib.DLL then has to be the number 2, because otherwise
    the mimimum number of such a concept increased to 3 by now. The
    order above isn't fixed, because eCSRxLib.DLL also can include yet
    another MyCls(), but the order is the most likely one. After all,
    using RexxUtil.DLL is hard to avoid (e.g. SysFileTree()), but other
    DLLs don't have that advantage.

    > can be expanded easily enough... which we do from time to time


    Perhaps aiming at the #2 position, does that mean that eCSRxLib.DLL
    will become a true library of functions/libraries, as complete as
    reasonably possible, while keeping (the usual) quality in mind so
    it isn't flooded with useless functions?

    Another solution could be to e.g. download, install and RxFuncAdd()
    missing required ones, but AFAIK that's a bridge too far.



    ---

  7. Re: RexxUtil.DLL


    >> Can eCS ship with an updated, backwards compatible RexxUtil.DLL?


    > I'm pretty certain we don't have the source code, so no, probably
    > not. In any case...


    There are multiple copies of RexxUtil.C floating arround. If those
    are not usable, a remake should be possible.

    > ...what advantage would it have over providing new functions in
    > another DLL?


    A disadvantage of more than a minimum number of DLLs is that those
    extra DLLs are used far less frequently, starting with RxFtp.DLL,
    while RexxUtil.DLL already is used in the typical app: Install.CMD

    > see ECSRXLIB.DLL, which contains only a few functions now but
    > can be expanded easily enough... which we do from time to time.


    More than one already increases the minimum number of DLLs, but I
    do agree that it doesn't have to be limited to 1. And it does imply
    that eCSRxLib.DLL then has to be the number 2, because otherwise
    the mimimum number of such a concept increased to 3 by now. The
    order above isn't fixed, because eCSRxLib.DLL also can include yet
    another MyCls(), but the order is the most likely one. After all,
    using RexxUtil.DLL is hard to avoid (e.g. SysFileTree()), but other
    DLLs don't have that advantage.

    > can be expanded easily enough... which we do from time to time


    Perhaps aiming at the #2 position, does that mean that eCSRxLib.DLL
    will become a true library of functions/libraries, as complete as
    reasonably possible, while keeping (the usual) quality in mind so
    it isn't flooded with useless functions?

    Another solution could be to e.g. download, install and RxFuncAdd()
    missing required ones, but AFAIK that's a bridge too far.



    ---

  8. Re: RexxUtil.DLL

    [fup c.o.o.eCS]


    ML wrote:
    > There's no reason to follow the one(s) shipped with ooRexx as such,
    > but an update may offer a possiblity to add more functions. Besides
    > that, many functions in stand-alone Rexx DLL's (functionality) could
    > be added. So e.g. no more MyPi(), RxPi() and/or SysPi(), but instead
    > Math[group]Pi(). Well-designed, actually usefull functions only,
    > obviously.


    There is no reason to add this functions in REXXUTIL.DLL. All eCS have
    to do is to register the additional functions from whatever DLL
    automatically at the system startup. From the REXX programmer's point of
    view it makes absolutely no difference where they are located. I have
    done this for my favorite extensions too (codepage translation, hashes
    like MD5, fast Profile function replacements and so on).

    On the other side there are several advantages of separate DLLs. There
    are no version dependencies to REXXUTIL.DLL. There is probably no
    dependency to eCS at all (except for licencing issues, of course).


    Marcel

  9. Re: RexxUtil.DLL

    [fup c.o.o.eCS]


    ML wrote:
    > There's no reason to follow the one(s) shipped with ooRexx as such,
    > but an update may offer a possiblity to add more functions. Besides
    > that, many functions in stand-alone Rexx DLL's (functionality) could
    > be added. So e.g. no more MyPi(), RxPi() and/or SysPi(), but instead
    > Math[group]Pi(). Well-designed, actually usefull functions only,
    > obviously.


    There is no reason to add this functions in REXXUTIL.DLL. All eCS have
    to do is to register the additional functions from whatever DLL
    automatically at the system startup. From the REXX programmer's point of
    view it makes absolutely no difference where they are located. I have
    done this for my favorite extensions too (codepage translation, hashes
    like MD5, fast Profile function replacements and so on).

    On the other side there are several advantages of separate DLLs. There
    are no version dependencies to REXXUTIL.DLL. There is probably no
    dependency to eCS at all (except for licencing issues, of course).


    Marcel

  10. Re: RexxUtil.DLL


    > There is no reason to add this functions in REXXUTIL.DLL.


    There are several reasons to both limit the number of DLL's and to
    improve the actual use of other functions. Like mentioned before,
    using RexxUtil.DLL is hard to avoid (e.g. SysFileTree()), while the
    use of a lot of the other function libraries basily is avoided. Due
    to the additional, separated requirement, for one.

    Despite that, technically your remark is valid.

    > All eCS have to do is to register the additional functions from
    > whatever DLL automatically at the system startup.


    I think you have to do that yourself, you may write most apps for
    just your own use (which could be a shame, unshared apps), and it
    may mean you're an exception w.r.t. the number of DLL actually in
    use.

    > done this for my favorite extensions too (codepage translation


    If that was embedded in a common DLL, it would be far more obvious
    which extension you're talking about, and your favorites would be
    used more frequently than now.

    > On the other side there are several advantages of separate DLLs.


    If YourFunction() shipped with a very common DLL, I'ld know about
    it, having it is not an exception nor additional requirement, and
    adding it doesn't automaticly delete Your.DLL. A very common DLL
    may even point to the separated Your.DLL. No source code needed,
    no unavoidable version problems, no problem with functions names
    ued more than once: a library of libraries.

    > There are no version dependencies to REXXUTIL.DLL.


    It's e.g. far easier to detect a problem, and perhaps fix it, with
    the RexxUtil-version than a problem with a missing or wrong DLLs.

    And besides possible issues w.r.t. Your.DLL, RexxUtil.DLL still is
    expandable with more modern functions. It may be even be a way to
    avoid Rexx bugs, like Address() not returning PMREXX anymore, by
    offering a common replacement. That way a lot of Rexx apps can be
    ported to the PM again, no CMD.EXE involved, which now is broken.
    Another example is adding access to DosCopy(), a FAQ without a
    common, preferred, generally installed answer.



    ---

  11. Re: RexxUtil.DLL


    > coming up with the source for the latest RexxUtil for both CRexx
    > and ORexx on OS/2 would be the trouble.


    I haven't looked at possible differences, nor do I know what can be
    considered a typical situation. The default setup is CRexx + CRexx
    apps, but more advanced programmers probably use ORexx to execute
    CRexx apps. Just like Your.DLL isn't guaranteed to be installed, I
    cannot recall any (shared) ORexx apps while both interpreters can
    execute common CRexx apps (not counting any bugs, that is).

    > Several years ago I ported to RexxUtl2 various API's that were
    > contributed to ooRexx.


    I'm not sure ooRexx's RexxUtil.DLL is a perfect reference. I think
    SysIsFileDirectory() will always require an additional check, and
    I guess several mathematical functions were added "because C has
    'em". Besides that, with a library of functions/libraries perhaps
    a spreadsheet grouping convention is better than an enormous Sys*-
    group (e.g. SysPi() -> MathPi()). Nevertheless it's more modern,
    a SysFileCopy() is even usefull in OS/2's typical Install.CMD.

    > Possibly the same sort of thing could be done so as to maintain
    > the integrity of the official RexxUtil.


    Looking at each other wouldn't hurt. A general risk with a larger
    library is, apart from having to inheriting broken functions and
    many Sys*()'s, that improvements make using it harder due to more
    options, and added general functions will more and more actually
    come down to yet more macro's. I don't hate macro's as such, and
    other language know have macro's too, but it's easy to add yet
    another macro to please a user.

    I know I can rename SysIsFileDirectory() to add it to a File*()-
    group, for my own convenience, but other than that it may meet
    many of the arguments above: for a certain use it's broken, it
    adds no functionality to Rexx so in a way it's a macro, and such
    functions make the manual thicker than needed. I haven't lost the
    overview, but with many more classic solutions that risk grows,
    which meay lead to the impression that Rexx no longer is a very
    easy language (just like a "my mother" won't understand ORexx-
    code).



    ---

  12. Re: RexxUtil.DLL


    > coming up with the source for the latest RexxUtil for both CRexx
    > and ORexx on OS/2 would be the trouble.


    I haven't looked at possible differences, nor do I know what can be
    considered a typical situation. The default setup is CRexx + CRexx
    apps, but more advanced programmers probably use ORexx to execute
    CRexx apps. Just like Your.DLL isn't guaranteed to be installed, I
    cannot recall any (shared) ORexx apps while both interpreters can
    execute common CRexx apps (not counting any bugs, that is).

    > Several years ago I ported to RexxUtl2 various API's that were
    > contributed to ooRexx.


    I'm not sure ooRexx's RexxUtil.DLL is a perfect reference. I think
    SysIsFileDirectory() will always require an additional check, and
    I guess several mathematical functions were added "because C has
    'em". Besides that, with a library of functions/libraries perhaps
    a spreadsheet grouping convention is better than an enormous Sys*-
    group (e.g. SysPi() -> MathPi()). Nevertheless it's more modern,
    a SysFileCopy() is even usefull in OS/2's typical Install.CMD.

    > Possibly the same sort of thing could be done so as to maintain
    > the integrity of the official RexxUtil.


    Looking at each other wouldn't hurt. A general risk with a larger
    library is, apart from having to inheriting broken functions and
    many Sys*()'s, that improvements make using it harder due to more
    options, and added general functions will more and more actually
    come down to yet more macro's. I don't hate macro's as such, and
    other language know have macro's too, but it's easy to add yet
    another macro to please a user.

    I know I can rename SysIsFileDirectory() to add it to a File*()-
    group, for my own convenience, but other than that it may meet
    many of the arguments above: for a certain use it's broken, it
    adds no functionality to Rexx so in a way it's a macro, and such
    functions make the manual thicker than needed. I haven't lost the
    overview, but with many more classic solutions that risk grows,
    which meay lead to the impression that Rexx no longer is a very
    easy language (just like a "my mother" won't understand ORexx-
    code).



    ---

  13. Re: RexxUtil.DLL


    Excuse me, my newsreader seems to have picked up a nickname somewhere.

    I've seen the reverse problem before, it isn't my intention to litter
    newsgroups with identity crisis. :-)



    ---

  14. Re: RexxUtil.DLL


    Excuse me, my newsreader seems to have picked up a nickname somewhere.

    I've seen the reverse problem before, it isn't my intention to litter
    newsgroups with identity crisis. :-)



    ---

  15. Re: RexxUtil.DLL

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

    >Can eCS ship with an updated, backwards compatible RexxUtil.DLL?


    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

    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


  16. Re: RexxUtil.DLL

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

    >Can eCS ship with an updated, backwards compatible RexxUtil.DLL?


    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

    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


  17. Re: RexxUtil.DLL


    >> Can eCS ship with an updated, backwards compatible RexxUtil.DLL?


    > Wouldn't it be better to switch to open Object REXX


    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.

    > and to submit back any needed enhancements back to RexxUtil.DLL?


    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... :-)



    ---

  18. Re: RexxUtil.DLL


    >> Can eCS ship with an updated, backwards compatible RexxUtil.DLL?


    > Wouldn't it be better to switch to open Object REXX


    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.

    > and to submit back any needed enhancements back to RexxUtil.DLL?


    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... :-)



    ---

  19. Re: RexxUtil.DLL

    In <93sZHlQNABPR090yn@hotmai1.com>, on 12/17/2007
    at 09:29 PM, spamgate@hotmai1.com (ML) said:

    >Honestly I haven't seen any public domain ORexx apps, so perhaps a port
    >of ooRexx comes down to an updated CRexx?


    Well, I dropped CREXX years ago, so for Serenity to invest in enhancing it
    doesn't do anything for me unless they enhance OREXX as a byproduct.
    Similarly, Regina might be useful under Linux but for OS/2 I want OREXX or
    OOREXX

    --
    Shmuel (Seymour J.) Metz, SysProg and JOAT

    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


  20. Re: RexxUtil.DLL

    In <93sZHlQNABPR090yn@hotmai1.com>, on 12/17/2007
    at 09:29 PM, spamgate@hotmai1.com (ML) said:

    >Honestly I haven't seen any public domain ORexx apps, so perhaps a port
    >of ooRexx comes down to an updated CRexx?


    Well, I dropped CREXX years ago, so for Serenity to invest in enhancing it
    doesn't do anything for me unless they enhance OREXX as a byproduct.
    Similarly, Regina might be useful under Linux but for OS/2 I want OREXX or
    OOREXX

    --
    Shmuel (Seymour J.) Metz, SysProg and JOAT

    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


+ Reply to Thread
Page 1 of 6 1 2 3 ... LastLast