World: r3wp

Doc wrote async-call which would also work .. except it locks up 
VID when I recently tested it.

How does one determine which of the interfaces reported by get-modes 
tcp:// 'interfaces is the active one??

I see lo0, if11, if25, if13

This is pretty cool ... I am sitting in front of my laptop, and on 
the other side of the room is my 46" LCD screen with my media PC 
attached.  I installed the rebxr xmlrpc server on it .., and I have 
cheyenne installed on the laptop.  I click on a file in my application, 
it gets downloaded to the www directory in cheyenne, and then I send 
a command to the xmlrpc server to browse to that file so that it 
displays on the big screen but is served up by the laptop's cheyenne 
server.

It's now quite remote controlling a browser on another PC because 
all I can do is tell it to open a new page.

not quite

I presume using xmlrpc I can ask the server to spawn more instances 
of itself on different ports so that I cah have a number of different 
"tasks" available

Question : 
I have a script like this :

ctx: context [
	markup: "my script with <%val1%> and <%val2%>"
	val1: "Hello"
	val2: "Bye"
	build: does [build-markup markup]
]

It produce this result :
>> ctx/build

== {my script with ***ERROR no-value in: val1 and ***ERROR no-value 
in: val2}


Its because 'build-markup use 'parse and 'parse looks its word in 
the global context.

Is there any binding tricks to solve this ?

Smart Guys... What's the trick to using a variable to hold an email 
address when using "Send"
Send/header  some-email-address Some-text myheader
I always get a failed email because  the "To:"  word is not set.
If you directly type in an email address such as
Send/header  [confused-:-rebol-:-com] Some-text myheader

It works. I've tried composing, reducing, scrubbing and washing and 
the stains still don't come out, if you know what I mean.

There must be some trick. (And I know you know)

what is the type of some-email-address?

It's an email

Its weird. I've tried placing it in a block, etc.

then it would be a bug, if it doesn't get passed to 'send.

I can't believe after all these years that it's still there.

just had a look at the SEND source and from what I saw it is highly 
unlikely that it does not work Moreover, I am actually using the 
SEND function from time to time and no such problem occurrred.

so, I bet, that your description is missing some detail

Henrik and Ladislav, 

OK, stupid me. I was using a word name that I shouldn't have. Thanks!

Didier, assuming you can't preface the markup fields with the context 
name, e.g. 

  markup: "my script with <%ctx/val1%> and <%ctx/val2%>"


either manually or programmatically, hacking build-markup may be 
best. e.g., add a /with refinement that takes the object and bind 
to that.

DideC.
even this does not really use markup, it works at least
ctx: context [
	markup: ["my script with" val1 "and" val2]
	val1: "Hello"
	val2: "Bye"
	build: does [build-markup form reduce markup]
]

Obviously, I was tired yesterday !! If not I would have done this 
without asking. By the way, thanks sqlab!

I wrote a blogpost with code about the usage of actor-net lib that 
we chatted with Graham a little (few days back) http://itmmetelko.com/blog/2009/07/03/rebols-actor-net-used-for-real-distributed-system/

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 
..