Re: [Oorexx-devel] Status of RxFTP

[Rick McGuire]

On Sat, May 18, 2024 at 12:19 PM Mike Cowlishaw  wrote:

> [Wow, your memory of elap is impressive!!]
>

except I forgot it was called elap!

>
> But no, the command is called from MemoWiki which is started from a
> Chrome browser icon which in turn talks to a goserve HTTP server which runs
> a Rexx program to effect the wiki.  That Rexx program is continually
> running -- so that is likely the underlying cause.
>
> And indeed the publishpage simply does a:
>
>call webPublish ftpserver'/'path,,
>   ftpuser':'ftppassword,,
>   textTypes, ignoretypes, binarytypes,,
>   'memowiki' args, filesdir
>
> rather than running it in a separate process.
>
> So I should restart the server, which is faster than rebooting Windows
> :-), but is still a bit tedious.
>
> Is there a simpler way to force reload of the .cls?
>

The package manager uses a weak reference for loaded packages, so if there
are no references pointing into that package it will get garbage collected
eventually. A bit tricking to control and there's always the issue of
unexpected references locking it down. Restarting the server is probably
the best solution.

Rick



>
> Mike
>
>
>
> --
> *From:* Rick McGuire [mailto:object.r...@gmail.com]
> *Sent:* 18 May 2024 17:02
> *To:* Open Object Rexx Developer Mailing List
> *Subject:* Re: [Oorexx-devel] Status of RxFTP
>
> are you calling the program using your custom command shell? I suspect
> that might be the problem. Otherwise it should be picking up the change
> every time the program is run, assuming it runs in a new process.
>
> Rick
>
> On Sat, May 18, 2024 at 11:55 AM Mike Cowlishaw 
> wrote:
>
>>
>>
>>
>>
>> With a bit more info from the ISP .. I think I can solve this; so for
>> now, no need for anyone else to spend time on this!
>>
>>
>>
>> Well, I was wrong, but am homing in on the problem using a modified
>> rxftp.cls (rxftpx.cls).
>>
>> A quick question: how do I 'refresh' a class .. that is, have ooRexx use
>> a modified version after I have made an experimental change?
>>
>> At present, if I edit the .cls file the next time I use the Rexx program
>> that requires it the old version continues to be used (until I reboot
>> Windows, in which case the change takes effect).
>>
>> Q:  So .. *how do I get ooRexx to use the modified .cls file without
>> rebooting Windows*?
>>
>> Mike
>> ___
>> 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

Re: [Oorexx-devel] Status of RxFTP

[Rick McGuire]

are you calling the program using your custom command shell? I suspect that
might be the problem. Otherwise it should be picking up the change every
time the program is run, assuming it runs in a new process.

Rick

On Sat, May 18, 2024 at 11:55 AM Mike Cowlishaw  wrote:

>
>
>
>
> With a bit more info from the ISP .. I think I can solve this; so for now,
> no need for anyone else to spend time on this!
>
>
>
> Well, I was wrong, but am homing in on the problem using a modified
> rxftp.cls (rxftpx.cls).
>
> A quick question: how do I 'refresh' a class .. that is, have ooRexx use a
> modified version after I have made an experimental change?
>
> At present, if I edit the .cls file the next time I use the Rexx program
> that requires it the old version continues to be used (until I reboot
> Windows, in which case the change takes effect).
>
> Q:  So .. *how do I get ooRexx to use the modified .cls file without
> rebooting Windows*?
>
> Mike
> ___
> 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

Re: [Oorexx-devel] StackFrame of INTERNALLCALL within a method missing target ?

[Rick McGuire]

That is correct. The stackframe is for an internal call, so it does not
have a target object.

Rick

On Thu, Apr 25, 2024 at 6:27 AM Rony G. Flatscher 
wrote:

> While experimenting and analyzing various traces I stumbled over the
> following: if calling a label within a method the stackframes for the
> called internal routine miss the reference to the method's TARGET object
> (and therefore to the method and scope), rather the TARGET entry is set to
> .nil (which is fine for PROGRAM and ROUTINE).
>
> Here an example program calling a label in the main program (prolog) and
> calling a label from within a method:
>
> -- test INTERNALCALL's stackframestrace 
> offarr=.array~new.traceObject~collector=arr.traceObject~option='F'say 
> .context~nametrace all
> sf1=hey()trace offsaysay "stackframes:"say sf1
> line="-"~copies(79)say line
> sf2=.test~new~ohasaysay "stackframes:"say sf2say lineexithey:
>   return dumpStackFrames(.context~stackframes)
> ::class test::method ohatrace all
>   return hey()trace off  exithey:
>   return dumpStackFrames(.context~stackframes)
> ::routine dumpStackFrames
>   trace off  use arg stackframes
>
>   mb=.MutableBuffer~new
>   do counter c sf over stackFrames
>  call dumpSF mb, c, sf
>   end  return mb~string
> ::routine dumpSF
>   trace off  use strict arg mb, c, SF
>
>   crlf="0d0a"x  tab="09"x  target=sf~target
>   mb~append("... stackFrame # ", c, ": ", -
> "line=",  "[",sf~line, "]", " name=",  "[",sf~name, "]", crlf, -
> tab, "type=",  "[",sf~type, "]", " target=",  "[",target~string, 
> "] ", crlf, -
> tab, "executable~package~name=",  "[",sf~executable~package~name, 
> "]", crlf, -
> tab, "traceline=", "[", sf~traceline, "]", crlf, crlf)
>   return::routine pp
>   trace off  return "["arg(1)"]"
>
> Running it yields the following output:
>
> [R1   T1   I1   ] 9 *-* sf1=hey()
> [R1   T1   I2   ]23 *-*   hey:
> [R1   T1   I2   ]24 *-*   return 
> dumpStackFrames(.context~stackframes)
> [R1   T1   I1   ]10 *-* trace off
>
> stackframes:
> ... stackFrame # 1: line=[24] name=[HEY]
> type=[INTERNALCALL] target=[The NIL object]
> executable~package~name=[G:\test\orx\trace\bug\test_stackframe.rex]
> traceline=[24 *-*   return dumpStackFrames(.context~stackframes)]
>
> ... stackFrame # 2: line=[9] name=[G:\test\orx\trace\bug\test_stackframe.rex]
> type=[PROGRAM] target=[The NIL object]
> executable~package~name=[G:\test\orx\trace\bug\test_stackframe.rex]
> traceline=[ 9 *-* sf1=hey()]
>
>
> ---
> [R1   T1   I3G A1L1   *] 29 *-* return hey()*[R1   T1   I4G 
> A2L0] 33 *-*   hey:
> [R1   T1   I4G A2L0] 34 *-*   return 
> dumpStackFrames(.context~stackframes)*
> [R1   T1   I3G A1L0] package "G:\test\orx\trace\bug\test_stackframe.rex".
>
> stackframes:
> ... stackFrame # 1: line=[34] name=[HEY]
> type=[INTERNALCALL] *target=[The NIL object]*
> executable~package~name=[G:\test\orx\trace\bug\test_stackframe.rex]
> traceline=[34 *-*   return dumpStackFrames(.context~stackframes)]
>
> ... stackFrame # 2: line=[29] name=[OHA]
> type=[METHOD] *target=[a TEST]*
> executable~package~name=[G:\test\orx\trace\bug\test_stackframe.rex]
> traceline=[29 *-* return hey()]
>
> ... stackFrame # 3: line=[16] name=[G:\test\orx\trace\bug\test_stackframe.rex]
> type=[PROGRAM] target=[The NIL object]
> executable~package~name=[G:\test\orx\trace\bug\test_stackframe.rex]
> traceline=[16 *-* sf2=.test~new~oha]
>
>
> ---
>
> The call to the label "hey" within the method reveals in full format that
> the attributepool id gets changed from "A1" ("a TEST" target) to "A2" ("The
> NIL object").
>
> Shouldn't the TARGET entry of called labels/internal routines within a
> method supply the reference to the context object ("a TEST") rather than
> .nil ("The NIL object")?
>
> ---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

Re: [Oorexx-devel] How IntegerZero is GC protected?

[Rick McGuire]

On Mon, Apr 8, 2024 at 11:33 AM Jean Louis Faucher 
wrote:

> Thanks!
>
> Returns an instance from the integer cache maintained by the
> RexxIntegerClass object. These are all marked by the live() method on the
> object, so RexxMemory doesn't need to do anything special.
>
>
> I never realised that the RexxInteger has a (what? metaclass?) different
> from RexxClass.…
> And apparently, it’s the only class to be like that.
>

That's because it has some additional static fields that need to be marked
for garbage collection.



>
> My notes:
>
> All classes declare they class using CLASS_CREATE
> except RexxInteger and NumberString which use CLASS_CREATE_SPECIAL
> and except RexxClass, probably for bootstrap.
> CLASS_CREATE_SPECIAL(NumberString, "String", RexxClass);
> CLASS_CREATE_SPECIAL(Integer,  "String", *RexxIntegerClass*);
>
> RexxClass *NumberString::classInstance = OREF_NULL;
> *RexxIntegerClass* *RexxInteger::classInstance = OREF_NULL;
>

The  NumberString and Integer classes are special optimizations for doing
arithmetic. The instances masquerade as string objects, but from an ooRexx
user standpoint, they don't exist.

>
>
> Only the file IntegerClass.cpp has 2 live methods:
> void RexxInteger::live(size_t liveMark)
> void RexxIntegerClass::live(size_t liveMark)
>

That's because it has additional marking to do. NumberString has no such
requirement, so it can be created from a standard Class instance.

>
>
> I noticed that all the class are doing
> memory_mark(objectVariables);
> instead of doing
> RexxObject::live(liveMark)
>
> This is aligned with the comment in ObjectClass.cpp
>  * Other exported classes that inherit from Object are
>  * also expected to mark this field.
> but to not forget if other attributes are added to RexxObject in the
> future.
>
> ___
> 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

Re: [Oorexx-devel] How IntegerZero is GC protected?

[Rick McGuire]

On Mon, Apr 8, 2024 at 8:14 AM Jean Louis Faucher 
wrote:

> RexxMemory.cpp
> IntegerZero   = new_integer(0);
> IntegerOne= new_integer(1);
> ...
>
> Looking at RexxMemory::live, I don’t see what is marking IntegerZero.
>
> Other global static variables like TheTrueObject  or nullPointer are put
> in a collection.
> addToEnvironment("TRUE", TheTrueObject);
> addToSystem("NULLPOINTER", TheNullPointer);
> and protected:
> memory_mark(environment);
> memory_mark(system);
>
>
> Side question, out of curiosity:
> // Create some special Rexx objects.
> TheTrueObject  = new RexxInteger(1);
> TheFalseObject = new RexxInteger(0);
> With these assignments, we have TheTrueObject <> IntegerOne, right?
> Why not assigning IntegerZero, IntegerOne?
>

There is one complication with trying to do that. The TRUE and FALSE
objects are part of the saved image, while the values in the integer
allocation class are not saved in the image and are recreated as part of
the image load time.

Rick



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

Re: [Oorexx-devel] How IntegerZero is GC protected?

[Rick McGuire]

On Mon, Apr 8, 2024 at 8:14 AM Jean Louis Faucher 
wrote:

> RexxMemory.cpp
> IntegerZero   = new_integer(0);
> IntegerOne= new_integer(1);
> ...
>
> Looking at RexxMemory::live, I don’t see what is marking IntegerZero.
>

This is a good question, and the answer is not particularly obvious! It
took me a little while to figure this out. The assignment

   IntegerZero = new_integer(0);

Returns an instance from the integer cache maintained by the
RexxIntegerClass object. These are all marked by the live() method on the
object, so RexxMemory doesn't need to do anything special.


>
> Other global static variables like TheTrueObject  or nullPointer are put
> in a collection.
> addToEnvironment("TRUE", TheTrueObject);
> addToSystem("NULLPOINTER", TheNullPointer);
> and protected:
> memory_mark(environment);
> memory_mark(system);
>
>
> Side question, out of curiosity:
> // Create some special Rexx objects.
> TheTrueObject  = new RexxInteger(1);
> TheFalseObject = new RexxInteger(0);
> With these assignments, we have TheTrueObject <> IntegerOne, right?
> Why not assigning IntegerZero, IntegerOne?
>

Six of one, half dozen of another. It could easily be done that way. Not
sure there's any real benefit in doing so. What might be better would be to
remove the static variables from IntegerClass and change the defines to
directly address the cache entries in RexxIntegerClass.

Rick


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

Re: [Oorexx-devel] Working with TraceObjects, maybe adding OBJECT, removing OBJECTID, and adding STACKFRAME?

[Rick McGuire]

I’m thinking it might make sense to move the lock number to the stack frame
too.

Rick

On Mon, Apr 8, 2024 at 7:06 AM Rony G. Flatscher 
wrote:

> On 03.04.2024 09:26, Chip Davis wrote:
> > Seems more Rexx-ish, unless its specification might conflict with a
> future usage of the term in
> > that context.
> > -Chip-
> >
> > On 4/2/2024 4:19 PM, Rony wrote:
> >> Another question: offline I got the suggestion to change the NR entry
> in TraceObject to NUMBER.
> >> What do you think?
>
> The entry has been renamed from "NR" to "NUMBER".
>
> The TraceObject entries "OBJECT" and "SCOPE" have been removed as those
> values can be retrieved from
> the "STACKFRAME" entry.
>
> The documentation and the test case has been updated accordingly.
>
> ---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

Re: [Oorexx-devel] Update with further information ... (Re: Anyone with a more uptodate debugger? (Re: Segmentation faults in environmentEntries.testGroup

[Rick McGuire]

The symptoms suggest a garbage collection problem during the copying of the
behaviour object during the setmethod calls. That probably requires a few
protected objects to be added. However, this is seriously using a sledge
hammer to implement something that can be done much more simply. Because
all of the things that need to be done during a setmethod call, this is a
very expensive operation and should not typically be used for something
that might be done repeatedly, particularly on a object that is part of the
saved image, which adds yet another layer of complication to the garbage
collection. Here is a much simpler and lower cost way to do the same thing
using the RUN() method to invoke the alternate formatter.

Rick



On Fri, Apr 5, 2024 at 8:26 AM Rony G. Flatscher 
wrote:

> Thankfully Jean Louis was able to reproduce the crash and was able to
> trace and to analyze the problem further:
>
> I can reproduce the crash under Windows ARM, same call stack as you.
>
> The data breakpoint triggers 2 times, but it's a normal situation.
> It's because of
>   .TraceObject~setMakeString(.resources~myMakeString)
>   .TraceObject~unsetMakeString   -- reset (uses default implementation)
> In both cases, a copy of the behaviour is assigned for this = RexxClass
> "TraceObject"
>
>
> > rexx.dll!RexxObject::defineInstanceMethod(RexxString * msgname,
> MethodClass * methobj, RexxClass * scope) Line 2310 C++
> {
> ...
> // copy primitive behaviour object and define the method, a
> copy is made to
> // ensure that we don't update the behaviour of any other
> object, since they
> // may have been sharing the mvd.
> setField(behaviour, (RexxBehaviour *)behaviour->copy());
> ...
> }
>
>
> > rexx.dll!RexxObject::deleteInstanceMethod(RexxString * msgname) Line
> 2335 C++
> {
> ...
> // copy primitive behaviour object and define the method, a
> copy is made to
> // ensure that we don't update the behaviour of any other
> object, since they
> // may have been sharing the mvd.
> setField(behaviour, (RexxBehaviour *)behaviour->copy());
> ...
> }
>
>
> I still don't know the root cause of the crash.
> I protected buffer in RexxActivation::traceSourceString but the crash
> still occurs.
>
> After the crash, I noticed that the attribute owningClass of the behaviour
> is NULL, which is not normal.
> I put a data breakpoint on owningClass but it doesnt trigger.
>
> But good news:
> If I put in comment the setMakeString & unsetMakeString, no more crash
> (well… I tested only once, maybe I was lucky)
>
> *[rgf: indeed, commenting out the setMakeString and unsetMakeString tests
> in TRACE_TraceObject.testGroup makes the test suite pass without a crash
> repeatedly]*
>
> So there is maybe something to investigate around the impacts of this
> assignement of behaviour->copy()
> ... cut ...
>
> Any idea what the problem might be and how to fix it?
>
> ---rony
>
> P.S.: Thinking of notable things in this context:
>
>- setMethod/unsetMethod in this case gets applied to a class object
>- TraceObject subclasses StringTable which in native code subclasses
>StringHashCollection
>
>
> On 04.04.2024 19:04, Rony G. Flatscher wrote:
>
> Am using an almost ten year old version of MVS (Microsfot Visual Studio),
> which was bought (but due to lack of money has not been updated by buying
> an update, newer version).
>
> It seems that I am not able to define a data break point with it for the
> TraceObject RexxClass object successfully. MVS in the breakpoint window
> seems to not be able to allow for setting a data breakpoint at
> "RexxClass->RexxObject->RexxInternalObject->behaviour->methodDictionary" to
> learn from where in the ooRexx runtime this area gets overwritten.
>
> Therefore, if anyone has newer debugging means and is able to recreate the
> crash, then requesting help to debug this strange situation (please see the
> call stack below, the top record is not always shown, the crash indicates
> that behaviour->methodDictionary is NULL, yet the class object got
> successfully used many times before in the test suite)!
>
> Again, if the crash occurs then only after running the test suite with
> "rexx testOORexx.rex -s -U" from "test/trunk" in
> "test\trunk\ooRexx\base\runtime.objects\environmentEntries.testGroup".
> Running that test group standalone does not crash here.
>
> Any help highly appreciated!
>
> ---rony
>
>
>
> On 03.04.2024 17:29, Rony G. Flatscher wrote:
>
> On 03.04.2024 16:25, ooRexx wrote:
>
> It seems we currently have ALL platforms failing this test, can the person
> (Rony?) who committed lately check if there was a side-effect of the
> changes and/or amend the test to the new behaviour.
>
> Executing .../ooRexx/base/runtime.objects/environmentEntries.testGroup
> /tmp/jenkins3639803152023253797.sh: line 15: 26971 Segmentation fault
>  (core 

Re: [Oorexx-devel] Method's "scope" method and TRACE's ">I>" information

[Rick McGuire]

On Wed, Mar 27, 2024 at 9:33 AM Rony G. Flatscher 
wrote:

> On 27.03.2024 14:16, Rick McGuire wrote:
>
> The scope is not the variable pool that is used, it is rather the index
> used to look up the appropriate variable pool in the object instance. The
> results you are showing are the correct one. Also consider the case of two
> instances of the same class. The scope in question will be the same in both
> instances, but the set of variables that are guarded will be different.
> Also note that the scope of methods that have been dynamically added to an
> object instance will show up as .Nil. Again, that is the index that is used
> to look up the appropriate variable pool.
>
> Thank you for the explanation!
>
> Would it be possible to determine whether a method instance got assigned
> as a class method, maybe adding some method like isClassMethod? Maybe from
> within a method something like ".context~executable~isClassMethod"
>

There is nothing special that makes a method a "class method". They are all
just methods. The identity of the object the method is running is the only
difference. The only appropriate test would be "self~isa(.Class)',

 Rick

> ---rony
>
>
> On Wed, Mar 27, 2024 at 9:10 AM Rony G. Flatscher 
> wrote:
>
>> Consider the following short program that defines a class and an instance
>> method and uses them:
>>
>> .TraceObject~option='N'
>> .test~clzHi-- class method will be invoked
>> .test~new~hi   -- instance method will be invoked
>>
>> ::class test
>> ::method clzHi class
>>   say self": clzHi, scope:" .context~executable~scope
>> ::method hi
>>   say self": Hi,scope:" .context~executable~scope
>>
>> ::options trace all
>>
>> Running it yields the following output:
>>
>>  1 *-* .TraceObject~option='N'
>>  2 *-* .test~clzHi-- class method will be invoked
>>   * >I> Method "CLZHI" with scope "TEST" in package 
>> "G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
>>  7 *-* say self": clzHi, scope:" .context~executable~scope
>> The TEST class: clzHi, scope: The TEST class
>>  3 *-* .test~new~hi   -- instance method will be invoked
>>   * >I> Method "HI" with scope "TEST" in package 
>> "G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
>>  9 *-* say self": Hi,scope:" .context~executable~scope
>> a TEST: Hi,scope: The TEST class
>>
>> The ">I>" trace line hints that both methods share the same scope "TEST"
>> which is not the case as the class method and the instance method should
>> have different scopes, which is also indicated by the following variant
>> (full debug information):
>>
>> .TraceObject~option='*F*'
>> .test~clzHi-- class method will be invoked
>> .test~new~hi   -- instance method will be invoked
>>
>> ::class test
>> ::method clzHi class
>>   say self": clzHi, scope:" .context~executable~scope
>> ::method hi
>>   say self": Hi,scope:" .context~executable~scope
>>
>> ::options trace all
>>
>> which yields the following output:
>>
>>  1 *-* .TraceObject~option='F'
>> [R1   T1   I1   ] 2 *-* .test~clzHi-- class method 
>> will be invoked
>> [R1   T1   I2G *A1*L0]*>I> Method "CLZHI" with scope 
>> "TEST" in package "G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
>> [R1   T1   I2G *A1*L1   *]  7 *-* say self": clzHi, scope:" 
>> .context~executable~scope
>> The TEST class: clzHi, scope: The TEST class
>> [R1   T1   I1   ] 3 *-* .test~new~hi   -- instance 
>> method will be invoked
>> [R1   T1   I3G *A2*L0]   * >I> Method "HI" with scope "TEST" 
>> in package "G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
>> [R1   T1   I3G *A2*L1   *]  9 *-* say self": Hi,scope:" 
>> .context~executable~scope
>> a TEST: Hi,scope: The TEST class
>>
>> As can be seen the attribute (object variable) pool is different as the
>> scope is really different ("A1" versus "A2").
>>
>> Method's scope() method returns the same class object. The TRACE ">I>"
>> output also does not allow for differentiating between the two scopes.
>>
>> Maybe the ">I>" output could add something like '... scope "TEST" *at
>> the class level *...' in the case of a class method?
>>
>> Also, it would be helpful to learn whether from a method object (if
>> .context~executable~isA(.method) then...) whether its scope is at the class
>> level (the method is a class method) or at the instance level. Maybe some
>> method isClassMethod or so?
>>
>> Would that be a feasible extension?
>>
>> ---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

Re: [Oorexx-devel] Method's "scope" method and TRACE's ">I>" information

[Rick McGuire]

I also want to point out this was something I pointed out previously when I
said that the lock count was not a very useful piece of information in the
original trace proposal. What is really needed is the combination of
"object instance (perhaps the identity hash)" + "method scope (to identify
the variable pool in question)" + "the lock count for the activity".

That will uniquely identify what the scope lock situation is.

Rick

On Wed, Mar 27, 2024 at 9:10 AM Rony G. Flatscher 
wrote:

> Consider the following short program that defines a class and an instance
> method and uses them:
>
> .TraceObject~option='N'
> .test~clzHi-- class method will be invoked
> .test~new~hi   -- instance method will be invoked
>
> ::class test
> ::method clzHi class
>   say self": clzHi, scope:" .context~executable~scope
> ::method hi
>   say self": Hi,scope:" .context~executable~scope
>
> ::options trace all
>
> Running it yields the following output:
>
>  1 *-* .TraceObject~option='N'
>  2 *-* .test~clzHi-- class method will be invoked
>   * >I> Method "CLZHI" with scope "TEST" in package 
> "G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
>  7 *-* say self": clzHi, scope:" .context~executable~scope
> The TEST class: clzHi, scope: The TEST class
>  3 *-* .test~new~hi   -- instance method will be invoked
>   * >I> Method "HI" with scope "TEST" in package 
> "G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
>  9 *-* say self": Hi,scope:" .context~executable~scope
> a TEST: Hi,scope: The TEST class
>
> The ">I>" trace line hints that both methods share the same scope "TEST"
> which is not the case as the class method and the instance method should
> have different scopes, which is also indicated by the following variant
> (full debug information):
>
> .TraceObject~option='*F*'
> .test~clzHi-- class method will be invoked
> .test~new~hi   -- instance method will be invoked
>
> ::class test
> ::method clzHi class
>   say self": clzHi, scope:" .context~executable~scope
> ::method hi
>   say self": Hi,scope:" .context~executable~scope
>
> ::options trace all
>
> which yields the following output:
>
>  1 *-* .TraceObject~option='F'
> [R1   T1   I1   ] 2 *-* .test~clzHi-- class method 
> will be invoked
> [R1   T1   I2G *A1*L0]*>I> Method "CLZHI" with scope 
> "TEST" in package "G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
> [R1   T1   I2G *A1*L1   *]  7 *-* say self": clzHi, scope:" 
> .context~executable~scope
> The TEST class: clzHi, scope: The TEST class
> [R1   T1   I1   ] 3 *-* .test~new~hi   -- instance method 
> will be invoked
> [R1   T1   I3G *A2*L0]   * >I> Method "HI" with scope "TEST" 
> in package "G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
> [R1   T1   I3G *A2*L1   *]  9 *-* say self": Hi,scope:" 
> .context~executable~scope
> a TEST: Hi,scope: The TEST class
>
> As can be seen the attribute (object variable) pool is different as the
> scope is really different ("A1" versus "A2").
>
> Method's scope() method returns the same class object. The TRACE ">I>"
> output also does not allow for differentiating between the two scopes.
>
> Maybe the ">I>" output could add something like '... scope "TEST" *at the
> class level *...' in the case of a class method?
>
> Also, it would be helpful to learn whether from a method object (if
> .context~executable~isA(.method) then...) whether its scope is at the class
> level (the method is a class method) or at the instance level. Maybe some
> method isClassMethod or so?
>
> Would that be a feasible extension?
>
> ---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

Re: [Oorexx-devel] Method's "scope" method and TRACE's ">I>" information

[Rick McGuire]

The scope is not the variable pool that is used, it is rather the index
used to look up the appropriate variable pool in the object instance. The
results you are showing are the correct one. Also consider the case of two
instances of the same class. The scope in question will be the same in both
instances, but the set of variables that are guarded will be different.
Also note that the scope of methods that have been dynamically added to an
object instance will show up as .Nil. Again, that is the index that is used
to look up the appropriate variable pool.

Rick

On Wed, Mar 27, 2024 at 9:10 AM Rony G. Flatscher 
wrote:

> Consider the following short program that defines a class and an instance
> method and uses them:
>
> .TraceObject~option='N'
> .test~clzHi-- class method will be invoked
> .test~new~hi   -- instance method will be invoked
>
> ::class test
> ::method clzHi class
>   say self": clzHi, scope:" .context~executable~scope
> ::method hi
>   say self": Hi,scope:" .context~executable~scope
>
> ::options trace all
>
> Running it yields the following output:
>
>  1 *-* .TraceObject~option='N'
>  2 *-* .test~clzHi-- class method will be invoked
>   * >I> Method "CLZHI" with scope "TEST" in package 
> "G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
>  7 *-* say self": clzHi, scope:" .context~executable~scope
> The TEST class: clzHi, scope: The TEST class
>  3 *-* .test~new~hi   -- instance method will be invoked
>   * >I> Method "HI" with scope "TEST" in package 
> "G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
>  9 *-* say self": Hi,scope:" .context~executable~scope
> a TEST: Hi,scope: The TEST class
>
> The ">I>" trace line hints that both methods share the same scope "TEST"
> which is not the case as the class method and the instance method should
> have different scopes, which is also indicated by the following variant
> (full debug information):
>
> .TraceObject~option='*F*'
> .test~clzHi-- class method will be invoked
> .test~new~hi   -- instance method will be invoked
>
> ::class test
> ::method clzHi class
>   say self": clzHi, scope:" .context~executable~scope
> ::method hi
>   say self": Hi,scope:" .context~executable~scope
>
> ::options trace all
>
> which yields the following output:
>
>  1 *-* .TraceObject~option='F'
> [R1   T1   I1   ] 2 *-* .test~clzHi-- class method 
> will be invoked
> [R1   T1   I2G *A1*L0]*>I> Method "CLZHI" with scope 
> "TEST" in package "G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
> [R1   T1   I2G *A1*L1   *]  7 *-* say self": clzHi, scope:" 
> .context~executable~scope
> The TEST class: clzHi, scope: The TEST class
> [R1   T1   I1   ] 3 *-* .test~new~hi   -- instance method 
> will be invoked
> [R1   T1   I3G *A2*L0]   * >I> Method "HI" with scope "TEST" 
> in package "G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
> [R1   T1   I3G *A2*L1   *]  9 *-* say self": Hi,scope:" 
> .context~executable~scope
> a TEST: Hi,scope: The TEST class
>
> As can be seen the attribute (object variable) pool is different as the
> scope is really different ("A1" versus "A2").
>
> Method's scope() method returns the same class object. The TRACE ">I>"
> output also does not allow for differentiating between the two scopes.
>
> Maybe the ">I>" output could add something like '... scope "TEST" *at the
> class level *...' in the case of a class method?
>
> Also, it would be helpful to learn whether from a method object (if
> .context~executable~isA(.method) then...) whether its scope is at the class
> level (the method is a class method) or at the instance level. Maybe some
> method isClassMethod or so?
>
> Would that be a feasible extension?
>
> ---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

Re: [Oorexx-devel] Ad "scope": how to discover it at runtime?

[Rick McGuire]

if .context~executable~isa(.Method) then say .context~executable~scope

On Sun, Mar 24, 2024 at 10:32 AM Rony G. Flatscher 
wrote:

> While working on the multithreaded related parts it has become clear that
> the term "scope" is very
> important, such that I linked the word "scope" to the respective section
> that describes it.
>
> Also, looking at questions and answers in the RexxLA mailing list related
> to multithreading "scope"
> turns out to not be well understood, if at all. With the interlinking and
> additional explanations
> this may have been improved a little bit.
>
> However, there is one omission IMHO for ooRexx. ooRexx being a dynamic
> language should allow for
> introspection/reflection (which it does in many different aspects) of the
> current scope, such that
> one can learn within a method to which scope it belongs to, got defined
> for. It would help the
> ooRexx programmer to experiment with and to determine the scope of a
> method at runtime.
>
> To the best of my knowledge it is not possible to get at the method's
> scope at runtime.
>
> Currently, within a method we can get at the object that invoked it (self)
> and its immediate
> superclass (super), but not at the scope (class object) that the method
> belongs to. As a method may
> be used in different scopes depending on the context, maybe RexxContext
> would be a class where a new
> method "scope" could be added to return the "scope": for routines it would
> return .nil, for methods
> the class object that defines the scope of the method, and .nil for
> floating methods. So the idea
> would be that ".context~scope" would return it.
>
> Would that be a sensible solution or are there better possibilities?
>
> Maybe adding an entry "SCOPE" to the TraceObject instance and supplying
> the value that gets used for
> the ">I>" trace line?
>
> What do you think?
>
> ---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

Re: [Oorexx-devel] RexxDateTime is internal, how to use its information for a .DateTime object to be stored in a StringTable?

[Rick McGuire]

Um, .DateTime~new does this. This is how the time stamp used by the
date/time functions is managed such that there is consistencies across all
terms used in expressions.

Rick

On Thu, Jan 25, 2024 at 8:52 AM Rony G. Flatscher 
wrote:

> Experimenting with tracing and one idea that came up with was to also
> supply Activation::getTime()
> which is an internal interpreter/classes/support/RexxDateTime object and
> as such cannot be used
> directly as an argument to put().
>
> The attempt is to create a TIMESTAMP entry in a StringTable making the
> Activation::getTime()
> information available as a .DateTime object to the Rexx programmer.
>
> How would one become able to achieve that?
>
> ---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

Re: [Oorexx-devel] An ooRexx implementation of the TraceObject class

[Rick McGuire]

The part about the variable dictionary doesn't make any sense at all. The
context where the line is being traced doesn't really provide any useful
information. The guard start is a combination of the guard state of all the
stack frames for a given activity. Since methods are guarded by default,
for any call stack, there are going to be many frames in a guarded state on
potentially many objects and scopes, including nesting. This does NOT
belong as part of tracing. It seriously clutters stuff up and doesn't
really provide information that is needed on a statement-by-statement
basis.

Rick

On Mon, Jan 22, 2024 at 11:32 AM Rony G. Flatscher 
wrote:

> Here an ooRexx implementation of the proposed TraceObject class in today's
> "Proposal for multithreaded trace prefix" class:
>
> /* = 
> */::class "TraceObject" subclass StringTable public
> /* - 
> */::attribute mtPrefix class -- if .true causes the mtPrefix to 
> be created/* 
> - 
> */::method MAKESTRING
>   if self~class~mtPrefix<>.true then   -- do not show multithreaded prefix
>  return self["TRACELINE"]  -- return standard trace line  mb = 
> .MutableBuffer~new  -- for performance reasons  mb~append("[")
>   mb~append("R", adjLeft(self["INSTANCE"]  ,3), " ")  -- R_exx interpreter 
> instance  mb~append("T", adjLeft(self["THREAD"],3), " ")  -- 
> T_hread/activity  mb~append("I", adjLeft(self["INVOCATION"],3) )  -- 
> I_nvocation/activation  vd=self["VARIABLEDICTIONARY"]
>   if vd<>0 then  -- an object's variable dictionary in hand, we are in a 
> method  do
>  mb~append(" ")
>  mb~append(self["ISGUARDED"]~?("G","U") , " ")  -- G_uarded or 
> U_unguarded mb~append("V", adjLeft(vd   ,3), " ")  -- 
> V_ariable dictionary pool mb~append("L", adjLeft(self["LOCKCOUNT"],3), " 
> ")  -- L ... lock reserve count mb~append(self["ISLOCKED"]~?("*"," "))  
> -- asterisk to indicate holding object lock (can execute)  end
>   mb~append("] ", self["TRACELINE"])
>   return mb~string   -- return trace line with mtPrefixadjLeft: procedure   
> -- left adjust, but make sure we show all chars  use arg value, width
>   if value~length>=width then -- no left adjustment return value
>   return value~left(width)-- left adjust with given width
>
> ---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

Re: [Oorexx-devel] FindClass in ThreadContext

[Rick McGuire]

In the case of oodialog, the best approach would be to cache a reference to
the package in a global location or in a control block associated with the
event that triggers the need to attach a new thread.

Rick

On Sat, Jan 13, 2024 at 1:10 PM Erich Steinböck 
wrote:

> When a native function package like ooDialog has call-backs which
> re-attach through AttachThread() the call-back has just a ThreadContext
> available.  This makes it difficult for the call-back to search for its own
> classes loaded with a ::requires.
>
> FindClass() is available in a ThreadContext but will only search the REXX
> package.
> FindContextClass() is unavailable for a ThreadContext.
> FindPackageClass(), GetPackagePublicClasses() or similar require a Package
> object to search.
> ooDialog used to re-load the full ooDialog.cls with LoadPackage which I
> think is a bit desperate.
>
> Is there a decent way to access own classes from a ThreadContext?
>
> ___
> 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

Re: [Oorexx-devel] Question ad rexx.img

[Rick McGuire]

On Sun, Jan 7, 2024 at 1:21 PM Rony G. Flatscher 
wrote:

> Is rexx.img dependent on the architecture and bitness?
>

Yes, it contains LOTS of binary data that depends on the bitness of the
architecture. There are some bits that might even be dependent on the
compiler used to compile the interpreter that created the image file.


>
> With other words: can a rexx.img be used at the same time for arm64 and
> amd64 (Intel)?
>

Not a chance.


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

Re: [Oorexx-devel] Failing Test

[Rick McGuire]

The problem with the original line is that because of the reply statement,
the error did not get propagated back to the calling framework, it just
terminated the thread. Because that did not get trapped and there were no
assertion failures, it was marked as successful. Correcting the typo
eliminated the error, which caused the assertion failure. From the
assertion information, it's obvious that the method activation line in the
trace did not get removed, which caused the mismatch on the assertion.

Rick

On Sat, Jul 22, 2023 at 9:38 AM Jeremy Nicoll 
wrote:

> On Sat, 22 Jul 2023, at 14:14, ooRexx wrote:
> > Hi Jeremy,
> >
> > In the normal case the testing framework DO catch syntax errors and
> > reports them, but It can be tweaked for special tests
>
> That's fascinating.  I didn't stop to think about how one would design a
> framework intended to spot errors in ooREXX's internal error handling
> which - I think - is what you're saying this error occurred in?
>
> --
> Jeremy Nicoll - my opinions are my own.
>
>
> ___
> 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] Fwd: Build failed in Jenkins: ooRexx-CentOS9-build #123

[Rick McGuire]

Okay, I'm at a loss as to why this is failing. What is the config.h file
that is generated by the build? Is HAVE_PTHREAD_GETATTR_NP getting set
properly? For some reason, it's trying to compile with the MacOS version of
the code and I don't understand why.

Rick

-- Forwarded message -
From: 
Date: Tue, Jul 4, 2023 at 7:10 PM
Subject: Build failed in Jenkins: ooRexx-CentOS9-build #123
To: , 


See <
https://build.oorexx.org/job/ooRexx-CentOS9-build/123/display/redirect?page=changes
>

Changes:

[bigrixx] [#1911] The interpreter is using too small of a stacksize.
Give the build a kick to get more debugging information

[bigrixx] [#1911] The interpreter is using too small of a stacksize.
Make sure config.h is included in the SysActivity file.


--
[...truncated 112.04 KB...]
  805 | char stringData[4];  // Start of the string
data part
  |  ^~
<
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/StringClassSub.cpp>:462:19:
warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  462 | *string++ = *end--;
  | ~~^~~~
In file included from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/support/HashContents.hpp
>:47,
 from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/support/HashCollection.hpp
>:47,
 from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/TableClass.hpp
>:47,
 from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/runtime/RexxCore.h
>:337,
 from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/StringClassSub.cpp
>:44:
<
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/StringClass.hpp>:805:10:
note: at offset 25 into destination object ‘RexxString::stringData’ of size
4
  805 | char stringData[4];  // Start of the string
data part
  |  ^~
<
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/StringClassSub.cpp>:462:19:
warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  462 | *string++ = *end--;
  | ~~^~~~
In file included from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/support/HashContents.hpp
>:47,
 from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/support/HashCollection.hpp
>:47,
 from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/TableClass.hpp
>:47,
 from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/runtime/RexxCore.h
>:337,
 from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/StringClassSub.cpp
>:44:
<
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/StringClass.hpp>:805:10:
note: at offset 26 into destination object ‘RexxString::stringData’ of size
4
  805 | char stringData[4];  // Start of the string
data part
  |  ^~
<
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/StringClassSub.cpp>:462:19:
warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  462 | *string++ = *end--;
  | ~~^~~~
In file included from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/support/HashContents.hpp
>:47,
 from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/support/HashCollection.hpp
>:47,
 from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/TableClass.hpp
>:47,
 from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/runtime/RexxCore.h
>:337,
 from <
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/StringClassSub.cpp
>:44:
<
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/StringClass.hpp>:805:10:
note: at offset 27 into destination object ‘RexxString::stringData’ of size
4
  805 | char stringData[4];  // Start of the string
data part
  |  ^~
<
https://build.oorexx.org/job/ooRexx-CentOS9-build/ws/oorexxSVN/interpreter/classes/StringClassSub.cpp>:462:19:
warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  462 | *string++ = *end--;
  | ~~^~~~
In file included from <

Re: [Oorexx-devel] Unexpected behaviour with serial reuse of address ... with output replace stream 'streamName'

[Rick McGuire]

You are using the same stream object to process the file after each
command. After you read the first file, the stream object thinks it's at
the end-of-file and won't return anything else. You should close the stream
after each read and start with a fresh state.

Rick

On Mon, Jun 12, 2023 at 11:45 PM J Leslie Turriff 
wrote:

> Hello,
> I'm trying out the address ... with output replace stream
> 'streamName' instruction, but it doesn't behave the way I
> would expect, and there are no examples in either of the ooRexx manuals
> for other than stem and array.
>
> What I'm trying to do is issue several OS commands and capture
> each command's output using the stream option.
> The first address instruction works as expected, but successive address
> instructions return no lines.
>
> Attached are two test programs that show the problem I'm having.
>
> Perhaps I'm using stream incorrectly or inappropriately? but I
> can't tell by what is in the manuals.
>
> Leslie
> --Platform: Linux
> Distribution: openSUSE Leap 15.4 (x86_64)
> Open Object Rexx Version 5.0.0 r12583
> Build date: Dec 23 2022
> Addressing mode: 64
> ___
> 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

Re: [Oorexx-devel] [oorexx:bugs] #1897 Entry missing in Windows installer

[Rick McGuire]

On Wed, May 10, 2023 at 12:22 PM ooRexx  wrote:

> I am sorry but I have to come back to this item:
>
> What is the difference between the milestones 5.0.0, 5.0.1 and 5.1.0?

>>>
>>> That indicates which release the change is going to ship on. Since the
>>> 5.0.0 has already been released, that should never be used again. 5.0.1
>>> would be a release that will contain only bug fixes to 5.0.0. The 5.1.0
>>> release will contain new content, as well as bug fixes to 5.0.0 content.
>>> Bug fixes like this one should be applied to both the trunk and the 5.0.1
>>> branch and the 5.0.1 milestone used.
>>>
>>>
>>>
> Currently we do not have a 5.0.1 branch in SVN, so it is not possible to
> commit anything specifically to 5.0.1; all go into trunk which is then
> uploaded to 5.1.0beta on sourceforge.
>
Sigh, it looks like an important item got deleted from the release process
check list. I know I highlighted this when we were starting up. At the
point where the release candidate gets moved from branches to releases, a
copy should have been made in branches with the fix level incremented (e.g.
5.0.0 -> 5.0.1). That branch also gets the changes made to change the build
number to the matching level. The only updates allowed to that branch are
big fixes we wish to ship in a bug-fix release. No new features can be
added to this branch. It would be nice if bug fixes get applied to both
trunk and the bug fix branch at the same time, but it is not necessary. If
we choose to ship a bug-fix release, we can review all of the pending bugs
in trunk and apply the changes to the bug-fix branch as part of the release
process.



>
> Are you saying that we should have branched off a 5.0.1 from 5.0.0? Where
> should it have gone? Into
> svn.code.sf.net/p/oorexx/code-0/main/branches/5.0.1?
>
> I also looked at the revisions of all the twigs of .../oorexx/code-0/main/
> and it seems that although we froze 5.0.0 on revision 12583 there are
> commits up to revision 12601, unclear how that can happen.
>
> 5.0.0 was branched off as <…>main/releases/5.0.0 whereas 4.2 and before
> were branched off as <…>main/releases/4.2.0/trunk, is this significant in
> any way?
>

That was a mistake really. It just reflected how/where the copy was made
from.


>
> Can all changes (5.0.1 and 5.1.0) stay in trunk?
>

All changes should be made to trunk. As I mentioned earlier, it would be
nice if they would also get applied to 5.0.1, but that can be sorted out
when the decision is made to make a bug-fix release.

Rick


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

Re: [Oorexx-devel] [oorexx:bugs] #1897 Entry missing in Windows installer

[Rick McGuire]

Just upload them as is.

Rick

On Wed, May 10, 2023 at 10:02 AM ooRexx  wrote:

> Just one more question and I be gone: re #1895
> <https://sourceforge.net/p/oorexx/bugs/1895/> and the fact that 4 (vital)
> files are missing on sourceforge in the files/oorexx/5.0.0 section
>
> ReadMe.txt
> ReleaseNotes
> INSTALL.txt
> CHANGES.txt
>
> Since we cannot modify them for 5.0.0 should we (i) upload them as-is from
> r12583 or (ii) just ignore them until the next release.
>
> my preferred option would be (i) since they still contain useful albeit
> not always up-to-date information.
>
> I have started to update these files as far as I can but that will be for
> 5.0.1 or 5.1.0
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
> On 10. May 2023, at 11:45, Rick McGuire  wrote:
>
>
>
> On Wed, May 10, 2023 at 5:33 AM ooRexx  wrote:
>
>>
>> On 10. May 2023, at 11:16, Rick McGuire  wrote:
>>
>>
>>
>> On Wed, May 10, 2023 at 3:51 AM ooRexx  wrote:
>>
>>> I added the missing softlink so that Windows users can find rxsock.pdf,
>>> Is this the right way to do it on sourceforge?
>>>
>>> The status “Closed” is only set when there is a release version, right?
>>>
>>> When shall the status “Pending” be used?
>>>
>>
>> Pending should be used until the change is available in a shipped
>> release. That allows us to determine what changes are actually in a
>> release. Closed should never be used until a release containing the change
>> has shipped.
>>
>>
>>>
>>> What is the difference between the milestones 5.0.0, 5.0.1 and 5.1.0?
>>>
>>
>> That indicates which release the change is going to ship on. Since the
>> 5.0.0 has already been released, that should never be used again. 5.0.1
>> would be a release that will contain only bug fixes to 5.0.0. The 5.1.0
>> release will contain new content, as well as bug fixes to 5.0.0 content.
>> Bug fixes like this one should be applied to both the trunk and the 5.0.1
>> branch and the 5.0.1 milestone used.
>>
>>
>>>
>>> This fix solved the problem for 5.1.0Beta but the installer for 5.0.0 is
>>> still missing it. Is it ok to go in and make a retrospective build for
>>> 5.0.0 and correct it manually?
>>>
>>
>> No, it is not ok. Once 5.0.0 has shipped, no changes to that tree are
>> permitted. Fixes can only be released by spinning a 5.0.1 release.
>>
>>
>>
>>
>> Thanks for the info, makes sense. But unfortunately most people will be
>> using 5.0.0 rather than the rolling release so they will miss out on things
>> like this. I guess we need to start thinking about a 5.0.1 then.
>>
> We don't ship a new bug-fix release every time there's a change. This
> should wait until we have a significant number of them or there's a bug
> that impacts a lot of users. This is nowhere near that level.
>
>
>
>> I will change the milestone for #1894 and #1875 to 5.0.1 then.
>>
>> Re #1854 it is still ok to add missing files, like the source files to
>> 5.0.0 ?
>>
>
> I think it's ok to upload the source file archive to sourceforge and label
> it 5.0.0, but any changes (e.g. CmakeList changes) only get applied to the
> appropriate branches.
>
>
>
>>
>> /P.O.
>>
>>
>>> Any information on how the bug tracker should be used is welcome.
>>>
>>> Hälsningar/Regards/Grüsse,
>>> P.O. Jonsson
>>> oor...@jonases.se
>>>
>>>
>>>
>>> Begin forwarded message:
>>>
>>> *From: *"Per Olov Jonsson" 
>>> *Subject: **[oorexx:bugs] #1897 Entry missing in Windows installer*
>>> *Date: *10. May 2023 at 09:02:55 CEST
>>> *To: *"[oorexx:bugs] " <1...@bugs.oorexx.p.re.sourceforge.net>
>>> *Reply-To: *"[oorexx:bugs] " <1...@bugs.oorexx.p.re.sourceforge.net>
>>>
>>> - **status**: open --> accepted
>>> - **assigned_to**: Per Olov Jonsson
>>> - **Comment**:
>>>
>>> Fixed with r12676
>>>
>>>
>>>
>>> ---
>>>
>>> **[bugs:#1897] Entry missing in Windows installer**
>>>
>>> **Status:** accepted
>>> **Group:** None
>>> **Created:** Sun May 07, 2023 08:15 PM UTC by Per Olov Jonsson
>>> **Last Updated:** Sun May 07, 2023 08:15 PM UTC
>>> **Owner:** Per Olov Jonsson
>>>
>>>
>>> For Windows there is no entry referring to rxSock.cls documenta

Re: [Oorexx-devel] [oorexx:bugs] #1897 Entry missing in Windows installer

[Rick McGuire]

On Wed, May 10, 2023 at 5:33 AM ooRexx  wrote:

>
> On 10. May 2023, at 11:16, Rick McGuire  wrote:
>
>
>
> On Wed, May 10, 2023 at 3:51 AM ooRexx  wrote:
>
>> I added the missing softlink so that Windows users can find rxsock.pdf,
>> Is this the right way to do it on sourceforge?
>>
>> The status “Closed” is only set when there is a release version, right?
>>
>> When shall the status “Pending” be used?
>>
>
> Pending should be used until the change is available in a shipped release.
> That allows us to determine what changes are actually in a release. Closed
> should never be used until a release containing the change has shipped.
>
>
>>
>> What is the difference between the milestones 5.0.0, 5.0.1 and 5.1.0?
>>
>
> That indicates which release the change is going to ship on. Since the
> 5.0.0 has already been released, that should never be used again. 5.0.1
> would be a release that will contain only bug fixes to 5.0.0. The 5.1.0
> release will contain new content, as well as bug fixes to 5.0.0 content.
> Bug fixes like this one should be applied to both the trunk and the 5.0.1
> branch and the 5.0.1 milestone used.
>
>
>>
>> This fix solved the problem for 5.1.0Beta but the installer for 5.0.0 is
>> still missing it. Is it ok to go in and make a retrospective build for
>> 5.0.0 and correct it manually?
>>
>
> No, it is not ok. Once 5.0.0 has shipped, no changes to that tree are
> permitted. Fixes can only be released by spinning a 5.0.1 release.
>
>
>
>
> Thanks for the info, makes sense. But unfortunately most people will be
> using 5.0.0 rather than the rolling release so they will miss out on things
> like this. I guess we need to start thinking about a 5.0.1 then.
>
We don't ship a new bug-fix release every time there's a change. This
should wait until we have a significant number of them or there's a bug
that impacts a lot of users. This is nowhere near that level.



> I will change the milestone for #1894 and #1875 to 5.0.1 then.
>
> Re #1854 it is still ok to add missing files, like the source files to
> 5.0.0 ?
>

I think it's ok to upload the source file archive to sourceforge and label
it 5.0.0, but any changes (e.g. CmakeList changes) only get applied to the
appropriate branches.



>
> /P.O.
>
>
>> Any information on how the bug tracker should be used is welcome.
>>
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se
>>
>>
>>
>> Begin forwarded message:
>>
>> *From: *"Per Olov Jonsson" 
>> *Subject: **[oorexx:bugs] #1897 Entry missing in Windows installer*
>> *Date: *10. May 2023 at 09:02:55 CEST
>> *To: *"[oorexx:bugs] " <1...@bugs.oorexx.p.re.sourceforge.net>
>> *Reply-To: *"[oorexx:bugs] " <1...@bugs.oorexx.p.re.sourceforge.net>
>>
>> - **status**: open --> accepted
>> - **assigned_to**: Per Olov Jonsson
>> - **Comment**:
>>
>> Fixed with r12676
>>
>>
>>
>> ---
>>
>> **[bugs:#1897] Entry missing in Windows installer**
>>
>> **Status:** accepted
>> **Group:** None
>> **Created:** Sun May 07, 2023 08:15 PM UTC by Per Olov Jonsson
>> **Last Updated:** Sun May 07, 2023 08:15 PM UTC
>> **Owner:** Per Olov Jonsson
>>
>>
>> For Windows there is no entry referring to rxSock.cls documentation  in
>> the Documentation folder in the ooRexx startup menu item. RxSock.pdf exists
>> but the Windows user may not be aware of its existence since it is not in
>> the list of links in the Start Menu item for ooRexx.
>>
>> What is missing is a softlink with an appropriate name
>>
>> from
>>
>> C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Open Object
>> Rexx\Documentation
>>
>> to
>>
>> C:\Program Files\ooRexx\doc\rxsock.pdf
>>
>>
>> ---
>>
>> Sent from sourceforge.net because you indicated interest in <
>> https://sourceforge.net/p/oorexx/bugs/1897/>
>>
>>
>>
>> To unsubscribe from further messages, please visit <
>> https://sourceforge.net/auth/subscriptions/>
>>
>>
>> ___
>> 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
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Fwd: [oorexx:bugs] #1897 Entry missing in Windows installer

[Rick McGuire]

On Wed, May 10, 2023 at 3:51 AM ooRexx  wrote:

> I added the missing softlink so that Windows users can find rxsock.pdf, Is
> this the right way to do it on sourceforge?
>
> The status “Closed” is only set when there is a release version, right?
>
> When shall the status “Pending” be used?
>

Pending should be used until the change is available in a shipped release.
That allows us to determine what changes are actually in a release. Closed
should never be used until a release containing the change has shipped.


>
> What is the difference between the milestones 5.0.0, 5.0.1 and 5.1.0?
>

That indicates which release the change is going to ship on. Since the
5.0.0 has already been released, that should never be used again. 5.0.1
would be a release that will contain only bug fixes to 5.0.0. The 5.1.0
release will contain new content, as well as bug fixes to 5.0.0 content.
Bug fixes like this one should be applied to both the trunk and the 5.0.1
branch and the 5.0.1 milestone used.


>
> This fix solved the problem for 5.1.0Beta but the installer for 5.0.0 is
> still missing it. Is it ok to go in and make a retrospective build for
> 5.0.0 and correct it manually?
>

No, it is not ok. Once 5.0.0 has shipped, no changes to that tree are
permitted. Fixes can only be released by spinning a 5.0.1 release.



>
> Any information on how the bug tracker should be used is welcome.
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
> Begin forwarded message:
>
> *From: *"Per Olov Jonsson" 
> *Subject: **[oorexx:bugs] #1897 Entry missing in Windows installer*
> *Date: *10. May 2023 at 09:02:55 CEST
> *To: *"[oorexx:bugs] " <1...@bugs.oorexx.p.re.sourceforge.net>
> *Reply-To: *"[oorexx:bugs] " <1...@bugs.oorexx.p.re.sourceforge.net>
>
> - **status**: open --> accepted
> - **assigned_to**: Per Olov Jonsson
> - **Comment**:
>
> Fixed with r12676
>
>
>
> ---
>
> **[bugs:#1897] Entry missing in Windows installer**
>
> **Status:** accepted
> **Group:** None
> **Created:** Sun May 07, 2023 08:15 PM UTC by Per Olov Jonsson
> **Last Updated:** Sun May 07, 2023 08:15 PM UTC
> **Owner:** Per Olov Jonsson
>
>
> For Windows there is no entry referring to rxSock.cls documentation  in
> the Documentation folder in the ooRexx startup menu item. RxSock.pdf exists
> but the Windows user may not be aware of its existence since it is not in
> the list of links in the Start Menu item for ooRexx.
>
> What is missing is a softlink with an appropriate name
>
> from
>
> C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Open Object
> Rexx\Documentation
>
> to
>
> C:\Program Files\ooRexx\doc\rxsock.pdf
>
>
> ---
>
> Sent from sourceforge.net because you indicated interest in <
> https://sourceforge.net/p/oorexx/bugs/1897/>
>
>
>
> To unsubscribe from further messages, please visit <
> https://sourceforge.net/auth/subscriptions/>
>
>
> ___
> 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

Re: [Oorexx-devel] Conventions

[Rick McGuire]

Gil, the setting he's proposing to change only affects the names of the
built packages, nothing else.

Rick

On Fri, Apr 14, 2023 at 9:03 AM Gilbert Barmwater 
wrote:

> I think this needs more discussion before making, what seems on the
> surface to be, a "trivial" change.
>
> When RexxLA received the source for Object Rexx from IBM, there was
> quite a bit of discussion on what the project should be called with the
> eventual decision being "ooRexx".  I'm sure the archives have the pro's
> and con's but there were reasons for the choice. It was definitely NOT
> arbitrary.
>
> I understand the need for all lower case for *nix systems but isn't the
> "build" that one downloads from the "Files" section of Source Forge just
> a "container"?  Couldn't the "contents" have all lower case names and
> wouldn't that meet the *nix requirements?  I realize I'm showing my
> ignorance here so please help me understand if this is a "must" or just
> a "preference".
>
> Gil
>
> On 4/14/2023 7:27 AM, Rony G. Flatscher wrote:
> > On 14.04.2023 09:44, P.O. Jonsson wrote:
> >> While working on creating a source package for #1854 I realized that
> >> all our artifacts starts off with ooRexx-,  in CamelFont. It comes
> >> from this line in CMakeLists.txt
> >>
> >> set(CPACK_PACKAGE_NAME "ooRexx")
> >>
> >> Since we have a requirement in the build to keep all other parts in
> >> lowercase (example -DOS_DIST=centos9 etc) this is a bit odd. I would
> >> like to change this to
> >>
> >> set(CPACK_PACKAGE_NAME "oorexx")
> >>
> >> Any objections?
> >
> > Not at all, it seems that all lowercase is the norm on Unix systems
> > and necessary for distributions. Please go for it!
> >
> > ---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

Re: [Oorexx-devel] GUARD issue

[Rick McGuire]

Looking at the code, the explanation is a little bit off. The instruction
does the following:

   set the guard state to the indicated state
   while when expresson != true
   release GUARD lock
   wait for  an expression variable to be updated.
   restore the GUARD lock to the desired state
   end

So, any time the GUARD instruction is waiting for a variable to update, it
does not hold the GUARD lock, so that other methods are able to run and
update the variables it is waiting on. Using GUARD WHEN gives permission
for the lock to be released.

I'd say the last two sentences are a bit dodgy.

Rick



On Fri, Apr 7, 2023 at 12:26 PM Erich Steinböck 
wrote:

> If in this, heavily GUARDED example m2 can start running while m1 is
> running, and later
> m1 can get back control even though m2 is running GUARDED, then how can
> any method make sure it runs with exclusive access?
>
> Am I missing something?
>
> ~~~
> c = .c~new
> c~m1
> c~m2
>
> ::class c
>
> ::method m1 guarded
>   expose a
>   guard on
>   reply
>   guard on
>   say "m1 start"
>   guard on when a = 3
>   say "m1 end"
>
> ::method m2 guarded
>   expose a
>   guard on
>   say 'm2 start'
>   do a = 1 to 5
> call SysSleep 0.2
> say "m2, a =" a
>   end
>   say "m2 end"
> ~~~
>
> gives
>
> ~~~
> m1 start
> m2 start
> m2, a = 1
> m2, a = 2
> m1 end
> m2, a = 3
> m2, a = 4
> m2, a = 5
> m2 end
> ~~~
>
> This came up when I read rexxpg how GUARD OFF WHEN is supposed to work and
> couldn't make much sense out of what it says: "if you specify "GUARD OFF
> WHEN expression," the active method keeps running until expression becomes
> true. To become true, another method must assign or drop an object variable
> that is named in expression. Whenever an object variable changes, Rexx
> reevaluates expression. If expression becomes true, GUARD is turned off,
> exclusive use of the variable pool is released, and other methods needing
> exclusive use can begin running. If expression becomes false again, GUARD
> is turned on and the active method regains exclusive use."
>
> Especially "keeps running" and the last sentence don't seem right to me.
> ___
> 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

Re: [Oorexx-devel] Higher precision time on Windows.

[Rick McGuire]

The good news is it does work. The bad news is that rxwinsys on longer
compiles if I bump the API level.

Rick

On Wed, Apr 5, 2023 at 3:23 AM Erich Steinböck 
wrote:

> Hi Rick,
> we've so far refrained from using a Windows API younger than 0600 (0600
> means no more support for XP, but Vista and above still supported).
> GetSystemTimePreciseAsFileTime is _WIN32_WINNT_WIN8 and thus would be the
> end of ooRexx support for Vista and Windows 7.
>
> It's the compile define _WIN32_WINNT=0x0600 in CMakeLists.txt that stops
> us from inadvertently introducing code with such a newer API.
>
>
> ___
> 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

Re: [Oorexx-devel] Higher precision time on Windows.

[Rick McGuire]

Ah, thanks. I was just doing an exploratory change to see if this would
work. The decision on the Win 7 implications can be made later. It was
driving me nuts that it wasn't compiling correctly!

Rick

On Wed, Apr 5, 2023 at 3:23 AM Erich Steinböck 
wrote:

> Hi Rick,
> we've so far refrained from using a Windows API younger than 0600 (0600
> means no more support for XP, but Vista and above still supported).
> GetSystemTimePreciseAsFileTime is _WIN32_WINNT_WIN8 and thus would be the
> end of ooRexx support for Vista and Windows 7.
>
> It's the compile define _WIN32_WINNT=0x0600 in CMakeLists.txt that stops
> us from inadvertently introducing code with such a newer API.
>
>
> ___
> 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

Re: [Oorexx-devel] Jenkins

[Rick McGuire]

I have never logged in to Jenkins. Don't really want to.

Rick

On Tue, Apr 4, 2023 at 4:31 PM P.O. Jonsson  wrote:

> Sorry I was OK, I have made it a bug report to save bandwidth here.
>
> I assume you can logon to Jenkins? It is much easier to check it out there.
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
>
> Am 04.04.2023 um 21:04 schrieb Rick McGuire :
>
> PO, please post the complete list of files with errors. The fix is
> correct, the error is in the test cases.
>
> Rick
>
> On Tue, Apr 4, 2023 at 2:56 PM P.O. Jonsson  wrote:
>
>> All went well and Jenkins is up again. Besides Marks M1 Mac all
>> platforms are online.
>>
>> I looked at the current projects and it seems most builds pass but ALL
>> test fail with the build from 3.4.2023. The build before that. from
>> 1.4.2023 seems to have passed on most platforms.
>>
>> On CentOS there are 59 Failures and 20 Errors, here some of them
>>
>> caselessLastpos.testGroup
>> lastpos.testGroup
>> caselessWordPos.testGroup
>> overlay.testGroup
>> String_verifyMethod.testGroup
>> String_wordposMethod.testGroup
>> String_bitorMethod.testGroup
>> bitxor.testGroup
>> caselessCompare.testGroup
>>
>> But there are more. Please review the latest commit.
>>
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se
>>
>>
>>
>>
>> Am 04.04.2023 um 15:48 schrieb P.O. Jonsson :
>>
>> I am making a 2nd attempt to replace my cable modem/router today and
>> tomorrow, so Jenkins may be unavailable for some time.
>>
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se
>>
>>
>>
>>
>> ___
>> 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
>
>
> ___
> 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

Re: [Oorexx-devel] Jenkins

[Rick McGuire]

PO, please post the complete list of files with errors. The fix is correct,
the error is in the test cases.

Rick

On Tue, Apr 4, 2023 at 2:56 PM P.O. Jonsson  wrote:

> All went well and Jenkins is up again. Besides Marks M1 Mac all
> platforms are online.
>
> I looked at the current projects and it seems most builds pass but ALL
> test fail with the build from 3.4.2023. The build before that. from
> 1.4.2023 seems to have passed on most platforms.
>
> On CentOS there are 59 Failures and 20 Errors, here some of them
>
> caselessLastpos.testGroup
> lastpos.testGroup
> caselessWordPos.testGroup
> overlay.testGroup
> String_verifyMethod.testGroup
> String_wordposMethod.testGroup
> String_bitorMethod.testGroup
> bitxor.testGroup
> caselessCompare.testGroup
>
> But there are more. Please review the latest commit.
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
>
> Am 04.04.2023 um 15:48 schrieb P.O. Jonsson :
>
> I am making a 2nd attempt to replace my cable modem/router today and
> tomorrow, so Jenkins may be unavailable for some time.
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
>
> ___
> 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

[Oorexx-devel] Higher precision time on Windows.

[Rick McGuire]

According to ChatNGT, the attached patch should allow us to have
microsecond time resultion on Windows. Unfortunately, I can't get it to
compile. It can't seem to find the definition of
GetSystemTimePreciseAsFileTime(). I have the correct level of the SDK, I
can find it defined in the header files, but I can't get to compile.
Perhaps someone else would like to give this a try.

Rick


precise.patch
Description: Binary data
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A thought on multi-threaded tracing.

[Rick McGuire]

On Sat, Mar 25, 2023 at 11:52 AM Gilbert Barmwater 
wrote:

> Let me see if I've got this.  If there was a class, perhaps a subclass
> of outputStream, that implemented a SAY method which would "collect" the
> additional multi-threading information and add it to the argument that
> it receives, then one would only need to create an instance of that
> class associated with (presumably) STDERR and then change the
> destination of .traceOutput to be that instance.  The "enhanced" trace
> lines would appear instead of the standard trace lines.  Is that
> somewhat correct?
>

Pretty much spot on. It would require a couple of enhancements in other
places to allow the additional information to be gathered, but those would
be fairly trivial to implement and also useful for situations other than
TRACE. This solution requires no new TRACE command syntax, and the
arguments about how much information is appropriate to add goes away
because any user can choose to modify the information as they see fit.

Rick

>
> Gil
>
> On 3/25/2023 8:34 AM, Rick McGuire wrote:
> > I had one of those AHA moments this morning. The whole question about
> > multithreaded tracing can be quite cleanly resolved by removing the
> > question from the TRACE command entirely.
> >
> > Currently, the trace output is written to the .TRACEOUTPUT monitor.
> > With a few small enhancements to already existing classes, it would be
> > possible for any additional information to be added by the
> > TRACEOUPUT target. To enable it, one would only need to push a new
> > output destination to the monitor. The new destination would add any
> > additional debug information to the trace lines. This is not only
> > pretty simple, but it also means any user can customize the trace
> > information to their own requirements, though it would be nice to
> > supply a couple of builtin alternatives.
> >
> > The enhancements necessary to do this are pretty simple. The
> > StackFrame class already has most of the information you need for
> > debugging, but it could use methods to expose a threadid, instance id,
> > and also the current GUARD status in the case of method calls. This
> > can be quite easily done, and would provide useful debug information
> > for more than just the trace output. It might be desirable to add the
> > same methods to .Context. I can go either way with that one.
> >
> > Rick
> >
> >
> > ___
> > 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

[Oorexx-devel] A thought on multi-threaded tracing.

[Rick McGuire]

I had one of those AHA moments this morning. The whole question about
multithreaded tracing can be quite cleanly resolved by removing the
question from the TRACE command entirely.

Currently, the trace output is written to the .TRACEOUTPUT monitor. With a
few small enhancements to already existing classes, it would be possible
for any additional information to be added by the TRACEOUPUT target. To
enable it, one would only need to push a new output destination to the
monitor. The new destination would add any additional debug information to
the trace lines. This is not only pretty simple, but it also means any user
can customize the trace information to their own requirements, though it
would be nice to supply a couple of builtin alternatives.

The enhancements necessary to do this are pretty simple. The StackFrame
class already has most of the information you need for debugging, but it
could use methods to expose a threadid, instance id, and also the current
GUARD status in the case of method calls. This can be quite easily done,
and would provide useful debug information for more than just the trace
output. It might be desirable to add the same methods to .Context. I can go
either way with that one.

Rick
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Musings with tracing multithreaded ooRexx programs, mt91.rex: on two Rexx interpreter instances (RII)

[Rick McGuire]

I’m in complete agreement with Mike on this. There are better ways to make
this sort of information available than trying to force fit it   In to
trace.

Rick

On Wed, Feb 15, 2023 at 12:58 PM Mike Cowlishaw  wrote:

> Thanks for the multiple examples!
>
> As for the 'spaced out' case (excerpt below) ... this really would not
> work for me.   I often have 5-9 windows open when I'm programming and these
> are 80 characters wide so I can minimise overlaps.  With the suggested
> layout this would only work for programs less than ~40 characters wide!
> Here's how the excerpt looks for me (and this example has very short lines
> -- most of my programs use 72 or more characters per line for better
> commentary):
>
> ---> mt91.rex_nr_1_via_JSR223
> R1   T1   A13 *-* t=.Test~new
> R1   T1   A2V1  1* 21 *-* say "arrived in:" .context~name
> arrived in: INIT
> R1   T1   A2V1  1* 22 *-* counter=0
> R1   T1   A1  >>>   "a TEST"
> R1   T1   A14 *-* t~m1
> R1   T1   A3V1  1* 27 *-* counter+=1  -- increase
> counter
> R1   T1   A3V1  1* 28 *-* say "arrived in:" .context~name
> "before reply"
>
> Almost any line of any length will wrap.  That's why the trace headers in
> Rexx are kept as short as feasible.  Adding an unexplained 27 characters on
> the front of each line makes little sense, especially as the information is
> the same on most lines, and as I mentioned before is not user-friendly
> (here I mean 'user' as being a writer of Rexx programs, not someone who
> runs a Rexx program without looking at it or caring which language it is
> written in).
>
> Mike
>
>
>
>
>
>
>
> Multithreading trace output activated:
>
> ---> mt91.rex_nr_1_via_JSR223
> R1   T1   A13 *-* t=.Test~new
> R1   T1   A2V1  1* 21 *-* say "arrived in:" .context~name
> arrived in: INIT
> R1   T1   A2V1  1* 22 *-* counter=0
> R1   T1   A1  >>>   "a TEST"
> R1   T1   A14 *-* t~m1
> R1   T1   A3V1  1* 27 *-* counter+=1  -- increase counter
> R1   T1   A3V1  1* 28 *-* say "arrived in:" .context~name "before 
> reply"
>
> ___
> 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

Re: [Oorexx-devel] Ad trace options

[Rick McGuire]

I really like this idea!

Rick
On Mon, Feb 13, 2023 at 10:40 AM Mike Cowlishaw  wrote:

> Nice summary from Rony -- Thanks.
>
> I definitely see the utility of having the thread number in a trace (if
> there's more than one thread) -- I use this all the time in printfs in my C
> programs, and in Rexx trace it could simply be added after the trace
> identifier (the second character in the >_> sequence), for example:
>
> 14 *-*   dthen=dthen.i
>>C3> DTHEN.I => "DTHEN.1"
>>V3> DTHEN.I => "2023-03-26"
>>>3> "2023-03-26"
>>=3> DTHEN <= "2023-03-26"
>
> Only one extra character per line (unless you have more than 8 cores) and
> minimal change to documentation, too.  :-)
>
> Mike
>
>
>
> ___
> 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

Re: [Oorexx-devel] Ad trace options

[Rick McGuire]

On Mon, Feb 13, 2023 at 8:19 AM Rony G. Flatscher 
wrote:

> Trace options (rexxref.pdf, 2.29 TRACE):
>
>- prefixes: there is a ? prefix option; on mainframe Rexx (cf. e.g.
>z/OS TSO/E REXX Reference:
>
>)
>there is ! as a prefix option for C (commands); the letters ?, !, _ in Rexx
>can be used in symbols like the alphabetic letters
>
>- alphabetic options: there are the following options, where only the
>first letter is taken, the rest ignored:
>
>- All or A
>   - Commands or C
>   - Error or E
>   - Failure or F
>   - Intermediates or I
>   - Labels or L
>   - Normal or N
>   - Off or O
>   - Results or R
>
> Adding an option for activating multithreaded tracing could be in one of
> the following forms that adhere to the current logic:
>
>- prefix: allow a letter like 'M' (for multithreading) as a prefix
>like ? or !
>
>- Mike would see this option option as a subsidiary option and
>   therefore it should not precede the alphabetic ("main") option and
>   therefore suggests to append it instead, making it postfix
>
>   - alphabetic option:
>
> I very much dislike the alphabetic option because of the way the options
have always been parsed. Many people think they are complete words and are
used to typing things like "Trace off" or "Trace results". It would seem
very astonishing to suddenly be using Trace MResults instread.



>
>-
>- Add an optional second option 'Multithreaded' following after a
>   blank the alphabetical option, hence the following two words need to be
>   given (only the first character of each word would be used):
>
>   - All Multithreaded or A M
>  - Commands Multithreaded or C M
>  - Error Multithreaded or E M
>  - Failure Multithreaded or F M
>  - Intermediates Multithreaded or I M
>  - Labels Multithreaded or L M
>  - Results Multithreaded or R M
>
> This is workable, but has some implications for the trace value form and
also how the additional keyword would be handled by the TRACE() bif. Still
workable, but this needs to be spelled out in the document. BTW, that needs
to be done regardless of how this is specified.


>
>-
>  - postfix: following Mike's idea a trailing 'M' will activate
>multithreaded tracing and if it is not supplied will stop multithreading
>tracing:
>
>- AM
>   - CM
>   - EM
>   - FM
>   - IM
>   - LM
>   - RM
>
>
I dislike this even more than the prefix because of the awkwardness of it.


>
>
> In theory the postfix notation could be implemented such, that the full
> name of an option may be given, but if the last letter is 'M' the
> programmer activates multithreading trace:
>
>- AllM or All_M or Anything_however_the_last_letter_is_M ...
>- CommandsM
>- ErrorM
>- FailureM
>- IntermediatesM
>- LabelsM
>- NormalM
>- OffM
>- ResultsM
>
> Possibly less objectionable than the others, but one thing I don't like is
how the M setting is handled differently from the "?" prefix character.
When parsing the trace setting, there can be multiple occurrences of the
prefix character, e.g. "trace ???I" is the same as "Trace ?I" because each
occurrence flips the debug setting to the other state. Of course, the
prefix can be " M", which makes it the previous proposal.


>
>-
>
> Ad postfix letter 'M': if not desiring an alphabetic letter, letters like
> ?, !, _ could be picked (can be part of a symbol). If so, the underscore
> may be error prone (can be easily overlooked), ? may be irritating as it is
> used already as a prefix. If wanting to use ! then the same is true if
> considering mainframe Rexx' use as a prefix. OTOH, if ! is not regarded to
> be a problem in ooRexx, then one could use that letter:
>
>- A! or All!
>- C! or Commands!
>- E!  or Error!
>- F!  or Failure!
>- I!  or Intermediates!
>- L! or Labels!
>- R! or Results!
>
> The only combination that may be regarded to be a little bit problematic
> is 'I!' as it looks almost like 'II'.
>
I'm sure there will be members of the main-frame community who will scream
bloody murder if "!" is used. Although in the 35+ years since we did the
OS/ 2 version, I've not heard a single complaint about that option not
being included. I really believe nobody ever uses it.

There's one additional character available, the '.'. That might not be a
bad option, though my personal preference remains to make this automatic
rather than explicit.

>
> ---
>
> As this is a new feature of trace we could restrict activating the
> multithreaded output option to a two-letter trace option word where the
> last/second letter must be 'M'/'!' in order to activate it (if the last
> letter is not 'M'/'!' then it it is not activated or if currently 

Re: [Oorexx-devel] Ad '!' as trace prefix letter (Re: Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rick McGuire]

On Sun, Feb 12, 2023 at 9:26 AM Rony G. Flatscher 
wrote:

> On 11.02.2023 18:06, Rick McGuire wrote:
>
> '!' suppresses the issuing of commands. Generally used for
> non-destructiive test runs. Not really used much but it takes up the '!'
> symbol character.
>
> It seems that this is not in the documentation.
>
It's something that is part of the Mainframe classic Rexx implementations.
I was dropped when Mike wrote TRL1 and was never implemented on other
platforms.

Rick



>
> Also trying this as a trace option prefix causes an error:
>
> say "hi! #1"
> trace ?
> "dir"
> trace !
> say "hi! #2"
> "dir"
> say "hi! #3"
>
> ::options trace r
>
> yields as output:
>
> G:\test\orx\trace>test.rex
>  4 *-* trace !
> Error 24 running G:\test\orx\trace\test.rex line 4:  Invalid TRACE request.
> Error 24.1:  TRACE request letter must be one of "ACEFILNOR"; found  "!".
>
> So there seems to be no '!' trace prefix implemented.
>
> Where and how would '!' be used as a prefix letter with the behaviour that
> you describe? Maybe I have missed the related documentation in rexxref.pdf.
>
> ---rony
>
>
> On Sat, Feb 11, 2023 at 12:01 PM Rony G. Flatscher <
> rony.flatsc...@wu.ac.at> wrote:
>
>> Just a quick question: what is the purpose of '!' in TRACE, have not seen
>> documentation about it.
>>
>> In the case '!' is available then this could be used as an MT toggle?
>>
>> ---rony
>> On 09.02.2023 13:40, Rick McGuire wrote:
>>
>> One other thing about the trigger character. The '?' and '!' triggers act
>> as toggles, so issuing "Trace ?" will trigger the interactive debug setting
>> without changing the level of tracing being done. This should also work
>> with whatever is chosen to turn on the multithreaded information.
>>
>> Another possibility would be to automatically add the additional
>> information when more than one thread is active. That way, most users who
>> only work single threaded never see this, but people who are working with
>> multiple threads get the extra information without needing to think about
>> having to change the trace settings. I think I would prefer that rather
>> than the M suffix, which really works quite differently from how ? and !
>> are handled.
>>
>> Rick
>>
>> On Thu, Feb 9, 2023 at 7:21 AM Rony G. Flatscher 
>> wrote:
>>
>>> Thanks for the feedback. Probably putting M as the trailing letter after
>>> the alphabetic letter as Mike suggests is the best option. Omitting the
>>> trailing M would switch back to the simple form. Would that be acceptable
>>> for everyone?
>>>
>>> ---rony
>>>
>>>
>>> On 08.02.2023 21:24, Rick McGuire wrote:
>>>
>>> The special symbol characters "." and "_" are also available as
>>> indicators. I'm a definite -1 to using environment variables and Erich has
>>> also voiced his displeasure about that.
>>>
>>> Another option might be to allow a second keyword following the trace
>>> type that indicates using the expanded form. It should also allow explicit
>>> specification of the simple form too.
>>>
>>> Rick
>>>
>>> On Wed, Feb 8, 2023 at 2:46 PM Mike Cowlishaw 
>>> wrote:
>>>
>>>> I would have put the M after the other letter because it's really a
>>>> subsidiary option.  If it's first it rather 'M'asks the main option?
>>>>
>>>> Mike
>>>>
>>>> --
>>>> *From:* Rony G. Flatscher [mailto:rony.flatsc...@wu.ac.at]
>>>> *Sent:* 08 February 2023 14:16
>>>> *To:* oorexx-devel@lists.sourceforge.net
>>>> *Subject:* [Oorexx-devel] Planning to add multithreaded (concurrent)
>>>> tracing (Re: RFC for feature request "794 Concurrency request"
>>>>
>>>> Coming back to this RFE from 17 months ago which I would like to add to
>>>> trunk. Without it one can hardly use TRACE for debugging multithreaded
>>>> programs in a Rexx-like, i.e. easy manner.
>>>>
>>>> Currently having tried to incorporate the feedback about too many
>>>> whitespaces between the new columns (Rexx interpreter instance number,
>>>> Thread number, Activity number, reserved object pool).
>>>>
>>>> There was another idea about making this concurrency/multihreaded trace
>>>> available without a need to define an environment va

Re: [Oorexx-devel] A draft for documenting MT tracing (Re: Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rick McGuire]

On Sat, Feb 11, 2023 at 12:53 PM Rony G. Flatscher 
wrote:

> On 11.02.2023 18:16, Rick McGuire wrote:
>
> Some comments:
>
> 1) the T and A columns are a bit redundant. We really only need a single
> identifier for the thread, having two is just extra clutter.
> 2) The term activity is introduced here without explanation. It doesn't
> really appear any other place in the documentation and is really more of an
> internal concept than part of the language. If it is used here, then this
> needs to be used consistently in all other places that concurrency is
> discussed.
> 3) The variable pool term is a bit misleading. The thing that gets locked
> is the object's variable pool for a particular scope, not all of the
> variables for the object. For example, two different threads might have the
> GUARD lock on the same object at different scope levels. Knowing the scope
> would be a very useful piece of information.
> 4) I don't like the use of the term "lock" here. At least refer to them as
> a GUARD lock, since that is the concept that is used in other places.
> 5) I still don't like the M prefix. I think things would just be simpler
> if multi-thread mode is used any time there are multiple active threads.
>
> Thank you for the feedback!
>
> A question ad 5): what about using M as a postfix (AM, RM, IM: on, A, R,
> I: off)?
>
I am opposed to any alphabetic marker at all, prefix or suffix. My
recommendation is to make the extra information available whenever it makes
sense (i.e., there's more than one active thread. The user shouldn't have
to adjust things because suddenly things are happening on separate threads.

Rick




> ad 1): indeed in the used example it looks redundant; maybe a different
> example would show both to be benefitial as there may be different
> activities on the same thread, but also a single activity on different
> threads. E.g. example_12_5.rex:
>

This sentence makes no sense to me at all. There will never be multiple
activities active on the same thread at the same time, and an a single
activity will never be active on different threads.

> /* Example of sending message to SELF */
> object1 = .example~new
> object2 = .example~new
> say object1~repeater(5, "Object 1 running")
> say object2~repeater(5, "Object 2 running")
> say "Main ended."
>
> ::class example
> ::method repeater
>use arg reps,msg
>reply "Entered repeater."
>say self~repeat(reps,msg)
>
> ::method repeat
>use arg reps,msg
>do reps
>   say msg
>end
>return "Repeated" msg"," reps "times."
>
> ::options trace a
>
> 
> R1   T1   A12 *-* object1 = .example~new
> R1   T1   A13 *-* object2 = .example~new
> R1   T1   A14 *-* say object1~repeater(5, "Object 1 
> running")
> R1   T1   A2V1>I> Method "REPEATER" with scope "EXAMPLE" 
> in package "G:\oorexx.tmp\concurrencyTrace\example_12_5.rex".
> R1   T1   A2V1  1* 10 *-* use arg reps,msg
> R1   T1   A2V1  1* 11 *-* reply "Entered repeater."
> Entered repeater.
> R1   T1   A15 *-* say object2~repeater(5, "Object 2 
> running")*R1   T2   A2V1  1*>I> Method "REPEATER" with scope 
> "EXAMPLE" in package "G:\oorexx.tmp\concurrencyTrace\example_12_5.rex".*
> R1   T1   A3V2>I> Method "REPEATER" with scope "EXAMPLE" 
> in package "G:\oorexx.tmp\concurrencyTrace\example_12_5.rex".*R1   T2   A2
> V1  1* 12 *-* say self~repeat(reps,msg)*
> R1   T1   A3V2  1* 10 *-* use arg reps,msg*R1   T2   A4V1 
>  1 >I> Method "REPEAT" with scope "EXAMPLE" in package 
> "G:\oorexx.tmp\concurrencyTrace\example_12_5.rex".*
> R1   T1   A3V2  1* 11 *-* reply "Entered repeater."*R1   T2   A4  
>   V1  2* 15 *-* use arg reps,msg*Entered repeater.*R1   T2   A4V1 
>  2* 16 *-* do reps*R1   T1   A16 *-* say "Main 
> ended."
> Main ended.*R1   T3   A3V2  1*>I> Method "REPEATER" with 
> scope "EXAMPLE" in package 
> "G:\oorexx.tmp\concurrencyTrace\example_12_5.rex".**R1   T2   A4V1  
> 2* 17 *-*   say msg*Object 1 running*R1   T3   A3V2  1* 12 
> *-* say self~repeat(reps,msg)**R1   T2   A4V1  2* 18 *-* end**R1  
>  T3   A5V2  1 >I> Method "REPEAT" with scope "EXAMPLE" i

Re: [Oorexx-devel] A draft for documenting MT tracing (Re: Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rick McGuire]

  A17 *-* say "b:" b~result
>> b: Repeated Object 2 running, 3 times.
>> R1   T1   A18 *-* say "Main ended."
>> Main ended.
>>
>> --- trace example 1 (end) 
>> ---
>>
>>
>>
>> --- trace example 2 (begin) 
>> ---
>>
>> Tracing Example 2: Asynchroneously sending the same message to the same
>> object of the same class (blocking takes place)
>>
>> /* Example of methods with the same scope not running concurrently*/
>> object1 = .example~new
>>
>> a = object1~start("REPEAT",3,"Object 1 running call 1")
>> b = object1~start("REPEAT",3,"Object 1 running call 2")
>> say "a:" a~result
>> say "b:" b~result
>> say "Main ended." /* concurrently. */
>>
>> ::class example
>> ::method repeat
>>use arg reps,msg
>>do reps
>>   say msg
>>end
>>return "Repeated" msg"," reps "times."
>>
>> ::options trace a
>>
>> Trace output:
>>
>> R1   T1   A12 *-* object1 = .example~new
>> R1   T1   A14 *-* a = 
>> object1~start("REPEAT",3,"Object 1 running call 1")
>> R1   T1   A15 *-* b = 
>> object1~start("REPEAT",3,"Object 1 running call 2")
>> R1   T1   A16 *-* say "a:" a~result
>>* R1   T2   A2V1>I> Method "REPEAT" with scope 
>> "EXAMPLE" in package "G:\oorexx.tmp\concurrencyTrace\example_12_4.rex".*
>>* R1   T3   A3V1>I> Method "REPEAT" with scope 
>> "EXAMPLE" in package "G:\oorexx.tmp\concu*rrencyTrace\example_12_4.rex".
>> *R1   T2   A2V1  1* 12 *-* use arg reps,msg**R1  
>>  T2   A2V1  1* 13 *-* do reps**R1   T2   A2V1  
>> 1* 14 *-*   say msg*
>> Object 1 running call 2
>>* R1   T2   A2V1  1* 15 *-* end**R1   T2   A2    
>> V1  1* 13 *-* do reps**R1   T2   A2V1  1* 14 *-* 
>>   say msg*
>> Object 1 running call 2
>>   *  R1   T2   A2V1  1* 15 *-* end**R1   T2   A2
>> V1  1* 13 *-* do reps**R1   T2   A2V1  1* 14 *-* 
>>   say msg*
>> Object 1 running call 2
>>* R1   T2   A2V1  1* 15 *-* end**R1   T2   A2
>> V1  1* 13 *-* do reps**R1   T2   A2V1  1* 16 *-* 
>> return "Repeated" msg"," reps "times."*
>> *R1   T3   A3V1  1* 12 *-* use arg reps,msg**R1  
>>  T3   A3V1  1* 13 *-* do reps**R1   T3   A3V1  
>> 1* 14 *-*   say msg**Object 1 running call 1**R1   T3   
>> A3V1  1* 15 *-* end**R1   T3   A3V1  1* 13 
>> *-* do reps**R1   T3   A3V1  1* 14 *-*   say msg**   
>>  Object 1 running call 1**R1   T3   A3V1  1* 15 *-* 
>> end**R1   T3   A3V1  1* 13 *-* do reps**R1   T3  
>>  A3V1  1* 14 *-*   say msg**Object 1 running call 1**
>> R1   T3   A3V1  1* 15 *-* end**R1   T3   A3V1
>>   1* 13 *-* do reps**R1   T3   A3V1  1* 16 *-* 
>> return "Repeated" msg"," reps "times."*
>> a: Repeated Object 1 running call 1, 3 times.
>> R1   T1   A17 *-* say "b:" b~result
>> b: Repeated Object 1 running call 2, 3 times.
>> R1   T1   A18 *-* say "Main ended." /* 
>> concurrently. */
>> Main ended.
>>
>> --- trace example 2 (end) 
>> ---
>>
>>
>> ---rony
>>
>>
>> On 09.02.2023 13:27, Rick McGuire wrote:
>>
>> This is one of those features where I think I need to see the complete
>> documentation written first before any code is checked in. In particular, I
>> have some reservations on how this exp

Re: [Oorexx-devel] A draft for documenting MT tracing (Re: Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rick McGuire]

Ugh, I don't find this to be helpful information at all. I can determine
that information just by looking at the thread numbers, the activation
number has no real connection to any concept in the interpreter.

Rick

On Sat, Feb 11, 2023 at 12:33 PM Jean Louis Faucher 
wrote:

> A quick feedback about point 1:
> The A column is in fact the activation identifier (RexxActivation).
> It’s used to know which method/routine is executing the current line.
> The name of this method/routine can be found by looking back in the trace
> the first >I> for the current T.
>
> In rexxref, “activation” is not used.
> I think the good term is “invocation”, as in "An activity contains a stack
> of invocations… An invocation is activated when an executable unit is
> invoked and removed (popped) when execution completes. "
>
>
> This is the displayed informations
> struct ConcurrencyInfos
> {
> uint32_t interpreter;
> uint32_t activity; —> display a counter related to the system
> tread identifier, not the activity identifier
> uint32_t activation;
> uint32_t variableDictionary;
> unsigned short reserveCount;
> char lock;
> };
>
> On 11 Feb 2023, at 18:16, Rick McGuire  wrote:
>
> Some comments:
>
> 1) the T and A columns are a bit redundant. We really only need a single
> identifier for the thread, having two is just extra clutter.
> 2) The term activity is introduced here without explanation. It doesn't
> really appear any other place in the documentation and is really more of an
> internal concept than part of the language. If it is used here, then this
> needs to be used consistently in all other places that concurrency is
> discussed.
> 3) The variable pool term is a bit misleading. The thing that gets locked
> is the object's variable pool for a particular scope, not all of the
> variables for the object. For example, two different threads might have the
> GUARD lock on the same object at different scope levels. Knowing the scope
> would be a very useful piece of information.
> 4) I don't like the use of the term "lock" here. At least refer to them as
> a GUARD lock, since that is the concept that is used in other places.
> 5) I still don't like the M prefix. I think things would just be simpler
> if multi-thread mode is used any time there are multiple active threads.
>
> Rick
>
> On Sat, Feb 11, 2023 at 12:02 PM Rony G. Flatscher <
> rony.flatsc...@wu.ac.at> wrote:
>
>> Ad documentation: here a draft, meant for rexxref.pdf, chapter "12.
>> Concurrency", suggesting of adding a section at the end (activity, variable
>> pool, locks already explained in that chapter):
>>
>> --
>>
>> 12.5 Tracing Concurrent Execution
>>
>> Each invoked routine and method routine will execute on a proper activity. 
>> If a
>> method runs for different objects each such invocation will execute on a 
>> proper
>> activity. Activities may run on different threads if sending messages
>> concurrently or using the reply keyword instruction.
>>
>> Upon entry of a method routine access to the variable pool of the object (its
>> object variables, attributes) gets secured by reserving exclusive access by
>> default.  If a concurrent message to the same object gets sent from a
>> concurrently executing part of the program, then the method routine attempts 
>> to
>> get the lock on the variable pool and will be blocked as long as the the 
>> owning
>> method routine for that object does not release it, either by returning from
>> the method invocation or by issuing "guard off" in its routine.
>>
>> If a method routine's activity owns the variable pool lock it may invoke 
>> other
>> method routines by sending the message to "self" without getting blocked.
>>
>> In order to help understand and debug concurrently executing programs the 
>> TRACE
>> keyword instruction and the TRACE() built-in function allow for supplying
>> additional trace output information by adding five columns to the begin of 
>> the
>> trace output:
>>
>> - the Rexx instance column: the letter 'R' plus a unique number denoting a
>> proper Rexx interpreter instance.  This is a counter that starts out with 1.
>> If ooRexx gets instrumentated by applications it may be possible that 
>> different
>> Rexx programs may execute concurrently on different Rexx interpreter 
>> instances
>> (cf. rexxapi.pdf, 1.1.1 RexxCreateInterpreter).
>>
>> - the operating system thread column: the letter 'T' plus a unique number per
>> operating system thread in the process.

Re: [Oorexx-devel] A draft for documenting MT tracing (Re: Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rick McGuire]

 in package "G:\oorexx.tmp\concurrencyTrace\example_12_4.rex".*
>* R1   T3   A3V1>I> Method "REPEAT" with scope 
> "EXAMPLE" in package "G:\oorexx.tmp\concu*rrencyTrace\example_12_4.rex".
> *R1   T2   A2V1  1* 12 *-* use arg reps,msg**R1   
> T2   A2V1  1* 13 *-* do reps**R1   T2   A2V1  1*  
>14 *-*   say msg*
> Object 1 running call 2
>* R1   T2   A2V1  1* 15 *-* end**R1   T2   A2
> V1  1* 13 *-* do reps**R1   T2   A2V1  1* 14 *-*  
>  say msg*
> Object 1 running call 2
>   *  R1   T2   A2V1  1* 15 *-* end**R1   T2   A2
> V1  1* 13 *-* do reps**R1   T2   A2V1  1* 14 *-*  
>  say msg*
> Object 1 running call 2
>* R1   T2   A2V1  1* 15 *-* end**R1   T2   A2
> V1  1* 13 *-* do reps**R1   T2   A2V1  1* 16 *-* 
> return "Repeated" msg"," reps "times."*
> *R1   T3   A3V1  1* 12 *-* use arg reps,msg**R1   
> T3   A3V1  1* 13 *-* do reps**R1   T3   A3V1  1*  
>14 *-*   say msg**Object 1 running call 1**R1   T3   A3
> V1  1* 15 *-* end**R1   T3   A3V1  1* 13 *-* do 
> reps**R1   T3   A3V1  1* 14 *-*   say msg**Object 
> 1 running call 1**R1   T3   A3V1  1* 15 *-* end**
> R1   T3   A3V1  1* 13 *-* do reps**R1   T3   A3V1 
>  1* 14 *-*   say msg**Object 1 running call 1**R1   T3   
> A3V1  1* 15 *-* end**R1   T3   A3V1  1* 13 
> *-* do reps**R1   T3   A3V1  1* 16 *-* return "Repeated" 
> msg"," reps "times."*
> a: Repeated Object 1 running call 1, 3 times.
> R1   T1   A17 *-* say "b:" b~result
> b: Repeated Object 1 running call 2, 3 times.
> R1   T1   A18 *-* say "Main ended." /* 
> concurrently. */
> Main ended.
>
> --- trace example 2 (end) 
> ---
>
>
> ---rony
>
>
> On 09.02.2023 13:27, Rick McGuire wrote:
>
> This is one of those features where I think I need to see the complete
> documentation written first before any code is checked in. In particular, I
> have some reservations on how this explicitly introduces activities and
> reservation counts concepts to the language without them ever appearing
> elsewhere in the language reference. I'm also not willing to accept the
> format with which the additional information is added without some
> additional discussion. Also the concept of giving the activities a unique
> identifier. Since activities are pooled and reused, it needs to be defined
> how that all plays out. This feature, while useful, needs a lot more
> discussion before it is put in place.
>
> Rick
>
> On Thu, Feb 9, 2023 at 7:21 AM Rony G. Flatscher 
> wrote:
>
>> Thanks for the feedback. Probably putting M as the trailing letter after
>> the alphabetic letter as Mike suggests is the best option. Omitting the
>> trailing M would switch back to the simple form. Would that be acceptable
>> for everyone?
>>
>> ---rony
>>
>>
>> On 08.02.2023 21:24, Rick McGuire wrote:
>>
>> The special symbol characters "." and "_" are also available as
>> indicators. I'm a definite -1 to using environment variables and Erich has
>> also voiced his displeasure about that.
>>
>> Another option might be to allow a second keyword following the trace
>> type that indicates using the expanded form. It should also allow explicit
>> specification of the simple form too.
>>
>> Rick
>>
>> On Wed, Feb 8, 2023 at 2:46 PM Mike Cowlishaw 
>> wrote:
>>
>>> I would have put the M after the other letter because it's really a
>>> subsidiary option.  If it's first it rather 'M'asks the main option?
>>>
>>> Mike
>>>
>>> --
>>> *From:* Rony G. Flatscher [mailto:rony.flatsc...@wu.ac.at]
>>> *Sent:* 08 February 2023 14:16
>>> *To:* oorexx-devel@lists.sourceforge.net
>>> *Subject:* [Oorexx-devel] Planning to add multithreaded (concurrent)
>>> tracing (Re: RFC for feature request "794 Concurrency request"
>>>
>>> Coming back to this RFE from 17 months ag

Re: [Oorexx-devel] Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rick McGuire]

'!' suppresses the issuing of commands. Generally used for
non-destructiive test runs. Not really used much but it takes up the '!'
symbol character.

Rick

On Sat, Feb 11, 2023 at 12:01 PM Rony G. Flatscher 
wrote:

> Just a quick question: what is the purpose of '!' in TRACE, have not seen
> documentation about it.
>
> In the case '!' is available then this could be used as an MT toggle?
>
> ---rony
> On 09.02.2023 13:40, Rick McGuire wrote:
>
> One other thing about the trigger character. The '?' and '!' triggers act
> as toggles, so issuing "Trace ?" will trigger the interactive debug setting
> without changing the level of tracing being done. This should also work
> with whatever is chosen to turn on the multithreaded information.
>
> Another possibility would be to automatically add the additional
> information when more than one thread is active. That way, most users who
> only work single threaded never see this, but people who are working with
> multiple threads get the extra information without needing to think about
> having to change the trace settings. I think I would prefer that rather
> than the M suffix, which really works quite differently from how ? and !
> are handled.
>
> Rick
>
> On Thu, Feb 9, 2023 at 7:21 AM Rony G. Flatscher 
> wrote:
>
>> Thanks for the feedback. Probably putting M as the trailing letter after
>> the alphabetic letter as Mike suggests is the best option. Omitting the
>> trailing M would switch back to the simple form. Would that be acceptable
>> for everyone?
>>
>> ---rony
>>
>>
>> On 08.02.2023 21:24, Rick McGuire wrote:
>>
>> The special symbol characters "." and "_" are also available as
>> indicators. I'm a definite -1 to using environment variables and Erich has
>> also voiced his displeasure about that.
>>
>> Another option might be to allow a second keyword following the trace
>> type that indicates using the expanded form. It should also allow explicit
>> specification of the simple form too.
>>
>> Rick
>>
>> On Wed, Feb 8, 2023 at 2:46 PM Mike Cowlishaw 
>> wrote:
>>
>>> I would have put the M after the other letter because it's really a
>>> subsidiary option.  If it's first it rather 'M'asks the main option?
>>>
>>> Mike
>>>
>>> --
>>> *From:* Rony G. Flatscher [mailto:rony.flatsc...@wu.ac.at]
>>> *Sent:* 08 February 2023 14:16
>>> *To:* oorexx-devel@lists.sourceforge.net
>>> *Subject:* [Oorexx-devel] Planning to add multithreaded (concurrent)
>>> tracing (Re: RFC for feature request "794 Concurrency request"
>>>
>>> Coming back to this RFE from 17 months ago which I would like to add to
>>> trunk. Without it one can hardly use TRACE for debugging multithreaded
>>> programs in a Rexx-like, i.e. easy manner.
>>>
>>> Currently having tried to incorporate the feedback about too many
>>> whitespaces between the new columns (Rexx interpreter instance number,
>>> Thread number, Activity number, reserved object pool).
>>>
>>> There was another idea about making this concurrency/multihreaded trace
>>> available without a need to define an environment variable
>>> RXTRACE_CONCURRENCY before starting a Rexx program. This post is about
>>> ideas of how to activate and deactivate concurrent tracing at runtime
>>> (either via the TRACE keyword instruction or the TRACE()-BIF) in a manner
>>> that is intuitive and easy to remember.
>>>
>>> One possibility would be to introduce new alphabetic options, this time
>>> with two letters by prepending the letter 'M' (for multithreaded as the
>>> letter c is already used for tracing commands and may therefore be
>>> irritating) to the existing alphabetic characters, hence defining the
>>> following semantics:
>>>
>>> *Trace*
>>> *Option, turn off MT*
>>> *Option, turn on MT*
>>> All
>>> A
>>> MA
>>> Command
>>> C
>>> MC
>>> Error
>>> E
>>> ME
>>> Failure
>>> F
>>> MF
>>> Intermediates
>>> I
>>> MI
>>> Labels
>>> L
>>> ML
>>> Normal
>>> N
>>> MN
>>> Off
>>> O
>>> -
>>> Results
>>> R
>>> MR
>>>
>>>
>>>
>>> This would have the benefit that anytime it becomes possible to turn on
>>> and to turn off multithreaded/concurrent tracing at runtime.
>&g

Re: [Oorexx-devel] Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rick McGuire]

One other thing about the trigger character. The '?' and '!' triggers act
as toggles, so issuing "Trace ?" will trigger the interactive debug setting
without changing the level of tracing being done. This should also work
with whatever is chosen to turn on the multithreaded information.

Another possibility would be to automatically add the additional
information when more than one thread is active. That way, most users who
only work single threaded never see this, but people who are working with
multiple threads get the extra information without needing to think about
having to change the trace settings. I think I would prefer that rather
than the M suffix, which really works quite differently from how ? and !
are handled.

Rick

On Thu, Feb 9, 2023 at 7:21 AM Rony G. Flatscher 
wrote:

> Thanks for the feedback. Probably putting M as the trailing letter after
> the alphabetic letter as Mike suggests is the best option. Omitting the
> trailing M would switch back to the simple form. Would that be acceptable
> for everyone?
>
> ---rony
>
>
> On 08.02.2023 21:24, Rick McGuire wrote:
>
> The special symbol characters "." and "_" are also available as
> indicators. I'm a definite -1 to using environment variables and Erich has
> also voiced his displeasure about that.
>
> Another option might be to allow a second keyword following the trace type
> that indicates using the expanded form. It should also allow explicit
> specification of the simple form too.
>
> Rick
>
> On Wed, Feb 8, 2023 at 2:46 PM Mike Cowlishaw  wrote:
>
>> I would have put the M after the other letter because it's really a
>> subsidiary option.  If it's first it rather 'M'asks the main option?
>>
>> Mike
>>
>> --
>> *From:* Rony G. Flatscher [mailto:rony.flatsc...@wu.ac.at]
>> *Sent:* 08 February 2023 14:16
>> *To:* oorexx-devel@lists.sourceforge.net
>> *Subject:* [Oorexx-devel] Planning to add multithreaded (concurrent)
>> tracing (Re: RFC for feature request "794 Concurrency request"
>>
>> Coming back to this RFE from 17 months ago which I would like to add to
>> trunk. Without it one can hardly use TRACE for debugging multithreaded
>> programs in a Rexx-like, i.e. easy manner.
>>
>> Currently having tried to incorporate the feedback about too many
>> whitespaces between the new columns (Rexx interpreter instance number,
>> Thread number, Activity number, reserved object pool).
>>
>> There was another idea about making this concurrency/multihreaded trace
>> available without a need to define an environment variable
>> RXTRACE_CONCURRENCY before starting a Rexx program. This post is about
>> ideas of how to activate and deactivate concurrent tracing at runtime
>> (either via the TRACE keyword instruction or the TRACE()-BIF) in a manner
>> that is intuitive and easy to remember.
>>
>> One possibility would be to introduce new alphabetic options, this time
>> with two letters by prepending the letter 'M' (for multithreaded as the
>> letter c is already used for tracing commands and may therefore be
>> irritating) to the existing alphabetic characters, hence defining the
>> following semantics:
>>
>> *Trace*
>> *Option, turn off MT*
>> *Option, turn on MT*
>> All
>> A
>> MA
>> Command
>> C
>> MC
>> Error
>> E
>> ME
>> Failure
>> F
>> MF
>> Intermediates
>> I
>> MI
>> Labels
>> L
>> ML
>> Normal
>> N
>> MN
>> Off
>> O
>> -
>> Results
>> R
>> MR
>>
>>
>>
>> This would have the benefit that anytime it becomes possible to turn on
>> and to turn off multithreaded/concurrent tracing at runtime.
>>
>> What do you think?
>>
>> ---rony
>>
>> P.S.: The "fallback" would be to just add it as is, i.e. using the
>> environment variable RXTRACE_CONCURRENCY, making the
>> multithreaded/concurrent tracing a global option that needs to be set
>> before running a Rexx program.
>>
>>
>> On 05.09.2021 14:12, Rony G. Flatscher wrote:
>>
>> Almost a week ago Jean Louis Faucher registered feature request "794 
>> Concurrency request", 
>> cf.<https://sourceforge.net/p/oorexx/feature-requests/794/> 
>> <https://sourceforge.net/p/oorexx/feature-requests/794/> together with a 
>> patch that implements the
>> feature request. So far there have been no comments, hence "requesting for 
>> comments (RFC)" here as
>> it may be the case that the RFE has been overlooked.
>&g

Re: [Oorexx-devel] Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rick McGuire]

This is one of those features where I think I need to see the complete
documentation written first before any code is checked in. In particular, I
have some reservations on how this explicitly introduces activities and
reservation counts concepts to the language without them ever appearing
elsewhere in the language reference. I'm also not willing to accept the
format with which the additional information is added without some
additional discussion. Also the concept of giving the activities a unique
identifier. Since activities are pooled and reused, it needs to be defined
how that all plays out. This feature, while useful, needs a lot more
discussion before it is put in place.

Rick

On Thu, Feb 9, 2023 at 7:21 AM Rony G. Flatscher 
wrote:

> Thanks for the feedback. Probably putting M as the trailing letter after
> the alphabetic letter as Mike suggests is the best option. Omitting the
> trailing M would switch back to the simple form. Would that be acceptable
> for everyone?
>
> ---rony
>
>
> On 08.02.2023 21:24, Rick McGuire wrote:
>
> The special symbol characters "." and "_" are also available as
> indicators. I'm a definite -1 to using environment variables and Erich has
> also voiced his displeasure about that.
>
> Another option might be to allow a second keyword following the trace type
> that indicates using the expanded form. It should also allow explicit
> specification of the simple form too.
>
> Rick
>
> On Wed, Feb 8, 2023 at 2:46 PM Mike Cowlishaw  wrote:
>
>> I would have put the M after the other letter because it's really a
>> subsidiary option.  If it's first it rather 'M'asks the main option?
>>
>> Mike
>>
>> --
>> *From:* Rony G. Flatscher [mailto:rony.flatsc...@wu.ac.at]
>> *Sent:* 08 February 2023 14:16
>> *To:* oorexx-devel@lists.sourceforge.net
>> *Subject:* [Oorexx-devel] Planning to add multithreaded (concurrent)
>> tracing (Re: RFC for feature request "794 Concurrency request"
>>
>> Coming back to this RFE from 17 months ago which I would like to add to
>> trunk. Without it one can hardly use TRACE for debugging multithreaded
>> programs in a Rexx-like, i.e. easy manner.
>>
>> Currently having tried to incorporate the feedback about too many
>> whitespaces between the new columns (Rexx interpreter instance number,
>> Thread number, Activity number, reserved object pool).
>>
>> There was another idea about making this concurrency/multihreaded trace
>> available without a need to define an environment variable
>> RXTRACE_CONCURRENCY before starting a Rexx program. This post is about
>> ideas of how to activate and deactivate concurrent tracing at runtime
>> (either via the TRACE keyword instruction or the TRACE()-BIF) in a manner
>> that is intuitive and easy to remember.
>>
>> One possibility would be to introduce new alphabetic options, this time
>> with two letters by prepending the letter 'M' (for multithreaded as the
>> letter c is already used for tracing commands and may therefore be
>> irritating) to the existing alphabetic characters, hence defining the
>> following semantics:
>>
>> *Trace*
>> *Option, turn off MT*
>> *Option, turn on MT*
>> All
>> A
>> MA
>> Command
>> C
>> MC
>> Error
>> E
>> ME
>> Failure
>> F
>> MF
>> Intermediates
>> I
>> MI
>> Labels
>> L
>> ML
>> Normal
>> N
>> MN
>> Off
>> O
>> -
>> Results
>> R
>> MR
>>
>>
>>
>> This would have the benefit that anytime it becomes possible to turn on
>> and to turn off multithreaded/concurrent tracing at runtime.
>>
>> What do you think?
>>
>> ---rony
>>
>> P.S.: The "fallback" would be to just add it as is, i.e. using the
>> environment variable RXTRACE_CONCURRENCY, making the
>> multithreaded/concurrent tracing a global option that needs to be set
>> before running a Rexx program.
>>
>>
>> On 05.09.2021 14:12, Rony G. Flatscher wrote:
>>
>> Almost a week ago Jean Louis Faucher registered feature request "794 
>> Concurrency request", 
>> cf.<https://sourceforge.net/p/oorexx/feature-requests/794/> 
>> <https://sourceforge.net/p/oorexx/feature-requests/794/> together with a 
>> patch that implements the
>> feature request. So far there have been no comments, hence "requesting for 
>> comments (RFC)" here as
>> it may be the case that the RFE has been overlooked.
>>
>> ---
>>
>> IMHO this RFE is incredi

Re: [Oorexx-devel] Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rick McGuire]

The special symbol characters "." and "_" are also available as indicators.
I'm a definite -1 to using environment variables and Erich has also voiced
his displeasure about that.

Another option might be to allow a second keyword following the trace type
that indicates using the expanded form. It should also allow explicit
specification of the simple form too.

Rick

On Wed, Feb 8, 2023 at 2:46 PM Mike Cowlishaw  wrote:

> I would have put the M after the other letter because it's really a
> subsidiary option.  If it's first it rather 'M'asks the main option?
>
> Mike
>
> --
> *From:* Rony G. Flatscher [mailto:rony.flatsc...@wu.ac.at]
> *Sent:* 08 February 2023 14:16
> *To:* oorexx-devel@lists.sourceforge.net
> *Subject:* [Oorexx-devel] Planning to add multithreaded (concurrent)
> tracing (Re: RFC for feature request "794 Concurrency request"
>
> Coming back to this RFE from 17 months ago which I would like to add to
> trunk. Without it one can hardly use TRACE for debugging multithreaded
> programs in a Rexx-like, i.e. easy manner.
>
> Currently having tried to incorporate the feedback about too many
> whitespaces between the new columns (Rexx interpreter instance number,
> Thread number, Activity number, reserved object pool).
>
> There was another idea about making this concurrency/multihreaded trace
> available without a need to define an environment variable
> RXTRACE_CONCURRENCY before starting a Rexx program. This post is about
> ideas of how to activate and deactivate concurrent tracing at runtime
> (either via the TRACE keyword instruction or the TRACE()-BIF) in a manner
> that is intuitive and easy to remember.
>
> One possibility would be to introduce new alphabetic options, this time
> with two letters by prepending the letter 'M' (for multithreaded as the
> letter c is already used for tracing commands and may therefore be
> irritating) to the existing alphabetic characters, hence defining the
> following semantics:
>
> *Trace*
> *Option, turn off MT*
> *Option, turn on MT*
> All
> A
> MA
> Command
> C
> MC
> Error
> E
> ME
> Failure
> F
> MF
> Intermediates
> I
> MI
> Labels
> L
> ML
> Normal
> N
> MN
> Off
> O
> -
> Results
> R
> MR
>
>
>
> This would have the benefit that anytime it becomes possible to turn on
> and to turn off multithreaded/concurrent tracing at runtime.
>
> What do you think?
>
> ---rony
>
> P.S.: The "fallback" would be to just add it as is, i.e. using the
> environment variable RXTRACE_CONCURRENCY, making the
> multithreaded/concurrent tracing a global option that needs to be set
> before running a Rexx program.
>
>
> On 05.09.2021 14:12, Rony G. Flatscher wrote:
>
> Almost a week ago Jean Louis Faucher registered feature request "794 
> Concurrency request", 
> cf. 
>  together with a 
> patch that implements the
> feature request. So far there have been no comments, hence "requesting for 
> comments (RFC)" here as
> it may be the case that the RFE has been overlooked.
>
> ---
>
> IMHO this RFE is incredible helpful for debugging multi-threaded Rexx 
> programs and for understanding
> how ooRexx dispatches multithreaded code.
>
> The way Jean Louis devised the implementation has practically no impact on 
> the interpreter (unless
> one defines an environment variable "RXTRACE_CONCURRENCY=on" modelled after 
> the existing
> "RXTRACE=ON" environment variable in which case helpful information gets 
> generated for prefixing
> each trace output statement) makes it easy even for beginners (= students) to 
> get insight and
> understand how ooRexx executes multithreaded programs. Some problems rooted 
> in multithreaded Rexx
> code can be quickly located, understood and resolved with this feature.
>
> Having tested this concurrency trace feature with the most challenging JavaFX 
> ooRexx programs I have
> been really impressed with the results. Using the ooRexx program 
> "samples/tracer.rex" (included in
> the patch) to render the massive concurrency trace output of some JavaFX 
> ooRexx programs to csv and
> importing the concurrency trace into a spreadsheet (e.g. Excel) makes it 
> possible to analyze such
> massive concurrency traces in every possible detail using the spreadsheet 
> features (e.g. filtering
> for a specific ooRexx interpreter instance or specific threads, pivots and 
> the like). Therefore I
> uploaded one such test to this RFE such that one can directly get at the 
> massive concurrency trace,
> the csv file created by "tracer.rex" from it and an Excel spreadsheet which 
> was used to import the
> generated csv file. (I wished this feature had been available when devising 
> some of the BSF4ooRexx
> JavaFX samples, which would have saved me literally weeks of debugging!)
>
> The patch implementing RFE 794 makes it really easy for ooRexx programmers to 
> understand and to
> debug multithreaded ooRexx programs, 

Re: [Oorexx-devel] e-Mail notifications from patches tracker ?

[Rick McGuire]

There was definitely a notification email sent out. Are you subscribed to
the list? Click on the envelope icon in the tracker page for that item.

Rick

On Fri, Feb 3, 2023 at 8:44 AM Rony G. Flatscher 
wrote:

> Just noticed that I have not received any e-mail notification messages
> when a patch tracker item
> gets created (unlike with the bug- or rfre-tracker).
>
> Does anyone know where one can activate/define this feature and define the
> e-mail address to send
> notifications to? (Could not find anything looking at the bug tracker
> definitions.)
>
> ---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

Re: [Oorexx-devel] Question ad native tests ...

[Rick McGuire]

On Thu, Feb 2, 2023 at 11:53 AM Rony G. Flatscher 
wrote:

> While looking into what is needed to formulate native tests I found
>
> F:\work\svn\oorexx\test\trunk>grep -R LoadPackage
> ooRexx/API/oo/METHODPackage.cls:::method TestLoadPackage EXTERNAL "LIBRARY 
> orxmethod TestLoadPackage"
> ooRexx/API/oo/METHODPackage.cls:::method TestLoadPackageFromData EXTERNAL 
> "LIBRARY orxmethod TestLoadPackageFromData"
>
> F:\work\svn\oorexx\test\trunk>grep -Rl orxmethod *
> ooRexx/API/oo/CONVERSIONPackage.cls
> ooRexx/API/oo/METHODPackage.cls
>
> but lack the native (C++) files that would implement the test methods.
>
> Also have not been able to find any usage of TestLoadPackage[FromData] in
> any of the test units:
>
> F:\work\svn\oorexx\test\trunk>grep -Ri TestLoadPackage
> ooRexx/API/oo/METHODPackage.cls:::method TestLoadPackage EXTERNAL "LIBRARY 
> orxmethod TestLoadPackage"
> ooRexx/API/oo/METHODPackage.cls:::method TestLoadPackageFromData EXTERNAL 
> "LIBRARY orxmethod TestLoadPackageFromData"
>
> The native test code is not located under test/trunk, but rather in
> main/trunk/testbinaries. Why are these files not located under
> test/trunk/testbinaries? What is the reason for this?
>
They were moved there years ago so that they always get built as part of
the build rather than requiring a separate build step that was more
difficult to set up.



> Is there anything else one needs to be aware of (regarding locations of
> files belonging to the test framework)?
>
> How can one just run the native tests, how would one have to invoke them?
>
> ---rony
>
> P.S.: This is for creating tests for:
>
> Bugs
>
>  126: # 1625 NewRoutine() and LoadPackageFromData() raise error 13.1 on
> tokenized Rexx code
>  (entered by Rony G. Flatscher on 2019-04-06 -> 2019-07-16)
> ***TODO: [doc+test]
>
>  127: # 1624 .Routine~newFile(rexxc-program) raises error 13.1
>  (entered by Rony G. Flatscher on 2019-04-06 -> 2019-04-17)
> ***TODO: [doc+test]
>
> RFE
>
>   27: #  754 'rexxc' binary (compiled/tokenized) data: please encode as
> plain text (7-Bit-ASCII) to allow it to be read as a string (e.g. from Java
> java.io.Reader)
>  (entered by Rony G. Flatscher on 2019-04-07 -> 2020-03-08)
> ***TODO: [tests]
>
>
> ___
> 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

Re: [Oorexx-devel] I think I've seen the future...

[Rick McGuire]

On Mon, Jan 23, 2023 at 10:01 AM CV Bruce  wrote:

> I’ve played with ChatGPT, nothing as complex as your example, and it is
> amazing.
> But don’t underestimate that Rick had the expertise to recognize that the
> first solution presented had the same problems as the current code. Rick
> was also able to criticize the solution, which enabled the AI to generate a
> better solution. Again, Rick had the expertise to evaluate the second
> solution as to its suitability.
>

I was able to criticize it, but had serious doubts I could phrase things
well enough that ChatGPT would understand the problem. I have had a hard
enough time explaining it to actual people. The fact it understood my
one-sentence clarification well enought to zero in on what I believe to be
a workable solution was nothing sort of amazing. I had previous spent two
month trying to figure this out with no success.

The other part I like is that this is like StackOverflow without all of the
snarking responses :-)

Rick


>
> It kind of seems like the days when people checked the assembler created
> by the compiler to make sure the compiler was “doing it right”.
>
> I think we are crossing a bridge from one technology to the next, and
> until full faith can be give to the new technology, check and check again.
>
> Bruce
>
> Sent by Magic!
>
> On Jan 23, 2023, at 6:42 AM, Rick McGuire  wrote:
>
> 
>
>
> On Mon, Jan 23, 2023 at 9:34 AM Sahananda Sahananda 
> wrote:
>
>> Rick,
>>
>> Fascinating!
>>
>> I'm really impressed and grateful for the time that you put into trying
>> to solve this question.
>>
>> Did ChatGPT provide the comments and variable names as well?
>>
>
> That was a direct cut and paste from the chat session. It provided
> anything.
>
>
>>
>> Do you think it 'created' that code or merely 'found it' already solved
>> by human brains?
>>
>
> I actually think it created the code. As a result of the chat, it needed
> to make adjustments to the orginal code. Also, I spent a LOT of time
> looking for an example like this one, in any form. If a clear one like this
> had existed, I believe I would have found it.
>
> Rick
>
>>
>> Jon
>>
>> On Mon, 23 Jan 2023 at 14:21, Rony G. Flatscher 
>> wrote:
>>
>>>
>>> On 23.01.2023 14:17, Mike Cowlishaw wrote:
>>> >
>>> >> "but still humans need to be able to
>>> >> understand and assess/control them otherwise humanity becomes
>>> >> helpless and dependent over time"
>>> > So it just happens earlier in life ...?  :-))
>>> Indeed! 
>>>
>>>
>>> ___
>>> 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
>
> ___
> 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

Re: [Oorexx-devel] I think I've seen the future...

[Rick McGuire]

On Mon, Jan 23, 2023 at 9:34 AM Sahananda Sahananda 
wrote:

> Rick,
>
> Fascinating!
>
> I'm really impressed and grateful for the time that you put into trying to
> solve this question.
>
> Did ChatGPT provide the comments and variable names as well?
>

That was a direct cut and paste from the chat session. It provided anything.


>
> Do you think it 'created' that code or merely 'found it' already solved by
> human brains?
>

I actually think it created the code. As a result of the chat, it needed to
make adjustments to the orginal code. Also, I spent a LOT of time looking
for an example like this one, in any form. If a clear one like this had
existed, I believe I would have found it.

Rick

>
> Jon
>
> On Mon, 23 Jan 2023 at 14:21, Rony G. Flatscher 
> wrote:
>
>>
>> On 23.01.2023 14:17, Mike Cowlishaw wrote:
>> >
>> >> "but still humans need to be able to
>> >> understand and assess/control them otherwise humanity becomes
>> >> helpless and dependent over time"
>> > So it just happens earlier in life ...?  :-))
>> Indeed! 
>>
>>
>> ___
>> 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

[Oorexx-devel] I think I've seen the future...

[Rick McGuire]

Today in a FaceBook group I'm a member of, someone made a post about a
remarkable result obtained from ChatGPT. I decided I would check it out,
using a problem that I struggled with for two months, then gave up an
implemented a less than optimal solution that fixed the problem but was not
exactly secure.

The problem in question was the problem caused when the rexxapi daemon gpt
created by a process with elevated privledges, which prevented processes
with non-elevated privledges from connecting to the rexxapi daemon via the
named pipe. I struggled for several months trying figure out the Windows
documenation for the security APIs and a lot of time in StackOverflow
trying to find some examples I could adapt. I came up empty and ended up
creating the pipe with no security restrictions.

So, today I asked ChatGPT how to create a named pipe that only users of the
same process could connect to. It immediately gave me a program that
created the named pipe using the same code we were using at first that had
the elevated permissions issues. Not what I was looking for, but impressive
nontheless.

I told ChatGPT has issues communicating between processes with elevated
permissions. It agreed with me and produced a new program that I *think*
might be exactly what is needed to close the security hole. I was truly
amazed!

I don't know if I'm interested in fixing this myself, nor if I'll have the
time. However, I want to post the code suggested by ChatGPT in case anyone
else wants to adapt it to rexxapi communcations.

Rick

#include #include 
int main(){
HANDLE hPipe;
SECURITY_ATTRIBUTES sa;
PSECURITY_DESCRIPTOR pSD;
PACL pACL;
HANDLE hToken;
DWORD dwSize;
TOKEN_USER *pUser;
PSID pSid;
SID_NAME_USE eUse;
WCHAR szUser[256];
DWORD cchUser = sizeof(szUser) / sizeof(WCHAR);
WCHAR szDomain[256];
DWORD cchDomain = sizeof(szDomain) / sizeof(WCHAR);

// Open the access token associated with the current process.
if (!OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, ))
return GetLastError();

// Retrieve the size of the user SID.
if (!GetTokenInformation(hToken, TokenUser, NULL, 0, ))
{
DWORD dwError = GetLastError();
if (dwError != ERROR_INSUFFICIENT_BUFFER)
return dwError;
}

// Allocate memory for the user SID.
pUser = (TOKEN_USER *)malloc(dwSize);
if (pUser == NULL)
return ERROR_OUTOFMEMORY;

// Retrieve the user SID.
if (!GetTokenInformation(hToken, TokenUser, pUser, dwSize, ))
{
DWORD dwError = GetLastError();
free(pUser);
return dwError;
}

// Obtain the user name and domain name
if (!LookupAccountSid(NULL, pUser->User.Sid, szUser, ,
szDomain, , ))
{
DWORD dwError = GetLastError();
free(pUser);
return dwError;
}
// Create a new DACL.
if (!InitializeAcl(, sizeof(ACL), ACL_REVISION))
{
DWORD dwError = GetLastError();
free(pUser);
return dwError;
}

// Add an ACE to the DACL.
if (!AddAccessAllowedAce(pACL, ACL_REVISION, FILE_GENERIC_READ |
FILE_GENERIC_WRITE, pUser->User.Sid))
{
DWORD dwError = GetLastError();
free(pUser);
return dwError;
}


// Initialize a security descriptor.
if (!InitializeSecurityDescriptor(, SECURITY_DESCRIPTOR_REVISION))
{
DWORD dwError = GetLastError();
free(pUser);
return dwError;
}

// Set the DACL in the security descriptor.
if (!SetSecurityDescriptorDacl(, TRUE, pACL, FALSE))
{
DWORD dwError = GetLastError();
free(pUser);
return dwError;
}

// Initialize a security attributes structure.
sa.nLength = sizeof(sa);
sa.lpSecurityDescriptor = 
sa.bInheritHandle = TRUE;

// Create the named pipe.
hPipe = CreateNamedPipe(
L".\\pipe\\MyPipe",
PIPE_ACCESS_DUPLEX,
PIPE_TYPE_BYTE | PIPE_READMODE_BYTE | PIPE_WAIT,
PIPE_UNLIMITED_INSTANCES,
0,
0,
0,
);

if (hPipe == INVALID_HANDLE_VALUE)
{
DWORD dwError = GetLastError();
free(pUser);
return dwError;
}
else
{
free(pUser);
return 0;
}}
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question with ooRexx 5.0.0 and some error "Error:94.101 - Error connecting to 127.0.0.1 on port 5757: "No error"" while issuing a command

[Rick McGuire]

Just a shot in the dark, but is it possible you are accidentally picking up
the Regina version of rxqueue?

Rick

On Tue, Jan 10, 2023 at 10:20 AM Rony G. Flatscher 
wrote:

> Received the following rexxtry.rex session on a Windows 10 machine:
>
> C:\Users\Walter\Downloads\tmp\bsf4oorexx\install>*rexx rexxtry*
> REXX-ooRexx_*5.0.0*(MT)_64-bit 6.05 23 Dec 2022
> rexxtry.rex lets you interactively try REXX statements.
> Each string is executed when you hit Enter.
> Enter 'call tell' for a description of the features.
> Go on - try a few... Enter 'exit' to end.*command="java -cp . 
> JavaInfo4BSF4RexxInstallation | rxqueue"*
> ... rexxtry.rex on WindowsNT*address 
> system command**Error:94.101 - Error connecting to 127.0.0.1 on port 5757: 
> "No error"*rc = 101 .. rexxtry.rex on 
> WindowsNT
> exit
> C:\Users\Walter\Downloads\tmp\bsf4oorexx\install>
>
> It seems that a socket is tried to be opened which does not succeed and
> yield an error "94.101" which looks like a Rexx error number, but is not
> defined nor documented. The error string is in addition contradictive: "...
> Error connecting ..." and ending in "No error".
>
> What can be the cause, how could one overcome this problem?
>
> ---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

Re: [Oorexx-devel] Ad books not included in the (Windows) installation

[Rick McGuire]

On Sun, Jan 1, 2023 at 12:09 PM Rony G. Flatscher 
wrote:

> The following books do not get installed on Windows:
>
>1. ooconsole.pdf (not/never complete, leave out?)
>
> leave out

>
>1.
>2. oorexxbuild.pdf (up-to-date and helpful?)
>
> Not useful to the general user, leave out

>
>1.
>2. oosqlite.pdf (up-to-date and helpful?)
>
> oosqlite is not part of the install package, it shouldn't be included.

>
>1.
>2. ootest.pdf (up-to-date and helpful?)
>
> The tests are not part of the install package, it shouldn't be included.

>
>1.
>2. orxncurses.pdf
>
> orxncurses is only built for the unix variants. I should not be part of a
window install

>
>1.
>2. unixextensions.pdf
>
> ditto

>
>1.
>
> What do you think?
> ---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

Re: [Oorexx-devel] Release of ooRexx 5

[Rick McGuire]

I just discovered that I have a copy of the 4.1.3 PDFs. I'll send you a
copy.

Rick

On Sun, Dec 25, 2022 at 6:04 PM ooRexx  wrote:

> I have some god news and some bad news
>
> The good news:
>
> FreeBSD is now revision 12583, I rebuilt it manually
> macOS is also 12583, but now with the correct documentation
> Ubuntu22 has been renamed to Ubuntu2204 (to indicate LTS version)
>
> I set the date to 2022-12-23 so all installers have the same date (except
> Ubuntu for S390X, still revision 12506)
>
> The proposed download for Windows is Windows 64 bit,
> The proposed download for macOS now 5.0.0, not 4.1
> The proposed download for BSD is FreeBSD
> I did not indicate any Linux default since we have several platforms
>
> The bad news: My FTP client played me a trick and erased the entire
> oorexx-docs when I ordered it to delete oorexx-docs/5.0.0beta :-(
>
> I recreated oorexx-docs and uploaded 5.0.0 again and I have asked on
> Sourceforge to get the other folders back from a backup but I guess they
> are not so active over Christmas
>
> If anyone have copies of at least the latest version of the documentation
> for version 4 I would like to have a copy so I can upload it.
>
> If nothing else works I will rebuild it manually from source.
>
> Rony asked that no changes be made to the documentation right now, he
> wanted to do something first.
>
> I will reactivate Jenkins build system from trunk tomorrow.
>
>
> Hälsningar/Regards/Grüsse,
> ooRexx
> oor...@jonases.se
>
>
>
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad updating copyright statement in sources

[Rick McGuire]

In general, we only update the copyrights in the source files if they have
an update. It doesn't always get done, but it's ok if the files have
different copyright dates.

Rick

On Fri, Dec 23, 2022 at 5:34 AM Rony G. Flatscher 
wrote:

> Just noticed that there are plenty of files in the code area that have
> their copyright statements not updated to 2022.
>
> Question: shall we update the copyright notice there like we did for the
> documentation?
>
> If so, what patterns should we use for SysFileTree to look for existing
> copyright text that should be updated? E.g.:
>
> *.html *.txt *.rex *.cls *.?pp *.h
>
> ---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

Re: [Oorexx-devel] Another problem for the doc revision and a possible solution (Re: updateEntityValues with revision information

[Rick McGuire]

Updating the copyright date is another of those items that should have
taken place before creating the branch. In my opinion, it is useless to
include an SVN revision number in a release version of the documentation.
Once the release ships, that branch is frozen, so the SVN revision number
is essentially meaningless. That version of the docs will never be anything
else. Any new version will just be part of another release update, so it
really is uniquely identifiable by the release number information. I have
no objections to also including a date with the version information, but
again, there will be no other version associated with the current release
number.

Rick

On Thu, Dec 22, 2022 at 9:36 AM Rony G. Flatscher 
wrote:

> On 22.12.2022 14:58, Gilbert Barmwater wrote:
>
> Back in July (seems like years ago), I modified the ooRexx version of the
> document build tools.  As part of that effort, I did some work to have
> docprep.rex modify the VERSION and EDITION ENTITIES "on the fly" (Note only
> in the working copy).  Have a look in the tools/bldoc_orx folder at
> docprep.rex around line 130.  You will se that it uses a function
> getdocrev() which is in a separate file in the same folder: getdocrev.rex.
> It uses the SVN log command to determine the revision number and the
> revision date for the document name supplied as an argument.  It is well
> documented so a little time reading it will show how it works. This is just
> for additional information as we consider possible solutions.  Please ask
> any questions that you may have.
>
> Looked up your code (was not aware of that at all) and looked into
> getdocrev.rex which uses the "svn log" command with "-l 1". This will
> return the latest log entry in the form (used the current
> "docs/branches/5.0.0/rexxapi"):
>
> 
> r12568 | orexx | 2022-12-22 13:41:55 +0100 (Do., 22 Dez 2022) | 1 line
>
> add authors who committed as of late
> 
>
> As you can see the revision and date has today's value. The reason being
> that I updated the Author_Group.xml file by adding Erich.
>
> Each time "rexxapi.ent" gets changed by your tool will cause a commit to
> at least set the log to that date, irrespectable of having changed any of
> the documentation xml files.
>
> ---
>
> In order to figure out the last change to the documentation files
> themselves is inspecting the xml files in rexxapi/en-US and gathering the
> newest commits from them. However, whenever rexxapi/en-US/rexxapi.ent
> changes or rexxapi/en-US/Author_Group.xml changes they would mostlikely be
> the latest commit.
>
> The documentation files themselves might been committed longer ago. If I
> understand the request correctly, then we want the latest revision of the
> documentation files (the xml files in rexxapi/en-US) instead. Doing so
> would bring up commit r12507 as of 2022-09-02 for the rexxapi book, not
> r12568 as of today.
>
> The utility svnListRevisions.rex that I committed two years ago would
> allow for gathering all commit information of all files in rexxapi/en-US
> and return an array where each commit is a Rexx object that can be
> interrogated for these commit-revision and commit-date attributes (and also
> for the author info) for each file. It uses "svn -r HEAD --xml
> --incremental list".
>
> ---
>
> Now another problem shows up: if we update the copyright year to the
> latest year in all those documentation xml files (not sure whether we are
> supposed to do that), then the logs for all those xml files will get
> updated on the next commit to reflect the change of the copyright
> information, not the content of the documentation file.
>
> Hence coming up with the idea of placing the "real" revision  information
> right in the rexxapi directory as a text file (that can also be manually
> changed). This allows one to check out all books revision information that
> is related to changing the documentation xml files. As long as copyright
> changes, or changes in rexxapi.ent or Author_Group.xml take place the
> content of "rexxapi/revision_info.txt" will be used for setting the
> revision information if employing "updateEntityValues.rex" which will
> update "rexxapi.ent" accordingly.
>
> In the case that a true content change gets made to any documentation xml
> files the author could change "rexxapi/revision_info.txt" manually.
>
> Alternatively, if we know that the content of any documentation xml file
> got changed we could eventually run "updateEntityValues.rex" with the "-r"
> switch for that book, but need previously to remove
> "rexxapi/revision_info.txt" such that svnListRevisions.rex gets employed to
> get the latest commit from the documentation files, which then will cause
> "rexxapi/revision_info.txt" to be created with that revision information.
>
> ... cut ...
>
> ---rony
>
> ___
> 

Re: [Oorexx-devel] "Stupid" question

[Rick McGuire]

On Thu, Dec 22, 2022 at 7:55 AM ooRexx  wrote:

> We are currently making all changes to
>
> /oorexx/code-0/docs/branches/5.0.0/
> /oorexx/code-0/main/branches/5.0.0/
>
> But the document where  to document the changes *release-steps.txt* is in
> the trunk
>
> /oorexx/code-0/main/trunk/
>
> Are we supposed to keep two separat SVN trees active while this is going
> on?
>

Yes, the branch is taken to be a frozen in time version where all changes
necessary to complete
the release can be made. The trunk version is now open for anybody to make
changes to add things
for the next feature release. The downside is some of the changes made to
the release branch also
need to be made to the trunk version. In theory, those sorts of things
should have been done before
creating the release candidate branch, but there's inevitably something
that slips through the cracks.

btw, we should probably add some notes about checking author lists, etc. as
changes that should be
made before creating the release candidate branch.

Rick

>
> I ask because this exercise is a "first" for me
>
> Hälsningar/Regards/Grüsse,
> ooRexx
> oor...@jonases.se
>
>
>
> ___
> 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

Re: [Oorexx-devel] docs Re: Ad current release 5.0.0

[Rick McGuire]

On Mon, Dec 19, 2022 at 11:54 AM Gilbert Barmwater 
wrote:

> OK, I can see that but in looking at the 4.2.0 Rexx Ref. document, I don't
> see them so I assumed they should go away.  Totally agree that they should
> come out of the trunk version.
>
We didn't start using them until Erich took over updating the docs in
5.0.0.

Rick



> Gil
> On 12/19/2022 10:22 AM, Rick McGuire wrote:
>
> No, the flags should still be there. Those are for the benefit of anybody
> making the upgrade. However, removing them from the trunk version should be
> added to the release process checklist.
>
> Rick
>
> On Mon, Dec 19, 2022 at 10:13 AM Gilbert Barmwater 
> wrote:
>
>> I have downloaded and installed the 5.0.0 Release Candidate and noticed
>> that the docs still have the *CHG* and *NEW* flags in them.  I believe
>> they are normally removed once a release is made but I am not sure what
>> the process is to make that happen.  Can anyone comment on this?  BTW,
>> the code is running without problem.
>>
>> Gil
>>
>> On 12/19/2022 8:37 AM, ooRexx wrote:
>> >> On 19. Dec 2022, at 11:23, Rony G. Flatscher 
>> wrote:
>> >>
>> >> Dear P.O.,
>> >>
>> >> On 18.12.2022 22:42, ooRexx wrote:
>> >>> Regarding the documentation I have merged 5.0.0html and 5.0.0beta
>> into 5.0.0beta and then copied all into 5.0.0_Release_Candidate. Everything
>> amended from this point on should arrive in 5.0.0_Release_Candidate only.
>> >> great, thank you very much!
>> >>
>> >> Would it be possible to rename the zip-files such that they end in
>> "-html.zip" as was done for 4.2.0, e.g. instead of "rexxref.zip" it should
>> read "rexxref-html.zip"?
>> > I have done that, both for 5.0.0beta and for 5.0.0_Release_Candidate. I
>> amended the build scripts so that for the future it will stay like that.
>> >
>> > At the same time I removed rexxgtk from the documentation. It will also
>> not be built in the future; it you want to revive it let me know and I will
>> add it again.
>> >
>> >> This way it is clear for the uninitiated that the zip-archives contain
>> the html-rendering of the documentation as opposed to the pdf-files
>> ("rexxref.pdf").
>> >>
>> >> ---
>> >>
>> >> @Terry: in the context of rehauling the oorexx.org page we could make
>> all the html-documentation available from that site which eventually would
>> make it possible to hit the ooRexx documentation via search engines.
>> >>
>> >> ---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
>>
>
>
> ___
> Oorexx-devel mailing 
> listOorexx-devel@lists.sourceforge.nethttps://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

Re: [Oorexx-devel] docs Re: Ad current release 5.0.0

[Rick McGuire]

No, the flags should still be there. Those are for the benefit of anybody
making the upgrade. However, removing them from the trunk version should be
added to the release process checklist.

Rick

On Mon, Dec 19, 2022 at 10:13 AM Gilbert Barmwater 
wrote:

> I have downloaded and installed the 5.0.0 Release Candidate and noticed
> that the docs still have the *CHG* and *NEW* flags in them.  I believe
> they are normally removed once a release is made but I am not sure what
> the process is to make that happen.  Can anyone comment on this?  BTW,
> the code is running without problem.
>
> Gil
>
> On 12/19/2022 8:37 AM, ooRexx wrote:
> >> On 19. Dec 2022, at 11:23, Rony G. Flatscher 
> wrote:
> >>
> >> Dear P.O.,
> >>
> >> On 18.12.2022 22:42, ooRexx wrote:
> >>> Regarding the documentation I have merged 5.0.0html and 5.0.0beta into
> 5.0.0beta and then copied all into 5.0.0_Release_Candidate. Everything
> amended from this point on should arrive in 5.0.0_Release_Candidate only.
> >> great, thank you very much!
> >>
> >> Would it be possible to rename the zip-files such that they end in
> "-html.zip" as was done for 4.2.0, e.g. instead of "rexxref.zip" it should
> read "rexxref-html.zip"?
> > I have done that, both for 5.0.0beta and for 5.0.0_Release_Candidate. I
> amended the build scripts so that for the future it will stay like that.
> >
> > At the same time I removed rexxgtk from the documentation. It will also
> not be built in the future; it you want to revive it let me know and I will
> add it again.
> >
> >> This way it is clear for the uninitiated that the zip-archives contain
> the html-rendering of the documentation as opposed to the pdf-files
> ("rexxref.pdf").
> >>
> >> ---
> >>
> >> @Terry: in the context of rehauling the oorexx.org page we could make
> all the html-documentation available from that site which eventually would
> make it possible to hit the ooRexx documentation via search engines.
> >>
> >> ---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
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] "rexxgtk" and release 5.0.0

[Rick McGuire]

+1

On Mon, Dec 19, 2022 at 5:53 AM Rony G. Flatscher 
wrote:

> There is a current question on
> "
> https://sourceforge.net/p/oorexx/discussion/general/thread/94d8616a49/?limit=25#19b3;
> about rexxgtk
> being included or not in the release.
>
> The documentation "rexxgtk.pdf" gets installed on my PC and in its
> installation section describes
> Linux and Windows. One is supposed to '::requires "rexxgtk.cls"' to get
> access to it, however there
> is no "librexxgtk.so" on my Ubuntu Linux nor "librexxgtk.dll" on Windows.
>
> AFAIK originally this library got created by David Ashley, but I have no
> memory about anyone else
> having worked on it or what its state would be.
>
> As such I would propose to not install "rexxgtk.pdf" as the missing
> shared/dynamic library does not
> get installed either in the ooRexx 5.0.0 release.
>
> What do you think?
>
> ---rony
>
> P.S.: As gtk is doubtlessly important it would be great if some of the
> Unix gurus would look into
> it, check out the code and state and advice.
>
>
> ___
> 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

Re: [Oorexx-devel] Ad current release 5.0.0 work

[Rick McGuire]

except for the change for api/oorexxapi.h, the rest of the stuff only
applied to the old build system.

Rick

On Thu, Dec 15, 2022 at 11:53 AM ooRexx  wrote:

> I also found this info, I would be happy if someone worked through this
>
> Read Me
>
> When changing the version number of ooRexx you will need to change the
> following files:
>
> oorexx.ver
> configure.ac
> CHANGES
> ReleaseNotes
> api/oorexxapi.h (REXX_INTERPRETER_5_x_x)
> extensions/rxftp/rxftp.cls
> platform/unix/rexx.1
> platform/unix/rexxc.1
> platform/unix/rxqueue.1
> platform/unix/rxsubcom.1
>
> When the library interface changes you need to modify the oorexx.ver
> file. BE CAREFUL! Some of this info has no relationship to the ooRexx
> package
> version! If you don't know what you are doing, then don't do anything!
>
>
> Tree [r12545] / test / branches / 5.0.0 /
>
> Hälsningar/Regards/Grüsse,
> ooRexx
> oor...@jonases.se
>
>
>
> > On 15. Dec 2022, at 17:49, Rony G. Flatscher 
> wrote:
> >
> > Will be away from my office from tomorrow until Monday such that I may
> not be able to do additional work at the moment (should be able to follow
> the e-mail though).
> >
> > So if someone would be able to update main/branches/5.0.0/CHANGES that
> would be great!
> >
> > ---
> >
> > Also main/branches/5.0.0/NOTICE (do we have a need to update the
> copyright year 2010 to 2022?) and main/branches/5.0.0/INSTALL may need
> updates.
> >
> > ---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

Re: [Oorexx-devel] Release ooRxx 5.0.0: Step 2 URGENT

[Rick McGuire]

On Thu, Dec 15, 2022 at 10:15 AM P.O. Jonsson  wrote:

> I am a bit confused so could someone (Rony?) please let me know what I
> should change for Jenkins? At the moment the commits are processed but they
> may be going to the wrong place. Please fill in the new places below. I
> will add this to the todo list once it is complete
>
>
> Build Repository URL
>
> https://svn.code.sf.net/p/oorexx/code-0/main/trunk
>

That's the trunk. You need to be building from the release candidate
branch: https://svn.code.sf.net/p/oorexx/code-0/main/branches/5.0.0


>
> Test Repository URL
>
> https://svn.code.sf.net/p/oorexx/code-0/test/trunk
>

We haven't yet branched the tests, but we probably should. For now, this is
correct.


>
> Documentation Repository URL
>
> https://svn.code.sf.net/p/oorexx/code-0/docs/trunk
>

Again, you need to be building from the release candidate, not trunk:
https://svn.code.sf.net/p/oorexx/code-0/docs/branches/5.0.0


>
> The upload of docs go to (two folders, PDF and html)
>
> /oorexx-docs/5.0.0beta'
> /oorexx-docs/5.0.0html'
>
>
> The upload of  artifacts go to
>
> sourceforgeFiles = "/home/frs/project/oorexx/oorexx/5.0.0beta"
>
> The following artifacts are selected for upload:
> ooRexx-CentOS9-build
> ooRexx-Debian11-build
> ooRexx-Fedora35-build
> ooRexx-FreeBSD13-build
> ooRexx-linux-aarch64-build
> ooRexx-LinuxMint20-build
> ooRexx-macOS11-build
> ooRexx-macOS12-build
> ooRexx-NetBSD9-build
> ooRexx-OpenBSD7_1-build
> ooRexx-OpenIndiana-build
> ooRexx-OpenSuse15-build
> ooRexx-RaspberryPiOS32-build
> oorexx-ubuntu16-build
> oorexx-ubuntu16debug-build
> ooRexx-Controller-Ubuntu20-build
> ooRexx-Ubuntu22-build
> ooRexx-windows32-build
> ooRexx-windows64-build
> ooRexx-Z-build
>
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
>
> Am 15.12.2022 um 15:53 schrieb Gilbert Barmwater :
>
> Just one more comment that I feel should not be overlooked.  As we review
> the "accepted" items we may find a small change - adding a test or updating
> the docs - would allow the status to be upgraded to "pending".  If that is
> the case and those changes are made, they MUST be made in TWO places - the
> "branches" subtree AND the "trunk".  Otherwise they will only apply to the
> 5.0.0 release and 5.1.0 will NOT contain them.  This may be obvious but it
> is too easy to overlook.
>
> Gil
> On 12/15/2022 9:30 AM, Rick McGuire wrote:
>
>
>
> On Thu, Dec 15, 2022 at 9:26 AM Rony G. Flatscher 
> wrote:
>
>> On 15.12.2022 11:24, Rick McGuire wrote:
>>
>> One more TODO. The CHANGES file needs to be finished off. It's in decent
>>> shape but is definitely missing some of the recent changes.
>>>
>> Added it to the "release-steps.txt" file: please note, there are a few
>> entries with "??" in the first two columns where I was not sure whether
>> that is correct that way.
>>
>> Looking through the Tickets (bugs, feature-requests, documentation,
>> patches) I notice that some tickets have a status of "accepted". Shall
>> these be added to the CHANGES file in branches/5.0.0 as well, or only the
>> ones with a status of "pending"?
>>
> Accepted means that there's still some work pending on the item, generally
> either doc or test work. It usually means the code changes have been
> committed, so they should be included.
>
>
>
>> After finalizing the CHANGES file in branches/5.0.0 should all "pending"
>> tickets be changed to "closed" and the CHANGES file in trunk be "emptied"
>> to allow for adding what is new while working on 5.1.0?
>>
> Yes.
>
>
>> ---rony
>>
>>
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>
>
> ___
> Oorexx-devel mailing 
> listOorexx-devel@lists.sourceforge.nethttps://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
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Release ooRxx 5.0.0: Step 2

[Rick McGuire]

On Thu, Dec 15, 2022 at 9:26 AM Rony G. Flatscher 
wrote:

> On 15.12.2022 11:24, Rick McGuire wrote:
>
> One more TODO. The CHANGES file needs to be finished off. It's in decent
>> shape but is definitely missing some of the recent changes.
>>
> Added it to the "release-steps.txt" file: please note, there are a few
> entries with "??" in the first two columns where I was not sure whether
> that is correct that way.
>
> Looking through the Tickets (bugs, feature-requests, documentation,
> patches) I notice that some tickets have a status of "accepted". Shall
> these be added to the CHANGES file in branches/5.0.0 as well, or only the
> ones with a status of "pending"?
>
Accepted means that there's still some work pending on the item, generally
either doc or test work. It usually means the code changes have been
committed, so they should be included.



> After finalizing the CHANGES file in branches/5.0.0 should all "pending"
> tickets be changed to "closed" and the CHANGES file in trunk be "emptied"
> to allow for adding what is new while working on 5.1.0?
>
Yes.


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

Re: [Oorexx-devel] Release ooRxx 5.0.0: Step 2

[Rick McGuire]

>
>
> Another suggestion. Create a file in the root directory of the trunk
> detailing all of the steps taken to make the release and update it
> immediately for every action that is taken for making the release. That
> will result in a fairly easy to follow checklist in a known location that
> can be followed in the future.


Rick
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Release ooRxx 5.0.0: Step 2

[Rick McGuire]

>
> One more TODO. The CHANGES file needs to be finished off. It's in decent
> shape but is definitely missing some of the recent changes.


Rick
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Release ooRxx 5.0.0: Step 2

[Rick McGuire]

How about calling it "5.0.0 Release Candidate"?

Rick

On Thu, Dec 15, 2022 at 5:01 AM P.O. Jonsson  wrote:

>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
>
> Am 15.12.2022 um 09:00 schrieb Rony G. Flatscher  >:
>
> Thanks to Rick we got the version information updated in trunk (
> 
> ).
>
> Todos:
>
>- add "#define REXX_INTERPRETER_5_1_0  0x00050100" to trunk's
>api/oorexxapi.h
>
>- on Sourceforge create "files/oorexx/5.1.0beta" to receive the new
>builds from trunk
>
>- change branches/5.0.0 such that release builds
>
>- set debug to .false in .rexxinfo
>
>   - and "rexx -v" does not append the string "- Internal Test
>   Version" to the first line
>
>   - on Sourceforge create "files/oorexx/5.0.0gamma" to receive the
>new builds from branches/5.0.0, this directory will be removed before
>producing the final release installation packages for which then the
>directory "files/oorexx/5.0.0" gets created and staged for three days such
>that the developers can test the location and prepare supporting materials
>like list of changes since the last release, announcements and such
>
> If can rename 5.0.0.Beta to 5.0.0 already now, is that a problem? I will
> amend the scripts to upload there until we have a new beta. I do not know
> how to „Stage“ it, if I rename it the change will be visible automatically.
> I can put a text warning in there until it is an official release though.
>
> 5.0.0Gamma sounds weird, I never had a software in „Gamma“. Why not simply
> call it 5.1.0alfa (or beta), this is where the rolling version will go once
> the version in 5.0.0 is frozen.
>
>
>-
>
> ---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

Re: [Oorexx-devel] Release ooRexx 5.0.0: Step 1 (Re: Proposal for creating a release version for ooRexx 5.0.0

[Rick McGuire]

On Wed, Dec 14, 2022 at 2:05 PM Gilbert Barmwater 
wrote:

> I seem to remember, perhaps incorrectly, that there was some documentation
> on the steps necessary in order to create a new release of ooRexx.
> However, my cursory attempt at locating it has come up empty.  If anyone
> else remembers such a document and, more importantly, where it is, please
> let us know.  In our attempt to get 5.0.0 "out the door", I would hate to
> think that we might be making mistakes either of omission or commission.
> Just my two cents worth.
>
I have a vague memory of doing this after the 4.2.0 release, but I don't
remember where it was. I believe it was just an email to this list, but a
cursory search didn't turn up anything. I suspect a lot of that information
was made obsolete by moving to the cmake-based build.

Rick



> Gil
> On 12/14/2022 12:39 PM, Rony G. Flatscher wrote:
>
> Hi P.O.,
> On 14.12.2022 16:06, P.O. Jonsson wrote:
>
>
> Am 14.12.2022 um 15:41 schrieb Rony G. Flatscher  >:
>
> @P.O.: is it possible for you to have the Jenkins creations work on
> /docs/branches/5.0.0 and main/branches/5.0.0?
>
> Yes, I can do the necessary changes to the Jenkins build and test scripts
> as well as to the uploading scripts for the Artifacts and the Documentation
> when we are ready.
>
> Super!
>
> We will need to look whether and what we need to change in the
> documentation and installation production for ooRexx 5.0.
>
> Also an idea: once we have the installation packages for all the operating
> systems created it may be helpful for people wishing to evaluate ooRexx
> 5.0.0 without installing it to create portable versions of those packages
> (make portable) and place the resulting zip-archives either in a
> subdirectory "portable" or into a different location in the files menu.
> This may prove helpful for future versions as well as starting with ooRexx
> 5.0.0 there may be different versions usable in parallel/concurrently.
>
> Anyone who gives a helping hand is highly appreciated! :)
>
> Ideally we should have a 5.0.0 folder on sourceforge for the frozen
>  „Release“ version and then a 5.0.1beta for all the work committed to the
> next release. I assume there is a lot of work to be done with the status of
> all bug reports as well, I have no experience of these parts so I hope
> someone else can come forward for doing that.
>
> Yes, this has a little time though. When creating a new folder there is an
> option for staging it for three days which means that we as developers can
> use it, but no one would see it. This allows us to experiment and to change
> the content of that directory.
>
> Until then (next week?) I would not change anything there at this point in
> time.
>
> ---
>
> Also, we probably need to increase the version number of ooRexx in trunk
> from 5.0.0 probably to 5.1.0 and the standard installation packages
> produced by Jenkins would then go to "5.1.0beta"?
>
> Are there other changes we should apply to trunk?
>
> ---rony
>
>
>
>
> ___
> Oorexx-devel mailing 
> listOorexx-devel@lists.sourceforge.nethttps://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

Re: [Oorexx-devel] 4.2/5.0 Coexistence on Windows

[Rick McGuire]

Details:

1) Install both versions.
2) in the command line where you want to run oorexx, set the path to point
to the appropriate version.
3) Run that version.

The big issue with using multiple versions was always rxapi. With that
problem being resolved in 5.0.0, the two versions can happily coexist.

Rick

On Mon, Dec 5, 2022 at 2:29 PM Gilbert Barmwater 
wrote:

> A recent discussion on RFE 715 led to the question of whether or not
> ooRexx 4.2.0 and 5.0.0 could coexist on a system.  I am starting this
> thread to hopefully expose the discussion to a larger audience.  As my
> experience is restricted to Windows systems, I am restricting the subject
> to that environment but the question certainly applies to non-Windows
> systems as well.  Anyone with expertise in those environments should start
> a parallel thread to extend the discussion to them as well.
>
> I guess the first question that comes to mind is why one would want to
> have both 4.2 and 5.0 on their system at the same time.  One scenario that
> comes to mind is the case where a system is being used in a production
> environment using 4.2 but there is interest in moving to 5.0 when it
> becomes GA.  So having the ability to test the production programs under
> 5.0 before that while still running the 4.2 production programs would be
> beneficial and accelerate the time to needed to make the transition once
> 5.0 goes GA.  I'm sure there are other cases as well and I would be happy
> to hear them.
>
> So the simple answer to the question was provided by Rick: "Actually, with
> the changes to how rxapi communicates in 5.0.0, they coexist quite nicely.
> They can both be active at one time."  As always, the devil is in the
> details!  I'll get into those details in the next post.
>
> Gil
>
>
> ___
> 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

Re: [Oorexx-devel] ooRexx /dev/null for redirected command handler

[Rick McGuire]

-1. This would require a change to the .Monitor class beyond it's original
intent. However, this is easily accomplished already with a simple custom
class:

::class nullOutput
::method say
::method linout

Use that as the target and the output will be discarded.

Rick

On Sat, Dec 3, 2022 at 1:22 PM Rony G. Flatscher 
wrote:

> Redirecting stdout and stderr on the commandline allows one to redirect to
> the null device (on Windows "nul", on Unix "/dev/null"), e.g.
>
> someCommand >nul  (Windows)
> someCommand >/dev/null(Unix)
>
> someCommand 2>nul (Windows)
> someCommand 2>/dev/null   (Unix)
>
>
> There are redirections where the same need occurs with redirected command
> handlers. Therefore it would be helpful, if .nil could be used as the null
> device on ooRexx redirected commands such that ooRexx would ignore any
> output to that destination.
>
> Something like
>
> address system 'some command' with error using (.nil)
>
> or
>
> address system 'some command' with output using (.nil)
>
> instead of
>
> errArr=.array~new
> address system 'some command' with error using (errArr)
>
> where "errArr" never would get used in the Rexx program.
>
> or
>
> outArr=.array~new
> address system 'some command' with output using (outArr)
>
> where "outArr" never would get used in the Rexx program.
>
> ---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

Re: [Oorexx-devel] Jenkins

[Rick McGuire]

On Sun, Nov 13, 2022 at 5:57 AM Mike Cowlishaw  wrote:

>
>
>
> I'm not familiar with internals of ooRexx, but reading this:
>
> I tried to "tune" Virtualbox to get rid of the timing error
> problems but every attempt actually made things worse, with
> more than half of the timing tests failing. I have reset
> Virtualbox to default values now. What *DID* help on the
> other hand was to deprive the VMs of resources. Changing from
> 2 cores/4 GB memory to 1 core/ 2 GB memory made all *nixes
> pass all tests, so it looks like the problem were related to
> Virtualbox rather than to ooRexx. Only exception are the
> BSDs, that are still a bit problematic to test. But all
> platforms (Win macOS Linux Unix) build without error now.
>
>
> makes me wonder a bit: by reducing to one core then anything multithreaded
> is forced to run on a single thread which makes race conditions much less
> likely than when on multicore where multiple threads can run
> simultaneously.
>
> ooRexx is not truly multithreaded. Only one thread at a time is allowed to
run Rexx code at a time, with a cooperative internal dispatch mechanism.
Only threads running external code (e.g., calls to native libraries or
running commands) truly run concurrently.  Multiple cores might affect the
timing of which thread happens to get permission to run next, but which
thread gets permission has always been unpredictable.



>
> Which means that there can be no unexpected time glitches between threads
> since they run consecutively on one core. And that ooRexx handles any such
> race conditions GREAT. This shows IMO how robust ooRexx 5 has become. Gold
> standard ;-)
>
> Right, but in the real world it will be running on multicore machines...
>

The failing test cases run just fine on multicore machines, they only seem
to fail in multicore virtual machines. Also, the failures don't really
appear to be race conditions, but rather checks in timer values that are
falling outside expected ranges. There's something funny going on with the
clocks in the virtual machines in those situations.



>
> Mike
> ___
> 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

Re: [Oorexx-devel] ADDRESS using environment stored in a variable to run command?

[Rick McGuire]

On Wed, Sep 28, 2022 at 1:06 PM Rony G. Flatscher 
wrote:

> There are use cases where one wishes to address different environments
> with commands where the desired target environment is stored in a variable.
>
> Something like:
>
> address var cmd
>
> where some variable VAR may resolves to a string with the possible values
> "A", "B", "SYSTEM", "C" and some variable CMD resolves to a string that
> gets sent to the environment referred to by VAR.
>
> Currently it seems that one either has to verbatimely denote the
> environment, e.g.
>
> address A commandForA
> ... address environment and command change
> address SYSTEM CMD
> ... address environment and command change
> addrexx XYZ CMD
> ...
>
> or use "address value" and use the command:
>
> address value (VAR)
> CMD
> ... address environment and command change
> address value (VAR)
> CMD
> ...
>
> What may be desirable in the case many different environment handlers
> exist would be a solution like:
>
> addresss (VAR) CMD
> ... address enviornment and command change
> address (VAR) CMD
> ...
>
> This would mean to allow the environment to be denoted in additiony by an
> expression in parentheses (this would follow e.g. the pattern found in the
> FORWARD keyword statement).
>
> The documentation would need to be changed from "To send a single command
> to a specified environment, code an environment, a literal string or a
> single symbol, which is taken to be a constant, ..." to "To send a single
> command to a specified environment, code an environment, a literal string,
> a single symbol, which is taken to be a constant,  *or an expression in
> parentheses*, ..." .
>
> Would that be an acceptable RFE for the ADDRESS keyword instruction?
>
Not particularly, because it represents an incompatible syntax change. What
you are proposing is already accepted syntax by the ADDRESS instruction,
covered by the

ADDRESS expr

form.

Rick



> The reason/motivation for this is a real world application of deploying
> multiple environment handlers in a single Rexx program and sending commands
> to the different environment handlers (the result of one command handler
> should be immediately processed by another command handler, maybe edited by
> the program in between).
>
> ---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

Re: [Oorexx-devel] Problem with redirected command handler

[Rick McGuire]

Or more specifically, the targets identified with ADDRESS WITH are
reevaluated in the current context each time a command is issued. If the
variable context has changed, ARRAYOUTPUT evaluates to a string object,
which is not a valid output target.

Rick

On Mon, Sep 26, 2022 at 9:12 AM Erich Steinböck 
wrote:

> This works as designed. Redirection objects most be accessible at the time
> the command is executed.
> ___
> 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

Re: [Oorexx-devel] checking haveHaltCondition

[Rick McGuire]

Those places are all on the other side of the API wall. There’s no way to
access that.

On Sun, Sep 11, 2022 at 12:26 PM Erich Steinböck 
wrote:

> It would be beneficial if long-running tasks like writing/reading/sleeping
> implemented in native code could check whether a Halt condition was raised
> and return early if so.
>
> How does code like SysFile::write or SysThread::longSleep get access to
> its Activation settings, so that it can call haveHaltCondition to check?
>
> Thanks!
> ___
> 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

Re: [Oorexx-devel] Question ad redirection handlers and input, output, error ...

[Rick McGuire]

Nothing. If redirection is not active, then ooRexx is not handling the
input and output.

Rick

On Sat, Sep 3, 2022 at 5:21 AM Rony G. Flatscher 
wrote:

> In a redirection handler it may be the case that redirection is not active
> for the invocation
> (isRedirectionRequested() returns false).
>
> Question: if redirection is not active, what happens if one still uses
> ReadInput[Buffer](),
> WriteOutput[Buffer](), WriteError[Buffer]()? Will ReadInput[Buffer]() read
> from stdin,
> WriteOutput[Buffer]() write to stdout and WriteError[Buffer]() write to
> stderr?
>
> ---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

Re: [Oorexx-devel] Question ad exit "1.15.2.4. RXCMD"

[Rick McGuire]

On Tue, Aug 30, 2022 at 11:07 AM Rony G. Flatscher 
wrote:

> While testing a RXMCD exit, implemented in Java and preconfigured for the
> Rexx instance, commands trigger the exit, however the DLL information is
> not supplied, but empty (expecting "BSF4ooRexx850.dll" as that is the
> library that contains the callback function).  Also, trying it with
> AddCommandEnvironment()-API would not supply the dll name.
>
> The sequence is: a Java program loads and configures a Rexx instance,
> setting a RXCMD exit handler (implemented in Java) and a
> RexxRedirectingCommandHandler (implemented in Java), the callback functions
> are in the native DLL ("BSF4ooRexx850.dll"). Both handlers get invoked, the
> RXCMD exit handler does not get a dll name (it is empty).
>
> In addition, the exit intercepts also commands to CMD, however the dll
> name is empty as well.
>
> rexxapi.pdf says among other things:
>
> Example 1.43. API — Rexx_IO_Exit parameter list
> typedef struct {
> struct { /* Condition flags */
>unsigned rxfcfail : 1; /* Command failed. Trap with */
>/* CALL or SIGNAL on FAILURE. */
>unsigned rxfcerr : 1; /* Command ERROR occurred. */
>/* Trap with CALL or SIGNAL on */
>/* ERROR. */
> } rxcmd_flags;
> const char * rxcmd_address; /* Pointer to address name. */
> unsigned short rxcmd_addressl; /* Length of address name. */*const char *   
> rxcmd_dll; /* dll name for command. */**unsigned short rxcmd_dll_len; /* 
> Length of dll name. 0 ==> */**  /* executable 
> file. */*
> CONSTRXSTRING rxcmd_command; /* The command string. */
> RXSTRING rxcmd_retc; /* Pointer to return code */
> /* buffer. User allocated. */
> } RXCMDHST_PARM;
>
> What does "Length of dll name. 0 ==> executable file" mean, when would
> that take effect? Is there anything I need to/can do to get at the DLL-name
> in the exit?
>
Nothing, it appears. I don't know what that field was every used for, and
from the documentation, it sounds like it was intended for something other
than the dll name of the exit. This is born out by the fact that the other
exits that can be registered as dlls don't have that field. However, as far
back as 3.1.2, it has always been set to null.

Rick



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

Re: [Oorexx-devel] Question ad ADDRESS keyword statement

[Rick McGuire]

No, it should not, at least not the way you are expecting. This falls into
the

address expression

branch of the syntax diagram, which can only be used to change the current
address target and not to issue a command. The new address environment is
set to "TEST ping", the result of evaluating the entire expression.

Rick

On Thu, Aug 25, 2022 at 11:27 AM Rony G. Flatscher 
wrote:

> Should the following ADDRESS statement work?
>
> environment="TEST"
> say 'environment:' pp(environment)
> say .line "command:" pp(sourceline(.line+1))*address (environment) "ping"*
> say " RC:" pp(rc) ".rs="pp(.rs) "| RESULT="pp(result)
>
> Running the above ADDRESS keyword statement seems to have no effect at
> all, here is the output:
>
> environment: [TEST]
> 49 command: [address (environment) "ping"]
>  RC: [RC] .rs=[.RS] | RESULT=[RESULT]
>
> It is as if this form of the address statement gets ignored (the
> environment handler for TEST does not get invoked).
>
> ---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

Re: [Oorexx-devel] Ad WriteOutput(), ErrorOutput()

[Rick McGuire]

They absolutely do not add linends to the date. The supplied data gets
converted into a string and is appended to the array with no additional
processing. If there are extra linends, it's because you left them on the
line before making the call. WriteError() and WriteOutput() assume you have
done any linend processing yourself, WriteXXXBuffered() assumes you are
writing a buffer of data with individual lines separated by linends and the
separation is handled for you.

Rick

On Thu, Aug 25, 2022 at 8:28 AM Rony G. Flatscher 
wrote:

> WriteOutput() and ErrorOutput()-APIs add a trailing .endofline character
> to the data that get output.
>
> E.g. if "out=.array~new" and using it for output redirection, then doing
> two times 'WriteOutput("abc")' (causing a total of two items to be output)
> and upon return to Rexx "say '['out~makeString']'" will cause the following
> surprising output:
>
> [abc
>
> abc
> ]
>
> Using Rexx only:
>
> out=.array~new
> out~~append("abc")~~append("abc")
> say '['out~makeString']'
>
> yields:
>
> [abc
> abc]
>
> So changing/processing the supplied data by appending an .endofline should
> not occur with WriteOutput() and ErrorOutput().
>
> ---rony
>
> P.S.: ReadInput() will read and return the data unchanged/unprocessed,
> even if it contains .endofline (which in Rexx e.g. array[i]  would do as
> well, returning the stored item unchanged).
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad ReadInputBuffer

[Rick McGuire]

Yes, all of the lines get terminated by an eol marker.

Rick

On Mon, Aug 22, 2022 at 2:10 PM Rony G. Flatscher 
wrote:

> When reading with ReadInputBuffer() from input that has only one element,
> then this function appends
> .endOfLine nevertheless. Eg. a single input item like the string "one"
> becomes "one"||.endofline
>
> Is this intentionally?
>
> ---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

Re: [Oorexx-devel] Question ad Write{Output|Error}Buffer

[Rick McGuire]

The data written is split at linend boundaries.

Rick

On Thu, Aug 18, 2022 at 6:01 AM Rony G. Flatscher 
wrote:

> The Write{Output|Error}Buffer API states:
>
> Adds a string composed of strings separated by the platform-specfic
> line-end characters as separate
> items or lines to an output redirection Rexx object that was specified
> using the WITH subkeyword of
> an ADDRESS instruction.
>
> Is there any processing done on the received data or does the
> Write{Output|Error}Buffer-API just take the receive data as is and place it
> as a single item to the output sink? In this case it would become possible
> to produce binary data as a result of a command (and will motivate the need
> of an additional API on the Java side to become able to distinguish between
> Strings (Reader,Writer, codepage dependent) and Streams (byte oriented, raw
> data)).
>
> ---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

Re: [Oorexx-devel] SendMessageScoped incomplete condition object (line number seems to be missing)?

[Rick McGuire]

There's no line number because you're sending the message from native code.
There's nothing to fill in that case.

Rick

On Mon, Aug 15, 2022 at 7:31 AM Rony G. Flatscher 
wrote:

> It seems that the condition object returned by SendMessageScoped() misses
> the line number information as the entry cond.position contains 0, e.g.:
>
> Error 93 running 
> F:\work\svn\bsf4oorexx\branches\850\bsf4oorexx.dev\source_cc\BSF.CLS
> line *0*:  Incorrect call to method.
> Error 93.957:  Target object "a CLASS_LEVEL4" is not a subclass of the
> message override scope (The Array class).
>
> Other exceptions will supply the line/position value.
>
> Here the code
>
> ...
> RexxCondition cond;
> rtc->DecodeConditionInfo(condObj, );
> ...
> snprintf(line2, 2048, "Error %d running %.512s line *%d*:  %.1024s",
> (int) cond.rc,  (NULL != cond.program   && 
> rtc->Nil() != cond.program   ? rtc->CString( cond.program )  : "program n/a") 
>   ,
> *(int) cond.position*,(NULL != cond.errortext && 
> rtc->Nil() != cond.errortext ? rtc->CString( cond.errortext ): "errortext 
> n/a") );
> ...
>
> The same routine will supply the line number for other runtime errors
> (e.g. creating an arithmetic error like 1/0) from the supplied condition
> object via "context->GetConditionInfo()".
>
> ---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

Re: [Oorexx-devel] Observation with .routine's callwith and threadContext->RaiseException(...)

[Rick McGuire]

On Sun, Aug 14, 2022 at 8:17 AM Rony G. Flatscher 
wrote:

> On 14.08.2022 13:41, Rick McGuire wrote:
> > - The method NativeActivation::checkConditions() is where the raised
> exceptions are processed when
> > your external routine returns. Understanding why that code is not
> raising the exception on the
> > calling Rexx code would be helpful.
>
> The conditionObj NativeActivation::checkConditions() is NULL right before
> returning.
>

That would suggest you are using the wrong context to raise the exception,
because the one you used was returning true for CheckCondition().
CheckCondition() just checks the value of the conditionObj variable.

Rick

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

Re: [Oorexx-devel] Observation with .routine's callwith and threadContext->RaiseException(...)

[Rick McGuire]

One question and a couple of suggestions.

- Is the AttachThread() being done on the same instance as the originating
rexx code where the call on syntax was made or a different instance.
- The method NativeActivation::checkConditions() is where the raised
exceptions are processed when your external routine returns. Understanding
why that code is not raising the exception on the calling Rexx code would
be helpful.
- This might be easier to debug if you can take Java completely out of the
picture. That is, have an external call that does an AttachThread(), does a
SendMessage(), does a DetachThread(), then does a RaiseException() with the
call context. I suspect you'll probably see the same problem, and that
simple type of scenario would be much easier to debug.

Rick

On Sun, Aug 14, 2022 at 7:24 AM Rony G. Flatscher 
wrote:

> Sorry, one thing is wrong in my synopsis (over the past days too many
> different test cases and attempts): the call to the Java side in this case
> is not carried out via the unknown method but directly with invoking the
> native routine BSF.
>
> ---
>
> The last thing I tried was making sure that in the native routine that
> creates the exception and carries out  RaiseException1()  that it would use
> the RexxCallContext everywhere (and not use RexxCallContext-threadContext
> which should work anyway). It did not change this observation.
>
> The use of SetContextVariable() in the native routine that creates the
> exception works and the variables are available upon return to the BSF
> unknown method.
>
> In the meantime I added a native method BsfCheckCondition() and calling it
> immediately upon return to the Rexx side returns .false/0.
>
> ---rony
> On 14.08.2022 12:47, Rony G. Flatscher wrote:
>
> O.K. before trying one more thing "in the dark" here a synopsis:
>
>- all calls are carried out on the same thread (no multithreading)
>- Rexx starts, using BSF4ooRexx Java gets demand loaded, the native
>code stores the primodal Rexx instance ("ri")
>- a Rexx program sends a message to a Java object (a BSF instance)
>- the BSF unknown method defines a 'signal on syntax' condition
>handler and sets up and carries out the call to the native routine BSF()
>- the native routine BSF() sets up and carries out the call into Java
>   - the Java method in this use case will cause a Rexx object to be
>   sent a message, in the course the native code
>  - ri->AttachThread(), sets up and carries out the call into Rexx
>  - a Rexx condition occurs causing a Java Throwable to be created
>  using the Rexx condition information
>  - ri->DetachThread()
>  - the Java Throwable gets thrown, control returns to Java
>  - the Java method returns to native code with the thrown Java
>   Throwable active (jenv->ExceptionCheck() returns true)
>   - the native code creates a Rexx exception using data from the Java
>   Throwable, adds the Java Throwable object to additional() to allow 
> access
>   from Rexx to it, then does a context->RaiseException1() wich is active
>   (tested with RexxCondition() immediately before returning from native 
> code
>   to Rexx); here to illustrate that section, both tests (using the
>   RexxCallContext and its contained threadContext) return true:
>
>   #if defined (DEBUG_BSF_FUNCTION)
>   fprintf(stderr, "*** *** DEBUG_BSF_FUNCTION: BSF() 5c: about to 
> return with NULL: context->CheckCondition()=%d | 
> context->threadContext->CheckCondition()=%d\n", context->CheckCondition(), 
> context->threadContext->CheckCondition());
>   fflush(stderr);
>   #endif
>   return NULLOBJECT;
>
>   - a return NULLOBJECT in native code returns to the Rexx caller
>   (the unknown method)
>   - the BSF unknown method does not transfer control to the syntax
>label, the condition has been cleared between returning from native code
>and transferring control back to the BSF unknown method
>
> ---rony
>
>
>
> On 12.08.2022 16:00, Rony G. Flatscher wrote:
>
> On 11.08.2022 21:13, Rony G. Flatscher wrote:
>
> In an ooRexx package there are the following statements:
>
> ... cut ...
>
> ::ROUTINE xBSF   PUBLIC   EXTERNAL "LIBRARY BSF4ooRexx BSF
>  "
>
> ... cut ...
>
> ::CLASS BSF
>
> ::ATTRIBUTE rBSF CLASS
>
> ::METHOD initCLASS
>   expose rBSF
>   rBSF =.routines["XBSF"]   -- fetch and store routine object
>   ... cut ...
>
> ::METHOD unknown UNGUARDED
>   ... cut ...
>   signal on syntax
>
>   self~class~rBSF~callWith(arr)  -- invoke external routine
>   return bsf.wrap(result)
> syntax:
>   ... cut ...
>   co=condition('o')
>   call ppJavaExceptionChain(co,.true)
>   raise propagate
>
> So a native routine BSF() gets defined and named in the package as the
> public routine xBSF which in the class constructor for the class BSF gets
> fetched from the .routines directory and stored as a routine 

Re: [Oorexx-devel] Question ad new ThrowException API...

[Rick McGuire]

On Sat, Aug 13, 2022 at 10:44 AM Rony G. Flatscher 
wrote:

> On 13.08.2022 15:16, Rick McGuire wrote:
>
> On Sat, Aug 13, 2022 at 8:45 AM Rony G. Flatscher 
> wrote:
>
>> E.g. rxapi.pdf "1.17.189. *NEW* ThrowException/0/1/2" states: "Throw a
>> SYNTAX condition. The API call doesn't return and the current method,
>> routine, or exit is exited immediately.".
>>
>> Testing ThrowException1() however will end the running Rexx program
>> immediately not the current call, here the calling sequence:
>>
>>- test.rex requires some testpkg.cls, creating an object o of a class
>>residing in testpkg.cls
>>- test.rex will send an unknown message with two arguemtns to o
>>causing the unknown method to call a routine in the native code
>>- the native code will cause a runtime exception to be thrown if one
>>of the two arguments has the value 1
>>
>> Using RaiseException1() will cause that exception to be raised and the
>> control gets back to the unknown method and then back to test.rex.
>>
>> Using ThrowException1() however will cause ending Rexx altogether as if
>> it causes not only the call to the native routine to be exited immediately,
>> but also the unknown method from which the call started and info.rex where
>> o's unknown method gets invoked from. Is that to be expected?
>>
> Are you using the correct context instance when calling ThrowExeption()?
> That's the behavior I would expect if an instance other than the context
> for the external call was used.
>
> Hmm, good question!
>
> Here is what is done in this test program (trying to get a small,
> self-contained example that would exhibit the reported behaviour, WIP):
>
>- define a RexxRoutine in native code that makes its RexxInstance
>globally available with 'ri', then calls a plain function with the
>following signature "RexxObjectPtr work(RexxCallContext *rcc, RexxObjectPtr
>o, int64_t val)"
>
>- work() will use the RexxInstance to carry out an
>ri->AttachThread() which will be used to send a message to the supplied
>object 'o'; if val has the value 1, then an unknown message gets sent to 
> 'o'
>
> Why are you doing an AttachThread()? This is totally unnecessary and
deactivates the current thread stack. Using the attached thread to raise an
exception will not percolate back to the calling routine because you just
drew a line in the sand. If you need to raise something in the caller, they
you will need to do a DetachThread() and use the original call context to
raise the exception.

Rick




>
>-
>- if rtc->CheckCondition() is true, then a debug message is shown
>   followed by the rcc->RaiseException1() call before returning; using
>   rcc->ThrowException1() instead ends the entire Rexx program as reported,
>   although the RexxCallContext gets used for it
>
>   - however, doing a rtc->DetachThread() before calling
>   rcc->ThrowException1() will yield the documented behaviour!
>
>
>
> This could also explain some of the problems you've been seeing with your
> calls.
>
> No, what happens in the bridge is the following:
>
>- for each Rexx instance a peer Java instance gets created. If there
>is a callback to Rexx the native code fetches the appropriate Rexx instance
>and carries out an AttachThread(), interact with ooRexx (e.g. sending an
>ooRexx object a message) and will do a matching DetachThread() prior to
>returning from the native code,
>
>- the invoked Rexx code (some Rexx method) may be calling back again
>into Java and if on the Java side there is a callback to Rexx needed, the
>same as above occurs recursively,
>
>- eventually returning from (possibly nesting) callbacks.
>
> In the case that a call to Java causes an exception to be thrown on the
> Java side an appropriate RaiseException gets prepared and raised such that
> upon return from Java that condition can be trapped on the Rexx side (and
> access to the Java Throwable becomes possible).
>
> The RaiseException gets prepared and raised in another native function
> that is written to deal with either a RexxCallContext or a RexxExitContext
> (Java implemented command and exit handlers are fully supported) with an
> argument indicating which type of context is currently supplied. In the
> past (and it used to work) RaiseCondition1() was invoked using the
> RexxThreadContext (fetching it e.g. with "((RexxCallContext *)
> argCtxt)->threadContext" to simplify the native code by using the
> threadContext for plain vanilla calls to e.g. ArrayPut, FindClass,
> NewArray, ReleaseLocalRef

Re: [Oorexx-devel] Question ad new ThrowException API...

[Rick McGuire]

On Sat, Aug 13, 2022 at 8:45 AM Rony G. Flatscher 
wrote:

> E.g. rxapi.pdf "1.17.189. *NEW* ThrowException/0/1/2" states: "Throw a
> SYNTAX condition. The API call doesn't return and the current method,
> routine, or exit is exited immediately.".
>
> Testing ThrowException1() however will end the running Rexx program
> immediately not the current call, here the calling sequence:
>
>- test.rex requires some testpkg.cls, creating an object o of a class
>residing in testpkg.cls
>- test.rex will send an unknown message with two arguemtns to o
>causing the unknown method to call a routine in the native code
>- the native code will cause a runtime exception to be thrown if one
>of the two arguments has the value 1
>
> Using RaiseException1() will cause that exception to be raised and the
> control gets back to the unknown method and then back to test.rex.
>
> Using ThrowException1() however will cause ending Rexx altogether as if it
> causes not only the call to the native routine to be exited immediately,
> but also the unknown method from which the call started and info.rex where
> o's unknown method gets invoked from. Is that to be expected?
>
Are you using the correct context instance when calling ThrowExeption()?
That's the behavior I would expect if an instance other than the context
for the external call was used. This could also explain some of the
problems you've been seeing with your calls.



> If so, when would one want to use ThrowException[0|1|2|3] over
> RaiseException[0|1|2|3]?
>

I would want to use it if I don't want to worry about unwinding my call
chain to do a normal return.

Rick


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

Re: [Oorexx-devel] A few questions ad new RexxIORedirectorContext *ioContext

[Rick McGuire]

On Tue, Aug 9, 2022 at 1:08 PM Rony G. Flatscher 
wrote:

> Trying to understand the native APIs and their purpose for the new
> redirecting environments. It
> still seems to be the case that any result can be returned and assigned to
> the RC variable.
>

Which has always been the case for command handlers.


>
> The question is about the usage of redirected input, output and error from
> the native side.
>
> Should one use e.g. ReadInput[Buffer](), WriteOutput[Buffer]() and
> WriteError[Buffer]() only if the
> respective redirection tests (IsRedirectionRequested() and
> IsInputRedirected()/IsOutputRedirected()/IsErrorRedirected()) return true?
>
Yes. While you don't have to, it's better to avoid the performance impact
associated with multiple interpreter callbacks that need to acquire the
interpreter lock. That's a pretty expensive noop.




>
> Would it be a fatal error to use e.g. Write{Error|Output}[Buffer]()
> although
> Is{Error|Output}Redirected() returns false? What would happen in such a
> case; is the operation
> ignored or would that have any adverse side effects?
>

The operation is ignored, but it has a non-zero cost associated with making
the call.

>
> And with ReadInput[Buffer]() would it just return 0 in length if it is not
> redirected?
>
It doesn't currently, it just leaves the length unchanged. It probably
should.

Rick



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

Re: [Oorexx-devel] suboptimal error diagnostic

[Rick McGuire]

In the parsing process, the check for invalid data on the end of the clause
happens first. The search for the matching control structure doesn't happen
until a correctly formed instruction is available.

Rick

On Mon, Jul 25, 2022 at 8:58 AM Mike Cowlishaw  wrote:

> Well, Walter, if you knew what the problem was ...
>
> It seems perfectly reasonable to be for the interpreter to treat 'call'
> there as the name of a control variable (as that's all that is allowed
> there).  But in this case I suppose "loop has no control variable but one
> is specified" might be more accurate -- but perhaps is just as confusing?
>
> Mike
>
>
>
>
> --
> *From:* WalterPachl via Oorexx-devel [mailto:
> oorexx-devel@lists.sourceforge.net]
> *Sent:* 25 July 2022 11:47
> *To:* Open Object Rexx Developer Mailing List
> *Cc:* WalterPachl
> *Subject:* Re: [Oorexx-devel] suboptimal error diagnostic
>
> *I know what the problem is:* the comma after the End.
> I consider your diagnostic no better. There is no control variable.
> Anyway: the diagnostic in context is what I consider suboptimal!
> See my first posting on that matter
> Thanks anyway
> Walter
>
> Rick McGuire  hat am 25.07.2022 12:03 geschrieben:
>
>
> I get a different result on the current build,
>
> 29 *-* End ,Call lineout oid
>  1 *-* call merge
> Error 21 running E:\ORexxDev\builds\oorexx\merge.rex line 29:  Invalid
> data on end of clause.
> Error 21.909:  Data must not follow the END control variable name; found
> "LINEOUT".
>
> you do have a dangling continuation character after the END.
>
> Rick
>
> On Mon, Jul 25, 2022 at 5:55 AM WalterPachl via Oorexx-devel <
> oorexx-devel@lists.sourceforge.net> wrote:
>
> H:\_tri>rexx merge
> REXX-ooRexx_5.0.0(MT)_64-bit 6.05 21 Apr 2022
> H:\_tri\.html konnte nicht gefunden werden
> H:\_tri>rexx merge
> 29 *-* End ,Call lineout oid
> Error 21 running H:\_tri\merge.rex line 29: Invalid data on end of clause.
> Error 21.909: Data must not follow the END control variable name; found
> "LINEOUT".
>
> Parse Arg pn
> Parse Var pn name '_'
> frame='7.html'
> data=name'_html.data'
> oid=name'.html'; 'erase' oid
> Do While lines(data)>0
> dl=linein(data)
> Do While lines(frame)>0
> fl=linein(frame)
> If left(fl,4)=' Parse Var fl aaa "'" p "." bbb
> Call o aaa"'"pn"."bbb
> Iterate
> End
> If left(fl,2)=left(dl,2) Then Do
> Call o dl''
> Leave
> End
> call o fl
> End
> End
> Do While lines(frame)>0
> fl=linein(frame)
> If left(fl,4)='D' Then Do
> Parse Var fl aaa ':'
> fl=aaa':' date() time()
> End
> call o fl
> End ,
> Call lineout oid
> Exit
> o: Return lineout(oid,arg(1))
>
> Rick McGuire  hat am 25.07.2022 11:22 geschrieben:
>
>
> Without being able to see merge.rex, it's pretty much impossible to give
> you an answer. Also, which version of oorexx are you using?
>
> Rick
>
> On Mon, Jul 25, 2022 at 2:28 AM WalterPachl via Oorexx-devel <
> oorexx-devel@lists.sourceforge.net> wrote:
>
> A phenomenon:
> A rather large program of mine ends as follows:
>
> H:\_tri>rexx trid test
> Syntax raised in line 219
> Call merge pn
> rc=21 (Invalid data on end of clause.)
>
> The problem lies in merge.rex as shown by this snippet:
>
> H:\_tri>rexx good
> We call bad
> 27 *-* End , call o fl
> 2 *-* Call merge
> Error 21 running H:\_tri\merge.rex line 27: Invalid data on end of clause.
> Error 21.909: Data must not follow the END control variable name; found
> "O".
>
> Any idea?
> Regards
> Walter
>
> PS There is no "END control variable name" in merge.rex
> ___
> 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
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> LG
>
> Walter
>
> ___
> 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

Re: [Oorexx-devel] suboptimal error diagnostic

[Rick McGuire]

Then open a bug report.

Rick

On Mon, Jul 25, 2022 at 6:47 AM WalterPachl via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

> *I know what the problem is:* the comma after the End.
> I consider your diagnostic no better. There is no control variable.
> Anyway: the diagnostic in context is what I consider suboptimal!
> See my first posting on that matter
> Thanks anyway
> Walter
>
> Rick McGuire  hat am 25.07.2022 12:03 geschrieben:
>
>
> I get a different result on the current build,
>
> 29 *-* End ,Call lineout oid
>  1 *-* call merge
> Error 21 running E:\ORexxDev\builds\oorexx\merge.rex line 29:  Invalid
> data on end of clause.
> Error 21.909:  Data must not follow the END control variable name; found
> "LINEOUT".
>
> you do have a dangling continuation character after the END.
>
> Rick
>
> On Mon, Jul 25, 2022 at 5:55 AM WalterPachl via Oorexx-devel <
> oorexx-devel@lists.sourceforge.net> wrote:
>
> H:\_tri>rexx merge
> REXX-ooRexx_5.0.0(MT)_64-bit 6.05 21 Apr 2022
> H:\_tri\.html konnte nicht gefunden werden
> H:\_tri>rexx merge
> 29 *-* End ,Call lineout oid
> Error 21 running H:\_tri\merge.rex line 29: Invalid data on end of clause.
> Error 21.909: Data must not follow the END control variable name; found
> "LINEOUT".
>
> Parse Arg pn
> Parse Var pn name '_'
> frame='7.html'
> data=name'_html.data'
> oid=name'.html'; 'erase' oid
> Do While lines(data)>0
> dl=linein(data)
> Do While lines(frame)>0
> fl=linein(frame)
> If left(fl,4)=' Parse Var fl aaa "'" p "." bbb
> Call o aaa"'"pn"."bbb
> Iterate
> End
> If left(fl,2)=left(dl,2) Then Do
> Call o dl''
> Leave
> End
> call o fl
> End
> End
> Do While lines(frame)>0
> fl=linein(frame)
> If left(fl,4)='D' Then Do
> Parse Var fl aaa ':'
> fl=aaa':' date() time()
> End
> call o fl
> End ,
> Call lineout oid
> Exit
> o: Return lineout(oid,arg(1))
>
> Rick McGuire  hat am 25.07.2022 11:22 geschrieben:
>
>
> Without being able to see merge.rex, it's pretty much impossible to give
> you an answer. Also, which version of oorexx are you using?
>
> Rick
>
> On Mon, Jul 25, 2022 at 2:28 AM WalterPachl via Oorexx-devel <
> oorexx-devel@lists.sourceforge.net> wrote:
>
> A phenomenon:
> A rather large program of mine ends as follows:
>
> H:\_tri>rexx trid test
> Syntax raised in line 219
> Call merge pn
> rc=21 (Invalid data on end of clause.)
>
> The problem lies in merge.rex as shown by this snippet:
>
> H:\_tri>rexx good
> We call bad
> 27 *-* End , call o fl
> 2 *-* Call merge
> Error 21 running H:\_tri\merge.rex line 27: Invalid data on end of clause.
> Error 21.909: Data must not follow the END control variable name; found
> "O".
>
> Any idea?
> Regards
> Walter
>
> PS There is no "END control variable name" in merge.rex
> ___
> 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
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> LG
>
> Walter
> ___
> 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

Re: [Oorexx-devel] suboptimal error diagnostic

[Rick McGuire]

I get a different result on the current build,

29 *-* End ,Call lineout oid
 1 *-* call merge
Error 21 running E:\ORexxDev\builds\oorexx\merge.rex line 29:  Invalid data
on end of clause.
Error 21.909:  Data must not follow the END control variable name; found
"LINEOUT".

you do have a dangling continuation character after the END.

Rick

On Mon, Jul 25, 2022 at 5:55 AM WalterPachl via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

> H:\_tri>rexx merge
> REXX-ooRexx_5.0.0(MT)_64-bit 6.05 21 Apr 2022
> H:\_tri\.html konnte nicht gefunden werden
> H:\_tri>rexx merge
> 29 *-* End ,Call lineout oid
> Error 21 running H:\_tri\merge.rex line 29: Invalid data on end of clause.
> Error 21.909: Data must not follow the END control variable name; found
> "LINEOUT".
>
> Parse Arg pn
> Parse Var pn name '_'
> frame='7.html'
> data=name'_html.data'
> oid=name'.html'; 'erase' oid
> Do While lines(data)>0
> dl=linein(data)
> Do While lines(frame)>0
> fl=linein(frame)
> If left(fl,4)=' Parse Var fl aaa "'" p "." bbb
> Call o aaa"'"pn"."bbb
> Iterate
> End
> If left(fl,2)=left(dl,2) Then Do
> Call o dl''
> Leave
> End
> call o fl
> End
> End
> Do While lines(frame)>0
> fl=linein(frame)
> If left(fl,4)='D' Then Do
> Parse Var fl aaa ':'
> fl=aaa':' date() time()
> End
> call o fl
> End ,
> Call lineout oid
> Exit
> o: Return lineout(oid,arg(1))
>
> Rick McGuire  hat am 25.07.2022 11:22 geschrieben:
>
>
> Without being able to see merge.rex, it's pretty much impossible to give
> you an answer. Also, which version of oorexx are you using?
>
> Rick
>
> On Mon, Jul 25, 2022 at 2:28 AM WalterPachl via Oorexx-devel <
> oorexx-devel@lists.sourceforge.net> wrote:
>
> A phenomenon:
> A rather large program of mine ends as follows:
>
> H:\_tri>rexx trid test
> Syntax raised in line 219
> Call merge pn
> rc=21 (Invalid data on end of clause.)
>
> The problem lies in merge.rex as shown by this snippet:
>
> H:\_tri>rexx good
> We call bad
> 27 *-* End , call o fl
> 2 *-* Call merge
> Error 21 running H:\_tri\merge.rex line 27: Invalid data on end of clause.
> Error 21.909: Data must not follow the END control variable name; found
> "O".
>
> Any idea?
> Regards
> Walter
>
> PS There is no "END control variable name" in merge.rex
> ___
> 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
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] suboptimal error diagnostic

[Rick McGuire]

Without being able to see merge.rex, it's pretty much impossible to give
you an answer. Also, which version of oorexx are you using?

Rick

On Mon, Jul 25, 2022 at 2:28 AM WalterPachl via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

> A phenomenon:
> A rather large program of mine ends as follows:
>
> H:\_tri>rexx trid test
> Syntax raised in line 219
> Call merge pn
> rc=21 (Invalid data on end of clause.)
>
> The problem lies in merge.rex as shown by this snippet:
>
> H:\_tri>rexx good
> We call bad
> 27 *-* End , call o fl
> 2 *-* Call merge
> Error 21 running H:\_tri\merge.rex line 27: Invalid data on end of clause.
> Error 21.909: Data must not follow the END control variable name; found
> "O".
>
> Any idea?
> Regards
> Walter
>
> PS There is no "END control variable name" in merge.rex
> ___
> 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

Re: [Oorexx-devel] Memory leak (Re: A question (Re: Ad .local and/or monitor class

[Rick McGuire]

On Wed, Jul 20, 2022 at 12:35 PM Rony G. Flatscher 
wrote:

> On 20.07.2022 18:05, Rick McGuire wrote:
>
> When the instance is terminated, all object references are cleared out in
> case there might be a dangling reference to the instance object that might
> pin it in memory. This includes .local, which should not be pinned
> anywhere. I spent fair about of time recently tracing the termination code
> to fix #1734, so I know it's doing what it's supposed to be doing.
>
> I was going to suggest reverting your overrides before terminating the
> instance. A more appropriate way to do that is to call the destination
> method with no argument.
>
> Did that as the first strategy: calling destination until .nil gets
> returned and then placing back the destination right before it.
>
> The monitor maintains a queue of the destination objects, so this will pop
> your monitor off of the queue and revert to the previous destination.
>
> Yes. It is possible however that there are Rexx programmers who may put
> another destination on top of it (hence popping the destinations until
> getting to the very first one in the first attempts) hence using
> destination until .nil got returned. (Then changed the logic to simply
> remove the monitor objects from .local by replacing the monitor objects
> with new ones that got configured like in the beginning which seems to work
> as well.)
>
> The only other thing to comes to mind is that you are calling the
> terminate API on the wrong thread or in the wrong circumstances (e.g., on
> the correct thread but as the result of a callout from running oorexx
> code). I know you tried doing the second one once before. Are you checking
> the you are getting a true return value from the terminate call?
>
> Terminate() is defined to be void (from rexxapi.pdf):
>
> 1.17.187. Terminate
> This API is available in context Instance.
> // Method Syntax Form(s)
> context->Terminate();
> Terminates the current Rexx interpreter instance. Terminate() may only be
> called from the thread context that originally created the interpreter
> instance. This call will wait for all threads to complete processing before
> returning.
> Arguments
> None.
> Returns
> Void.
>
> When an instance gets created on the native side it will be stored in a
> structure together with its Java peer (a jobj) and the Java object
> representing the Rexx interpreter configuration used when creating the
> instance (a jobj). That structure then gets placed on a simply linked list
> on the native side. The Java side gets the context instance pointer
> returned as a string rendering.
>
> In the use case of termination the native side gets that string, turns it
> into a RexxInstance pointer and searches it in the linked list. If found it
> gets used for invoking Terminate(), if not, then a Java exception gets
> raised.
>
> At operating system thread in which Terminate() gets invoked: this is
> controlled by Java (in this case by the cleaner of PhantomReferences).
>
That is probably your problem. Terminate() is getting called on the wrong
thread so the instances are leaking. I've just been looking at the code,
and I believe it should be possible to terminate an instance from another
thread as long as there's nothing currently running on the initial thread.

Rick


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

Re: [Oorexx-devel] Memory leak (Re: A question (Re: Ad .local and/or monitor class

[Rick McGuire]

When the instance is terminated, all object references are cleared out in
case there might be a dangling reference to the instance object that might
pin it in memory. This includes .local, which should not be pinned
anywhere. I spent fair about of time recently tracing the termination code
to fix #1734, so I know it's doing what it's supposed to be doing.

I was going to suggest reverting your overrides before terminating the
instance. A more appropriate way to do that is to call the destination
method with no argument. The monitor maintains a queue of the destination
objects, so this will pop your monitor off of the queue and revert to the
previous destination.

The only other thing to comes to mind is that you are calling the terminate
API on the wrong thread or in the wrong circumstances (e.g., on the correct
thread but as the result of a callout from running oorexx code). I know you
tried doing the second one once before. Are you checking the you are
getting a true return value from the terminate call?

Rick



On Wed, Jul 20, 2022 at 11:04 AM Rony G. Flatscher 
wrote:

> After further excessive (literally additional days of) debugging I can
> state that upon Rexx interpreter instance (RII) terminations using the
> native Terminate() API, ooRexx does not release/run the uninit methods of
> at least the monitored objects (ooRexx BSF objects) of the .local monitors!
>
> =
> Here the relevant parts after creating, using and Terminate() 1,000 RIIs:
>
> References from ooRexx objects (under the control of ooRexx), pinning Java
> objects:
>
> ... cut ...*RexxAnalyzeRegistry category=[[B]**- 
> RefCount: entries=[  **2 000**] | references: min=[1] max=[1] 
> avg=[  1,0] sum=[2 000]**- MemSize:  entries=[  2 
> 000] | references: min=[1] max=[1] avg=[  1,0] sum=[
> **2 000**]**RexxAnalyzeRegistry category=[[C]**- 
> RefCount: entries=[  **2 000**] | references: min=[1] max=[1] 
> avg=[  1,0] sum=[2 000]**- MemSize:  entries=[  2 
> 000] | references: min=[2] max=[2] avg=[  2,0] sum=[
> **4 000**]**RexxAnalyzeRegistry category=[[I]**- 
> RefCount: entries=[  **4 000**] | references: min=[1] max=[1] 
> avg=[  1,0] sum=[4 000]**- MemSize:  entries=[  4 
> 000] | references: min=[4] max=[4] avg=[  4,0] sum=[   
> **16 000**]**RexxAnalyzeRegistry category=[java.io.InputStreamReader]**   
>  - RefCount: entries=[  **1 000**] | references: min=[1] 
> max=[1] avg=[  1,0] sum=[1 000]**RexxAnalyzeRegistry 
> category=[java.io.PrintWriter]**- RefCount: entries=[  
> **2 000**] | references: min=[1] max=[1] avg=[  1,0] 
> sum=[2 000]*
>
> ... cut ...
>
> References from Java objects (under the control of BSF4ooRexx), pinning 
> ooRexx engines (REXX_ENGINE, REXX_SCRIPT_ENGINE) and ooRexx objects 
> (REXX_PROXY):
>
>
> org.rexxla.bsf.engines.rexx.RexxCleanupRef:
> RexxCleanupRef [2022-07-20 15:16:10.61300]
>  RefKind: Instances: Finalized: Not Yet Finalized:
> --
> [TEST]..: [   0] [   0] [   0]
> [REXX_ENGINE]...: [   1 002] [   1 000] [   
> 2][REXX_PROXY]: [   9 000] [   8 994] [   
> 6]
> [REXX_SCRIPT_ENGINE]: [   1 000] [ 999] [   1]
> --
> Totals..: [  11 002] [  10 993] [   9]
>
> ---
>
> Here the ooRexx objects referenced by BSF4ooRexx on the Java side (cf. 
> REXX_PROXY above):
>
> OREXX_REGISTRY related:
> OREXX_REGISTRY   ~items: 6
> OREXX_REGISTRY_REFCOUNTER~items: 6
>
> t_jsr223.rex: ooRexx 5.0.0 r12473 (17 Jul 2022) / BSF 641.20220717 / Java 
> 17.0.3.1 (released: 2022-04-22), 64-bit (amd64) / Windows 10.0.19043
>
> count_rexx_gc: [4] count_java_gc: [4]
>
> ... cut ...
>
> =
> Here the relevant parts after creating, using and Terminate() 1,000 RIIs,
> this time running the following Rexx program right before termination of a
> RII from the Java side:
>
>  ... cut ...
>* String rexxCode =   // reset .input, .output, .error, 
> .traceOutput, .debugInput to free BSF objects if any
> "  lDir = .local  -- get .local  ;\n" 
> +
> "  lDir['INPUT'  ]= .monitor~new(ldir['STDIN' ]) ;\n" 
> +
> "  lDir['OUTPUT' ]= .monitor~new(ldir['STDOUT']) ;\n" 
> +
> "  lDir['ERROR'  ]= .monitor~new(ldir['STDERR']) ;\n" 
> +
> "  

Re: [Oorexx-devel] Ad debugging garbage collection dependent resources

[Rick McGuire]

On Sat, Jul 16, 2022 at 11:25 AM Rony G. Flatscher 
wrote:

> On 16.07.2022 17:18, Rick McGuire wrote:
>
> I am a serious -1 to this proposal. This is something with serious
> performance implications and will only be misused by people who don't
> understand how garbage collection works. There, you no longer need to worry
> about silent assent.
>
> Indeed.
>
> So, Rick, why do the Java programmers have the ability then? The
> implications on Java are exactly the same: improper use of System.gc()
> would impede Java programs (and Java frameworks) accordingly?
>
I have actually worked on JVMs and the developers (particularly the ones
who work on memory management) really hated that a decision was made early
on to include this method. It causes nothing but problems, not the least
because very few users really understand what garbage collection does.

Are ooRexx programmers by comparison regarded to be more stupid?
>
I suspect they are equally as stupid (or really, more ignorant) as the Java
users that misuse this. I remain a firm -1. And frankly, I consider you to
be the person most likely to misuse this because you really don't
understand garbage collection either.

Rick


> ---rony
>
>
> On Sat, Jul 16, 2022 at 11:12 AM Rony G. Flatscher <
> rony.flatsc...@wu.ac.at> wrote:
>
>> While debugging (for almost two months) ooRexx and BSF4ooRexx/Java it was
>> almost impossible to determine the source of some memory leaks.
>>
>> The reason was not being able to rely on the garbage collector having run
>> at a specific point in time such that all objects that have no references
>> anymore get garbage collected and if uninit methods present have them run.
>> Only then would an analysis become really possible.
>>
>> As it is possible with Java to kick the Java garbage collector in order
>> to get at a stable state with regards to garbage collecting Java objects a
>> gc() for ooRexx would make it possible to arrive at the same ability for
>> ooRexx: to become able to arrive at a stable state at a certain point in
>> time. Only then would it become possible to assess where the sources of
>> memory leaks are rooted: on the ooRexx side or on the Java side.
>>
>> Consider also the runtime dynamics in this context: there are cross
>> calls/invocations, even on different ooRexx and on different Java threads
>> at the same time (which all need to be controlled/synchronized while
>> debugging).
>>
>> In the end I created a gc() built in function in my "personal ooRexx
>> interpreter" ;) to become able to debug ooRexx and Java/BSF4ooRexx to help
>> identify all such locations and determine which side is responsible for
>> keeping references that should have been freed. While debugging quite a lot
>> of programs got created that would excercise gc() and java.lang.System.gc()
>> allowing to determine the various sources of memory leaks (ooRexx and Java
>> side) and thereby becoming able to address them and test the solutions.
>> Again, without gc on the ooRexx side this would not have been possible!
>>
>> ---
>>
>> For everyone who has such a need (to debug complex interactions with
>> external function libraries with observed memory leaks) it is mandatory to
>> have the ability in ooRexx available to kick off the ooRexx garbage
>> collector to achieve a stable state.
>>
>> Therefore proposing to add a gc() BIF (built-in-function) to ooRexx to
>> enable debugging in such dynamic native peer systems/environments.
>>
>> As any garbage collector run is relatively expensive it is necessary to
>> warn any ooRexx programmer from using the gc() BIF in regular programs and
>> make sure they only consider its use for debugging only. This may be
>> achieved by creating a documentation that communicates this fact
>> clearly/explicitly, maybe something along the lines:
>>
>> "Warning: this function should only be used for developers who explicitly
>> have a very special need of debugging memory leaks with external function
>> libraries!
>>
>> Do not use this function in regular ooRexx applications as each explicit
>> invocation of this function is very expensive and may slow down the
>> execution of your ooRexx application considerably!
>>
>> This function will kick off the ooRexx garbage collector out-of-bounds
>> and finalize all objects that have no references at that particular point
>> in time and run their uninit methods if present.
>>
>> Remark: the ooRexx garbage collector will get invoked by the interpreter
>> at well defined states and will thereby make sure that the pr

Re: [Oorexx-devel] Ad debugging garbage collection dependent resources

[Rick McGuire]

I am a serious -1 to this proposal. This is something with serious
performance implications and will only be misused by people who don't
understand how garbage collection works. There, you no longer need to worry
about silent assent.

Rick

On Sat, Jul 16, 2022 at 11:12 AM Rony G. Flatscher 
wrote:

> While debugging (for almost two months) ooRexx and BSF4ooRexx/Java it was
> almost impossible to determine the source of some memory leaks.
>
> The reason was not being able to rely on the garbage collector having run
> at a specific point in time such that all objects that have no references
> anymore get garbage collected and if uninit methods present have them run.
> Only then would an analysis become really possible.
>
> As it is possible with Java to kick the Java garbage collector in order to
> get at a stable state with regards to garbage collecting Java objects a
> gc() for ooRexx would make it possible to arrive at the same ability for
> ooRexx: to become able to arrive at a stable state at a certain point in
> time. Only then would it become possible to assess where the sources of
> memory leaks are rooted: on the ooRexx side or on the Java side.
>
> Consider also the runtime dynamics in this context: there are cross
> calls/invocations, even on different ooRexx and on different Java threads
> at the same time (which all need to be controlled/synchronized while
> debugging).
>
> In the end I created a gc() built in function in my "personal ooRexx
> interpreter" ;) to become able to debug ooRexx and Java/BSF4ooRexx to help
> identify all such locations and determine which side is responsible for
> keeping references that should have been freed. While debugging quite a lot
> of programs got created that would excercise gc() and java.lang.System.gc()
> allowing to determine the various sources of memory leaks (ooRexx and Java
> side) and thereby becoming able to address them and test the solutions.
> Again, without gc on the ooRexx side this would not have been possible!
>
> ---
>
> For everyone who has such a need (to debug complex interactions with
> external function libraries with observed memory leaks) it is mandatory to
> have the ability in ooRexx available to kick off the ooRexx garbage
> collector to achieve a stable state.
>
> Therefore proposing to add a gc() BIF (built-in-function) to ooRexx to
> enable debugging in such dynamic native peer systems/environments.
>
> As any garbage collector run is relatively expensive it is necessary to
> warn any ooRexx programmer from using the gc() BIF in regular programs and
> make sure they only consider its use for debugging only. This may be
> achieved by creating a documentation that communicates this fact
> clearly/explicitly, maybe something along the lines:
>
> "Warning: this function should only be used for developers who explicitly
> have a very special need of debugging memory leaks with external function
> libraries!
>
> Do not use this function in regular ooRexx applications as each explicit
> invocation of this function is very expensive and may slow down the
> execution of your ooRexx application considerably!
>
> This function will kick off the ooRexx garbage collector out-of-bounds and
> finalize all objects that have no references at that particular point in
> time and run their uninit methods if present.
>
> Remark: the ooRexx garbage collector will get invoked by the interpreter
> at well defined states and will thereby make sure that the programs will
> execute as efficiently as possible. Therefore there is no need - other than
> for debugging - to explicitly invoke the garbage collector out-of-bounds."
>
> Of course, not being a native English speaker the above draft for the
> documentation text may need to be rephrased to be more clear. However, it
> should be clear for everyone that the ooRexx gc() BIF is not meant to be
> used for production.
>
> ---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

Re: [Oorexx-devel] Ad .local and/or monitor class

[Rick McGuire]

On Wed, Jul 6, 2022 at 3:03 PM Rony  wrote:

> While debugging potential memory leaks I could narrow one down to the
> currently not tested hypothesis that if interpreter instances get
> terminated it may be the case that either the .local contained objects or
> the destination objects of the .local monitors do not release the
> references such that no uninit method runs.
>
> Background: in BSF4ooRexx whenever a ScriptEngine instance gets created an
> ooRexx interpreter instance gets created in which the .local monitors get
> redirected to Java‘s System.in, System.out and System.err. This occurs by
> wrapping up these Java objects as BSF objects which then get used to set
> the destinations for the .input, .output, .error, .traceoutput and
> .debuginput monitors. Upon termination of these ooRexx interpreter instance
> these BSF objects should get unreferenced such that their uninit methods
> can run which remove the reference to their peer Java objects in the Java
> registry, allowing them to be garbage collected on the Java side. This
> seems to not happen.
>
> After having come up with a Java registry analyze class plus a garbage
> collector BIF on the ooRexx side I have become able to get a raw overview
> about the area where running hundreds, if not thousands of ooRexx
> interpreter instances (each JSP request will cause an ooRexx interpreter
> instance to be created to process the Rexx-JSPs) causes continuous memory
> consumption on the Java side. Carrying out the redirections of the .local
> monitors  manually to and from Java shows that the reference counting via
> the uninit works and no memory leaks occur.
>
> So, is it possible that either .local or the destination objects of the
> contained monitors do not get freed if an ooRexx interpreter instance gets
> terminated? (Thinking about this, I need to verify tomorrow that the
> instances get explicitly terminated, did not double-check that today.)
>

The reference to the .local directory is most definitely released upon
instance termination. Note, however, that this happens AFTER the
end-of-instance garbage collection and uninit pass, since it is necessary
to run the uninit methods in a fully functional interpreter instance. And
NO, adding an additional garbage collection cycle after that is not the
answer. GC cycles are very expensive and really should be avoided as much
as possible.

Rick


>
> —-rony
>
> Rony G. Flatscher (mobil/e)
>
> ___
> 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

Re: [Oorexx-devel] Documentation build

[Rick McGuire]

On Fri, Jul 1, 2022 at 8:01 AM Rony G. Flatscher 
wrote:

> Hi P.O.,
> On 01.07.2022 11:53, P.O. Jonsson wrote:
>
>
> Am 28.06.2022 um 11:19 schrieb Rony G. Flatscher  >:
>
> Here the direct link:
> 
> 
>
>
>
> After initial tests I have moved to
>
> https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.0.0beta/
>
> +1
>
>
> And
>
> https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.0.0html/
>
> +1
>
> The next time anyone work on a book it will be reflected here,
>
> I intend to create a „docbuildtools“ directory here as well and add the
> documents from the /docs/trunk/tools brach of the source code tree. Any
> objections?
>
> +1
>
> On the same subject: in the „Files“ part of the source forge site there is
> the subdir windows-build-tools
>  which
> does NOT contain build tools but actually the obsolete „Publican“
> documentation build tools. Can I move this content to an „obsolete“ section
> of the source tree? I hesitate to delete it. Feedback requested.
>
> As it is not relevant anymore, why not delete it. SourceForge as a version
> control system would keep it around such that one could "undelete" (revert)
> it later should interest or need arise.
>

Except this the files section, which is not under version control. If it's
deleted, it's gone. I think we need to keep a copy around, but in place
where it's obvious it's not the most current.

Rick

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

Re: [Oorexx-devel] Documentation build

[Rick McGuire]

On Tue, Jun 28, 2022 at 1:58 PM Gilbert Barmwater 
wrote:

> Thanks P.O., they look great!  Now one more issue to address. As you
> know, the Windows build includes the documentation and the user has the
> option of installing it as part of installing ooRexx.  Currently, the PDFs
> in the Windows builds are NOT the ones you generate.  I have never done an
> NSIS build so I'm not sure how it finds the folder with the PDFs to include
> but it should point to the ones you build.  Of course this also implies
> that the documents need to be built BEFORE the Windows build is executed.
> Sorry for the extra complications.
>
There's a variable you can set on the initial CMake command for the build
that identifies the location of the docs. It is necessary to download the
files before doing the installer portion of the build.

Rick


> Gil
> On 6/27/2022 1:44 PM, P.O. Jonsson wrote:
>
> I have written a rexx script that taps into the existing build process and
> build only those documents that have been changed. I have done it on macOS
> but it should work also on Windows. I had to set today as a starting point
> (the documents will get todays date) but they will show the correct
> revision number (when they were last changed). I hope this is fine.
>
> For the upload I have added a folder 5.0.0test for comparing to existing
> documents in 5.0.0beta. I can merge them later.
>
> Please have a look and see if you can spot any visual differences, I have
> checked that the correct fonts are embedded but I have not checked if the
> visual appearance is different on Windows compared to macOS. If accepted I
> will set up a macOS VM for this task and retire the current doc-build on
> Windows.
>
> For completeness I included also the documentation in html form, This
> might be possible to upload maybe to https://www.oorexx.org/ once we have
> an official version.
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
>
>
>
> ___
> Oorexx-devel mailing 
> listOorexx-devel@lists.sourceforge.nethttps://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

Re: [Oorexx-devel] ooRexx Testing

[Rick McGuire]

The tests can be checked out from
https://svn.code.sf.net/p/oorexx/code-0/test/trunk

This is the test framework and all of the test cases. There's a readme file
in the root that explains how to run the tests. There's not much
documentation available on writing the test cases, but there are many, many
examples available to show you how to do it.

Rick

On Mon, Jun 27, 2022 at 6:42 PM tango foxtrot  wrote:

> Hello all,
>
> Many of the open tickets have 'tests' as pending work items.  I'd like to
> help out. Is there any available documentation on:
>
>- how to run the test framework on one's own machine?  either all or
>part
>- how to construct a test
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad parsing

[Rick McGuire]

The triggers get applied first, then things get broken in words using the
variable list. The +2 trigger matches to the second position, "c ", which
is then broken into words and assigned to the variables.

Rick

On Wed, Jun 8, 2022 at 10:51 AM Rony G. Flatscher 
wrote:

> Consider the following:
>
> parse value "c fgh" with v1 v2
>   ... rexxtry.rex on WindowsNT
> say "v1=["v1"] v2=["v2"]"
> v1=[c] v2=[fgh]
>   ... rexxtry.rex on WindowsNT
>
> parse value "c fgh" with v1 v2 +2
>   ... rexxtry.rex on WindowsNT
> say "v1=["v1"] v2=["v2"]"
> v1=[c] v2=[]
>   ... rexxtry.rex on WindowsNT
>
> Why would v2 in the second parse refer to an empty string (would have
> expected the string "fg")?
>
> ---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

Re: [Oorexx-devel] Strange observation, RFC

[Rick McGuire]

On Wed, Jun 1, 2022 at 6:11 AM Rony G. Flatscher 
wrote:

> While debugging orexxole.cpp I am using the existing function
> pszDbgVarType(vt) which returns a pointer to a zero terminated string which
> gets defined for the entire program as CHAR szDbg[255]. The same buffer is
> used by pszDbgInvKind(), pszDbgTypekind(), pszDbgParmFlags() and
> pszDbVariant(). With the exception of pszDbgVarType() these debug functions
> are there but not used AFAICT.
>
> It allows to get a human readable string of the type 'vt' represents, e.g.
> "VT_ARRAY VT_VARIANT", "VT_R8" and the like.
>
> The strange observation is using pszDbgVarType() multiple times in a
> single debug statement like:
>
> if (*pDestVt & VT_ARRAY)// an array in hand
> {
> VARTYPE tmpVt = *pDestVt & VT_TYPEMASK; 
> *fprintf(stderr, "orexxole.cpp # %d %s: --- b) VT_ARRAY: type=[%s] 
> *pDestVt=[%s][d=%d][x%08x] %s tmpVt=[%s][d=%d][x%08x] | 
> VT_ARRAY=[%s][d=%d][x%08x], VT_R8=[%s][d=%d][x%08x] \n\n",**__LINE__, 
> __FUNCTION__,**"VT_ARRAY",**pszDbgVarType( *pDestVt  ), 
> *pDestVt  , *pDestVt,**" /\\ ",**pszDbgVarType( tmpVt ),  
> tmpVt , tmpVt,**pszDbgVarType(VT_ARRAY), VT_ARRAY, VT_ARRAY,**
> pszDbgVarType(VT_R8), VT_R8, VT_R8**);*}
>
> So there are four invocations of pszDbgVarType() with four different
> variables. The ouput is surprisingly:
>
> ... cut ...
> oorexxole.cpp # 419 pszDbgVarType, vt: d=[5] [x0005] -> szDbg=[VT_R8] 
> (return value)
> oorexxole.cpp # 419 pszDbgVarType, vt: d=[0] [x] -> szDbg=[VT_ARRAY 
> VT_EMPTY] (return value)
> oorexxole.cpp # 419 pszDbgVarType, vt: d=[5] [x0005] -> szDbg=[VT_R8] 
> (return value)
> oorexxole.cpp # 419 pszDbgVarType, vt: d=[5] [x0005] -> szDbg=[VT_ARRAY 
> VT_R8] (return value)
>(added linebreaks for better legibility):*orexxole.cpp # 4359 
> checkForOverride: --- b) VT_ARRAY: type=[VT_ARRAY]
>*pDestVt=[VT_ARRAY VT_R8][d=8197][x2005]  /\
>   tmpVt=[VT_ARRAY* *VT_R8][d=5][x0005] |
>VT_ARRAY=[VT_ARRAY VT_R8][d=8192][x2000],
>   VT_R8=[VT_ARRAY VT_R8][d=5][x0005]*
>
> Line # 419 above is a debug statement in pszDbgVarType() displaying the
> value it returns. It uses strcat() with the szDbg buffer which upon entry
> in this function sets element 0 to 0.
>
> VT_ARRAY has the decimal value 8192 (x2000), VT_R8 the decimal value 5
> (x0005), hence the following should be shown:
>
> pszDbgVarType(*pDestVt): "VT_ARRAY VT_R8"
> pszDbgVarType(tmpVt)   : "VT_R8" (VT_TYPEMASK is defined as xFFF)
> pszDbgVarType(VT_ARRAY): "VT_ARRAY"
> pszDbgVarType(VT_R8)   : "VT_R8"
>
> It is as if for some of those invocations of pszDbvVarType the wrong
> buffer gets returned, hence displaying wrong information.
>
Well, if the buffer gets reused, then each invocation is going to overlay
the information from the previous call, so fprintf() will be using the
information from the last call when it formats.



Of course, having spent an enormeous amount of time debugging I might have
> arrived at a point where I overlook the obvious, hence this posting
> requesting comments.
>
> ---rony
>
> P.S.: Contemplating to change the pszDbg...() functions to force a buffer
> to be supplied rather than using a single global buffer, noticing that at
> least pszDbgVarType() gets also used by orexxole.cpp. This way no wrong
> optimizations should be applicable and also multithreaded usage of
> oorexxole.cpp would be improved.
>
Just make sure the allocated buffer gets released afterwards. This change
is likely to be an incredible pain to accomplish.

Rick


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

Re: [Oorexx-devel] A question ad orexxole.cpp

[Rick McGuire]

First of all, if you look closely, in many of those cases it is
already checking for null. However, once you get the assertion popup, you
should be able to attach to the process with the debugger and figure out
the location of the problem from the stack trace.

Rick

On Sat, May 21, 2022 at 1:18 PM Rony G. Flatscher 
wrote:

> While working on orexxole.cpp with debug versions of ooRexx, sometimes
> (very rarely) an assertion error popup was shown for "stricomp". It seems
> that sometimes one argument is not correct (probably NULL).
>
> Here the usages of stricmp():
>
> if ( (pCurrBlock->memId == memId) && (pCurrBlock->invkind == 
> invKind) &&
>  (pCurrBlock->FuncVt == funcVT) && (pCurrBlock->iParmCount == 
> iParmCount) &&
>  (pCurrBlock->iOptParms == iOptParms) && (pszFuncName != 
> NULL) &&
>  (stricmp(pCurrBlock->pszFuncName, pszFuncName) == 0) )
> {
>
> ... cut ...
> if ( (pCurrBlock->memId == memId) && (pCurrBlock->invkind == 
> invKind) &&
>  (pCurrBlock->FuncVt == funcVT) && 
> (pCurrBlock->iParmCount == iParmCount) &&
>  (pCurrBlock->iOptParms == iOptParms) && (pszFuncName != 
> NULL) &&
>  (stricmp(pCurrBlock->pszFuncName, pszFuncName) == 0) )
> {
> ... cut ...
> if ( (pCurrBlock->memId == memId) && (pszConstName != NULL) &&
>  (stricmp(pCurrBlock->pszConstName, pszConstName) == 0) )
> {
> ... cut ...
> if ( (pCurrBlock->memId == memId) && (pszConstName != NULL) &&
>  (stricmp(pCurrBlock->pszConstName, pszConstName) == 0) )
> {
> ... cut ...
> if (stricmp(pFuncInfo->pszFuncName, pszFunction) == 0)
> {
> ... cut ...
> if (stricmp(pConstInfo->pszConstName, pszConstName) == 0)
> {
> ... cut ...
> if (!stricmp(pFuncInfo->pszFuncName,szBuffer))
> {
> ... cut ...
> ((stricmp(pszFunction, "AT") == 0) ||
>  (stricmp(pszFunction, "[]") == 0)) )
> {
> ... cut ...
> if (stricmp(classID, "ARRAY") == 0)
> {
> ... cut ...
>
>
> The question is whether to ignore (only an error in assertions?) or fix it
> by prepending tests that check before stricmp() whether the "argument from
> the structure/from the variable !=NULL && stricmp(...)".
>
> ---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] Fwd: [Oorexx-svn] SF.net SVN: oorexx-code-0:[12404] main/trunk/extensions/platform/windows/ ole

[Rick McGuire]

I think .nil would be a better default if these properties are not set.

Rick

-- Forwarded message -
From: orexx--- via Oorexx-svn 
Date: Fri, May 20, 2022 at 10:26 AM
Subject: [Oorexx-svn] SF.net SVN: oorexx-code-0:[12404]
main/trunk/extensions/platform/windows/ ole
To: 
Cc: 


Revision: 12404
  http://sourceforge.net/p/oorexx/code-0/12404
Author:   orexx
Date: 2022-05-20 14:26:20 + (Fri, 20 May 2022)
Log Message:
---
[feature-requests:#801] Make CLSID and PROGID available.

Modified Paths:
--
main/trunk/extensions/platform/windows/ole/orexxole.cls
main/trunk/extensions/platform/windows/ole/orexxole.cpp

Modified: main/trunk/extensions/platform/windows/ole/orexxole.cls
===
--- main/trunk/extensions/platform/windows/ole/orexxole.cls 2022-05-19
10:24:39 UTC (rev 12403)
+++ main/trunk/extensions/platform/windows/ole/orexxole.cls 2022-05-20
14:26:20 UTC (rev 12404)
@@ -104,6 +104,16 @@
   else
 forward class (super)

+::ATTRIBUTE "PROGID" GET
+  expose !progid
+  if var("!PROGID") then return !progid
+  return "PROGID"-- uninitialized, return attribute name
+
+::ATTRIBUTE "CLSID" GET
+  expose !clsid
+  if var("!CLSID") then return !clsid
+  return "CLSID" -- uninitialized, return attribute name
+
 ::METHOD "!OLEOBJECT" ATTRIBUTE

 ::METHOD addEventMethod

Modified: main/trunk/extensions/platform/windows/ole/orexxole.cpp
===
--- main/trunk/extensions/platform/windows/ole/orexxole.cpp 2022-05-19
10:24:39 UTC (rev 12403)
+++ main/trunk/extensions/platform/windows/ole/orexxole.cpp 2022-05-20
14:26:20 UTC (rev 12404)
@@ -51,7 +51,12 @@
 #include "oorexxapi.h"
 #include "events.h"

+// #define DEBUG_TESTING

+// TODO: (2022-05)
+// in debug mode Visual C++ from time to time comes up with an assertion
error popup
+// for "stricmp", seems one argument is sometimes not correct (probably
NULL)
+
 
//**
 // global data
 
//**
@@ -130,11 +135,11 @@
 // OLE (HRESULT) ErrorMessage for programmer
 
//**

-// function to return a human readable string for the supplied HRESULT
-inline LPCTSTR get_HRESULT_ErrorMessage ( HRESULT hResult)
+// function that prints a human readable string for the supplied HRESULT
in the supplied buffer
+inline void get_HRESULT_ErrorMessage ( HRESULT hResult, char *szBuffer)
 {
 _com_error err(hResult);
-return err.ErrorMessage();
+sprintf(szBuffer, "%8.8x \"%s\"", hResult, err.ErrorMessage());
 }


@@ -2940,6 +2945,64 @@
 {
 pDispatch->AddRef();
 hResult = S_OK;
+// if the IPersist interface is present, we can get at its
CLSID and to its ProgID if present;
+// if !CLSID is present, then the code assumes that a
structure has been built for it,
+// TODO: ?? which is not the case for IDISPATCH; to
distinguish an IDISPATCH CLSID and ProgID the
+{
+IPersist *pPersist = NULL;
+
+int hr = pDispatch->QueryInterface(IID_IPersist,
(LPVOID*) );
+if (SUCCEEDED(hr))
+{
+CLSID CLSid;
+pPersist->GetClassID();
+{
+/* now store the CLSID and ProgID with the
object attributes */
+PSZ pszAnsiStr = NULL;
+
+hResult = StringFromCLSID(CLSid,
);
+pszAnsiStr = pszUnicodeToAnsi(lpOleStrBuffer);
+if (SUCCEEDED(hResult))
+{
+CoTaskMemFree(lpOleStrBuffer); // memory
was not freed
+}
+if (pszAnsiStr)
+{
+context->SetObjectVariable("!CLSID",
context->NewStringFromAsciiz(pszAnsiStr));
+ORexxOleFree(pszAnsiStr); // free this
memory!
+}
+
+hResult = ProgIDFromCLSID(CLSid,
);
+pszAnsiStr = pszUnicodeToAnsi(lpOleStrBuffer);
+if (SUCCEEDED(hResult))
+{
+CoTaskMemFree(lpOleStrBuffer); // memory
was not freed
+}
+if (pszAnsiStr)
+{
+context->SetObjectVariable("!PROGID",
context->NewStringFromAsciiz(pszAnsiStr));
+if (pClsInfo)
+{
+ 

Re: [Oorexx-devel] Question ad new .Message methods reply/replyWith

[Rick McGuire]

Those are not equivalent. The target message object is updated with the
supplied arguments and the copy is made after the update. The
original message object has a copy of the arguments used for the
invocation.

Rick

On Thu, May 19, 2022 at 4:21 AM Rony G. Flatscher 
wrote:

> While going through the send/With and start/With methods I "stumbled" over
> reply/With which I was not aware of that they got added.
>
> If understanding correctly, then reply/With is the same as start/With just
> creating a copy of the target message object to dispatch. If so, the same
> effect can be simply achieved in plain ooRexx code like:
>
> dispatchedMsg=msg~copy~start/With(...)
>
> If that is the case why would it be important to have new reply/With
> methods added for the .message class?
>
> ---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