World: r3wp

sunanda, I get some nasty crashes with rugby sometimes. I could tear 
my hair out, but decided that this will probably be fixed for R3. 
:-)

pekr: there goes all the negativity again... aren't you doing meditation 
to help you with that?   ;-)

I also experience strange out-of-memory conditions at times with 
non-CGI scripts. I can usually tweak some code until it stops, but 
it does look like garbage collection problems.

I fortunately got one of those crashes drilled down to a few lines 
of code, but it has not been fixed yet, sitting idly in RAMBO.

what negativity? I put smiley to what I said ;-) It is just clear, 
that most new system experience new bugs, no? It will be the same 
for R3, so looking forward to R3.1 already :-)

I know... was just pulling your leg... so you will come and see all 
those crashes at the devcon? yes?

you know, you and I in the same room will make some space-time continuum 
bubble, which will make R3 even more crash prone ;-)  all of that 
negativity swirling around like a maelstrom.

I will save my energy for next year's devcon -imagine - hundreds 
of new R3 users around the world and then elite (current community 
members) telling stories about R2 and old, not always so good, days 
:-)

you could hide in ladislav's luggage  ;-)

and call in sick  ;-)

MULTI-SWITCH:  New function in the code-snippet check list.

If you have a series of nested objects, how do you get the value 
of say, the nth nested object?


is there something like : get in object 'obj1/obj2/obj3/obj4/....objn/parameter

perhaps if you convert the path to a block?

Just wondering if there will be a shortcut method of accessing an 
object

>> to-block 'i/hate/icecream/yes/i/do
== [i hate icecream yes i do]

>> to-path head clear at to-block 'i/hate/icecream/yes/i/do 4
== i/hate/icecream

>> pick 'i/hate/icecream/yes/i/do 3                          
== icecream

This is not accessing the object

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?