World: r3wp

You are correct sir.  But I had to try.  :)

any one ever encountered an error in REBOL's binding?  yesterday 
I stumbled for hours on a bug in REBOL's interpretation... really.

for some reason, it seems that binding does not handle sub objects 
very well.


strangely, it seems that in a circumstance I cannot determine (and 
cannot reproduce)  when you have a series of nested objects at some 
point, even if you remake all parts of the inner objects, you still 
end up with functions which call previous bindings, thus calling 
the wrong functions!


I had to explicitely call the paths from the supplied outermost object 
back to the current object in order to reach my own local function:

ex:

within the body of a function in objc, I had to call this:

instance/ctx/other-function 


instead of only 'other-function. yet they are defined in the same 
make !

oops objc = ctx

I tried recreating the error and somehow it happens only in a circumstance 
which I can't determine... but its a strange issue cause its the 
first time I hit this in all my years as a reboler.

There are weird, hard to produce errors lurking inside REBOL.

Run 150,000 (separate) CGI sessions and you'll average one unexplainable 
crash......That's the stats from REBOL.org, anyway.

wait for R3 then ....

you will experience .... many more crashes :-)

hahahaha

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