World: r3wp

looks like rebol doesn't accept the caret with a url

must be encoded

>> http://foo^bar
== http://foo^bar
>> to-string http://foo^bar
== "http://foo^^bar"
>> load to-string http://foo^bar
== http://foo^bar

I think it's 'net-utils/url-parser/parse-url that breaks it.

(this is used by the builtin schemes)

yes, made a string and then to-url. this helps if the caret is hex-encoded 
 %E5

will check for lower level open port...

chris, is your previous replace/all snippet working ?

ok, the parse needs "^^" "%E5"

thx, chris and steeve

Is there any string that  'to-time will return an error?

Seems that it never returns an error.

But it should in this kind of input string : 
>> to-time "1:111:11"
== 2:51:11

R3 alphas will fail bad strings:
>> to-time ""
** Script error: content too short (or just whitespace)

>> to-time "x"
** Script error: cannot MAKE/TO time! from: "x"

>> to-time "12:12"
== 12:12

But Dockimbel's issue is unchanged in R3

So, a typo in a user input string could result in returning a wrong 
time! value without throwing an error. Looks like a bug or at least, 
a flaw IMO.

REBOL has always had a policy of "normalising" times with >59  minutes. 
Even without the to-time and string:
>> 1:111:11
== 2:51:11

Ditto with seconds:
>> 1:0:5000
== 2:23:20

That looks dangerous to me, some typo can't be detected.

Agreed!

interestingly, R3 returns:

>> 1:0.5000
== 0:01:00.5

but the other example is the same

I think you may have a typo........My example was 1:0:5000 (two colons). 
I see identical behavior in R2 and R3

you are right, sorry.

Where did the action PATH come from? Write in the console:
? path
I can't see it documented anywhere.

I guess it should not be visible if it's not documented... some internal 
function probably.

Ask on R3 chat so Carl can see it.

>> blk: [a b c d e]
== [a b c d e]
>> foo: [bar 5]
== [bar 5]
>> path blk foo/bar
>> blk
== [a b c d]
>> foo/bar: 1
== 1
>> path blk foo/bar
>> blk             
== []
>> foo
== [bar 1]

Returns an unset!, clears the block from given index...

So, beside the unset! returned, PATH is like CLEAR AT ?

Anyone using ALSO?

everywhere

Can you give examples?

The primary example use was in functions, to return the contents 
of a variable and also free the variable. eg, this:

	add-one: func [value][1 +  also value value: none]

replaces older code such as this:

	add-one: func [value][1 + first reduce [value value: none]]

Is that a good example? Why would you set value to none, if it's 
a number? It doesn't matter.

use cases: 
1/ swaping a with b
a: also b a: b
2/ in a function, returning a value after cleaning local vars
func [x /local tmp][
	tmp: a * 2
	also tmp tmp: none
]

error with swaping
a: also b b: a

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

When I think about it, much of this is based on assumption how memory 
is handled in REBOL. We don't really know, because it's not documented. 
When is it good to free a local, and when not? There may be something 
wrong, if this should be handled by the programmer (also when it's 
not documented).

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

Ok, your last func should have the /local result, right?

shouldn't have, right

Then it kinda makes sense. But then I think about all the internal 
sub-results, REBOL have to handle, and which I guess is freed by 
garbage collection. Is the problem, that REBOL keep locals, also 
when the funciton is finished?

In R3 it's not only to avoid the use of temporary vars, it's also 
faster (ALSO is native)

If I have a simple local in a language like C, I wouldn't allocate 
and free it every time, I call my function.

A local in C is just a value stored in some memory. I guess, it's 
the same in REBOL? Again we don't really know.

REBOL must have a look-up table for the known words in the context, 
but after that it should just end up at a memory address.

If you free the local every time, REBOL have to allocate that memory 
every time.

anyway ALSO is faster than using vars

ok