World: r3wp

lop? would be a function

well, you wouldn't know without running actual tests with the operator.

yeah you can

just like I do in the function above that I wrote.

please explain, because I can't see where you do that. :-)

I'm just checking the charset

all the ones that return logic are those operators that are or have 
in their form the characters "<" ">" or "="

lop?: func ['op][if find form op charset "<>=" [return true] false]

>> lop? +
== false
>> lop? <
== true

I see.

seems handy to me.

could be modified to become a true mezz

;a bit revised:

lop?: func ['op][if all [op? get op find form op charset "<>="] [return 
true] false]

You can sort of trick your way around things with ops in most cases. 
e.g.

	>> fn: func ['op a b] [op: get op  op a b]
	>> fn < 1 2
	== true


But I avoid doing that. It ends up not being worth it, IMO, when 
you start to reuse things, generate code, etc. Just use func alternatives.

heh but cool Gregg.

; Here's a thought:

	any-where: func [series [block!] test [block!]][
		foreach value series compose [if (test) [break/return value]]
	]

	probe any-where [1 2 3 4][value > 4]
	probe any-where [1 2 3 4][value >= 4]
	probe any-where [1 2 3 4][value < 4]


; I know it's a two block solution, but it's pretty language friendly. 
 You can recycle tests too:

	test: [value > 4]
	probe [1 2 3 4] :test
	probe [5 6 7 8] :test

Oops, forgot the function at the end there...

Very nice Chris!

It's kind of like an "apply-any".

simple problem:

>> a: [1 2 3 4 5]
== [1 2 3 4 5]
>> b: at a 3
== [3 4 5]
>> a
== [1 2 3 4 5]
>> b
== [3 4 5]
>> remove a
== [2 3 4 5]
>> b

== [4 5] ; I wonder if it's possible to make the index "sticky" at 
[3 4 5] in a relatively simple way. If it were, that would be very 
cool.

copy it first!  :)

nope, it has to be the same series

and if you copy the index? as well?

it must be the same series

Unless this is a feature request, you'll need an alternative to remove...

half a feature request and half trying to find a quick way to solve 
it. seems there is not an easy way.

can you just get around the problem by setting a: next a   ?

yes. that's janitoring of the index, which could be prone to bugs, 
etc.

yeah you'll definately have to be more judicial with your code but 
I'm thinking that the mechanics of it is the way it is intended to 
operate.

yes, it is. it would be too hard to track from inside rebol when 
an index should move.

(but if it were possible, some code would be greatly simplified)

>> a: make list! [1 2 3 4 5]
== make list! [1 2 3 4 5]
>> b: at a 3
== make list! [3 4 5]
>> a
== make list! [1 2 3 4 5]
>> b
== make list! [3 4 5]
>> remove a
== make list! [2 3 4 5]
>> b
== make list! [3 4 5]

Let's talk memory...

I that in the following the 10 represents 10 "bytes"?  a: make string! 
10

So how to we define those things in a block?

I know we can initilize the block with for example:

a: make block! 10 

But how do we determine what is in the block comprises a byte?

I know that in a string each character represents a byte but even 
then how much overhead is allocated merely by a: make string! 0?

These are the kinda things I wish Carl would go over so we can best 
optimize our use of memory.

interesting, dockimbel. thanks.

There is a lot of information about Rebol's memory usage in the mailing 
list archive. You culd start here: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-topic-index.r?i=memory

I have reassociated my scripts in windows with the new 2.7.6 core 
but I now get an error whenever I attempt to open them which is:

** Access Error: Cannot open /C/Documents
** Near: do/args script system/script/args

Any ideas?

It appears to see a broken path and sees the rest of the path as 
an argument.  Not sure where it is checking yet to get this information.

Fixed it.

I went into the registry and found the reference to rebview and deleted 
its registry keys and reassociated the .r extension with the rebol/view 
2.7.6 product.

; request for comments --

assert-all: func [cases [block!] /local value][
	until [
		set [value cases] do/next cases
		unless value cases/1
		cases: next cases
		any [not value tail? cases]
	]
	value
]

Usage:

	assert-all [
		a < 10 [print "a is more than 10"]
		a > 0 [print "a is less than 0"]
	]


It's the opposite of 'case really.  If any of the cases are false, 
the related block is evaluated and the function returns none/false. 
 If all cases are true, it returns the value of the last successful 
case.

Why would we need that as opposed to just changing the current evaluation 
of existing case?

I would like to see a good implementation of a function that performs 
a sequence of code blocks. If a code block is good, the next one 
is run. If the code block causes an error, a secondary code block 
that is either generic for all code blocks or specific to that particular 
code block is run. I'm thinking step-by-step code that either runs 
successfully or causes a generic or specific error.


I don't know if it makes sense to do that, but I sometimes miss that 
if I need to do something with user friendly network connectivity.

although I've recently switched to state machines for that kind of 
code.

all-nots ?