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 oor...@jonases.se > Am 16.05.2022 um 20:34 schrieb Rony G. Flatscher <rony.flatsc...@wu.ac.at>: > > Commits: > > <http://sourceforge.net/p/oorexx/code-0/12391> > <http://sourceforge.net/p/oorexx/code-0/12391>, > <http://sourceforge.net/p/oorexx/code-0/12392> > <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 <object.r...@gmail.com >>> <mailto:object.r...@gmail.com>> 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 <object.r...@gmail.com >>> <mailto:object.r...@gmail.com>> 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 <rony.flatsc...@wu.ac.at >>> <mailto:rony.flatsc...@wu.ac.at>> 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/> >>>> <https://sourceforge.net/p/oorexx/feature-requests/802/> >>>> ---rony >>>> >>> Implemented <http://sourceforge.net/p/oorexx/code-0/12390> >>> <http://sourceforge.net/p/oorexx/code-0/12390>. Added appropriate tests. >>> >>> ---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
