On Tue, Jul 1, 2008 at 4:33 PM, Rick McGuire <[EMAIL PROTECTED]> wrote:
> I think you can completely eliminate that rxqueue nonsense. There's
> no need to unload anything any more with the new package manager, so
> the rxqueue used for tracking that stuff wouldn't appear to be
> required.
I agre
Mark, you have provided a lot of material on unit testing
and I thank you for it. It has definitely clarified a number
of points that I was wondering about.
I have started on STREAM, but am going to have to take
a couple of days to repair another PC that just failed.
Luckly things only happen in
Mark,
I think you can completely eliminate that rxqueue nonsense. There's
no need to unload anything any more with the new package manager, so
the rxqueue used for tracking that stuff wouldn't appear to be
required.
Rick
On Mon, Jun 30, 2008 at 12:52 AM, <[EMAIL PROTECTED]> wrote:
> Revision:
Yes, that's one of the reasons I want executing code to have access to
it's own package. Once you have that, you can do things such as
dyamically add other packages to your lookup scope, perform dynamic
class resolution, etc. At lot of these functions will be particularly
useful from the native A
Rick,
You know I did a little investigation, using a sort of reflexion and
discovered that. It is quite cool.
src = .array~new
src[1] = "::routine speak public"
src[2] = "use strict arg w = 'Hello World'"
src[3] = "say w"
src[4] = "return 0"
obj = .Package~new("test", src)
itr =
Realized I didn't answer all of your questions. The other new class
is the Routine class, which decouples Routines from Methods.
Previously, a ::ROUTINE directive created a Method objectnow it
creates a Routine object. You could also have generated the parser
errors using a Routine object in
It should still be available in the condition traceback information,
just like you're doing with assertion failures.
Rick
On Tue, Jul 1, 2008 at 4:40 PM, Mark Miesfeld <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 1, 2008 at 11:29 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:
>
>> I was looking at what
On Tue, Jul 1, 2008 at 11:29 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:
> I was looking at what you've done for processing syntax errors in the
> CONSTANT directive test group, and I have some suggestions that might
> make these types of tests easier to manage. To start with, you can
> completel
I think I'd name the class RexxContext. It's something that will only
be created by the interpreter, so there's not too much use in
accessing the class directly.
Rick
On Tue, Jul 1, 2008 at 4:11 PM, Mark Miesfeld <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 1, 2008 at 12:13 PM, David Ashley <[EMAIL
On Tue, Jul 1, 2008 at 12:13 PM, David Ashley <[EMAIL PROTECTED]> wrote:
> Why not just call it .PackageCode?
That seems good.
Since the environment variable refers to a .Package object,
.PackageInstance might also be good.
However, I also like the idea of the Context object that could be used
d test_wrong_2nd_arg
parse source junk notUsed streamName
retDiscrpt = stream(streamName, "FILESTATE")
Maybe something along those lines? Output:
[error] [20080701 12:06:53.206000]
Test: TEST_WRONG_2ND_ARG
Class: STREAM.testGroup
File: C:\work.ooRexx\ooRexxUnit\3.2.0\oo
Why not just call it .PackageCode?
Thanks,
W. David Ashley
IBM Systems and Technology Group Lab Services
Open Object Rexx Team
Mobile Phone: 512-289-7506
"Rick McGuire"
I think your idea is a fundamentally Good Thing. As a fireman I am
always getting tangled up in large programs, recursive calls, etc. This
would offer a sound, native way to analyze the execution environment
both as a debugging tool and as an automated analyzer of program
functioning.
-Ori
Yes, that's again one of the long term plans for this. I'd like to
eventually add this sort of information to the error tracebacks so you
can determine exactly where each level of the call came from. And
another possible thing would be to request traceback information
directly from the context ob
Would the traceback offered by keeping this for the execution structure
be of value?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rick
McGuire
Sent: Tuesday, July 01, 2008 13:21
To: Open Object Rexx Developer Mailing List
Subject: Re: [Oorexx-devel] Ok,
It is scoped to the currently executing "thing", For example,
::routine myroutine
say "Currently executing" .context~name "which is in file" .context~package~name
variables = .context~variables
do variable over variables
say "Variable" variable "=" variables[variable]
end
These are only a
Do you see the .CONTEXT object as global, or local to the container
(object, method, routine, etc.) being processed? In other words, do you
see one such object per executing program, or several, each scoped to
the containing object?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAI
I was running through the code make sure I'd finished all of the items
I had intended to be in the last sandbox merge. One of the items I
found I had forgotten to code up was the environment symbol that would
give the currently executing code access to its own containing PACKAGE
object. In my min
Mark,
I was looking at what you've done for processing syntax errors in the
CONSTANT directive test group, and I have some suggestions that might
make these types of tests easier to manage. To start with, you can
completely eliminate the need to write this to a file by using the new
package class
On Tue, Jul 1, 2008 at 10:16 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:
> Mark, this has been wonderfulI think there's one more tutorial
> piece needed, and that's how to write tests where you want to validate
> that an error is generated.
Oh, yeah, you're right. Actually I also meant to sh
hows, there are usually several ways to write the
> same assertion. Pick what you are comfortable with.
>
> 5.) All the assertions have an optional 'message' argument that is the
> last arg. The message is printed out if the assertion fails.
>
> Here is an example:
sertion fails.
Here is an example:
::method test_addition
val = 2 + 3
self~assertSame(6, val, '2 plus 3 must equal 6')
and the output:
[failure] [20080701 09:19:45.455000]
Test: TEST_ADDITION
Class: STREAM.testGroup
File: C:\work.ooRexx\ooRexxUnit\3.2.0\ooRexx\STREAM.t
t.3.2.0>rexx testOORexx.rex -R ooRexx -f stream
...
Tests ran: 4
Assertions: 1
Failures:1
Errors: 0
Skipped files: 0
[failure] [20080701 07:48:09.882000]
Test: TEST_DESCRIPTION_ARG
Class: STREAM.testGroup
File: C:\work.ooRexx\ooRexx
Starting a new test group. I'm going to assume that the reader has
been following along in the thread and try not to repeat myself.
The idea behind this thread is to show how to start writing test cases
even if you do not understand classes by using boilerplate code.
If you download the 02 snaps
I just did a quick scan of the test cases, and it's pretty easy to
find holes in the coverage. Here's what I found in less than 5
minutes of searching:
There's no coverage for the "multiple condition" forms of IF, WHEN,
WHILE, or UNTIL (e.g. "if a = 1, b = 2 then "
There are no select tests t
25 matches
Mail list logo
