r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Chris
3-Apr-2010
[16224x2]
I use a variant of this:

sanitize: use [chars encode][
	chars: complement charset {&<>"}
	encode: func [txt chr][change/part txt chr 1]
	
	func [text [any-string!]][
		parse/all copy text [
			copy text any [
				text: some chars
				| #"&" (text: encode text "&amp;") :text
				| #"<" (text: encode text "&lt;") :text
				| #">" (text: encode text "&gt;") :text
				| #"^"" (text: encode text "&quot;") :text
			]
		]
		any [text ""]
	]
]

Provides a bit of scope for expansion...
Though it's admittedly bigger...
Gabriele
4-Apr-2010
[16226]
Well... I use this: http://www.rebol.it/power-mezz/mezz/text-encoding.html
:-)
PeterWood
4-Apr-2010
[16227x5]
exists? in R2 seems to ignore a traling slash on a file name. I have 
found that it returns true for a non-existant directory if there 
happens to be a file of the same name. Read does not giving the following 
results:

>> write %test "testfile"
>> if exists? %test/ [read %test/

]
** Access Error: Cannot open /Users/peter/WebSites/public_html/IT-Matters-Consulting/test/

** Near: read %test/

This seems like a bug to me. Should I add it to Rambo?
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
Steeve
4-Apr-2010
[16232]
old persistent debate :)
Ashley
4-Apr-2010
[16233]
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 
		]
	]
]
BrianH
4-Apr-2010
[16234]
Peter, R3's behavior with DIR? and EXISTS has already been reported 
and not fixed yet. Fixing R2 is unlikely, for compatibility.
Andreas
4-Apr-2010
[16235]
Anyone still has REBOL 1.x binaries around?
Pekr
4-Apr-2010
[16236]
I collected them from 0.7 alfa release or so, but lost my HD :-(
BrianH
4-Apr-2010
[16237]
I used to have 1.0.3.3.1, though I'll have to check previous computers 
to find it.
Andreas
4-Apr-2010
[16238x2]
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! :)
Graham
4-Apr-2010
[16240]
what are you collecting them for?
Ashley
5-Apr-2010
[16241]
Typo in the code above:

	target: change -> change
Ladislav
7-Apr-2010
[16242]
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?
Gregg
7-Apr-2010
[16243]
Absolutely.
Ladislav
7-Apr-2010
[16244]
:-)
BrianH
9-Apr-2010
[16245]
Blocks aren't bound to anything; their contents are. You could check 
whether the block contains any words bound to a context though.
Steeve
9-Apr-2010
[16246]
words only
BrianH
9-Apr-2010
[16247]
I'm sure that's what he meant.
Ladislav
9-Apr-2010
[16248x3]
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
BrianH
9-Apr-2010
[16251x2]
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.
Andreas
9-Apr-2010
[16253]
if `bind block context` has no observable effect due to no single 
binding being changed, one can certainly consider that a noop
Ladislav
10-Apr-2010
[16254x9]
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)
NickA
11-Apr-2010
[16263]
Ladislav is spamming us with REBOL bindology examples :)
Geomol
12-Apr-2010
[16264]
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?
Ladislav
12-Apr-2010
[16265]
I do not understand, which one looks strange to you: is it the representation 
of mold "^""?
Henrik
12-Apr-2010
[16266x3]
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
Ladislav
12-Apr-2010
[16269]
when writing it as: {"} you may immediately see, it is just three 
chars, while "^/" is four characters
Geomol
13-Apr-2010
[16270]
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
== {
^^/"}
Maxim
13-Apr-2010
[16271x3]
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.