World: r3wp

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.

Or we can do the remove-each copy [not find ...]  method, which tends 
towards n^2.

I'm not sure if I can make a decision here.

If you've imported a module and then updated the module and incremented 
the version of it and then call import again this time requesting 
a newer version than has been loaded shouldn't the module be reloaded?

One would think so .. can you even reload a module?

The answer is yes!  However I'm not sure this is a good idea...

remove/part find system/modules 'module 2
import 'module

anyone know if R3 RENAME will allow moving files and dirs now?

ammon, that doesn't look like an approved reload method!

Ammon, the answer is yes, without changing system/modules. The new 
module is added (and used for all new references), and the old module 
is still referenced in system/modules so the new version can migrate 
data from the old.

system/modules is a block. New modules are just added to the beginning 
of the block. Old versions are not removed by the module system. 
Security issues might prevent them from being removed at all in the 
future - this is an unresolved issue.

The actual module doesn't have much directly in it, just two objects, 
one for the spec, one for the local context. If you empty out the 
local context then there shouldn't be much memory referenced.

Then I've found a bug...  And some unexpected behaviour...

>> t: import 'test-module
>> test
0.0.1
>> t/test
0.0.1
>> t2: import/version 'test-module 0.0.2
** access error: cannot open: %test-module.r reason: none

>> t2: import/version 'test-module 0.0.2
>> test
0.0.1
>> t2/test
0.0.2



Apparently if you don't have the version available in your module 
search path then it errors out without telling you why it failed.

Yeah. The bug is that we need better errors. I am rewriting the module 
system now (more or less, I took a break for a bit). The last stage 
is reviewing the errors and getting more informative ones added to 
the error catalog.