World: r3wp

The type of the start and end variables must be the same. If you 
look at the source of for, you will see that it throws that error 
when they are not.

Yes, but 2.0 can be converted to 2, so no problem.

I would like to have read-thru in Rebol?Core as well

so at least such a simple function:

read-thru-to: func[url target /local data loc-path][
	either exists? target [read/binary target][
		loc-path: first split-path target
		if not exists? loc-path [make-dir/deep loc-path]
		write/binary target data: read/binary url
	]
	data
]

Oldes - on true for exists? shouldn't it be "data: read/binary target" 
since you return :data?

Robert, although 1 and 1.0 are both numbers, they are not the same 
type in REBOL. Sure, they can be converted, but unless you do so 
they aren't. It would be simpler to just rewrite your example to 
this:

>> a: 2.0
== 2.0
>> for test 1.0 a 1 [print test]
1.0
2.0


and not have the type mismatch I was talking about. Unfortunately 
REBOL doesn't have type signiatures that are powerful enough to specify 
that these two parameters need to be the same type, so that constraint 
has to be enforced in the code.

Oldes, a builtin read-thru would require Core to be installed rather 
than just copied somewhere, just like it does with View - view-root 
is set during installation. Still, all of the *-thru functions are 
written in REBOL, so they can be copied and adapted to your purposes 
quite easily.

a view-root: what-dir works quite well.

See, I told you they could be adapted easily :-)

:)

Personally, I always thought view-root should be under system/options 
somewhere.

Robert, what are the actual numbers you need FOR for ?

BrianH, like system/options/home ?

Yeah, something like that. Maybe system/user/sandbox or something. 
For that matter, system/user/home should be set to something useful 
on Windows, like %userprofile% or better yet %appdata%.

Oldes, Volker, I put into my rebol/core  user.r  file:
	view-root: dirize clean-path system/options/home/../view
	user-prefs: context [debug: none] ; fake user-prefs
	vbug: func [msg [block! any-string!] /local dbg][
	    if not dbg: user-prefs/debug [exit]
	    msg: head insert remold msg "view "
	    either file? dbg [write/append dbg msg] [print msg]
	]

along with the source to these functions:
	path-thru
	exists-thru?
	read-thru
	load-thru
	read-net

For that matter Volker, you could set view-root to the standard sandbox 
directory like this:
view-root: join to-rebol-file get-env "APPDATA" "REBOL"

Yes, but then i get security-questions.

And i dont like to rely on user.r . personal preference.

Yeah, those security questions.

As for relying on user.r, I prefer rebol.r for things like this.

On the plugin-side it can never be secure enough ;)

Hmm... should check that out.

and having a %public/alongside my /core-script work quite well for 
me.

Sure, why not (don't answer that).

I try to stay out of user.r because rebol installer has its way with 
it. I suspect rebol.r is also in the same category. You could lose 
your changes. Therefore I prefer to redirect to another script where 
all this action occurs.

i like to poitn peoples to install rebol and run a little launch-script 
i send them.

No, rebol.r used to contain the feedback function and so was included 
in the Core package. It is not written automatically. You can keep 
control of it if you want.

and have that run without problems.

It was supposed to be that global settings were contained in rebol.r 
and user-specific or local settings in user.r, but it never worked 
that way with Core because REBOL only looked for the location of 
those files once for both, rather than once for each, so you couldn't 
put user.r in a user-specific place and keep rebol.r is a global 
place. VIew does it right with version 1.3 though.

set-net [ "[carl-:-rebol-:-com]" smtp.rebol.com ]

should return an error ... but it doesn't.

as this happens

** User Error: ESMTP: Invalid command
** Near: insert smtp-port reduce [from reduce [addr] message]

Anton, why do the actual numbers for FOR matter? The thing is, those 
numbers are of type decimal! as my app has to use decimal! values 
for calculation.

Has someone a nice function to extract tuples by level? For example:
	1.0.0
	1.1.0
	1.2.0
	2.0.0
	2.1.0


I just need all 1st level tuples, than only the second level tuples 
etc.

tup: 1.2.3
i: 2
probe tup/:i
; ?

I need the function to return only 1.0.0, 2.0.0 or 1.1.0, 1.2.0, 
2.1.0

All tuples that have a specific level set.

I'm just playing around with a multiplier pattern like zero? (1.0.0 
* 0.1.1). This works expect for the 3rd level.

Robert, I was just wondering what actually triggered your initial 
question.

I thought perhaps we could refactor your original code to use WHILE 
or REPEAT etc..

I'm not arguing with your main point, which seems to be that the 
current behaviour of FOR is uncomfortable in this respect. (Or is 
it deficient ?)

Robert, how about this ?

tuples-of-level: func [level tuples /local compare][
	result: copy tuples
	remove-each tuple result [
		repeat n length? tuple [
			compare: get pick [<> =] n > level
			if compare 0 tuple/:n [break/return yes]
		]
	]
]

; test
blk: [1.0.0 1.1.0 1.2.0 2.0.0 2.1.0]

tuples-of-level 1 blk  ;== [1.0.0 2.0.0]
tuples-of-level 2 blk  ;== [1.1.0 1.2.0 2.1.0]
tuples-of-level 3 blk  ;== []
tuples-of-level 0 blk  ;== []

This version should scale better.

tuples-of-level: func [level tuples /local compare][
	result: copy []
	foreach tuple tuples [
		if repeat n length? tuple [
			compare: get pick [<> =] n > level
			if compare 0 tuple/:n [break/return no]
			yes
		][append result tuple]
	]
	result
]

Cool... I had this idea with the comparators too but not to use pick 
and the level as the selector. Cool stuff!

:)

Has anybody noticed problems with files that have "%" in name?