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
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?
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/)
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
<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)
o history:
+ Flatscher R.G., "D-Bus Language Bindings for ooRexx",
International Rexx Symposium 2011:
<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>
+ 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>
* 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()
(cf.
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/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
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
Gil Barmwater
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
