World: r3wp

Hmm, A98 had the same behaviour as A107, for both `to error!` and 
`make error!`.

['error = try/except [make error! [type: 'foo id: 'bar]] ['error]]

That kind of test would help.

try/except [make error! [type: 'foo id: 'bar]] [true]

Good, good!

A correctly made error is also TRUE? until it is triggered.

Indeed.

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

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 :)

The changes to error creation came with the fix to bug#1593. I put 
a comment to that effect in the ticket.

While you are at it, please reopen bug#1667 and bug#1679, both of 
which are not really fixed in A108.

I am going through the bugs in numeric order, testing them I have 
reopened a few so far.

You can also mark bug#1645 as tested, works for me.

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.

I can change all tickets I submitted.

Anything else would be stupid.

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.

Not without a hoskit.

Added another comment to #328.

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?

Of course.

But as I mention, if you do that, it's already 90% of what the decompressor 
does.

I'll mention in a comment to that ticket my preferred method of your 
three choices.

Fine, I'll state my preference afterwards :)

But I think the sane choice is pretty obvious :)

Done. Go ahead.

+1 :)

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.

Yes, but you would have to do half of the compression anyway.

As far as I remember, there are blocks with a length field, and blocks 
without (where you'll need to skip thru encoded the characters).

one thing that continually amazes me is that meijeru is probably 
the most prolific R3 bug poster/tester ever,  yet we know virtually 
nothing of him... 

its very intriguing that this guy has such deep knowldege of R3 but 
doesn't actually seem to be actively participating in any public 
Rebol project or employment that I know of.


maybe even more importantly where it not for curecode we probably 
woudn't even really be aware of this seemingly really nice guy...

Eh??  Rudolph did the Dom Level 3 implementation mentioned here http://rebolweek.blogspot.com/2008_03_01_archive.html

Perhaps you need to read the rebolweek blog!

yep... AFAIK, that single thread and then nothing ever again until 
he pops up on CC and starts debugging like a mad man  ;-).  

I mean he is really low-profile.

I guess some people talk about things and others just do them.

others do both and don't get the time to release  them  ;-)

so you're looking for post mortem fame?

isn't that when things get valued to millions  ;-)

pesos

notice that I've recently released a few things quickly and this 
thread is just going to continue  :-)

thread=trend

Wow, Christian took my advice, and redo ODBC extension into .DLL 
form, and now it uses ports! That is cool. Should be imo reported 
to rebolweek :-) 

http://www.diefettenjahresindvorbei.de/odbc/odbc-docs.html

And I've taken your advice to publish a .dll, too. Somestimes, yeah, 
sometimes, I take advice ...