World: r3wp

Some type of diagram would be useful.

you mean like who sends who what?

where are the actors?  where are the workers?

what does actor mean?  what does worker mean?

actor is general name for these units of code that run in "paralel" 
.. each that code block (REBOL object) is one actor ..  (make actor 
, make timer-actor make once-actor .. these are 3 types of actors)

it's somewhat similar to what erlang has

Ah .. so you're assuming your readers know erlang?

Interesting article - with some polish this could be interesting 
to the http://lambda-the-ultimate.orgcrowd :)

I suspect a lot of rebol readers won't be fully conversant with Erlang.

Except Maarten :)

who said he was going to implement a distributed Erlang system in 
Rebol .... some time ago !

However, concurrency fans will definitely be interested in the Erlang 
model, so this is good news for us if it can be efficient.

I'm currently preparing the most significant update of the liquid 
dataflow engine in years, in preparation for remark, I should look 
into this, maybe we could integrate the actor within liquid directly 
 :-)

hm .. yes .. I basically don't explain actors and message passing 
.. so one should not know erlang exactly but this general concept 
.. it's very simple basically .. but I looked at wikipedia and it 
wasn't nicely "graphically" explained .. maybe I should write one 
post about what actors+message passing are

yes, good idea.

Brian .. I am not sure if this is up to the level of Lambda the ultimate 
.. LtU in my rss reader but I only understand 30% of articles :)

you could refer to Apples Grand central  ;-)

But with next rewrite I think actor-net will already become nicer 
and generally consistent .. I now have some sense what works and 
what not ..

Apple grand central seems very interesting to me too .. I saw it 
when someone posted link here .. I was thinking that I would try 
to do taht model in rebol too .. I am interested in concurrency and 
this

(I don't know a lot about it, only it seemed minimal and clear in 
concept which I liked)

janko, maybe you should look into liquid a bit... maybe you'd have 
some perspective on how its kernel could embed an actor... then you'd 
have a robust management layer with very powerfull computing models 
all integrated into one system.  using actors or something similar, 
maybe we could allow the processes themselves to be offloaded.

this is something I wanted to build a long time ago, but just now 
seem to be needing, with remark development.  the ability to break 
up a page's rendering over a network of machines could be quite powerfull 
in allowing extremely high-loads.

Maxim, I will look at it .. Liquid seems very interesting to me , 
I looked at it few times but didn't fully get it .. maybe you would 
need to draw some diagrams .. like me with actors too :)

the current changes I'm adding to liquid is the ability to use bidirectional 
messaging... you can now supply arguments to the process, and it 
will use the params within as an index key to match recurring processing

BrianH .. I am not sure yet .. but maybe I will be able to change 
this system so that actors will be rebol functions instead of objects 
.. that would mean more lighweigh and by that more performant probably 
( you could run more of them, create and destroy more of them faster 
)

and if it will be possible at all, you would gain something that 
now isn't possible .. making state machines very elegantly with them 
like you can with erlang's actors

Your articles have made my to-think-about list, so we'll see how 
mch cleaner and more efficient we can make your model :)

very cool ! .. because none of you gurus ever responded to my 3 posts 
about actor-net I was begining to think I am pushing all this into 
totally stupid direction and I don't even see it (I am not CS educated) 
, now that I know I can chase this with a little more certanty .. 
so this is definately a positive push for me

now that I know it's not totally stupid, I .. = now that I know I 
..

This has been a really busy week for R3 semantics and changes - don't 
take it personally.

no problem at all .. I am very stubborn so I doubted in this only 
at a moment of weakness :)

Meijeru, Fork and Ladislav have really been stirring things up. We've 
had four alpha builds this week.

btw cheyenne with its handlers does the exact same thing as your 
actor system but using http, AFAICT.

I was focusing more on how to make actors look natural and elegant 
with rebol so I wasn't focusing at the implementation at all so far.. 
only so it worked so I could test further .. that's why I called 
all this "playing with actor library"

I was thinking yes that cheyenne has to do something like this , 
but very efficiently since it has multiple worker processes to generate 
responses

and we know how fast it is

Any work you all can do on thinking about this kind of thing will 
help greatly when we finalize the R3 multitasking model :)

And the services model too :)

yes, when I started it I was thinking that it could serve as some 
food for thought on R3 concur model .. because Pekr and others mentioned 
erlang a lot, so I wanted to see how erlang would look in rebol at 
all

well with actors as objects it was basically very easy to make .. 
it fits it nicelly ..

I am familiar with the actor model from back in college, but back 
then (15+ years ago) I hadn't heard of Erlang.

Before then (20+ years ago) I had thought about something similar, 
but had no computer development tools then.

cool

I was interested in erlang before it got popular .. but it's code 
always looked very ugly and complex .. then I got one e-book about 
it .. and in book where I knew what what I was looking it seemed 
very very clean in concepts

Erlang has been getting a lot of attention lately because it has 
a concurrency model that doesn't suck, which is amazing relative 
to most other systems. However, it's syntax is not great - we can 
do better :)

yes, .. syntax somehow looks bad .. after that book , if I go looking 
at erlang code it's still horrible ... I tried to find few times 
how to use its famous webserver YAWS for something ultimately simple 
, but those examples have such code that I just ran away each time

Just goes to show that great functionality (if it's on-topic) can 
beat bad syntax - just look at Perl, C++ or Erlang :)

and it has slow IO .. slower than even other dynamic langs .. another 
minus of it is it's limitation at strings .. so people use binaries 
for strings so code looks like this <<"somestring">> + <<"sadasd">> 
.. quite horrible .. if it werent for these strings I would use it 
for something a while back but strings are the base of webapps and 
writing <<"">> all the time seems horrible

yes :) .. I still think it's code concepts are very nice and clean 
but it's hard to see them when you look at code

and it's concurrency model seems to be one of rare that really work 
well and people can think in it .. that is the geniois of erlang 
probably