World: r4wp

ladislav: sorry, i'm using terminology sloppily

i guess: assigning to a word in the global (system?) context

that is what both the examples above do

(the 'A word is not local)

yes, but the other part was: not inside a(nother literal) block

That cannot be done.

okay, not inside another explicit literal block

MarcS, yes, now you are in X and Y pointing at the same context.

In REBOL, there is always a block somewhere

henrik: oh, right

ladislav: yes, okay - i'm just saying that i understand the pitfalls 
of not copying when you're re-entering a block (be it a loop, function, 
etc. body)

for example, something like:

do "a: []"

first "converts" the string to a block

but where i'm assigning to a "global" (which i understand is just 
another context) outside of an explicit (one i write myself) literal 
block, are there pitfalls in not using copy

yes, if you are running the same script several times in the same 
console.

also, i get that x: [ append [] 1 ] then 'do x do x' differs from 
x: [ append copy [] 1 ] 'do x do x'

henrik: so if i load the script, then do it, rather than doing the 
file?

makes sense, hadn't considered that

so: best practice is to consider everything to be inside a block, 
and hence copy even toplevel literals?

not even needed. you may DO the same script several times for the 
same effect.

in the

    a: []


it is so, that if you do not "reuse" the literal block then it does 
not matter whether you copy or not

by "reuse" I mean if you do not keep the code and reevaluate it once 
again

right

but of course,

>> x: load %foo.r 
== [
    foo: [] 
    append foo 1
]
>> do x
== [1]
>> do x
== [1 1]
>> foo
== [1 1]

which was henrik's point

actually not

oh!

and by "keep the code" I mean "keep the code as a block", if you 
keep it as a string then it does not matter

do %foo.r
do %foo.r

will produce something you may not intend.

well, if there are side effects, sure

but with the above, i get the anticipated result,

>> do %foo.r
Script: "Untitled" (none)
== [1]
>> do %foo.r
Script: "Untitled" (none)
== [1]
>> foo
== [1]

ladislav: yep, understood

sorry, MarcS. you are right again. I better take a nap...

so to get back to pitfall vs. stylistic - i notice that carl's scripts 
(makedoc, blog) tend not to copy 'global' literals

whereas, for example, the source for vanilla does

However, when writing something like:

a: []


into a file, you may not be totally sure that somebody does not LOAD 
your code and try to evaluate it twice....

yep

so unless you're certain (!) that that won't occur, better to be 
safe and copy?

Yes, copy looks safer....

thanks for the help

Henrik: I've registered on http://hmkdesign.dkBugs database (curecode), 
I got an error when I create a new account but I think it created 
my user. Can you check it please?
My username is "endo".

I've setup a new Cheyenne (r179) with html-008.r included, playing 
with html dialect.

now validated... also validated 3 other registrations from 2009... 
I guess they are in for a surprise email. :-)

Why can't  a button hide itself? Looks like /SHOW? is always set 
TRUE on exit from an action facet:
    view layout [b: button "hide me" [hide b print b/show?]]
   (esc)

   print b/show?   ;; expect FALSE if button clicked, but always get 
   TRUE


My ungainly work-around is to move the button well out of the visible 
area:

   view layout [b: button "hide me" [b/offset: -100x-100 - abs b/offset 
   show b]]

(the abs and -100s allow me to reverse the action to put it back 
where it was)

AFAIK, it's because the action is run on mouse down, and the mouse 
up event causes a redraw, which will then show the button again.

action is run on mouse up.  I can't figure out why face won't stay 
hidden... but its probably because Carl used redraw.   first thing 
I do when I build new styles is to clear the redraw.

you are right. the problem is probably that the action is run before 
the redraw takes place. but it's been a few years now since I worked 
on this problem.

IIRC feel/redraw does a show on a face which forces it back on.

just about every time I've had to fix something with VID it was related 
to the fact that redraw is being used.  its a very bad design... 
redraw should never have been put into the feel.   its also a big 
slowdow, since it forces every face to redraw itself when you show 
a pane.