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 <>:
> Given some free time I would like to add the following things to ooRexx 5.1:
> the Windows oleinfo Rexx utilities from the sandbox 
> ( 
> <>)
> planned for being placed as is in a new directory ooRexx/samples/ole/oleinfo 
> together with a readme.txt file
> history: first introduced at the RexxLA symposium in 2004, cf. 
> <> 
> <>
> 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 distributions)
> 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 Fingertips"
> Flatscher R.G., "The ooRexx DBus Bindings for Linux, MacOSX and Windows", 
> International Rexx Symposium 2016: 
> <> 
> <>
> multithreading trace ("MT trace")
> 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
> 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
> 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() (cf. 
> <>--) 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 
> ---rony
> _______________________________________________
> Oorexx-devel mailing list

Oorexx-devel mailing list

Reply via email to