World: r3wp
[Core] Discuss core issues
older newer | first last |
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 "&") :text | #"<" (text: encode text "<") :text | #">" (text: encode text ">") :text | #"^"" (text: encode text """) :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. | |
older newer | first last |