AltME groups: search

(i'm sorry for such a newbie questions, but I'm ill and my brain 
refuses to work :-)

maybe we should add special handling to bind so that each function 
is automatically passed a handle to refer to itself

NAMED-FUNC is excellent though. A great REBOL example. Thanks for 
doing that Ladislav.

Rebolek couldn't you have done this in your first example:
>> a/b/c
== 1

there are faster algorythms, if you are managing very large files, 
but they require a bit more code and/or use of parse.

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.

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...

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.

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?

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 
		]
	]
]

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

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?

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

The idea was a bit different: there is the¨

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.

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

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

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

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?

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?

FORM - Converts a value to a string.
MOLD - Converts a value to a REBOL-readable string.

Gabriele, interesting. My understanding of LOAD changed a bit. Loading 
a script... hm

Nah, my understanding of load didn't change. I can't have a string 
with double quotes across lines. But I still can't see, why my t 
get the extra hat (^).

, i.e. how would you write a string containing exactly the characters 
listed on the line below

    "^/"

Well, as I understand MOLD, it will create a string, we can LOAD 
in again. If the original holds a newline outside any string, it 
should just be kept as a newline, shouldn't it? REBOL can LOAD newlines, 
which are seen as white space (like the space character). Maybe tab 
is better to illustrate, what I mean:

>> mold {^-}
== {"^^-"}


I get a result string holding 4 characters, while 3 is good enough. 
When I LOAD this result, the two characters #"^^" and #"-" get changed 
into one tab. Why? And why does MOLD produce 4 characters in the 
first place?

when debugging these things you should always use probe... its more 
consistent, since it always shows the "escaped" value of a string!

 If the original holds a newline outside any string, it should just 
 be kept as a newline, shouldn't it? 
 - no!

Should LOADing a string be the same, as if I entered the content 
of the string at the prompt? I would expect that. If I write:

>> "^^-"

I entered a string consisting of 2 chars. So loding this:

>> load {"^^-"}

should be the same, 2 characters, but it isn't.

As said, if the original contains a newline, then it can be written 
as

    original: "^/"


, and the MOLD ORIGINAL expression should just yield a string containing 
the above four characters following the space after the colon

Or maybe there isn't a problem, and it's just me. :)

Certainly, that is another possibility, and if you state it that 
way, then, of course, there is a possibility to use that form, it 
is just not the one chosen in the MOLD implementation in this case.

So when you mold "^/", the resulting string has a round of escaping 
added, and then *that* string is molded again for the console, with 
another round of escaping added for display. This means two ^ characters 
are apparently added, though one is taken away earlier when the initial 
command is loaded:
>> mold "^/"
== {"^^/"}

It doesn't. It loads once (at the command line), then *you* load 
a second time explicitly.

And if this is in a script, and not at the prompt?

Then when the script is loaded it will be loaded. And there is no 
difference in R3: Every command entered into the prompt is a separate 
script.

Keep in mind that you are already loading a script: {load {"^^-"}}. 
And then executing that script, which loads another script: "^-".

All you have to remember is that every round of loading does another 
round of resolving escapes, and every round of molding does another 
round of adding escapes. And that there is one round of loading when 
you DO a script or do a command line, and one round of molding when 
the command line prints its results.

FSUTIL is your friend. I have a REBOL wrapper if you want.

fsutil fsinfo volumeinfo c:\

From a quick glance your masking logic is wrong. You need to mask 
both the address and the network and then compare if the results 
match.

I have a correct function for R3 lying around somewhere ... if only 
I could find it :)

Just a reminder :)

wow, what a bunch of reactions :-) BrianH - I used strings, because 
of original Mikrotik format. They use 10.10.10.10/24 format for IP, 
so it was easier for me to carry around in a string form, then parse 
it later when needed ....


IP arithmetics, and ranges would be 2 nice new datatypes for REBOL 
imo :-)

also because MIN and MAX don't compare on words, so there must be 
a different base of comparison.

And it's not just the first element:
>> min [b b] [b a]
== [b a]

& and | are easy to add. The gain is to have apply & modify operation. 
Maybe there is no gain ... Simply instead of a = a + 10, you can 
write in python a += 10 in Python.

I really hope we go through the CureCode tickets soon and collect 
all of the ones that make minor changes to core semantics, so we 
can do a rip-the-bandaid-off fix-them-all release soon. Before too 
much code is written that might depend on the unfixed behavior.

These make sense in C or Python syntax, or other languages where 
assignment is a syntax thing, but I'm not sure that it works that 
well with a language with word values, and assignment that doesn't 
use =. I don't see how they'd fit in REBOL syntax. That is not to 
say that the functions that these operators represent wouldn't be 
useful to have - just that they would fit in better in prefix form. 
Just an opinion though.

As long as the first argument is a series ...

is there a function which looks like find but return true here:

Type desktop to start the Viewtop.
>> a: ["111" "222" "111"]
== ["111" "222" "111"]
>> b: a/3
== "111"
>> same? find a b b
== false

it would also be a hell of a lot faster  :-D

or index? being extended, to return you a pointer to the originating 
series? But such information might not be available to interpreter 
after the assignment?

(but I wrote a corresponding function to the Identity articticle)

its a shame cause looping a large list manually and comparing with 
same?  is VERY slow  :-(

on a 10 million sized series. 


my fastest FIND-SAME loop is 20 time slower than FIND, which would 
be much faster, since all it would have to do is compare a pointer.

can't you wrap the items of the list inside objects ?
In that case, it will be a find/same

steeve no... its a database like flast list of labels with corresponding 
data items.

note the multi-column list will use the same data interface


IMHO it gets even less fun if you are using DB queries to populate 
the list.


it also generates a lot of useless & SLOW binding everytime you change 
the list

How about combining find with a loop
find-same: func [
	series [block!]
	item [series! ]
	/local s 
][
	while [s: find series item] [
		if same? first s item [return  true]
		series: next s
	]
	false
]

that's a hell of good a idea  :-)

the same goes for /first (find first occurance in a block of multiple 
targets ... a long planned feature)

you mean as in deep searching a tree of blocks ?

should be a little bit faster

while [serie: find/tail serie item][
	all [same? serie/-1 item return  true]
]

Optimization is a never ending story

because of liquid's lazyness, very few things are actually optimised 
(really need to)... but right now I have a problem on initialization 
where there is so much linkeage being done, it does create a nagging 
pause on startup.


I already know a few things that will greatly optimise liquid itself, 
and will implement speed minded plugs specifically for GLASS, but 
your input will be invaluable.


you've spent sooo much time on this specific aspect of REBOL coding 
that it will come naturally to you.

Well, It will a pleasure :)
Optimizing scripts is my hoby

in the last 6 months, I've allready optimized liquid's kernel by 
a factor of at least 50 times I think I can speed it up at least 
10x more.  on specific points, I can probably improve it even more. 
 that will probably come at increased memory use for some plugs though.

for example, I am thinking of building a !node and !container base 
plugs which cannot mutate into different processing mechanisms.... 
will all the removed overhead, that will make a BIG difference.  


it will require a bit more experience in handling liquid... but within 
controled environments like glass and glob, this can be a non-issue.

yes.  it would be exceedingly easy, since you have state information 
about things being clean or not, and liquid is 100% class based OOP 
(as opposed to prototype) so once a node has been defined, it can 
be freely JIT, since every reference to the instance is referenced, 
not bound.

I wouldn't say We MUST add /SAME to FIND, though it could be useful 
in special cases. Another posssibility, though I want to think about 
it more before standing behind it, would be to allow AT to take an 
index value that is a reference. Hmmm, no, maybe not. It would then 
have to return NONE if the item wasn't in the block. Nevermind.

How can I check that a given value conforms to a typeset? E.g.,  
If I say "make typeset! [string! integer!]" how can I check that 
the number 17 conforms to that typeset?

I've written a recursive function to do it, but I wondered if there 
weren't some better way.

On MIN/MAX with pairs, sorry I wasn't clear. I do NOT think it's 
a bug. I use that behavior myself, and seem to recall it being discussed 
long ago. It may not be what you expect initially, but I think it's 
the right design choice.

how does one probe a map! ?

>> probe a
make map! [
    r 4
]
== make map! [
    r 4
]

>> foreach [key value] a [print key]
r
>> a/e: 5
== 5

>> foreach [key value] a [print key]
r
e

>>foreach key a [print key]
works too.

how about this.. adding a variable as key in a map ie:
n: make map![]
b: 4398

n/b: "42" ; where b is 4398?

hmm... need a delimeter in the key.. 
n/8497:9823 ;err invalid time
n/9384-5842; err invalid date

>> a: 1234
== 1234
>> b: 345
== 345

>> key: b or shift a 32
== 5299989643609

or you can make a string with the 2 parts and the delimiter as a 
key, but it will cost more memory

it's a function of R3

no matter.. can't search by value in Redis either.. i have a work 
around

or create a second map! with reversed key-values

DP: :DELTA-PROFILE, meaning change in profile. It's R3's built-in 
profiler. R3 also has a built-in timer, DT: :DELTA-TIME.

How does one sort on the 3 item in a seres?

You mean using /skip and /compare to sort a series in sets?
s: [1 2 8 a   1 2 6 b   1 2 7 c]    ;; three sets of four items
sort/skip/compare s 4 [3]        ;; sort on the third item
== [1 2 6 b 1 2 7 c 1 2 8 a]

Didn't know you could put the /compare index in a block. Can you 
specify more than one index?

Yes you can:
sort/skip/compare s 4 [1 2 4 3]
== [1 2 8 a 1 2 6 b 1 2 7 c]

Graham, no, noone can update that doc page, it's a permissions issue. 
All docs updates by anyone other than Carl are on hold.

OK, good, that way you will remember to submit a CureCode ticket 
later.

>> a: 0.24.26
== 0.24.26
>> poke a 2 155
== 0.155.26
>> a
== 0.24.26 ; huh?

>> a: b: 0.24.26
== 0.24.26

>> poke a 2 155

** Script error: poke does not allow tuple! for its value argument