I guess I need to refresh everyone's memory on this topic. When we
released 5.0.0 about a year ago, it contained a lot of changes! The
CHANGES file listed 361 bug fixes, 169 RFEs, 66 documentation bug fixes
and 10 patches. Unfortunately, some of the bug fixes and RFEs were NOT
in the "pending" state but still in the "accepted" state which indicated
additional work items - typically doc, and/or test - were not complete.
Rather than delay the release any longer(!) until they were all in the
pending" state", it was decided to proceed, listing them as included in
the release. Shortly following the release, all the "pending" items
were changed to "closed" as well as SOME of the "accepted" ones. Since
that time, additional items have been completed and their status changed
to "pending" or "closed" but there remain a number that are still
unresolved. My analysis indicates that there are 11 bugs - 1447, 1624,
1625, 1656, 1742, 1762, 1763, 1786, 1827, 1837, and 1838 - and 11 RFEs
- 353, 544, 550, 552, 569, 576, 578, 581, 603, 754, and 803 - still to
be completed. Whether we decide to do a bug-fix release - 5.0.1 - or a
new feature release - 5.1.0 - it is time to clean up this "unfinished
business".
On 11/29/2023 7:11 AM, Rony G. Flatscher wrote:
On 24.11.2023 01:05, Gilbert Barmwater wrote:
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!
Could you point them out (unfortunately, I have no idea what you mean
or which bugs and RFEs are affected)?
---rony
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
--
Gil Barmwater
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
