Had some unexpected time today (a holiday) such that I was able to tackle the
first item oleinfo:
* to document created feature request # 830 (#830 Add oleinfo scripts from
sandbox/rony/oleinfo,
https://sourceforge.net/p/oorexx/feature-requests/830/)
* committed with [r12746], changes can be seen at:
<http://sourceforge.net/p/oorexx/code-0/12746>
Changed the license in all files, updated readme.txt and test.rex (cater for Internet Explorer being
pulled from Windows eventually) accordingly.
---rony
On 20.11.2023 11:30, Rony G. Flatscher wrote:
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
