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.
     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 2015:
         + Flatscher R.G., LinuxCon Europe 2015: "dbusoorexx Bringing the Power 
of D-Bus to Your
         + 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 
               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

 * 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.lang.System.gc() (cf. or 
       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

Reply via email to