World: r3wp

needs quotes around the windows path

]
>> to-rebol-file "\\bens2000as\c$\myTestdir"
== %/bens2000as/c$/myTestdir

note the single leading "/"

Excellent point Graham.

that worked!  thank you folks!!

to-rebol-file has been the answer before, I really need to remember 
that one. :-)

Nice little function for you math guys:


max-summands: func [n /local i][i: 0 until [i: i + 1 n: n - i n < 
i] i]

Small but significant fix:


max-summands: func [n /local i][i: 0 until [i: i + 1 n: n - i n <= 
i] i]

This function will return a number that corresponds to the maximum 
summands that can result in the sum of the number without repeating. 
 For example:

1 + 2 + 3 = 6


therefore it would have a value of 3 since their is 3 numbers added 
together.

1 + 2 + 3 + 4 = 10

just be mindfull about the unc paths... any local root dir which 
has the same name as a machine will take precedence...  I have been 
bitten by this on linux. 


I really wish rebol left the double \\ as double // on the root or 
if it had a real machine name separator.  which translated to whatever 
local path it equates to (UNC most probably).

Anyone have an idea of what might be causing this problem?

make object! [
   code: 331
   type: 'script
   id: 'call-fail
   arg1: "The system cannot find the path specified.^M^/"
   arg2: none
   arg3: none
   near: [browse/only join http://127.0.0.1:8002/ url]
   where: 'browse-local
]

Cheyenne is listening on port 8002 and gives a 404 if a browser is 
used.

call-fail means what??  That rebol can't find the browser?

I don't have access to this person's PC so I can't test it :(

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.