World: r4wp

Waiting on a block is always "in addition to". I mean, being able 
to wait on a condition changing, as another wait feature. How would 
you want this implemented? We don't have write barriers for words 
(that I know of). WAIT basically works based on signalling events, 
afaik. Would a port scheme for generic signalling completion of a 
task do, as long as it's easy enough to do?

Yes, a port scheme was something I was thinking of

How does wait on a date! work?  is the date checked or is there a 
signal/event produced on change of system date ?

wait does not work with date!, it works with time.

Ah... the documentation is a little misleading then http://www.rebol.com/r3/docs/functions/wait.html

The spec is taken from R3, but the docs for this function haven't 
been updated from their R2 equivalents. A problem with a lot of the 
R3 docs, I'm afraid.

Thanks for reporting Graham, fixed.

What is fixed?

The problem in the documentation you reported earlier.

ahh... the old version was caching

I'm getting metaphorically killed by the FOREACH function blowing 
a system assertion 1207 periodically. I'm trying to process a couple 
thousand files and it's dying before it's finished. The script will 
need to be rewritten to call another R3 instance per file, just to 
make sure that it completes.

There's only so much of the process that can be rewritten to uzse 
FORALL. And of course MAP-EACH is getting hit by the same bug.

which build?

Latest from rebolsource, but it also affected alpha 111.

and it's not a memory leak?

I was able to make it last longer by switching some calls from FOREACH 
to FORALL - I figure it's a context allocation bug.

I'm going to switch the rest of the code to non-rebinding loops and 
see if that helps.

Well, that doesn't bode well for long running scrips

Right? Gah!

And it's an emergency too, we really need that analysis.

Rebol2

It might be easier. It's parsing, and uses MAP-EACH a lot, and there's 
a bug in MAP-EACH in R2 (that's my fault, sorry), but that is one 
approach I'll have to consider.

Win32, I assume?

Yup.

1207 is RP_MISSING_END

Only point that is thrown is within the GC.

Is it easy for you to reproduce?

I mean, can you quickly run a test binary and see if things improve?

I can reproduce it like clockwork. It even crashes in the same spot 
every time. Send me your test binaries!

I'm going to save this version of the crashing script, then see if 
I can get it to crash with local files only, then see if I can get 
it to crash without using the files at all (since they are proprietary). 
Also, I have to make a separate version that doesn't crash so I can 
get the results. This is annoying, but if we can get a GC bug fixed 
in R3 then it will be worth it.

Apparently I can make it last longer by using the *EACH functions 
less., switching to loops that don't allocate contexts. However, 
I create objects to store the data, so those eventually cause the 
crash. Still repeatable, so it's probably happening after allocating 
a certain number of objects/contexts. It acts identically on 32bit 
and 64bit Win7, crashing at the same point in the process.

Switching the objects allocated in the data to maps makes the crash 
go away altogether. That narrows down what to search for rather thoroughly.

How does one compile r3 for a platform in which there is no existing 
R2 ?

Just curious as to how r3 would make it to Aros

Compile a simple c version of make make for Aros?

Carl states that he can do it in 5 minutes. (Because he has the sources 
for R2) :(

Graham, I thought that make make uses R3, not R2. You could run make 
make on another platform, then copy the resulting setup files to 
your target platform.

that sounds right ... if I can install Aros I might give it a whirl

Going over some basic evaluation errors, which look like they're 
easier to fix than I thought they'd be. While at it, I've been discovering 
R3 language features that I never knew about before. Going to check 
older versions to see when they were added. Turns out that there's 
a SET optimization that I never knew, but which would really come 
in handy :)

>> a: 1 
== 1 
>> set [:b] [a] 
== [a] 
>> b 
== 1


Setting a get-word in a block to a word sets the get-word to the 
value of the word, not to the word itself. This would eliminate the 
intermediary block in most set word-block reduce value-block expressions, 
making it a better multi-assignment function.

Is there an opposite function to DEHEX in R3?

Setting a get-word in a block to a word sets the get-word to the 
value of the word, not to the word itself.

 - this is rather dangerous if not documented, I do not think it is 
 expectable

Rebolek: to-url

Vincent, unfortunately not:


>> to url! "http://www.domain.com?url='http://nope.it.is/unencoded'"
== http://www.domain.com?url='http://nope.it.is/unencoded'

Anyway, I wrote simple enhex function that does what I need.

Ladislav, document it then. It's too useful to drop. And according 
to the docs you couldn't use get-words in SET block at all, so I 
never wrote code that had them. SET block with anything other than 
word! is rare, at least until R3 added FUNCT, which makes set-words 
very common.

It is a little unfortunate that SET [:word] works like get-word parameters 
used to in R2, but don't anymore. Inconsistent. Still, too useful 
to drop.

Works that way in R2 as well, so if it would have caused a problem, 
it hasn't so far :)

Care with documentation on this one.  Could become a problem if people 
know about it.

Not really. It would only be a problem if people started using this 
and someone wanted to remove the feature.

It hasn't been a problem so far, and there's nothing wrong with the 
code. This code:
    set [:get-word] [word]
is currently equivalent to this code in R2:
    get-word: get 'word

There's a general problem in R3 that SET block acts like SET/any 
block, but I'm going to fix that too.

AFAICT noone has used get-words in a SET block call before, even 
in R2 code.