World: r3wp
[!REBOL3]
older newer | first last |
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. |
Andreas 19-Oct-2010 [5547x2] | I can change all tickets I submitted. |
Anything else would be stupid. | |
BrianH 19-Oct-2010 [5549x3] | CC tickets are supposed to only be changeable by reviewers after they have been reviewed. Otherwise the reviewing process is broken. |
Could you test #1651? | |
Sorry, I mean #1652. | |
Andreas 19-Oct-2010 [5552x2] | Not without a hoskit. |
Added another comment to #328. | |
BrianH 19-Oct-2010 [5554x2] | That would slow down decompression quite a bit. It looks like a /zlib option would be a good idea, to tell it when to try that method. |
Can you determine the length of the uncompressed data using that method? | |
Andreas 19-Oct-2010 [5556x2] | Of course. |
But as I mention, if you do that, it's already 90% of what the decompressor does. | |
BrianH 19-Oct-2010 [5558] | I'll mention in a comment to that ticket my preferred method of your three choices. |
Andreas 19-Oct-2010 [5559x2] | Fine, I'll state my preference afterwards :) |
But I think the sane choice is pretty obvious :) | |
BrianH 19-Oct-2010 [5561] | Done. Go ahead. |
Andreas 19-Oct-2010 [5562] | +1 :) |
BrianH 19-Oct-2010 [5563] | What I was asking before is whether a quick block scan could tell you the size of the decompressed data *before* you decompress, perhaps if you add it up. It's been a while since I studied the zip standard, so I don't remrmber if that was the case. |
Andreas 19-Oct-2010 [5564] | Yes, but you would have to do half of the compression anyway. |
older newer | first last |