World: r3wp

Anton, would it add too much to change the 'forall loop to a 'while 
loop?

Fundamentally, I don't see much difference in our separate approaches. 
 Using 'compose certainly makes it easier to read.  (I'm not sure 
why, I seem to have an inherent aversion to 'compose)

Using compose, I could get the word! argument working:

bind body first words: use words compose/deep [[(words)]]

Volker, yep, documentation last, as usual !

Chris, no, I would do it:

; my fourth version, using WHILE
	use-foreach: func [
		words [block! word!]
		data [series!] "The series to traverse"
		body [block!] "Block to evaluate each time"
	][
		use words compose/deep [
			while [not tail? data][
				set [(words)] data/1
				(body)
				data: next data
			]
		]
	]

It's a pity that it uses five more words, but the extra stability 
and simplicity of going direct to a native seems worth it.

(FORALL will be ok, it gets enough usage in normal code. ;-)

; more commented:
use-foreach: func [words records body /local fresh-locals][
    ; make fresh locals for the args
    fresh-locals: use words reduce  [words] ; trick
    ; bind body to one of  the new locals
    bind body first fresh-locals
    ; now loop
    foreach record records [
        set words record 
        do body
    ]
]

Comments good, but I think, don't add them yet. There are still some 
code changes to make yet, I think.

Agreed. Tried to make it  more readable. The original looked like 
magic, but somewhat formatted i find it clear.

(Also, I think adding FRESH-LOCALS is not a good move.)

Was for readibility-demonstration.Would notdo that in the working 
version. but somewhere in the docu.

Agreed, the original did look like magic.

has anybody used core async dns ? I am trying to resolve domains 
using a port per domain but I get a sequential behaviour. Ideally, 
this should be done with a single port, sending requests and getting 
replies in an async fashion. snippet below

f-awake: func [
	port
	/local res
][
	res: 	copy port
	print 	[port/user-data/host res]
	remove	find system/ports/wait-list port
	false
]


b-hosts: [ "www.rebol.net" "www.google.com" "www.yahoo.com" "www.microsoft.com" 
"xxafda" "www.ebay.com" "www.amazon.com" ]
foreach	h b-hosts [
		 p: 	open/no-wait make port! [
				scheme: 	'dns
				host:		"/async"
				user-data:	reduce ['host h]
				awake:		:f-awake
			]
		insert	tail system/ports/wait-list p
		insert	p h
	]
wait 	[]

although dns:///async is asyncronous, it probably can't do multiple 
host resolution at the same time.

i never used it this way, so i can't say if it can be made to work. 
but by thinking about how this is implemented on unix (a second process 
that calls gethostbyname), i'd guess that it can only do one host 
resolution at a time.

only now I noticed, that:

    even? 0.1 ; == true


my understanding differs slightly, I would more likely expect a test 
like:

    zero? 0.1 // 2

any opinions?

I totaly agree.

gabriele, thanks, does your async library handle async dns ?

yes, when you use the async:// protocol the host name is resolved 
asynchronously.

but i never tried what happens if i try to resolve many hosts at 
the same time

(btw, my code is very similar to yours above, so i think you're using 
it correctly.)

http://www.colellachiara.com/soft/libs/async-protocol.r

ladislav, i guess even? and odd? just convert everything to integer?

with your test above, would any non-integer number be odd?

odd - well, another possibility is to say that ods is not even

ladislav yes, ods is not even, ods is odd, but i think that not-czechs 
can't understand ;-]

:-))

sorry for the typo

I meant: "odd: not even"

Gabriele, any news about when the new async core will be released 
(it was almost ready TWO years ago!)

Joe - I wonder if it gets ever released. RT is now dedicated to R3, 
so I would not away some major architecture changes in 2.x family. 
And as R3 should support tasking probably via threads, my suspicion 
is, that we are going to be playing cheap tricks - suggesting ppl 
to use new thread for each new connection, instead of implementing/fixing 
async mode. IIRC even Gabriele expressed himself in the past, that 
coding async is not all that easy, and that it might be better to 
use threading ...

iirc there was a blog post mentioning that it would get added in 
1.3.x . I hope so !  Async networking is a must for decent performance 
apps !

petr, it's not a cheap trick. r3 is going to be better than the async 
core.

Gabriele - I hope so - otoh - what is the expense of threads? I looked 
into my friends code programming server in Delphi - they used exactly 
that - simply new thread for each connection. I would like to know 
what is the overhead - speed, memory etc. I called it "a cheap trick", 
as my friend could not even imagine, how he would do a multiplexed 
scenario ...

With current aproach I at least learned difference between blocking, 
non-blocking io and correspondive techniques. My opinion is, that 
underlying engine (REBOL) should not use task/thread unless I ask 
it to do it. That is why I think that kernel should be anync in its 
roots too ....

well, i guess i should say again what i said it devcon 2004 with 
my async core presentation.

the first thing i said was: "why async?"

for two reasons: 1) it gives you more control over things; which 
means it is harder than threading, but threading is just "looking" 
simpler, while it actually isn't, so with threading you get many 
hard to debug problems later on. with async you get the hard part 
in the beginning, so you don't get fooled into believing it works 
while it doesn't. 2) rebol does not have threading.

so... with r3, the second reason just goes away.

let's get on the first reason: why did I say that threading is worse? 
for the reason holger explained a lot of time ago on the mailing 
list. shared memory.

ok, maybe I mix things incorrectly. I will ask other way - async 
and non-blocking are two separate things, right? I don't need async 
console etc., that I might solve via threading. But - will it be 
possible to have fully non-blocking behavior? Even for DNS reads 
(it is now) and opening connection?

that is, handling concurrency in a threaded app is hard, so they 
just fool you into thinking that threading is easier.

but - now this is the difference: as far as i know, our goal with 
r3 is to have no sharing between threads (from the point of view 
of the user, of course) unless really necessary.

that is, the user does not have to handle concurrency. you just talk 
with other "threads" (tasks would probably be a better term) with 
ports

which must mean, that the ports in question must be async.

Gabriele - so what is "tasking" in R3 going to be under the hood? 
There were various things said - 1) we will have something like make 
task! syntax, which will use OS threads in the background, just hiding 
the complexity of threading model from user (= simplicity in rebol 
level) 2) In one of recent blogs and their comments Carl said he 
might have its own way of how to do tasking in Rebol. So, how will 
it look? Is it already decided?

what you describe above, can be easily obtained by doing the dns 
resolution in one task. what you see is a port, that to you looks 
exactly like an async dns port. except that it is implemented in 
mezz code rather than being native.