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? Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > 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 > (https://sourceforge.net/p/oorexx/code-0/HEAD/tree/sandbox/rony/oleinfo/ > <https://sourceforge.net/p/oorexx/code-0/HEAD/tree/sandbox/rony/oleinfo/>) > 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. > <https://www.rexxla.org/presentations/2004/ronyf1.pdf> > <https://www.rexxla.org/presentations/2004/ronyf1.pdf> > 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 > <https://sourceforge.net/p/oorexx/code-0/HEAD/tree/sandbox/rony/dbus/> > <https://sourceforge.net/p/oorexx/code-0/HEAD/tree/sandbox/rony/dbus/> 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: > <https://www.rexxla.org/presentations/2011/201112-DBus4ooRexx.pdf> > <https://www.rexxla.org/presentations/2011/201112-DBus4ooRexx.pdf> > Margiol S., "DBusooRexx", International Rexx Symposium 2015: > <https://www.rexxla.org/presentations/2015/DBusPresentation_Margiol.pdf> > <https://www.rexxla.org/presentations/2015/DBusPresentation_Margiol.pdf> > 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: > <https://www.rexxla.org/presentations/2016/201608-dbusoorexx.pdf> > <https://www.rexxla.org/presentations/2016/201608-dbusoorexx.pdf> > 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. > https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#gc > <https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#gc>--) or > .Net/CLR's System.GC.collect() (cf. > https://learn.microsoft.com/en-us/dotnet/api/system.gc.collect#System_GC_Collect > > <https://learn.microsoft.com/en-us/dotnet/api/system.gc.collect#System_GC_Collect>, > > https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals > > <https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals>) > 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
