Dear P.O., not near of a computer until later today, can you please post one if the reports such that one can learn about the failing tests?
TIA —-rony Rony G. Flatscher (mobil/e) > Am 16.05.2022 um 22:32 schrieb P.O. Jonsson <[email protected]>: > > Dear Rony and others, > > At the moment 25 out of 25 possible ooRexx test jobs on Jenkins are failing. > I suggest all developers making commits right now have a look as to the > consequences for the tests. Currently all Win, Unix and Linux tests are > failing for various reasons, I think that should not be the case. > > In addition building on Windows 7 both 32 and 64 bit is failing, unclear to > me why but someone should have a look. > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > [email protected] > > > > >> Am 16.05.2022 um 20:34 schrieb Rony G. Flatscher <[email protected]>: >> >> Commits: >> >> <http://sourceforge.net/p/oorexx/code-0/12391>, >> <http://sourceforge.net/p/oorexx/code-0/12392>. >> Also removed "Error_Execution_super" definitions from various *.h files >> manually as not having been able to get cmake to find xalan to recreate the >> files from <main/trunk/interpreter/messages/rexxmsg.xml>. >> >> Two questions: >> >> on Windows (having the Java version of Xalan): where to get Xalan from, or >> alternatively, how to get cmake to find and use the Java Xalan version? >> ad documentation w.r.t Error_Execution_super: have not found the relevant >> section in rexxref.pdf, unfortunately. Maybe others can find that and point >> it out, or maybe even adjust the text ;) ? >> ---rony >> >> >> >> On 16.05.2022 14:55, Rony G. Flatscher wrote: >>> On 16.05.2022 14:33, Rick McGuire wrote: >>>> There are also other places where this check is made. Search for >>>> Error_Execution_super to find it. The entire validateOverrideContext() >>>> method and it's calls should be deleted. >>> Thank you for your hints and pointers, will take care of it. >>> >>> ---rony >>> >>>> >>>> On Mon, May 16, 2022 at 8:24 AM Rick McGuire <[email protected]> wrote: >>>>> You have only fixed part of the problem. There's also a change required >>>>> to MessageInstruction.cpp and also tests needed for that case. >>>>> >>>>> Rick >>>>> >>>>> On Mon, May 16, 2022 at 8:15 AM Rick McGuire <[email protected]> >>>>> wrote: >>>>>> Weren't there any tests for the restriction that needed to be removed? I >>>>>> only need new tests added for the case where this is not restricted. >>>>>> Also, I'd recommend adding some tests using mixins to make sure the >>>>>> correct targets are getting invoked. >>>>>> >>>>>> Rick >>>>>> >>>>>> On Mon, May 16, 2022 at 8:10 AM Rony G. Flatscher >>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> On 15.05.2022 14:47, Rony G. Flatscher wrote: >>>>>>>> >>>>>>>> On 15.05.2022 12:27, Rony G. Flatscher wrote: >>>>>>>>> On 14.05.2022 22:06, Jean Louis Faucher wrote: >>>>>>>>>> >>>>>>>>>>> So there is a need for having one or more methods that can be used >>>>>>>>>>> for forcing the invocation of the ooRexx .Object methods. >>>>>>>>>> The syntax described in 4.2.7 Changing the Search Order for Methods >>>>>>>>>> could be used, if the restriction >>>>>>>>>> "Message search overrides can be used only from methods of the >>>>>>>>>> target object” >>>>>>>>>> was removed. >>>>>>>>>> >>>>>>>>>> It works with oorexx4, after removing the check >>>>>>>>>> if (_target != context->getReceiver()) >>>>>>>>>> in RexxExpressionMessage::evaluate. >>>>>>>>>> >>>>>>>>>> s1 = "hello" >>>>>>>>>> s2 = "hello" >>>>>>>>>> say s1~"="(s2) -- display 1 >>>>>>>>>> say s1~"=":.Object(s2) -- display 0 because not the same objects >>>>>>>>> Indeed that would really be a general, fine solution alleviating a >>>>>>>>> programmer to come up with weird and cumbersome solutions. >>>>>>>>> >>>>>>>>> Rather than having to create methods SEND.SUPER, SENDWITH.SUPER, >>>>>>>>> CLASS.SUPER and COPY.SUPER to allow programmers to invoke the ooRexx >>>>>>>>> root class methods in .object, this problem with OLEObject, but also >>>>>>>>> all comparable in general would be solved with this. So instead one >>>>>>>>> could code >>>>>>>>> >>>>>>>>> ole~send(msg) ... will check for existence on the Windows side, and >>>>>>>>> if present invoke it, otherwise lookup super (which is .object) >>>>>>>>> ole~send:.object(msg) ... will start resolving the method in the >>>>>>>>> superclass bypassing inspecting .oleobject >>>>>>>>> and with the same technique: >>>>>>>>> >>>>>>>>> ole~sendWith:.object(msg,arrArg) >>>>>>>>> ole~copy:.object >>>>>>>>> ole~class:.object >>>>>>>>> This would be much easier and very clear. >>>>>>>>> >>>>>>>>> In ooRexx 5.0 this would be the place to change: >>>>>>>>> >>>>>>>>> Index: interpreter/expression/ExpressionMessage.cpp >>>>>>>>> =================================================================== >>>>>>>>> --- interpreter/expression/ExpressionMessage.cpp (revision >>>>>>>>> 12388) >>>>>>>>> +++ interpreter/expression/ExpressionMessage.cpp (working copy) >>>>>>>>> @@ -161,6 +161,7 @@ >>>>>>>>> // do we have a super class override? >>>>>>>>> if (super != OREF_NULL) >>>>>>>>> { >>>>>>>>> +/* >>>>>>>>> // super class overrides are only allowed if the >>>>>>>>> // sender and the target are the same object (i.e., a >>>>>>>>> message to SELF) >>>>>>>>> if (_target != context->getReceiver()) >>>>>>>>> @@ -167,6 +168,7 @@ >>>>>>>>> { >>>>>>>>> reportException(Error_Execution_super); >>>>>>>>> } >>>>>>>>> +*/ >>>>>>>>> >>>>>>>>> _super = (RexxClass *)super->evaluate(context, stack); >>>>>>>>> // we send the message using the stack, which >>>>>>>>> Doing so will make your example work on ooRexx 5 as well! >>>>>>>>> >>>>>>>>> Also experimented with other scenarious, including ones where >>>>>>>>> "mistakingly" wrong override classes get supplied. >>>>>>>>> >>>>>>>>> arr=.array~of("a", "b") >>>>>>>>> ........................................... rexxtry.rex on WindowsNT >>>>>>>>> say arr~items >>>>>>>>> 2 >>>>>>>>> ........................................... rexxtry.rex on WindowsNT >>>>>>>>> say arr~items:super >>>>>>>>> Oooops ! ... try again. Object method not found. >>>>>>>>> Object "an Array" does not understand >>>>>>>>> message "ITEMS". >>>>>>>>> rc = 97.1 ................................. rexxtry.rex on WindowsNT >>>>>>>>> say arr~items:.collection >>>>>>>>> 2 >>>>>>>>> ........................................... rexxtry.rex on WindowsNT >>>>>>>>> say arr~items:.rexxinfo >>>>>>>>> Oooops ! ... try again. Object method not found. >>>>>>>>> Object "an Array" does not understand >>>>>>>>> message "ITEMS". >>>>>>>>> rc = 97.1 ................................. rexxtry.rex on WindowsNT >>>>>>>>> say arr~copy >>>>>>>>> a >>>>>>>>> b >>>>>>>>> ........................................... rexxtry.rex on WindowsNT >>>>>>>>> say arr~copy:.rexxinfo >>>>>>>>> Oooops ! ... try again. Object method not found. >>>>>>>>> Object "an Array" does not understand >>>>>>>>> message "COPY". >>>>>>>>> rc = 97.1 ................................. rexxtry.rex on WindowsNT >>>>>>>>> say arr~copy:.object >>>>>>>>> a >>>>>>>>> b >>>>>>>>> ........................................... rexxtry.rex on WindowsNT >>>>>>>>> So ooRexx 5 already catches wrong overrides and raises the >>>>>>>>> appropriate conditions (cf. overrides "super", ".rexxinfo" above)! >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Conceptually this change will allow the programmer to not only send a >>>>>>>>> message to the object, but also to tell the object in which >>>>>>>>> superclass to start the search for a matching method if he has a need >>>>>>>>> to do so. >>>>>>>>> >>>>>>>>> In the case of .OLEObject it makes it simple for programmers to tell >>>>>>>>> the OLE object to start its search for a method in the root class >>>>>>>>> .object applying existing knowledge! So no need to come up with >>>>>>>>> awkwardly named methods or another dispatch.super method to somehow >>>>>>>>> get access to the root class methods making the usage/protocol of >>>>>>>>> such classes rather complicated. So such a change would simply allow >>>>>>>>> to apply the message resolution override pattern that the programmer >>>>>>>>> is accustomed to already. >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> The question would be whether there are any potentially dangerous >>>>>>>>> side-effects or incompatibilies with existing code that could get >>>>>>>>> introduced by removing this particular check. >>>>>>>>> >>>>>>>>> ---rony >>>>>>>>> >>>>>>>> Opened a RFE for this: >>>>>>>> <https://sourceforge.net/p/oorexx/feature-requests/802/> >>>>>>>> >>>>>>>> ---rony >>>>>>>> >>>>>>> Implemented <http://sourceforge.net/p/oorexx/code-0/12390>. Added >>>>>>> appropriate tests. >>>>>>> >>>>>>> ---rony >>>>>>> >> >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
