r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

Andreas
19-Oct-2010
[5497x2]
176-180 == 7-11 :)
Ok, 108 introduces 4 new errors (bad-header, bad-checksum, no-script, 
invalid-port-arg), renames 1 (bad-intrinsic to bad-sys-func) and 
changes the number of arguments for 1 (security-error)
BrianH
19-Oct-2010
[5499]
Then some of the others must have been changed or renamed earlier.
Andreas
19-Oct-2010
[5500x2]
The error IDs in the tests 7-10 do not exist in either A107 or A108.
And the error in 11 was renamed, as stated above.
BrianH
19-Oct-2010
[5502]
Yup. I think that error code checking came in an earlier release.
Andreas
19-Oct-2010
[5503x6]
So those are also things where the testsuite needs to be updated.
Well, maybe those are real regressions nevertheless.
At least the behaviour of error? has changed in this regard.
A107:
>> error? make error! [type: 'foo id: 'bar]
== true
A108:
>> error? make error! [type: 'foo id: 'bar]
** Script error: invalid argument: [type: 'foo id: 'bar]
** Where: make
** Near: make error! [type: 'foo id: 'bar]
I think we had a CC issue for that.
BrianH
19-Oct-2010
[5509x5]
Nope, but the behavior of make error! has changed to actually trigger 
a *different* error if the error codes it is passed aren't in the 
catalog. ERROR? is the same.
ERROR? isn't called in those tests because MAKE error! triggers a 
different error first.
We had a CC issue for that, and the result was adding the error code 
checking to make error!.
The fix was is alpha 98.
was in
Andreas
19-Oct-2010
[5514]
Something changed between A107 and A108.
BrianH
19-Oct-2010
[5515]
A lot changed. What do you mean?
Andreas
19-Oct-2010
[5516x5]
In this specific case.
Ah, I see.
>> make error! [type: 'foo id: 'bar]           
** foo error: (improperly formatted error)
Shouldn't have tested with type: 'script earlier :)
** script error
 and "** Script error" are fatally similar.
BrianH
19-Oct-2010
[5521]
If the error checking of make error! itself is more strict in A108, 
cool :)
Andreas
19-Oct-2010
[5522x2]
So the change is that `make error!` now is strict in what error types 
it accepts.
Yes, exactly.
BrianH
19-Oct-2010
[5524]
Oh, it must have been to error! that was fixed in a98 in the same 
way. Cool.
Andreas
19-Oct-2010
[5525x3]
Or it was "unfixed" somewhen between A98 and A107 :)
Good.
Should be noted on the changelog, though.
BrianH
19-Oct-2010
[5528]
You should add some tests to verify that error code checking. I suggest 
TRY/except as a way to format the tests.
Andreas
19-Oct-2010
[5529]
Hmm, A98 had the same behaviour as A107, for both `to error!` and 
`make error!`.
BrianH
19-Oct-2010
[5530x2]
['error = try/except [make error! [type: 'foo id: 'bar]] ['error]]
That kind of test would help.
Andreas
19-Oct-2010
[5532x2]
try/except [make error! [type: 'foo id: 'bar]] [true]
Good, good!
BrianH
19-Oct-2010
[5534]
A correctly made error is also TRUE? until it is triggered.
Andreas
19-Oct-2010
[5535]
Indeed.
BrianH
19-Oct-2010
[5536x2]
So if the tests succeed on TRUE? conditions, rather than #[true] 
ones, your test will fail with false success. Does your test processor 
check for #[true] results, or does it just standard REBOL conditional 
code?
does it just use
Andreas
19-Oct-2010
[5538x4]
It checks for logic?.
IIRC, but I haven't yet read the code in detail. Given that it was 
written by Ladislav, I suspect it is rather advanced.
Yes, it does indeed logic? test results.
But making the tests a bit more explicit does no harm :)
BrianH
19-Oct-2010
[5542]
The changes to error creation came with the fix to bug#1593. I put 
a comment to that effect in the ticket.
Andreas
19-Oct-2010
[5543]
While you are at it, please reopen bug#1667 and bug#1679, both of 
which are not really fixed in A108.
BrianH
19-Oct-2010
[5544]
I am going through the bugs in numeric order, testing them I have 
reopened a few so far.
Andreas
19-Oct-2010
[5545]
You can also mark bug#1645 as tested, works for me.
BrianH
19-Oct-2010
[5546]
Unless you are an admin, you shouldn't have been able to change the 
status of CC #1647 even if you submitted the ticket, since it was 
marked built. It looks like that CC bug is back.