World: r3wp
[Core] Discuss core issues
older newer | first last |
Steeve 31-Mar-2010 [16202] | or, >> do head insert p 'a |
Pekr 31-Mar-2010 [16203] | :-) ... amazing :-) |
Rebolek 31-Mar-2010 [16204] | (i'm sorry for such a newbie questions, but I'm ill and my brain refuses to work :-) |
Ladislav 31-Mar-2010 [16205x2] | ...does it for e.g. mean, that with earlier versions of R2, it was possible?... - no, it is possible in R3 |
jdishun (and other fans of named functions) - check http://www.rebol.org/view-script.r?script=named-func.r | |
ChristianE 1-Apr-2010 [16207] | That's nice, finally something to point to when that question comes up again. |
Andreas 1-Apr-2010 [16208x4] | ah, those named functions are brilliant |
maybe we should add special handling to bind so that each function is automatically passed a handle to refer to itself | |
we could call it ..... self! | |
/apr1 | |
Ladislav 2-Apr-2010 [16212] | :-D |
BrianH 2-Apr-2010 [16213] | :) |
Gregg 2-Apr-2010 [16214] | NAMED-FUNC is excellent though. A great REBOL example. Thanks for doing that Ladislav. |
Paul 2-Apr-2010 [16215] | Rebolek couldn't you have done this in your first example: >> a/b/c == 1 |
Steeve 2-Apr-2010 [16216] | No no no. It's again the rules. You have to find the weirdest way. |
Paul 2-Apr-2010 [16217] | Ahhh... |
Ashley 3-Apr-2010 [16218] | Is there is better way to code the following idiom: foreach [from to] [ "&" "&" "<" "<" ">" ">" "^/" "<br>" ][ replace/all string from to ] I'm using this much too frequently for my own liking ;) |
Maxim 3-Apr-2010 [16219x3] | there are faster algorythms, if you are managing very large files, but they require a bit more code and/or use of parse. |
still, replace is pretty fast... I don't know if the parse approach will be faster with only 4 items to replace. | |
then again, if your source string has many of the origin ("from") strings the parse could still be faster... I guess it largely depends on the size and shape of the data you are manipulating. | |
Rebolek 3-Apr-2010 [16222] | Steeve :)) Paul - no. The object is anonymous and I know only the b/c part. |
Gregg 3-Apr-2010 [16223] | Ashley, I've done parse-based REPLACE funcs, and a simple TRANSLATE func, but I haven't generalized and dialected them the way I want to either. This week is busy for me, but if you want to collaborate on something, let me know. I think it would have a lot of value. |
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 [16251] | 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. |
older newer | first last |