World: r3wp

no, but it's cool. I didn't know you could do this :-)

Graham; I've never looked to close at the code, but maybe the ROAM 
tool from the viewtop has some hints.

s/to close/too close/

>> mold/all to-email ""
== ""


Is there a problem here or am I putting too much faith in mold/all?

or perhaps putting too much faith in the email! datatype :-)

latter

so, don't use the email datatype in an object and mold/all when you 
save it.

or use it if you consider data loss a feature :-)

this is a big bug....  even a proper email doesn't get serialized. 
 :-(

actually its more like don't use an email type AT ALL  !

I've had a mental lapse. How do I get the follwing to work:

>> a: func [b /local v] [v: 1 do b]
>> a [print v]

do bind b 'v  ?

Thanks, exactly what I was trying to remember.

is there any better way how to make from nasted block flat one than 
this one:
>> a: []  b: [[1 2][3 4]]  forall b [append a b/1] a
== [1 2 3 4]

is this what you would expect?
>> rejoin [[1 2][3 4]]
== [1 2 [3 4]]

>> load reform [[1 2][3 4]]
== [1 2 3 4]

It may not be sufficient

hm... it's much more faster, maybe I can use it:)

no.. I cannot use it...
load reform [["a" 1][b c]]
== [a 1 b c] ;;;I need ["a" 1 b c]

yes, it destroys strings

>> load trim/with mold/all [["1" 2][3 4]] "[]"
== ["1" 2 3 4
]

hm.. but it looks ugly:) I will rather stay with the forall loop

ugly, but is it slower?

it's still faster

ok.. I will use func flat-block: func[b][load trim/with mold/all 
b "[]"]

than it will be readable enough, I hope:)

I've seen worse code than that :-)

Oldes, avoid FORALL, maybe WHILE is much faster.

>> a: copy b
== [[1 2] [3 4]]
>> while [not tail? a][a: change/part a a/1 1] a: head a
== [1 2 3 4]

flatten: func [
	block [block!]
	/local result pos rule item
] [
	result: make block! 0
	parse block rule: [
		any [
			pos: block! :pos into rule |
			skip (insert/only tail result first pos)
		]
	]
	result
]

Ladislav's is recursive so that may be better.

anton, why do you say to avoid forall?

just speed?

I choosed Anton version which is as fast as the load version (but 
I somehow don't know if it's good just to convert to string and load).. 
and I don't need recursive (which is fine, but slower).. and maxim... 
yes.. just speed (it's a shortcut for forskip anyway)...  on the 
'while version is good that the 'change is automatically skiping 
to the position after change.

ok, I knew for the forskip, I just wanted to know if there where 
any other reasons (some sort of general rule)

Oldes: "which is fine but slower" - apparently you didn't do any 
measurements :-)

(or, maybe you did, but used different computer)

anyway, for small blocks the difference may be small. For bigger 
blocks the CHANGE-based algorithm is awfully slow, since it is O(n 
** 2), while the PARSE-based is just O(n)

example: for block: head insert/dup/only copy [] [1 2] 200000 the 
parse-based FLATTEN needs just about 0,6 sec, while the CHANGE-based 
takes more than 370 sec

parse is really much faster than I would have thought it is...

parse is screaming fast.  I'm using it as the front-end for a commercially 
used tcp service and it beats the server (in spead)  which it speaks 
with (and I mention its a 1200 line rule too ;-).  I had to throttle 
my service so the other end can keep up with how fast I can i/o things 
comming and going.

obviously like regexp, you have to be carefull how you do your rules 
though.

I never measured parse speed before, I just did. It can parse this 
19420 byte text:
http://www.fys.ku.dk/~niclasen/nicomdoc/math.txt
into this 56131 byte html:
http://www.fys.ku.dk/~niclasen/nicomdoc/math.html

in 0.3 seconds on my 1.2 GHz G4 Mac. The parse rules are around 1100 
lines of code. Parse is cool! :-) Good job, Carl!

Maxim, look at source of FORALL. It uses FORSKIP, which uses WHILE 
anyway. Use WHILE directly to avoid function call overhead.

(Also, FORALL just recently changed its behaviour.)

Ladislav, maybe Oldes meant "slower to write" ? I guess I was aiming 
for less typing too. Parse always seems to win in speed of operation. 
Yes, CHANGE is becomes terribly bad for large blocks. I must think 
of a better suggestion.

Ok, here are two more suggestions:

b: [[1 2][3 4]]

; REPEAT-based
a: [] repeat i length? b [append a pick b i]

; PARSE-based (non-recursive)
a: [] parse b [any [pos: block! (insert tail a first pos)]]

And their speed:

time-it: func [code /local t][t: now/precise do code print difference 
now/precise t]

; Ladislav's big block
block: head insert/dup/only copy [] [1 2] 200000

a: [] time-it [repeat i length? block [append a pick block i]]
;==> 0:00:01.062


a: [] time-it [parse block [any [pos: block! (insert tail a first 
pos)]]]
;==> 0:00:00.691

Ooh..