World: r3wp
[Core] Discuss core issues
older newer | first last |
Ladislav 10-Jan-2007 [6590] | why Brazilian, Anton? |
Gabriele 10-Jan-2007 [6591] | anton, chris' way is how i'd probably do it. |
Anton 10-Jan-2007 [6592x8] | Ladislav, a reference to Brazilian ju-jitsu, which is wrestling. |
Wait, I haven't shown you this yet. ; my second version, more like Chris's version, using FORALL use-foreach: func [ words [block! word!] data [series!] "The series to traverse" body [block!] "Block to evaluate each time" ][ use words compose/deep [ forall data [ set [(words)] data/1 (body) ] ] ] | |
It uses less words, is easier to understand, but it has a more brittle dependency chain via FORALL mezzanine which uses FORSKIP mezzanine which uses WHILE native. | |
Oh, and although it uses less words, it spreads them out across more lines. | |
Chris' version does not support WORDS argument as a word! - but I don't think it's that important to support. | |
Gabriele, since you say that, Chris' version does remind me of your style of coding. | |
- Nested blocks in the user code might require BIND/COPY. - [throw] (?) - [catch] (?) | |
- RETURN and BREAK ... | |
Volker 10-Jan-2007 [6600] | i opt for chris version. its a loop, foreach is faster. but add a version with more lines, for explanation^^. |
Chris 10-Jan-2007 [6601x3] | 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)]] | |
Anton 10-Jan-2007 [6604x5] | 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. ;-) | |
Volker 10-Jan-2007 [6609] | ; 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 ] ] |
Anton 10-Jan-2007 [6610] | Comments good, but I think, don't add them yet. There are still some code changes to make yet, I think. |
Volker 10-Jan-2007 [6611] | Agreed. Tried to make it more readable. The original looked like magic, but somewhat formatted i find it clear. |
Anton 10-Jan-2007 [6612] | (Also, I think adding FRESH-LOCALS is not a good move.) |
Volker 10-Jan-2007 [6613] | Was for readibility-demonstration.Would notdo that in the working version. but somewhere in the docu. |
Anton 10-Jan-2007 [6614] | Agreed, the original did look like magic. |
Joe 12-Jan-2007 [6615x2] | 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 [] | |
Gabriele 12-Jan-2007 [6617x2] | 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. | |
Ladislav 12-Jan-2007 [6619] | 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? |
Robert 12-Jan-2007 [6620] | I totaly agree. |
Joe 12-Jan-2007 [6621] | gabriele, thanks, does your async library handle async dns ? |
Gabriele 12-Jan-2007 [6622x6] | 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? | |
Ladislav 13-Jan-2007 [6628] | odd - well, another possibility is to say that ods is not even |
Rebolek 13-Jan-2007 [6629] | ladislav yes, ods is not even, ods is odd, but i think that not-czechs can't understand ;-] |
Pekr 13-Jan-2007 [6630] | :-)) |
Ladislav 13-Jan-2007 [6631x2] | sorry for the typo |
I meant: "odd: not even" | |
Joe 14-Jan-2007 [6633] | Gabriele, any news about when the new async core will be released (it was almost ready TWO years ago!) |
Pekr 14-Jan-2007 [6634] | 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 ... |
Joe 14-Jan-2007 [6635] | 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 ! |
Gabriele 15-Jan-2007 [6636] | petr, it's not a cheap trick. r3 is going to be better than the async core. |
Pekr 15-Jan-2007 [6637x2] | 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 .... | |
Gabriele 15-Jan-2007 [6639] | well, i guess i should say again what i said it devcon 2004 with my async core presentation. |
older newer | first last |