World: r3wp

My guess is the same as yours on the error Graham, though I've never 
seen it myself.

>> help system/error/script/call-fail

SYSTEM/ERROR/SCRIPT/CALL-FAIL is a block of value: ["External process 
failed:" :arg1]

I've asked the user to install Firefox and make it the default browser 
to see if that helps.

So, if the user has an empty value in the registry for the default 
browser, I guess that would cause this ...and :arg1 would be the 
browser .exe

I agree with your interpretation, the registry value is probably 
either empty or corrupted.

kib2: "Does that mean that we can use unicode encoding with the help 
of r2-forward ?"

No, I only can only spoof datatypes that don't exist in R2, and R2 
has a string! type. The code should be equivalent if the characters 
in the string are limited to the first 256 codepoints of Unicode 
(aka Latin-1), though only the first 128 codepoints (aka ASCII) can 
be converted from binary! to string and have the binary data be the 
same as minimized UTF-8.

There are ASCII? and LATIN1? functions that test, char!, string!, 
binary! and integer! in exactly the same way as the R3 natives, and 
a UTF? function that tests the BOM. When ENCODE and DECODE are written 
in R3, I'll backport them too if I can, though they probably won't 
generate string! values.

See the notes for what can and can't be supported. The unsupported 
list may grow or shrink with changes to R3 or more information.

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

It is probably better to load R2-Forward as a module (compatible 
with Gabriele's %module.r) - then it will just export, not set global 
words. Scripts written with R2-Forward are more likely to be compatible 
with R3 than they are with R2, so assume some porting will be necessary 
for existing R2 code. It makes a good porting tool though, since 
very little will need to be done to your app to make it R3-compatible 
if it runs with R2-Forward.

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?

Anyone else manipulate headers for more than a trivial degree of 
metadata?

I have done so in the past, specially for data files.

my own rule was, if its something you can edit and don't want to 
have to "look" for in the code, its ok.

its also (I find) a clean way of presenting end-user options to a 
script which shouldn't really be edited by the user.

So, like -- edit settings in the header, but don't touch the code?

(for your last example)

that's my way of seeing it

IMHO it should allow the user to "inject" code, unless its first 
parsed via a dialect.

oops  ...  should *NOT*

Eg:

	REBOL [
		factor: 1.5
	]

	multiply: func [val][val * header/factor]

yep... or default argument switches...

REBOL [
	verbose-lbl: ['error 'warning]
	confirm-deletes: true
]

....

But not:

	REBOL [
		modifier: [val ** 2]
	]

	multiplier: func [val] :header/modifier

That, I suppose, would depend on your target user?

exactly.  this is dangerous.  cause someone might do:

REBOL [
	modifier: [val + 2]
]
and then your whole script crumbles.

for such a simple effect its trivial, but if you start using the 
header for code, it might become a habit and then you'll open a door 
you didn't realise.

can be as simple as a binding error, which uses a global value instead 
of a local one, and bam, instant very hard to tackle bug.

Although, it's an expression, but it could still be considered a 
setting.  Expecially if you trust the competence of the user...

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.

rebol's binding and mutable series has a tendency to whip you in 
the face sometimes.  and a overly competer user might "assume" more 
than he should and create a bug he can't really understand.

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.

self-imposed order  ;-)

its also much easier to parse the header when there are only values, 
for any header management scripts.

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...

I can see it being used properly for well documented call-backs.

lightly, or inappropriately.

Yes, that's kind of what I was driving at with Sample C...

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.

It aids one type of file maintenance - a folder full of parse rules...

But, yes, binding has to be apparent and understood in order not 
to screw up.

like a rejoin spec which builds the TD of table:

REBOL [

 news-spec: [foreach item news-list [append output rejoin [<TR> <TD> 
  <P class="news-title"> item/date ": " item/title </P> </TD> </TR>] 
 ]]
]

remarks v2 binds parse rules to html and functionally rebuilds a 
page, much like what you describe.

the rules are linked dynamically, so can come from anywhere.

The type and exports header fields are used by R3 modules, in much 
the same way as your's Chris. Same with Gabriele's modules. In general, 
it is best to not put executable code in a header unless it is executed 
by the script itself. Don't assume that any word values assigned 
to fields in the header will be bound at all in R3, let alone bound 
to the same context as your script. Dialect code should be OK to 
assign to header fields, as long as it is not executable code.

I don't put config data in headers, just metadata.

How to easily wait for a keypress in console? I used following code 
in a loop, but it wait only once:

press: open console://
wait press
close press

ah, we have 'ask function :-)

Pekr, if you need single keystrokes:

http://www.rebol.net/cookbook/recipes/0060.html

thanks! I just run some data printing in a loop, and I want to stop 
at each iteration, and press enter to get another row ... 'ask served 
very well for me ...

I am once again amazed with REBOL - I feel like king when working 
with csv. My parse/all item ";" is common idiom :-)