> Am 17.05.2022 um 09:09 schrieb Rony G Flatscher <rony.flatsc...@wu.ac.at>: > > 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 >
Hi Rony, Not near a computer today I am traveling. I suggest you log on to the Jenkins system and look there, then you have also the (recent) history of commits. This is not urgent except maybe for the failing W7 builds. > Rony G. Flatscher (mobil/e) > >>> Am 16.05.2022 um 22:32 schrieb P.O. Jonsson <oor...@jonases.se>: >>> >> 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/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> >>>>> 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> >>>>>> 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> 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 >>> 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
