If the consensus is to do this, can we make a concerted effort to get the bugs and RFEs that were in 5.0.0 but were not marked as "pending" - usually as "accepted" - finally to a finished state, namely "pending"?  There has been a good amount of work on this but I'd really want to see ALL of them completed.  Thanks!

On 11/23/2023 3:51 PM, Rony G Flatscher wrote:
Dear P.O.,

fine, around end of January for planning a release of 5.1 would be fine!

Best regards


Rony G. Flatscher (mobil/e)

Am 23.11.2023 um 10:28 schrieb P.O. Jonsson <oor...@jonases.se>:

 Dear Rony,

I have no preferences regarding your proposals, for me you can go ahead and implement them.

Regarding a 5.1.0 release I have a tight schedule from now until Christmas so a release in 2023 would be very hard for me to cope with. What about aiming for end of January?

P.O. Jonsson

Am 20.11.2023 um 11:30 schrieb Rony G. Flatscher <rony.flatsc...@wu.ac.at>:

Given some free time I would like to add the following things to ooRexx 5.1:

  * the Windows oleinfo Rexx utilities from the sandbox
      o planned for being placed as is in a new directory
        ooRexx/samples/ole/oleinfo together with a readme.txt file
      o history: first introduced at the RexxLA symposium in 2004,
        cf. <https://www.rexxla.org/presentations/2004/ronyf1.pdf>
      o reasoning: many times it is very difficult, if not
        impossible to get at the published OLE interfaces of Windows
        COM/OLE objects including those returned by invocations of
        methods or fetching attribute values (they may not be
        registered in the registry, hence not discoverable); it is
        nice to have e.g. reference like printouts of the OLE
        interfaces (methods, attributes, events)

  * add the DBus support from the sandbox
    to ooRexx if the target platform has DBus support available
    (originally a message system on Linux exploited by many
      o history:
          + Flatscher R.G., "D-Bus Language Bindings for ooRexx",
            International Rexx Symposium 2011:
          + Margiol S., "DBusooRexx", International Rexx Symposium
          + Flatscher R.G., LinuxCon Europe 2015: "dbusoorexx
            Bringing the Power of D-Bus to Your Fingertips"
          + Flatscher R.G., "The ooRexx DBus Bindings for Linux,
            MacOSX and Windows", International Rexx Symposium 2016:

  * multithreading trace ("MT trace")
      o history: Jean-Louis has offered a very helpful and
        interesting means in form of a patch, that has not yet been
        applied; due to some discussions I had expected that an
        alternative means becomes available, but this has not
        materialized; after a couple of years it is time to give the
        ooRexx developers sound means into their hands; as designed
        Jean-Louis' version will have to be activated by setting an
        environment variable before starting the MT program, hence
        it is meant for explicitly debugging (no new MT-related
        trace options would have to be defined at all)
          + one aim when doing so is to come up with a BIF
            (suggestions?) that allows for retrieving the thread
            number, the activation number, the variable pool number
            and lock status, which the documentation of that BIF
            would explain: this should allow e.g. Gil to use this
            information to experiment with Rick's idea in
            non-explicit-debugging runs
              # this will cause these counters/this information to
                be always maintained, irrespectively whether  MT
                trace is active or not
      o reasoning: for debugging multithreaded programs it is
        necessary to get at the respective context invocation
        information, without it certain multithreaded problems
        cannot be analyzed/debugged

  * allow invoking the garbage collector for debugging purposes
      o history and reasoning: for debugging purposes in the context
        of the Java bridge it became necessary to make sure that the
        Rexx garbage collector ran (background: Java changed the
        finalization logics and to debug the new Java
        implementations for releasing cached Rexx objects and to
        test correct execution of their uninit methods); without a
        means to invoke the ooRexx garbage collector this is simply
        not possible; it is very likely that such debugging needs
        occur in other contexts where native information systems
        interacting with ooRexx (e.g. using ooRexx for scripts) need
        to be able to check/analyze/debug correct releases of cached
        ooRexx objects for debugging purposes; without such a
        function this simply cannot be achieved; as running the
        garbage collector (in every programming language) is a very
        expensive operation this needs appropriate documentation;
        invoking existing garbage collectors is possible in popular
        programming languages such as Java's java.lang.System.gc()
        or .Net/CLR's System.GC.collect() (cf.

Any comments?


Also we should plan to release the current 5.1 version of ooRexx as soon as possible for at least the following reasons:

  * make the current bug fixes available in the form of an
    officially released package: many companies do not allow beta
    software to be installed, used, hence the need for a officially
    release if we want ooRexx to remain a viable option
  * make new features available like the new UTF-8 support in the
    WindowsClipboard class
  * keep the knowledge about creating releases up-to-date, allow for
    improving, maybe even fully automizing the release steps as much
    as possible
  * show the public that development has been going on


Oorexx-devel mailing list

Oorexx-devel mailing list

Oorexx-devel mailing list

Gil Barmwater
Oorexx-devel mailing list

Reply via email to