Trying to reactivate this thread.
There are ooRexx users who depend on official releases as otherwise they cannot take advantage of
the latest versions (bug fixes, new features, etc.) as this thread shows:
<https://sourceforge.net/p/oorexx/discussion/general/thread/0bd421f711/?limit=25#3458>.
---
Personally I would postpone my intent to get the dbus support from the sandbox into ooRexx, despite
being convinced that this would be very helpful for the Linux users. But it can stay there for some
time more, I guess. :)
---
Ad releasing 5.1.0: this would be an opportunity to update the scripts and documentation to allow
for "push-button"-releases sometimes in the future which would allow for bug-fix releases to become
possible which may be important for ooRexx deployments in professional environments.
---
What are we going to do with the open items that Gil has pointed out (see below)? Would anyone have
any suggestions, ideas, takers?
---rony
On 30.11.2023 08:56, Rony G. Flatscher wrote:
Hi Gil,
thank you very much!
On 29.11.2023 19:10, Gilbert Barmwater wrote:
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".
Indeed, we should clean up this "unfinished business" ASAP.
Would it be possible for you or for anyone else on this list to give a helping hand? The more
shoulders carry this load the easier for each individual and the faster can the clean up go?
(Personally, I will probably only be able to get enough free time again during the New Year
vacation and would like to focus on the "planned additions".)
---rony
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
