On 17.05.2022 11:18, Rick McGuire wrote:
All of the tests in Message.testGroup and Object.testGroup that expected error 98.938 to be raised
are failing. I mentioned my surprise that you hadn't had to change any tests of this sort when you
made your first commit. These tests need to be adjusted to the new expectations.
Oh, my bad! After your feedback I had only adjusted the Message.testGroup accordingly but had not
committed it (an oversight), sorry! (Did not check for other testGroups for that error hence had not
changed the Object.testGroup.)
:(
Will go after the Object.testGroup tests now, adjust them accordingly and then
commit the testGroups.
---rony
On Tue, May 17, 2022 at 3:09 AM Rony G Flatscher <rony.flatsc...@wu.ac.at>
wrote:
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 <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/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> 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/>
<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