Re: [Oorexx-devel] Update on ooRexx -> Android

[Erich Steinböck]

Hi Thomas,
it seems that Android has no pthreads lib (it is built-in into libc
instead).  I will make appropriate changes to our CMake.
Can you attach CMakeFiles/CMakeError.log so that we can see why
pthread_attr_get_np isn't found (and also none ogf the others).
Thanks!
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] oelinfo from sandbox added to samples/ole/oleinfo (Re: Planned additions, release of ooRexx 5.1 ?

[Rony G. Flatscher]

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: 


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.

  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
 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: 

  + Margiol S., "DBusooRexx", International Rexx Symposium 2015:


  + 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:


  * 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()