World: r3wp

OpenGL GLUT events are driven by callbacks, which we can now push 
into REBOL "user space".


so for example, you provide an on-key() or on-mouse-down() callback, 
and you receive the events, directly at the function.

that sounds cool, doesn't it? :-)

yep.

all this nice stuff can be seen as a real ... enabler. I vote for 
the tasking/IPC being next, changing codecs to streamed port model, 
and then marking R3 Core a beta .... but not sooner ....

after we get those two, most of the framework will be ready for the 
prime-time ...

with a few more network schemes I agree.

yes, but network schemes are done on top of the framework itself. 
Adding them, does not influence the Core itself, while I fear, that 
not having tasking in the beta, could also mean, that later on it 
migh generate the need to change our code ...

yep, but I mean that the network schemes are important and should 
be part of the beta phase.  we don't have much working right now.

the tasking/ipc HAS TO be part of the beta. It will influence module 
code, etc. Codecs might come for 3.1 (unless we produce lot's of 
codec, which will change later)

yes - simply put - releasing R3 should mean, that ppl can do at least 
the same work, as using R2, or we have got a regression ....

I don't see tasks as that important as callbacks. Can someone please 
make a clear business-case for tasks? I know it's nice and helpful 
for some areas but is it mandatory?

I try to keep away as long as possible.

architecture can't be driven only by the business case point of view 
imo ...

well, given that REBOL isn't the fastest at processor intensive work, 
anything that could help spread things out over multiple cores would 
be welcome

just ask BrianH, how tasking/ipc might influence some core areas 
(especially module code). I fear we might face some incompatibilities. 
Well, otoh - when Carl finishes callbacks/extensions, what is your 
idea Robert, Carl should work on next? Even if it would be driven 
by some business-case?

but, IMO, parallel processing should be transparent - we should take 
a look at how F# exposes concurrent programming - really intuitive

I guess I can CureCode the request

IMO bug fixing should be the focus.

robert, task, non blocking interfaces?

async only is not sufficient for this. tasks are essential for commercial 
developing.

yes... most applications now are multi-threaded if only to make them 
smoother...  the GUI in one thread, heavy lifting in another, for 
example.


async, doesn't allow you to scale, only to time slice.   you can 
still only compute on a single request at a time.

if the request needs time to finish (rendering, for example), it 
effectively blocks all async and I/O handling.

R3 handles events on a timer base. So there is at least a way to 
do cooperative multitasking.

yes but you are still limited by the quantity you can process.  with 
just about every cpu out there now having at least two cores, its 
great waste.


with most of the serious apps I've done, multi-threading would have 
made things much easier or in the least smooth and interactive.  
with servers, I need not present a case, threading speaks for itself.

personally, I'd rather not have the focus be on "threads", but rather 
on concurrent or parallel programming - if done right, the user should 
be shielded away from inter-task synchronization as much as possible

Ok, maybe I need to make clear that I'm not against threads. But 
IMO it's better to get something done and finished now, and release 
it. Than keep the pace and concentrate on threads on the next release.

the word "thread" makes me think too much of the low level thread 
management that you typically do when that is the only concurrent 
programming construct

Most of the non-graphics mezzanine code is already tasking-safe, 
as that was kept in mind when we went over them early on. The module 
system would be most affected by tasking issues, but the necessary 
changes would be relatively simple since the refactoring is mostly 
done already.

Adrian, unfortunately that description may characterize the tasking 
model. For all its high-level features, in many ways REBOL is a low-level 
programming language. We don't have internal process separation, 
and we do have modifiability. The tricks that are done to make functional 
languages at all efficient require compilation, and we don't have 
that. Managing any of the new concurrency models requires changing 
the core semantics of the language and we aren't doing that much.

We will be able to build higher-level concurrency models in R3, but 
the core model is very low-level and requires a lot of manual management. 
I suppose that's rather REBOL-like since that can be said about binding 
and scoping as well.

oh well :-( , better low level multi-core support than nothing - 
what synchronization constructs have been talked about so far?

None: We haven't been talking about it yet. There has been some speculation 
that PROTECTed data could be shared, and the "user context" is supposed 
to be task-specific (designed that way, not task-specific yet). But 
the PROTECT security model isn't finished yet (there are tickets 
yet to implement), and nothing has yet been done to make it tasking-friendly.

Strangely enough, the only thing about tasks that works so far is 
tasks themselves, as long as you don't trigger any errors.

AdrianS: for what have been discussed so far - http://www.rebol.net/wiki/IPC_-_Inter-process_communication

http://blog.sitescraper.net/2010/06/scraping-javascript-webpages-in-python.html

http://blog.sitescraper.net/2010/06/scraping-javascript-webpages-in-python.html

is the SDK prebol available for R3?

BrianH, was there ever talk about a function that returns only duplicates 
in a series?

(prebol question has been answered)

I remember there being such a discussion, but it never really went 
anywhere.

if I say "pretty please", can we have such a mezz? :-)

see r3 chat #4447 for discussion there.

It would be expensive. And aren't we trying to make things optional 
now? It would complement DEDUPLICATE well though.

yes, I'm not sure there is a way to make it in-expensive, but I've 
stumbled onto several situations where I would like not having to 
write and test it.

These would make good library functions. Give me a moment.

Would it be alright to skip the /skip option? Then we can use a map! 
to do the work without too much overhead.

I'm fine with that, but it would perhaps lose a bit of consistency.

The problem with the /skip is that we would have to write our own 
hash function, or copy/part every record at least once, or go n^2.

The problem with the map! method is that we would have limits on 
what could be in the block.

ok

There's the 2-block method, which would only top out at n^2 performance. 
Or we could hybrid, using map! for non-structures.