World: r3wp

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

I've been looking at ropes lately - it's a kind of functional string 
structure built on trees of immutable substrings. Someone did an 
article about it recently. I think we can implement this in R3 as 
a user-defined string type. Ropes could be useful for increasing 
performance and lowering memory overhead for R3 multitasking and 
large string processing.

I think I saw some article with word ropes on reddit or HN lately 
.. but didn't read it .. from your description it sounds very interesting

I read the article linked from reddit. The author's opinions were 
a bit off sometimes, but the principle is sound. Combining ropes 
with the copy-on-write idea gets you copy-on-write strings that don't 
have to really copy if they don't need to. Only the modified part 
would need new storage - the unmodified part could be referenced 
unchanged. When you combine this with the possibility that PROTECTed 
series may be thread-global in R3, but unprotected series thread-local, 
then functional data structures start to become interesting in R3.

hm.. this would be very good to have .. and it sounds very much like 
data structures that Clojure has ... I think it calls them persistend 
data structures , like list, map, etc .. and the same as you described 
here. You have many versions of a data structure but they share the 
unchanged parts.. this highly benefits functional programming style 
.. you get "new" data structure each time, but without the penalty 
of copying it each time , and is cruicial in concurrency which is 
in focus in clojure, because then different threads dont's share 
and "corrupt" one to another the data structure , but each can have 
it's own revision , etc .. 


I am not that good in this complex stuff, but it might be very intersting 
to you becuase you will know much better what's he talking about 
and how can that be implemented .. they made some of his data structures 
in Factor , so they ren't impossible to make in other languages.. 
I don't remember exacty where I read about this

http://www.blackpepper.co.uk/black-pepper-blog/QCon-Persistent-Data-Structures-and-Managed-References.html

This is where persistent data structures come in. Based on the work 
of Phil Bagwell, Rich Hickey described how he used bit partitioned 
hash tries to make efficient "copies" of data structures, and this 
forms the basis of data storage within Clojure. Essentially all data 
is stored in a tree and when one makes a copy with a small change, 
one can create a tree with a new root and only the path to the changed 
item needs to be copied and modified. The rest of the tree's branches 
remain precisely the same. This significantly reduces the amount 
of copying that is required and makes multiple "versions" of a data 
structure entirely practical.

<<< that upthere is a excert from that article

hm.. it mentions trees like you with that strings .. having strings 
like that in rebol would really be awesome

and if you want to do for example efficient message passing concur. 
it's also cruicial to have this sort of data.. because message is 
always a copy .. if you are using message passing for distr. compuring 
- only between computers then you have to copy anyway so it's no 
penalty .. but if you use message passing for concurrency /paralel 
execution on one computer then copying data for messages each time 
will have a high penalty , but it wouldn't with ropes for example

Graham, your comment about diagram inspired me to do some drawing 
.. http://www.itmmetelko.com/blog/img/actor-net-scheme_t.gifI added 
it to blogpos

Plus, if you have immutable data structures you can copy them or 
not, or even persist them, with no change in semantics.

janko .. I see drawing is not your strong point!  :)   Try this tool 
http://map-editor.s3.amazonaws.com/map-editor.exe

It's just the Rebol 3flex script encapped.

To use it, double click on the blank canvas to create nodes, and 
double click on nodes to edit them.


Drag arrows from one node to another by click and drag from the left 
bottom corner.

Control-L to load a new map

Control-S to save a new map

Brian, yes.. since I like the FP a lot immutable stuff is certanly 
what I like , I sometimes discover looking at things this way solves 
or uncomplicates a lot of traditional imperative problems

Graham.. very very cool .. it seems that you have pockets full of 
magic rebol tools :) .. This graph editor is really nice and works 
smooth

I have updated the drawing again since I missed some connections 
. I was thinking .. once the "looks" of actor net is solid we should 
really move network stuff to uniserve to get the stable and fast 
network base.. it's one 1 function now so it shouldn't be too hard. 
Then I could actually recommend others to use it.

Janko .. not wriiten by me!  I just encapped it :)

See the !3flex channel here.

Twitter have updated their API .. so now if you post using their 
API, it says so whereas it used to say posted from the web.

Janko, how about attempting a CORBA interface ... that would mesh 
in with what you're doing

call/output does not work, when console is not being run? I tried 
to convert some character sets, prepared short script, and run it 
by double-clicking .r file. No result was shown and rebol process 
is hang in memory. It was enough to put one print statement so that 
console showed up, and it was OK then. But that is weird, I wanted 
it to run without REBOL console showing up ...