AltME groups: search

I am also not yet sure how/if this could be usefull :), but as I 
said it's very impressive that you can do that (I have to go to sleep 
now)

Ahhh! I see  hmmm  I think all I will  need to do is reorder *between* 
references and subject those  sub-blocks 
 to further partitioning

the initial offset  (which column)  the sort is on changes, but that 
is 
sort/skip/compare/part  ref1 span   column  ref2

Brian's concern is what does this sort do to ref5 and ref 6  position. 
are they still valid.

time to experiment

Not sure what your trying to do but in your function change the object 
reference to self such as:

self/obj-in-obj/a:

see if that makes a difference

I am not so exp. rebol user as you but where do you use lit words 
as they are.. I used them only to pass words (reduced lit-words) 
basically so far ... in blocks never

 write  [  'some 'random 'words ]  but  [ some random words ]  as 
 they don't get evaled anyway

Does this help?  X contains the code you see and type, the lit-word! 
typed in.  It gets reduced to its word value..
>> X: [type? 'one]
== [type? 'one]
>> type? X/2
== lit-word!
>> do X
== word!

In other words how do we not know that the native lit-word? function 
couldn't be modified to in fact report true in this case?

Surely we can return true with a modification to lit-word? function 
to do the same for lit-word? 'test

>> val: first ['a]
== 'a
>> lit-word? val
== false
>> lit-word? :val
== true
>> lit-word? first ['a]
== true


It's not the assignment or LIT-WORD? that is converting the lit-word! 
to a word!, it is DO. This is a good thing.

If you want DO to just get a value and not treat active values as 
values, use a get-word expression. This is evaluation model stuff. 
You need to be able to distinguish between the data that your code 
is working on, from the data that your code *is*, itself.

Paul, in REBOL 'test is a lit-word!. The problem is that you are 
getting datatypes and evaluation rules mixed up. When you are evaluating 
your own data, you can treat lit-words any way you like. When DO 
is evaluating *its* data (what you would call normal REBOL code), 
it treats lit-words as active values. Active values are normally 
evaluated when DO encounters them - the only exception is when they 
are just retrieved from some word they are assigned to, either using 
GET, or DO's shortcut for GET: get-words. All of DO's active values 
work this way.


And there is a good reason DO treats lit-words as active values: 
If there were no active lit-words, DO wouldn't be able to refer to 
word values without breaking words as variables, and normal REBOL 
code would cease to function.


When I say that it is not a bug that lit-words are active values, 
I am understating things. What is really the case is that lit-words 
being active values is the *entire reason for their existence* - 
if they weren't active values, there would be no point to them at 
all. Oh, and REBOL code wouldn't be able to work with its current 
syntax.

By the time LIT-WORD? sees the value, DO has already converted it 
to a word!, the way it is supposed to. LIT-WORD? works fine.

You aren't passing 'test as an argument to LIT-WORD? whenn you do 
this:
lit-word? 'test
==false

What you are doing is *evaluating* 'test and then passing *that* 
value to LIT-WORD?. There's a difference.

Functions do brian.  Which is my point that lit-word? could be modified 
to handle this.  You act like it can't be done.

Functions don't evaluate their arguments, the evaluator does. Your 
change to LIT-WORD? would break it. When you DO a lit-word! it returns 
the associated word! value. That is what lit-words mean in DO code: 
Literal words.

Rebol from the command line, as well as a running script IS a 'do 
session, that's what we're trying to get at.  'do is what's converting 
the lit-word! into a word! before it reaches the function

When, you've typed something at the console:

	>> 'test	

, and you press Enter, it is as if this is happening in a script:

	do ['test]


The result is equivalent - a lit-word reduces to a word, which is 
returned.

So.. it looks to me like this is just what you wanted:  any [word? 
val  lit-word? val]
Is it, or does is-lit-word? do something I'm missing?

Here is what BrianH said:


You aren't passing 'test as an argument to LIT-WORD? whenn you do 
this:
lit-word? 'test
==false

What you are doing is *evaluating* 'test and then passing *that* 
value to LIT-WORD?. There's a difference.

I have some plans for such a kit, but it depends on if I will get 
time to do it and if it collides with R3 GUI development. It involves 
removing some parts of the current VID, like the WindowsXP style 
buttons and making SET-FACE and GET-FACE uniform for all styles. 
Also adding some new styles and the new resize scheme would go under 
that. It would make VID way less painful to use.

For that matter, after the module rework so will modules, to the 
extent that I can do it. Probably based on Gabriele's code if I can 
convince him to MIT it - his code is currently BSD, and BSD's non-promotion 
clause may be at odds with the extensive attribution I've put in 
R2-Forward. That's why I used MIT: BSD licensing is too restrictive.

The same goes for pre-open-source Java and .NET code on the MS runtime 
instead of Mono: No GPL2 code, and no static linking of LGPL2 code, 
even if you do provide the source. You gotta use an exception like 
Classpath to use (L)GPL2. (L)GPL3 fixes this.

ah, it does that for a different reason than you might think. b/2 
references the second string itself, not the index in the block where 
the second string is.

you may want to do something like:

insert at a 2 '-


If you don't want to destroy 'a, copy it first, but in this case 
/deep is not necessary, as you wouldn't be affecting the strings 
in the block, only their positions.

I'll add the Unicode compatibility restrictions to the "Intentionally 
not supported:" list when I do the next release.

What is the etiquette for using metadata in a REBOL header?  Here's 
some scenarios:

A) From Viewtop:

	REBOL [
		type: 'index
	]

	title "My RebPage"


This is clearly ok, and a good way for an application to determine 
the disposition of data - in this case a Dialect.

B) I use this for QM modules:

	REBOL [
		type: 'module
		exports: [do-something]
	]

	var: 1
	do-something: func [val][val * var]


This adds a little more, as the 'exports block is more than just 
an 'id, it's contents are bound to the application.  Moreover, 'exports 
is not in the standard header.


C) A hypothetical dialect definition with some 'do code (I'll use 
VID to demonstrate):

	REBOL [
		title: "My Application Window"
		type: 'vid
		locals: [mybtn myarea]
		on-close: [save-all quit]
		options: [resize min-size (config/min)]
	]

	h1 "My Small App"
	myarea: area "Some Text"
	mybtn: btn "Submit" [save-all]



Now obviously all these cases can be fleshed out with R2, but is 
this abuse of the header?  There's still no security issue 'loading 
the file, indeed it takes a special handler to actually execute the 
code.  But again, is this taking the header where it shouldn't go? 
 What of R3?

in this simple case, its still pretty harmless, and you can still 
argue that its still a "setting", but I do think going to far is 
a dangerous can of worms.

I used to put history editing commands in the headers, and changed 
to a specification + data in the header, then parsed via a dialect. 
 seems cleaner and pretty in the end, and the user has to properly 
understand the spec in order to do anything, so its like forcing 
proper documentation and learning.

It's certainly not something I would choose to do lightly (I wouldn't 
be asking if I didn't feel a little trepidation in using it), however, 
in REBOL, code is data, data is code.  It may well be a way to solve 
a certain problem...

Callbacks.  One instance I'm thinking of is to have a file containing 
only a parse dialect -- parse "text" load %rule.r -- and having some 
callbacks specific to the rule - eg. on-success and on-fail.  Feels 
like it could be a natural way to do it.

The problem is what to do when the sizes of the two blocks don't 
match.

it has to match

 - That's the problem. What happens if it doesn't? Is an error thrown? 
 Do you just go as far as you can? Do you fill in the missing data 
 with none placeholders (my preference)? This needs to be decided.

This function sounds more like MOVE than FLATTEN. We had a debate 
about both of those functions, and MOVE was included while FLATTEN 
wasn't. It all came down to three factors:
- Is this function generally useful, or would it be used rarely?
- Is there consensus about what it should do?

- Is the function so difficult to get right that it makes sense to 
include it for that reason alone?


In the case of MOVE and FLATTEN, both were considered useful, but 
only MOVE had consensus and was tricky enough to be worth including, 
especially since the features had to be carefully restricted for 
it to work safely. FLATTEN was considered useful, but no two people 
requested the same behavior, and every implementation was so simplistic 
that it was hard to get wrong.


This multi-series loop function seems more like MOVE in this regard, 
but only if we can agree on what it should do.

tried to made nforeach for R3: 
- missing do/next to evaluate functions in the data block

- probably speed optimizations can be made (not probably, certainly)

nforeach: func [
	data [block!] body [block!]
	/local vars
][
	vars: make block! (length? data) / 2
	data: copy data
	forskip data 2 [
		append vars data/1 			;* extract vars

  change/only data to block! data/1 	;* convert vars to block (if needed)

  if word? data/2 [poke data 2 get data/2];* get serie from word (do/next 
  much relevant if available) 
	]	

 vars: bind? first use vars reduce [vars]	;* create a context with 
 vars
	bind head data vars
	while [
		also not tail? second data: head data 
		forskip data 2 [
			poke data 2 skip set data/1 data/2 length? data/1
		]
	] bind/copy body vars
]

Nothing about a function like nforeach should require DO/next. If 
it does, that would be the first thing to fix.

Gabriele, I'm having a little trouble finding your request for the 
DO operation in R3 chat, under the R3/Parse heading (28). I already 
added your DO proposal to the official Parse Proposals page months 
ago (with some semantic cleanup) but if you don't speak up in the 
discussion forum then I will have more trouble convincing Carl. Any 
requests for it here might as well be thrown away - they will be 
long gone before we get to PARSE.

As for nforeach, you didn't catch that the first thing I would change 
would be to have the words and data in separate blocks, to make generation 
of the data and pipelining easier. The words are an artifact of the 
call to nforeach, not part of the data. You need DO/next to implement 
the old version, not a version that I was talking about. Any REDUCE 
would be outside the function.

Brian: i was not comparing wiki to docs. I was comparing wiki to 
chat. If i need to restate do in chat, why is the wiki there?

Gab, sorry, I thought you were talking about DocBase (as others were) 
rather than the parse proposals. The reason I mentioned the chat 
is because you keep bringing up the DO operation as if you are trying 
to convince us of its importance, but we all agree with you so it 
doesn't help. I was trying to point you to a forum where trying to 
convince someone about a parse proposal would have some effect.

You have a good point about the nforeach reduce thing, but I am not 
convinced that giving up the ability to generate the data in other 
functions is worth it. I usually don't like to see DO/next in mezzanine 
code anyway: DO/next is usually a sign of a function that doesn't 
work in a REBOL-like way and has too much overhead to use. However, 
I still want Carl to fix DO/next in R3 - it doesn't work at all at 
the moment, and there are some proposed functions that can't be implemented 
without it.

to me do/next is just a sign of a dialect :-)

Chris, that sounds like a good job for DO/next. It also sounds like 
a function that would be replaced by CASE [NOT ... when the code 
is being optimized. REBOL programmers can be pretty ruthless when 
it comes to hand-optimization, so one of the goals of R3 is to make 
the mezzanine functions powerful and efficient enough that they will 
actually get used rather than optimized away, and to make native 
the functions that need to be. The hope is that the users of REBOL 
can just use functions and trust that they will be efficient, rather 
than having to manually inline code all of the time.

In other words, would it make sense to compare apples and pears? 
We kinda do that with char and integer now.

Documentation is the most important aspect for me, so people know 
what to expect. 


I don't want = to be as loose as you do, John, but maybe a loose/load-equal? 
op could be added. It's not something I've ever felt I needed. What 
scenario(s) do you want it for?

You touches some problem, I have, with remembering the difference 
between FORM and TO-STRING. I can't remember what these produce:
form [1 2 3]
to-string [1 2 3]

I have to try it. You have good points. What do you see as the arguments 
to both have = and == in REBOL?

I'm obviously talking low level here and not what we have ability 
to do via REBOL.

there is no other way... you have to know the bounds, and allow ram 
to be recycled.  indirection is the only way to do this.  rebol has 
its own memory manager.

Paul : never and I never plan to do so.

By installing or using the SOFTWARE, you are consenting to be
bound 
by and are becoming a party to this AGREEMENT. If you do
not agree 
to all of the terms of this AGREEMENT, do not use the
SOFTWARE.

What do you see as the arguments to both have = and == in REBOL?


There are times when you care about strict equality, and times when 
you don't. And it's a balancing act between usability, strictness, 
and risk; similar to the choice of making a language case sensitive 
or not.

In REBOL:
>> 0.1 + 0.1 + 0.1 = 0.3
== true


In C, this is not true. So REBOL tries to cope with this problem, 
but don't do it 100%.

Hm, a SWAP command could be a good idea, maybe. Or just do:
set [a b] reduce [b a]


About freeing local variables, why would you do that? Don't you call 
your function several times? You give garbage collector more to do 
this way. If it's often the case, that locals should be freed, then 
maybe we need a new function type, that does that?


(I'm asking all this, because I never understood the reason for having 
ALSO.)

In fact i use ALSO in functions to save the use of temporay variables.

Instead of doing  that:
func  [.. /local result][
	....
	result: ... 	;*** compute result
	... do something before returning the result
	:result    ;** return the result
]

I do:

func  [.. /local result][
	....
	 also (compute the result)
	.(do something before returning the result)
]

It saves the declaration of the result local var

wow, thanks Paul.  I think I freaked momenarily.  If I have to do 
it through Windoze I figure I could do a call (as a backup plan)

So you have this process-port function, and you need ALSO to not 
have an extra variable. I would just write:
... copy port
close port

without calling some function to do it.

I would never do the first, because there is no close to be seen 
for every open.

I've used it in a couple places, almost always having to do with 
ports - it is much nicer than spanning 3 lines for the same thing

Do you have any code, I can see? To see how you use it.

And why do you want to clear it? To save resources? But what then 
with the version, you return?

If you want to load more MP3s, it would be a good idea to reuse the 
same memory area. An example:

>> f: func [/local blk] [blk: []]   
>> a: f
== []
>> insert a 42
== []
>> a
== [42]
>> source f
f: func [/local blk][blk: [42]]
>> clear a
== []
>> source f
f: func [/local blk][blk: []]


You see, A and BLK inside F points to the same memory. Next time 
you call F, you can put some more stuff in BLK (read another MP3).

If you want to be able to completely remove BLK, I would do that 
using an object. Build the MP3 player as an object, instead of just 
a function. Makes sense?

that is what we do with ALSO, we set the return item to none.

John, yes true but what if you want to do several things with the 
local in the function?  Are you going to copy it every time?

Paul, in your last example with copy, the q memory is released, and 
the string after copy remains. So this actually is a version with 
something gained. Now I have to think, if I would do it this way.

Which is a good thing to do, because now the function does not maintain 
a reference to the large binary series after it has been called.

Geomol: I never said I do my-port: also... if you need to use a local 
word then you don't need also. I need also all the time.

Geomol, "just save a local word" - this is very useful !  I think 
ALSO just might take a bit of getting used to. It's like many other 
Rebol functions that we are now familiar with and use without thinking 
of its internal variable use. Do you think LOOP and REPEAT should 
not exist because they can be implemented with WHILE and a temporary 
variable? I reckon they are so cool to have in the language, because 
they make the code cleaner.

No, R2 doesn't use registers. The context assigned to the function 
is reused, with the value block switched out on recursion. The original 
(non-recursive) value block is left alone when the function returns, 
and set to nones on function entry. This is where the memory leaks 
come from: unintentionally persistent references to local variables. 
R2 actually does have a stack (it's a block), but it is used differently.


R3 just has a second context type that does stack-indirect word dereferencing. 
When the function starts a block of values is pushed on the task-local 
stack and the references to those values do an additional indirection 
to get the stack frame before getting the values - this is why function! 
word dereferencing is 28% slower than object! or closure! word dereferencing.


R2 has two context types: object! and system/words (an expandable 
object!). R3 also has two context types: it doesn't have R2-style 
object! contexts - all are expandable like system/words - but it 
does add the stack-indirect type.

I was going to thank God, but Doc will do.

Gregg.. aha, yes that was the option if there is no way..  Geomol 
.. thanks I wasn't avare of self.. but this probably doesn't enable 
me to see my name either because name of the object is name of the 
word is was asigned too .. so even if I do >> probe self << I dont 
have it ... looks like I really need to add it as a field

yes :) I thought of it too ... I will try to make something like 
a object factory function so I won't have to repeat myself  ... to 
not do
big-dog: make dog-agent [ name: "big-dog" .... ]  I will see

Yeah, you need to be escaping a lot more than just those characters 
to really do it right.  I can't help you with building the table 
of escapes, but this version should be a lot faster if you're escaping 
large quantities of text...

encode-html: func [

    "Make HTML tags into HTML viewable escapes (for posting code)"
    text
][
	parse/all text [
		any [
			h: #"&" (h: change/part h "&" 1) :h |
			h: #"<" (h: change/part h "&lt;" 1) :h |
			h: #">" (h: change/part h "&gt;" 1) :h |
			h: #""" (h: change/part h "&quot;" 1) :h |
			h: #"'" (h: change/part h "&apos;" 1) :h |
			h: #"€" (h: change/part h "&#8364;" 1) :h |
			skip
		]
    ]
	text
]

Peter: does not depend on me. The code is ready for release (actually, 
there is one thing i have to do first, but it should take a couple 
hours max), so it could happen "tomorrow" or in two months.

Hmmn, I am running a script, but not as CGI, on a remote 'nix box. 
 This script uses other scripts by 'do


The main script runs, but at the first use of parse rules from a 
do script, it fails.  Is there a magic setting of usage flags or 
file permissions to accomplish this?

$rebol -s main.r

runs main, but doesn't do the do %blah.r script from inside

It is weird, because from inside the REBOL console, a list-dir does 
not show the other scripts, like blah.r in the example above which 
main.r tries to do.

>list-dir ;after the file crashes...aha, I could see the files before 
doing the main.r.
main.r  main.r  


My scripts work fine on Windoze.  I am now thinking from this...I 
do a change-directory to get the directory of where I am running 
and I write my data into the current directory.  In Windoze, the 
change-directory seemed needed to pick up the directory I am in. 
 I'll bet 'nix doesn't like that, and perhaps needs the full pathnamem 
from the root, or soemthing like that.

I suppose you need to visit the registry to do that.

I write a batch script to do this .. ie. write the new file name 
as temp.exe or something.

Then do a call/quit to the update.cmd script.

You could try to convert one of your loops to a function and do something 
like this:

>> y: func [] [             
[    forever [                
[        i: i + 1                 
[        print i                  
[        if i > 3 [return [break]]
[        ]
[    ]
>> i: 0
== 0
>> forever [do y]                                               
1
2
3
4

The only thing that blocks numbers to become word! values is the 
lexical scanner. When you type anything in console (or DO a file 
script), your input is first a string! value that gets LOADed (that's 
where the lexical scanner raises errors). TO-WORD allows to bypass 
the LOAD phase and force the conversion of any symbol to word! value.

Maybe it would be a good idea, if constructors like TO-WORD etc. 
would do a lexical scanning of the result?

Geomol <funny or strange>

It gets odder ( or less consistent) as '+ does seem to be given special 
handing......

What I really wanted to do to solve the puzzle was:
    -- set to-word "2" 5
    -- set to-word "+" none
The block then becomes (in effect)
   do [5 none 5]
   == 5
      

But DOing the gimmicked block in R2 fell found of '+ being both a 
native and some hardwired syntax in the interpreter:

    set to-word "2" 5
    set to-word "+" none
    blk: copy []
    blk: reduce [to-word "2" to-word "+" to-word "2"]
    probe blk
        == [2 + 2]
    do blk
        ** Script Error: Invalid operator: +
        ** Near: 2 + 2

Wouldn't it be nice to do:

series: [1 2 3 4 5 6 7 8 9 10]

find series > 5

I know we can easily build a function to do this but it seems so 
well suited to the 'find function.

do any of you rebol gurus see a way to do something like coroutines 
/ yield / generators with rebol - so far a lot was possible to be 
done in rebol on a library level because it can change it's own code 
and because primitives aren't really primitives, but I don't see 
how this could be done ( there is magical do/next but it would block 
until loop exits so for something like this example it won't work). 
I am not sure I know the exact definition of coroutines so I will 
give an simple fictional example.. 

...
retvieve-time: func [ node /local msg ] [ 
	send-message node "get-time"
	while [ not msg: get-waiting-message ] [ yield ]
	print [ "the time is" msg ]
]

append *processes* :retrieve-time
retrieve-time *timer-node*

forever [ foreach p *processes* [ continue p ] ]


Yield returns controll from function, and next time continue is function 
continues at that point. I know the example isn't technically correct 
(for example when function exits it should be flagged and cleared 
from *processes* etc) , but just for illustration what I am asking

Henrik, maybe it's better to patch wake-event, then, which gets the 
events before they are sent to the window.
	probe get in system/view 'wake-event
Trap errors during DO EVENT like this:

	if error? set/any 'err try [
		do event
	][
		; stop more events and handle the error
	]

if error? program-error: try [
  view layout [
    h3 "Avoid the console from popping up"

    box 500x100 "Hold down left mouse button and drag to create errors" 
    feel [
      engage: func [face act evt] [
        if find [over away] probe act [
          2 / 0 ; error!
        ]
      ]
    ]
  ] do-events
] [
  ; what to do here to block the events from the view window?
  error-obj: disarm program-error
  inform layout [
    h3 "Program Error!"
    area 300x200 mold error-obj
    button "Close"
  ]
]

My first suggestion (just PICKing all events) doesn't work. I don't 
see another way to clear the event port, so I'm going to try patching 
wake-event, which is where you can prevent DO EVENT from sending 
the event to engage.

Aha, what you have to do is catch errors around both instances of 
DO EVENT in wake-event.

error-window: layout [
	h3 "Program Error!"
	area 300x200
	button "Close" [hide-popup]
]

inform-on-error: func [code [block!]][
	if error? set/any 'error try code [
    	error-obj: disarm error
    	?? error-obj
		error-window/pane/2/text: rejoin [
			mold disarm error 
			now/time/precise
		]
    	either viewed? error-window [
    		; subsequent errors
    		show error-window
		][
			; first error
			
			print "INFORM"		
			;inform error-window
			; Emulate INFORM but without WAIT
			error-window/text: "Dialog"
			error-window/feel: make system/view/window-feel []
			show-popup center-face error-window
		]
	]
]

system/view/wake-event: func [
	port 
	/local event no-btn error ; <-- added 'error
] bind [
    event: pick port 1
    if none? event [

        if debug [print "Event port awoke, but no event was present."]
        return false
    ]
    either pop-face [

        if in pop-face/feel 'pop-detect [event: pop-face/feel/pop-detect 
        pop-face event]
        inform-on-error [do event]
        found? all [
            pop-face <> pick pop-list length? pop-list
            (pop-face: pick pop-list length? pop-list true)
        ]
    ] [
    	inform-on-error [do event]
        empty? screen-face/pane
    ]
] system/view

view/title layout [
	h3 "Avoid the console from popping up"

 box 500x100 "Hold down left mouse button and drag to create errors" 
 feel [
		engage: func [face action event] [
			print ["ENGAGE:" event/time event/type mold event/face/text]
			if find [over away] action [
				2 / 0 ; error!
			]
		]
	]
] "Main Window"

That's a pretty good logic.

New windows can be brought to front (or if they are minimized, flashed 
in task bar) with:
	window/changes: [activate] show window
which you could do insistently on new errors.

But ok, you want to stop on the first error. Ok, so you're using 
a modal window.
In that case, I would change
	inform-on-error [do event]
to:
	filter-do event


where the FILTER-DO function is the same as INFORM-ON-ERROR except 
it examines the event first.

When event/face = error-window, then DO EVENT, else discard the event.

Ok, there is confusion between the layout spec block and the resulting 
window face.
A pattern I use very often:

infospec: [ area button ... ] 
infowin: layout infospec

either viewed? infowin [
	; bring the window to the front (or do the taskbar flash thing)
	infowin/changes: [restore activate]
	show infowin
][
	view/new infowin
]

Ok, so remote script looks like:
--------------------------
rebol []
info-win: layout [ ...]
--------------------------
Local script looks like:
--------------------------
rebol []
info-win: do remote-script-url
; Now info-win is a FACE object

; Only do the above line once, otherwise you will create a *new* 
face and set 'info-win to it, forgetting the old one !!

; The following code is done more than once:

either viewed? info-win [
	info-win/changes: [restore activate]
	show info-win
][
	view/new info-win
]

There is no "scope" in rebol. When you read from a url, you create 
a new string. That is, READ returns a new string.

When you set a word to that new string, you "switch" the word away 
from its old value (if it had one.) Eg:


 At the beginning of this example, the word  'info-resp  has no value 
 (It is unset!).
	Now, we set its value to the string returned by READ:

		info-resp: read url

	Now,  'info-resp  points to a string  "[ text ... ]"
	Let's do it again:

		info-resp: read url


 We have re-set  'info-resp  to a new string!  (even though old string 
 and new string look exactly same.)

 The old string may still exist as a value somewhere, but  'info-resp 
  does not know about it anymore.
	Normally this is not a problem.
--
	However, look at this example:
	
	1)	window: layout [box red]
	2)	view/new window
	3)	window: layout [box red]
	4)	unview/only window


 On line 1, LAYOUT creates a face object which we assign to the word 
  'window . (So  'window  points to a face.)
	On line 2, VIEW opens the value of  'window  as a window.

 On line 3, LAYOUT creates a *new* face object which we assign to 
 the word  'window.

  So  'window  points to a *new* face, and it has forgotten about the 
  old face.
		However, the old face is **still open as a window**.

  So we have lost our reference to the old window face, and it is now 
  more difficult for us to close it.
		So line 3 has created a problem.

 On line 4, we try to close the new window face, but we are unsuccessful 
 because the new window face is not open.

For those creating documentation involving a face hierarchy, here's 
a function which may help to visualise it:
do http://anton.wildit.net.au/rebol/doc/demo-to-3d-layout-image.r

So, if you export as pdf... you can then do a search and replace 
for the prepopulated text and then present this to acrobat?

Gabriele doesn't have any current plans to do so either.

But the end users won't be able to do this ...

So, the eps idea might be the better way to do it.

thought it could do that directly, but then:

save/png %a.png to image! layout/tight [image 300x300 i1]

How to properly invoke event after window opens.
Or the exact my problem is:

I need to display layout face for web browser plugin. And then after 
it is displayed update some one of subfaces and show them.

It is no problem to do so for new windows outside first one in web 
browser page if opening with /new, but I want to do it for main window 
in browser page.

In such cases it looks like /new does not help - nothing is executed 
after view/new main-win.