World: r3wp

The root of the problem appears to be that make port! creates a valid 
port object! with a non-existant path (but syntatically valid)  with 
an empty target (filename)  of %"".  Using query against such a post 
adds a state object to the port object. Exists? uses the existance 
of a state object in the port object to determine the existance of 
the file or not.

I should have written "status" object not "state" object above.

In R3, dir? returns true for a non-existant directory if the file! 
supplied ends with a /. This is the opposite from R2 but is it correct 
to do so?

non-existant -> non-existent

old persistent debate :)

A non-parse solution (for the replace problem) based on the existing 
replace mezz:

replace-each: make function! [
	target [series!] "Series that is being modified"
	values [block!] "Block of search/replace strings"
	/local len pos
][
	foreach [search replace] values [
		len: length? search
		while [pos: find target search] [
			target: change/part pos replace len 
		]
	]
]

Peter, R3's behavior with DIR? and EXISTS has already been reported 
and not fixed yet. Fixing R2 is unlikely, for compatibility.

Anyone still has REBOL 1.x binaries around?

I collected them from 0.7 alfa release or so, but lost my HD :-(

I used to have 1.0.3.3.1, though I'll have to check previous computers 
to find it.

Would be great if you had a look, if you ever stumble across those 
machines :) 1.0.3 would be great.

would be great + would be great = twice as good! :)

what are you collecting them for?

Typo in the code above:

	target: change -> change

A new idea for the Bindology article enhancement: for a given BLOCK 
and CONTEXT find out, whether the block is in the given context or 
not. Do you think, that such a function might be interesting?

Absolutely.

:-)

Blocks aren't bound to anything; their contents are. You could check 
whether the block contains any words bound to a context though.

words only

I'm sure that's what he meant.

The idea was a bit different: there is the¨

bind block context

operation, and it is meaningful to say, that "the block is bound 
to the context", if this operation is actually a no-op

It's not a noop, it's a composite operation. If the *block* was really 
bound to the context, rather than its contents (as applicable), then 
it would be a simple operation.

On the other hand, it is meaningful to say that the block has bindings 
to the context, or not.

if `bind block context` has no observable effect due to no single 
binding being changed, one can certainly consider that a noop

Yes, Andreas, thanks for the explanation, that is what I meant

Example: for any BLOCK and CONTEXT the

    bind block context


operation causes the BLOCK to be "in the context" in the above sense, 
i.e. any subsequent

    bind block context

operation becomes a no-op

Example: for any BLOCK and CONTEXT the

    bind block context


operation causes the BLOCK to be "in the context" in the above sense, 
i.e. any subsequent

    bind block context

operation becomes a no-op

Example: for any BLOCK and CONTEXT the

    bind block context


operation causes the BLOCK to be "in the context" in the above sense, 
i.e. any subsequent

    bind block context

operation becomes a no-op

Example: for any BLOCK and CONTEXT the

    bind block context


operation causes the BLOCK to be "in the context" in the above sense, 
i.e. any subsequent

    bind block context

operation becomes a no-op

Example: for any BLOCK and CONTEXT the

    bind block context


operation causes the BLOCK to be "in the context" in the above sense, 
i.e. any subsequent

    bind block context

operation becomes a no-op

Example: for any BLOCK and CONTEXT the

    bind block context


operation causes the BLOCK to be "in the context" in the above sense, 
i.e. any subsequent

    bind block context

operation becomes a no-op

sorry, this notebook is never doing what I think it is

(a small "mistouch" and it detects it as multiple clicks)

Ladislav is spamming us with REBOL bindology examples :)

Something about MOLD:

>> length? mold "^""
== 3
>> length? mold "^/"
== 4


Many other 'escaped' characters become 2 characters, when using MOLD. 
Is there a good reason for this?

I do not understand, which one looks strange to you: is it the representation 
of mold "^""?

geomol, it probably is because the double-quote does not need to 
be escaped internally.

>> length? probe mold "^""
{{"}}
== 3

>> length? probe mold "^/"
{"^^/"}
== 4

Different reason, I guess

when writing it as: {"} you may immediately see, it is just three 
chars, while "^/" is four characters

The 4 chars are the strange ones to me. I think, these two should 
be the same:

>> s: {"^/"}
>> t: mold "^/"

I would expect both to hold 3 chars. But they're different:

>> s
== {"
}
>> t
== {
^^/"}

no the first is a string with a new line the second is an "escaped" 
newline

which is why printing it doesn't cause a new line on the console.

remember that molding a string actually escapes special chars, so 
you can 'LOAD it back intact.

REBOL can LOAD a script from file, which holds real newlines, not 
escaped ones. So it's not possible to produce a string including 
newlines, when using MOLD?

>> as-binary s
== #{220A22}
>> as-binary t
== #{225E2F22}

Maybe what you want is:
>> form s
== {"
}
>> length? form s
== 3

Geomol, no, REBOL cannot load your S string...