That's good to know. I know that Carl was aware of the browser limitation if not multi-threaded. I just didn't know if he worked that into R3.
Kaj
There's unfinished multitasking functionality in R3. It couldn't work if it would be impossible to use R3's internals in a thread-safe way. Indeed, the way functions work was redesigned to make it so
Robert
Has anyone tried to compile in 64bit mode and dived into the problematic areas already?
Robert
I think the first thing to look at is the structu sizes. Either press it back to fit 32bit size, or expand it into 64bit space. Not sure what kind of side-effect this will have.
LiH
Hi, I'm reading the REBOL3's source codes, and I don't know It's a typo or not: in this file https://github.com/rebol/r3/blob/master/src/include/reb-c.h at line 61, about defining the uint type, It seems #ifdef DEF_UINT was not correct. Maybe #ifndef DEF_UINT ?
Cyphre
LiH: to me it looks you are right, you can do "pull request" with the fix.
VincentE
As I'm updating my old scripts on rebol.org, I'm trying to understand the problems with compress/gzip & decompress/gzip , and found at least one issue in u-zlib.c . When compressing, as the checksum method is assumed to be adler32 for most of the code, stream->adler (the current checksum) is wrongly initialized to 1 in two places, giving an off-by-one checksum in the output and making it unusable for decompress/gzip.
Still no clue for what yields the ** Script error: value out of range: none error and why calling compress "" seems to fix this problem sometimes.It seems that something isn't correctly resetted between calls.