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

World: r3wp

[Core] Discuss core issues

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] [
		"&" "&"
		"<" "&lt;"
		">" "&gt;"
		"^/" "<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 "&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
[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.