World: r3wp

Yes.

ok

It's not retrocompatibility with R3: R3 is the future, so it's forward 
compatibility. If it's not forward compatible with R3, it won't get 
added as a mezzanine to R2. That is a major difference between writing 
mezzanines and just writing fuunctions.

I really do want to make it fast though, because slow functions don't 
get used in optimal code. This is why most of the loop functions 
from R2 have been converted to natives: The non-native loop functions 
were getting optimized out of R2 code.

so you could use 2 differrent foreach blocks

How would that help?

faster when using default map

The foreach block isn't affected by the /into option, so the code 
would be the same.

not the same implementation than with /into

How so?

you don't need to use a result var by default, remember

IIRC, insert tail [], is faster than result: insert result

No, you use tail instead, which is slower. The increase in overhead 
comes from the if value? stuff.

There is not that much difference between insert tail and res: insert 
res (ignoring caching issues, tail is faster). The if value? stuff 
is the big hit though.

hum...

That is not optional though. You might find it interesting that I 
did break compatibility by not backporting a bug :)

The divide-by-zero error is better than the infinite loop :(

The problem with preinserting with the /into option is break handling. 
If you break in the middle of the process, you end up with a bunch 
of nones in the middle of your series. I am interested in solutions 
to this.

something i don't uderstand with your unset! test.
>>head insert [] do []
== []

so, unset! values cause no problem with insert ??? why do you need 
to test that ?
have you an example ?

>> head insert [] ()
== [unset]

about the preinserting, perhaps you should insert in a second block, 
and then add the second into the result at the end of the process

What version of REBOL are you testing with?

R2

Be more specific.

In 2.7.6:
>> head insert [] do []
== [unset]

lol, SYSTEM/VERSION is a tuple of value: 1.3.2.3.1

I wondering if there was a regression in INSERT at some point in 
the last few years.

shit

about the preinserting when /into.
1/use a new result block! (like for default)

2/when exiting the foreach loop, insert the result into the input 
result

The problem is that the whole point of the /into option is to reduce 
the number of intermediate blocks.,

will work with break but not with return.

or you do a remove/part at the end (need of 2 pointers)

or you do nothing...

and it stay slow

It's a quandry. I already had to add a local function to get around 
the limits of FOREACH, because the alternatives were slower. Do you 
have a solution that handles both breaks and returns?

Keep in mind that returns are supposed to be passed through, but 
you can't detect them.

local function again.

the into option begins th have a huge cost....

Only in one case: Inserting into the middle of a series, which is 
usually slow. We could just special case that one situation, or accept 
that it is as slow as it is in the rest of REBOL.

Graham, how about making a jog processor context. The callback func 
is in there, along with a block to collect the data, so it knows 
what results it should get. Have each function call it back with 
its chunk of data. The callback collects the results, and checks 
to see when a "batch" is complete. Then you just need a timeout element 
(store the start time), and something to ping it. If you store the 
original calls, the processor can retry failed calls.

(about the unset! drawback) it was core 2.6.3.
i wondering if it's not a bug of 2.7.6

We should check if it was in the rest of the 2.7 series - 2.7.6 is 
recent, but 2.7.5 is 2 years old.

Gregg ... it's supposed to be real time .. push a button and see 
the graph.  I guess this is the same as Steeve suggests .. wait until 
the results come in, or timeout ...

I guess I should try and keep it simple vs trying to chain all the 
callbacks somehow.

If you can render the graph with partial data, do it each time data 
comes in, or set up a rendering callback that the data callback calls. 
Polling intervals (if needed) can be pretty short without burning 
the CPU. If it's on the net, there's no guarantee of real time. :-)

That's a thought ... it's on localhost ...

the rendering is in a browser ... so that's not going to work unfortunately 
as I can't make the browser refresh.

...without javascript or refresh tags...

The problem then shifts to determining how to make the browser only 
refresh when there is new data.

ajax