World: r3wp

a path! is a kind of block!. so i guess BUILD is just recursing into 
paths. it's a bug but... it seems a cool feature to me instead. you 
can build paths ;)

probably should be included in docs :-)

No, I'd say it's a bug, due to inconsistent behaviour:

>> build [append/only [] []]
== [append/unset [] []]

vs.

>> build [append/anything-other-than-only [] []]
== [append/anything-other-than-only [] []]

It's just the /only refinement producing the unexpected result.

How are the functions named to access the Windows Registry?

I need to read out a possible proxy config.

http://www.rebol.com/docs/sdk/registry.html

The reg funcs get unset in *some* versions of REBOL,so make sure 
they're available in the one you use.

Hm... in my version these functions are unset. I use REBFACE to start 
a script.

And it shows that the "Windows Registry Access" stuff is loaded. 
I use 2.7.5

Any idea what to do?

1) Go back to an older version.
2) Look at calling the registry APIs directly
3) Tell Carl we need them back. :-)

The Roxy setup toolkit uses them, so I'm still encapping installers 
with some really old version of REBOL.

hmm, I can't find them even in 1.2.8, nor 1.2.1

Hmm... ok. I drop him a note and see what happens. Otherwise I have 
to use registry.r from rebol.org

dunno why those were removed? I do understand it for plug-in, but 
normal View?

I think security was the issue, but they should still be available 
in the SDK in any case.

I think I use 1.2.48 to use them.

Yup, that's the one.

there are some funcs in the sdk, but for install kind of purpose, 
association etc., but those all are just wrappers around natives, 
which are unset. So - how can we have their sources, if reg* functions 
are natives? :-)

Christian, that's because "only" is a keyword for build. [append/only 
[] []] is for build the same as [[append only] [] []]. I agree it's 
a bug, however I'd be tempted to leave it as-is ;)

Ah, ok, you wouldn't know from HELP BUILD but it's in the script's 
comment. So it's kind of an "intended bug", I see that now ;-)

it is not bug, totally intended. If you are afraid of INS and ONLY 
keywords, you have to use the /WITH refinement

maybe I should use a less usual word instead of 'only ? 'ins seems 
to be less conflicting, since nobody uses it for "normal" purposes

anyway, when you use the /with refinement, you are totally safe, 
since it is you who specifies the keywords

regarding the path processing - I did that intentionally - the processed 
"parts" are: block! | paren! | path! | set-path! | lit-path! as you 
can see from the source

is there a request to leave something out?

(or change a default keyword?)

I'm not afraid of ONLY, nor was it me spending/loosing time understanding 
what's going on there. I'm just suggesting to put some info regarding 
INS and SOME into the help string if it's intended behaviour; so 
no offense intended.

yes, that is a good suggestion, putting it in

>> series? []
== true
>> trim [] 
** Script Error: Cannot use trim on block! value
** Near: trim []
>> ? trim
USAGE:
    TRIM series /head /tail /auto /lines /all /with str 
...

Is this not kind of inconsistent?

check http://www.fm.tul.cz/~ladislav/rebol/build.rplease to see 
whether the doc strings are better now

>> help trim
USAGE:
    TRIM series /head /tail /auto /lines /all /with str

DESCRIPTION:

     Removes whitespace from a string. Default removes from head and tail.
     TRIM is an action value.

so the only "inconsistency" is the argument name, as I see it

don't you get a list of arguments with accepted datatypes?

ARGUMENTS:
     series -- (Type: series port)

ah, sorry, it does not check whether the argument is an ANY-STRING! 
or a PORT! , but instead it allows SERIES!

I've brought this up before as well, but it looks like it will be 
there for R3, according to the recent blog on it.

I noticed this:
>> to-url [http b c]
== http://b/c
>> to-url [http b 125]
** Script Error: Invalid argument: 125
** Where: to-url
** Near: to url! :value


Couldn't it be useful to have 125 accepted as a port number since 
it's the first integer in the block?

why isn't 125 valid anyways?  

 http://b/125

 is a valid url AFAIK  no?

yes it is. I half-expect Gabriele or Ladislav to come back with an 
answer like "no, because if we allowed that, the Internet would explode" 
or something :-)

Yes it is - completely valid as a URL.

I came up with my own:

>> to-url [http a 125]
== http://a:125

or

== http://a/125


so probably not a good idea to autmatically assume it's a port number.

(hopefully) quick question - I know you can use prin "^(page)" (or 
prin "^L") to clear the current terminal window - is there something 
just as simple to clear just the current line?  Or move the cursor 
back to the beginning of the line?

prin cr

Sunanda;  You should have mentioned loading the Terminal User Interface 
and all the funky VT100 escape sequences and the...
Just kidding :)

I' not that evil .... not yet, anyway :-)

Henrik: actually, I guess you're the first to discover that :)

it's funny that it doesn't form integers though. maybe there's some 
reason for it.

gabriele, it doesn't eat tuples either (IP addresses)