AltME groups: search

The new casting warnings seem to assume that all structs are equal. 
Especially in GTK, many objects are both generic widgets and a specific 
class of widget. They need to be passed in different identities to 
different functions, even if those structs are only defined with 
the same dummy content

the performance of the Red program is a bit dissappointing

 Maybe I should have kept Red project secret until v1.0 to avoid "deceiving" 
 people who thinks that any v0.x version should be equal to a v1.0...;-)

In REBOL, 'a and 'A are aliases of the same symbol. Red/System converts 
them to their integer identifier, right? I'd say you need different 
identifiers for aliases somehow to implement the REBOL semantics 
of distinguishing equal? and strict-equal?

The most space efficient encoding I can come up with would be something 
like ~a-1 for 'a and ~A-2 for 'A. That would be cheap to evaluate 
for strict-equal? but expensive for equal?

A faster encoding would be to reserve a part of the integer identifier 
for the alias number, for example one byte. That would reduce the 
number of different symbols to 2^24 and the maximum number of aliases 
for one symbol to 256. That would only allow a word up to 8 characters 
to have all its aliases, but it would be cheap to evaluate for both 
strict-equal? and equal?

Aliases are already implemented in the symbol! type. Basically a 
word! relies on a symbol ID, which is an entry in the symbol table. 
Each entries in this table is a symbol! value that references the 
internal Red string! value and a possible alias ID (which is just 
another symbol ID).


Now, I just need to add alias handling in the equal? and strict-equal? 
natives when applied on words to make it work correctly.

Why would = translate to strict-equal? - shouldn't that be == instead?

I have completed the set of fixes for various path issues for Red. 
They are available from the `fix-issue-277` branch and they should 
cover the following issues:

#251 (Red doesn't find source in working directory)
#252 (#system cannot find #include)

#277 (Include system doesn't handle well files with same name in 
different directories)

#366 (Compilation of code outside of the Red/ path fails under Windows)
#381 (#system-global doesn't detect equal #include paths)


Please let me know if there are remaining path issues to fix before 
merging this branch with master.

Yes, so i should not be defined after performing the repeat. There 
is something to say about that.  On the other hand after performing 
the repeat, in my mind i is at the end of the range and thus has 
to be equal to the last value. Stupid humans ;)

STRICT-EQUAL? delegates to the datatype. Should the doc string just 
say "strictly equal" in it, or should it be more like R2? i.e., there 
may be more going on, unless you have a behavior locked down for 
it.

STRICT-EQUAL?: I prefer the R2 doc-string, it is more helpful.

My 'problem' with the Mersenne Twister is/was that if you print the 
integer it is turned into a negative number if the MSB is equal to 
1, the results could be the same, I did not check. Nevertheless it 
has inspired XieQ to work on his version? Nice to see this result 
XieQ! Keep up the good work!

 The Knuth algorythm is very interesting because of the pointers used 
 and I have little experience in pointers so I really learn a lot 
 and I hope to be able to document the differences, explaining it 
 to newbies in the Red language.

So you're pointing img3 to a semi-random memory area that happens 
to have an address equal to the size of the first image. That will 
crash the first time you try to access the image

To make the algorithm foolproof, you could also check that size1 
and size2 are equal

But what is troubling to me is that

print-line im1

is not equal to


print-line as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b / 3))

After current test, I conclude otherwise :) Output is the same. Output 
in C source is unsigned, output in R/S is signed.
C: 10 outputs of genrand_int32()
1067595299  955945823  477289528 4107218783 4228976476 
3344332714 3355579695  227628506  810200273 2591290167 
R/S:--- Test 3 10 outputs of genrand-int32 ---
--------------------------------------------
1067595299 955945823 477289528 -187748513 -65990820 
-950634582 -939387601 227628506 810200273 -1703677129 
----------------------------------

(Where the negative values are bitwise equal to their unsigned counterpart 
in the C output.)

Yet another task I think REBOL could help me with. Say I could not 
find the subtitles for an ancient tv-series i stumbled upon on the 
net. But I found subtitles in English. I can translate but some words 
will reoccur often, so I imagine a rebol script showing an original 
line or words to be translated. I type some translations and when 
I translate a word, all equal words in the rest of the document will 
change, saving me quite some time.

Here's a version of Doc's with all datatypes handled, even unset. 
It even avoids accidentally converting lit-words to words and lit-paths 
to paths:

rle: func [s [series!] /local out pos1 pos2 cont][
	out: make block! 1
	parse/all s [
		any [
			pos1: skip some [
				pos2: skip (cont: if any [
					not-equal? unset? :pos1/1 unset? :pos2/1
					strict-not-equal? :pos1/1 :pos2/1
				] [[end skip]]) cont |
				pos2: (repend out [offset? :pos1 :pos2 :pos1/1]) break
			]
		]
	]
	out
]

There was no point in using parse/case since the comparisons were 
being done by strict-not-equal?, not parse.

This version handles unsets too:

rle: func [s [series!] /local out emit pos1 pos2 cont][
	out: make block! 1
	emit: [(repend out [offset? :pos1 :pos2 :pos1/1])]
	parse/all s [
		any [
			pos1: unset! some [pos2: unset! | pos2: emit break] |
			pos1: skip some [
				pos2: unset! :pos2 emit break |
				pos2: skip (
					cont: if strict-not-equal? :pos1/1 :pos2/1 [[end skip]]
				) cont |
				pos2: emit break
			]
		]
	]
	out
]

Slight improvement:

rle: func [s [series!] /local out emit pos1 pos2 cont][
	out: make block! 1
	emit: [(repend out [offset? :pos1 :pos2 :pos1/1])]
	parse/all s [any [
		pos1: unset! any unset! pos2: emit |
		pos1: skip some [
			pos2: unset! :pos2 emit break |
			pos2: skip (
				cont: if strict-not-equal? :pos1/1 :pos2/1 [[end skip]]
			) cont |
			pos2: emit break
		]
	]]
	out
]

For old versions of R2, you might want to change IF STRICT-NOT-EQUAL? 
to UNLESS STRICT-EQUAL?. There used to be a bug in STRICT-NOT-EQUAL? 
in R2, but I forget how far back it was fixed, one of the last couple 
versions.

Two rules it is then. This doesn't crash, and is optimized for strings 
while we're at it. It's probably slower when doing blocks than Doc's, 
but it handles all datatypes:

rle: func [s [series!] /local out emit pos1 pos2 cont][
	out: make block! 1
	emit: [(repend out [offset? :pos1 :pos2 first :pos1])]
	parse/case/all :s pick [[
		any [pos1: skip (cont: first :pos1) any cont pos2: emit]
	] [
		any [
			pos1: unset! any unset! pos2: emit |
			pos1: skip some [
				end pos2: emit break |
				pos2: unset! :pos2 emit break |
				pos2: skip (

     cont: unless strict-equal? first :pos1 first :pos2 [[end skip]]
				) cont |
				pos2: emit break
			]
		]
	]] any-string? :s
	out
]


It also works around the strict-not-equal? bug in pre-2.7.7 R2, and 
using FIRST instead of path access is another speedup in R2 (path 
access is faster in R3).

Change the repend to chained inserts and it gets noticably faster, 
due to less mezzanine overhead:

rle: func [s [series!] /local out emit pos1 pos2 cont][
	out: make block! 2

 emit: [(out: insert/only insert out offset? :pos1 :pos2 first :pos1)]
	parse/case/all :s pick [[
		any [pos1: skip (cont: first :pos1) any cont pos2: emit]
	] [
		any [
			pos1: unset! any unset! pos2: emit |
			pos1: skip some [
				end pos2: emit break |
				pos2: unset! :pos2 emit break |
				pos2: skip (

     cont: unless strict-equal? first :pos1 first :pos2 [[end skip]]
				) cont |
				pos2: emit break
			]
		]
	]] any-string? :s
	head out
]

If you follow the /into option standard you can do chained calls 
to RLE too:


rle: func [s [series!] /into out [any-block!] /local emit pos1 pos2 
cont][
	unless into [out: make block! 2]

 emit: [(out: insert/only insert :out offset? :pos1 :pos2 first :pos1)]
	parse/case/all :s pick [[
		any [pos1: skip (cont: first :pos1) any cont pos2: emit]
	] [
		any [
			pos1: unset! any unset! pos2: emit |
			pos1: skip some [
				pos2: unset! :pos2 emit break |
				pos2: skip (

     cont: unless strict-equal? first :pos1 first :pos2 [[end skip]]
				) cont |
				pos2: emit break
			]
		]
	]] any-string? :s
	either into [:out] [head :out]
]

The PARSE IF method does let you add a /compare function option though, 
so you can be as specific as you want. Instead of if (:p/1 == :e/1) 
you would do if (apply :f [:p/1 :e/1]) then pass :== or :strict-equal? 
as a parameter..

This is more likely the code you might use:

foreach record results [

    either (first record) = (second record) [print ["they are equal:" 
    first record]] [print ["Alert!"]]
]

you have more than one solution, the first is a simple serial SELECT 
on each table -> compare the output for equal.

of course this produce unnecessary DB overhead but I guess you won't 
feel any speed difference except you are

serving a whole city concurrently. another, better one is a JOIN 
or UNION.

SELECT table_name1.column_name(s), ...
FROM table_name1
LEFT JOIN table_name2
ON table_name1.column_name=table_name2.column_name


the JOIN direction (LEFT,RIGHT,INNER) for your reference table is 
important here. 

the resultset is a table containing BOTH columns. if both having 
a value -> match, if one is empty then you don't.


index both fields to accelerate the query and use something like 
the free SQLyog 
to test different queries to make debugging easier for you.


while you situation reminds me to myself, sitting infront of a monochrom 
asthon tate dot some decades ago

and asking what next?, you should 'bite' yourself now thru the rest. 
It won't help you on longterm if you don't.

R2 says 0.0 and -0.0 are the same, but R3 does not. I replied to 
Lad's googlegroup post that I would prefer "0.0", as evaluating -0.0 
returns 0.0. So, they are equal but not the same under R3. What would 
be a scenario where you would want to maintain the sign?

my contribution to loop-for discussion:
	for-step: func [
		{simplified for}
		[catch]
		'word [word!]
		start [number!]
		end [number!]
		step [number!]
		body [block!]
		/local op result
		][
		do reduce [to set-word! :word start]
		if step = 0 [throw make error! "step parameter cannot be = 0"]
		op: either step > 0 [:lesser-or-equal?][:greater-or-equal?]

  while [op get word end][set/any 'result do body set word (get word) 
  + step] get/any 'result
	]
	for-step i 1 3 1 [print i]

another contribution:
	use [count inc start end op][
		count: inc: start: end: op: 0	
		in-range: func [
			[catch]
			'word [word!]
			start [number!]
			end [number!]
			/bump step [number!]
			/local result
			] [
			if inc = 0 [

    if step = 0 [throw make error! "step parameter cannot be = 0"]
				count: start

    either start > end [inc: -1 op: :greater-or-equal?][inc: 1 op: :lesser-or-equal?]
				unless none? step [inc: step]
			]
			set word count

   result: either op count end [count: (get word) + inc true][false]
			if not result [count: inc: start: end: op: 0]
			result
		]
	]
	i: 0 ; define a var
	while [in-range i 1 3] [print i]

The speed difference must be at least (actually, it should be even 
greater a bit due to the deimal nature) equal to the difference between 
floating point arithmetic done by the coprocessor, versus it being 
done by an emulator.

Graham: Is '== the operator for 'strict-equal? then?

distributed means that all nodes are equal. and with the right measures, 
a few nodes failing are not enough to cause a data loss.

>> greater-or-equal? 1.2.48.3.1 system/version
== false
>> system/version
== 1.2.102.3.1
>>

>> help greater-or-equal?
USAGE:
    GREATER-OR-EQUAL? value1 value2

DESCRIPTION:

     Returns TRUE if the first value is greater than or equal to the second 
     value.
     GREATER-OR-EQUAL? is an action value.

ARGUMENTS:
     value1 -- (Type: any)
     value2 -- (Type: any)

So you have to invert arguments :
greater-or-equal? system/version 1.2.48.3.1

so 6 in his example is equal tail ... index? tail "abcde" = 6

Is this a bug ?

I was making a field validator function, and it was hard to understand 
why VALUE wasn't always equal to face/text.

I do admit that he has a point wrt how the help states things. if 
 there is a stated difference between  '=  and '==   then maybe the 
'= should be expanded (and explicitely documented)  for obviously 
equal values...

like char and one letter string,
$ and equivalent decimal,
 etc.

thanks, I personally tend to think it *is* a bug, because they are 
only equal

I show you something from my article:

a: b: charset [#"a" #"b"] c: insert charset [#"a"] #"b
identical?: func [
    {are the values identical?}
    a [any-type!]
    b [any-type!]
    /local var var2
] [
    ; compare types

    if not-equal? type? get/any 'a type? get/any 'b [return false]
    ; there is only one #[unset!] value
    unless value? 'a [return true]
    ; errors can be disarmed and compared afterwards
    if error? :a [a: disarm :a b: disarm :b]
    ; we need to be transitive for decimals and money
    if any [decimal? :a money? :a] [
        return found? all [same? a b zero? a - b]
    ]
    ; we need to be transitive for dates

    if date? :a [return found? all [same? a b same? a/time b/time]]
    ; we need to be able to compare even the closed ports
    if port? :a [return equal? reduce [a] reduce [b]]
    ; our function has to work for structs
    if struct? :a [return same? third a third b]
    ; we can have something stronger than SAME? for bitsets
    if bitset? :a [
        unless same? a b [return false]
        if 0 = length? a [return true]
        unless equal? var: find a 0 find b 0 [return false]
        either var [
            remove/part a 0
            var2: find b 0
            insert a 0
        ] [
            insert a 0
            var2: find b 0
            remove/part a 0
        ]
        return var <> var2 
    ]
    same? :a :b
]
identical? a b ; == true
identical? a c ; == false

Expected behavior: things  which are modified  when one thing is 
 modified should be same.

Expected Reason for  current behavior:  bitsets with the  same data 
 share the  same data automatically  to save  space.

Expected Reason for bug: 'same? compares the  pointer to  the data, 
which is automatically made same with equal data.
Expected Fix: comare something else :)

Expected Reason for bug: 'same? compares the  pointer to  the data, 
which is automatically made same with equal data.
 proven wrong above

hu? a and b have the equal content. so  they would point to  the 
same  data. so  'same? would return true.

.. return still the equal stuff.

Not a bug.

DESCRIPTION:
     Returns TRUE if the values are equal.

>> equal? #"a" #"A"
== false

and

>> to integer! #"a"
== 97
>> to integer! #"A"
== 65

Definitely not equal.

Another question worth asking: I can agree that it is useful to obtain 
TRUE from equal? 0.1 + 0.1 + 0.1 0.3, although zero? 0.1 + 0.1 + 
0.1 - 0.3 cannot yield TRUE due to the limitations of 64-bit IEEE754 
floating point format. On the other hand the STRICT-EQUAL? and/or 
SAME? functions may be stricter. E.g. my IDENTICAL? function (see 
above) is the most strict possible in that respect and yields FALSE.

AFAIK equal? in rebol is relaxed and does a range-check. For close-to-zero. 
And 'equal?  is the  relaxed version. 'strict-equal? should not. 
IMHO.

even more strict than 'strict-equal? :)

(Ladislav is the one thinking this to be suspicious ;-)  I have a 
merge func which could not care less, all it wants is to make sure 
that equal things get inserted equaly, string into string, blocks 
into blocks...  so in that sense, the above is not suspicious at 
all.  but if only reacted differently for string, then I'd have to 
add an ugly escape route for that case ;-)

Found a couple RAMBO tickets dated back to 13-May-2006 related to 
the double evaluation of lit-words:
http://www.rebol.net/cgi-bin/rambo.r?id=4100&
http://www.rebol.net/cgi-bin/rambo.r?id=4101&


The tickets suggest, USE might be the problem, but isn't it SAME? 
that's the problem here? See the following R2 code:

>> a: first ['word]
== 'word
>> b: 'word
== word
>> strict-equal? a b
== true
>> strict-equal? :a :b
== false
>> same? a b
== true
>> same? :a :b
== true


I would expect all 4 to return false, but with double evaluation 
of lit-words, the last should still be false.

string comparisons are, in effect, right padded, to equal length 
before comparing.
The comparison is really
max "1000" "999*"

   where "*" is whatever the pad character is (probably a binary zero)

ah yes.. that's right. When you sort an already sorted list, some 
equal values would swap around sometimes.

It's easy to do case sensitive or case insensitive tests for equality:
     >> "abc" = "ABC"
     == true
     >> "abc" == "ABC"
     == false
(Or use equal? and strict-equal?)


Anyone know a  similar shorthand way to do the same for greater/less 
than comparisons?
     >> "abc" < "ABC"
     == false
     >> "abc" > "ABC"
     == false
Right now, I'm using to-binary to get the right result:
     >> (to-binary "abc") < (to-binary "ABC")
     == false
     >> (to-binary "abc") > (to-binary "ABC")
     == true

from my point of view its equal ;-)

Are you trying to compare area?  -- greater-pair?: func [p1 p2 /local 
ps][ps: reduce [p1 p2] pick ps (p1/x * p1/y) > (p2/x * p2/y)] -- 
which can be tweaked for when p1 and p2 are equal...

On a related theme......Is there an easy/built-in way to check if 
all values in a series are equal?  I'm using

     all-equal?: func [ser [series!]] [ser = join next ser first ser]
As in:
    all-equal? [1 1 1 ]
    == true
    all-equal? "yyy" 
    true
    all-equal? %xxx
     true

would prefer change/dup too. both lines look equaly ugly :)
all-equal?: 1 = length? unique blk

I looked up = in the Rebol Dictionary and, whilst it is not explicit, 
it implies different value types can be equal.

From the dictionary:


== - Returns TRUE if the values are equal and of the same datatype.

In that case, when source and destination are of equal weight, then 
you can apply other rules.

Does Rebol have an equal to PHP's exit; function?

Btw. performance-wise the 2 ways look equal good.

That's the more strict-equal, which turns off the case-insensitive 
equality of strings.

But you could be right. At least there is scope for moving the simple 
equality test to strict-equal ==

I have uploaded a new version of simple-test.r to the Script Library. 
The main changes were the addtion of some new assertions and a re-structuring 
of the code to provide an API for the function which evaluates test 
cases.


The assertions added are : equal with tolerance, not equal, not error, 
same, and not same.

I also have a naming convention I've been playing with for a while, 
where parse rule words have an "=" at the end (e.g. date=) and parse 
variables--values set during the parse process--have it at the beginning 
(e.g. =date). The idea is that it's sort of a cross between BNF syntax 
for production rules and set-word/get-word syntax; the goal being 
to easily distinguish parse-related words. By using the same word 
for a rule and an associated variable, with the equal sign at the 
head or tail, respectively, it also makes it easier to keep track 
of what gets set where, when you have a lot of rules.

>> strict-equal? 'A 'a
== true

>> alias 'a "aa"
== aa
>> strict-equal? 'A 'a
== false

This is related, I think, to my notes about VID and MySQL in the 
View section. In a test that we ran in 2004 we were able to load 
1,000,000 rows in under 30 minutes.  We did not investigate further 
but we thought we could improve this by running parallel loads and 
putting it on a real server instead of a laptop.  This volume was 
equal to the annual volume of  the transactions we were interested 
in so would represent a journal of everything that happened to this 
app as a keyed transaction in one year.   


From that 1,000,000 row database, we were able to create an HTML 
report based on some selected criteria in 2.5 seconds.  

All tests done with REBOL View using Doc's mySQL protocol.

As for comparing 13000 lines of Perl to 1600 lines of Ruby, if the 
Perl was written to be readable, that comparison sounds about right. 
Perl isn't that powerful a language unless it's written in an unmaintainable 
way. It takes a lot of Perl to equal Ruby, or REBOL for that matter.

Just realized that encapping the db's with the exe is not a good 
idea as the memory used is equal or close to the size of the exe 
and these db's will be quite large....

I keep thinking in terms of XPackerX where it unpacks first and runs 
the main file adn accesess the data as if its on disk (which it is) 
and does not  load it into memory...

either 1.2.8.31 < system/version [
	print "Version greater than 1.2.8.31"
][
	print "Version less than or equal to 1.2.8.30"
]

multiply, add, subtract, divide, remainder, lesser?, lesser-or-equal?, 
not-equal?, equal?, strict-equal?, same?, greater?, greater-or-equal?

Hmm, -1 0 1 code sometimes for lesser, equal, higher. brab .. -1

But how about a three-state if too? lesser/equal/higher 0? Could 
speed up binary search and such?

; And then use it like this:
cmp.i t a b
brab [leq lgt] t
; Less than
label leq
; Equal
label lgt
; Greater than

; And then use it like this:
cmp.i a b [
    ; Less than
] [
    ; Equal
] [
    ; Greater than
]

next s1 next s2
seti char s1  sub char s2
bra3 to-equal to-higher
; we are lesser here
label to-eqaul
next s1 next s2 ; check length..
bra loop
label to-higher ; we are higher here

A SIGN opcode would set a word to the integer -1, 0 or 1 depending 
on whether an argument is less than, equal to, or greater than 0.


sign: ["Set variable to the sign of a value (-1,0,1)" word! word!]


It would be preferable to have SIGN work with all numeric arguments, 
but you might choose to implement this as sign.i and sign.d for speed 
- either way is fine by me. The SIGN opcode, when combined with BRAB, 
would enable functionality equivalent to the BRAS proposal (#3948), 
and so would supercede it. There are many other uses as well.

Related to string COMPARE are these features:
1) case sensitive or not
2) which string is "greater"
3) index of non-equal (tail of compare)
4) find

Well after testing, it seems that the behavior of cmp is:

1) Case sensitive. Lowercase the strings for case insensitive compares.

2) If the first string is less than the second, cmp sets the return 
word to -1, equal sets to 0, and greater sets to 1. If two strings 
of different lengths and are the same for the length of the shorter 
string, the longer string counts as greater. Otherwise, the numeric 
equivalent of each corresponding character is compared.

3) You can roll your own with length?, repeatz, pick, lt.i, gt.i 
and breakt (if you want, I'll do it). The cmp opcode won't help here.
4) Use apply i find [ser val] - it'll be faster.

; Index of non-equal, 1-based, assumes indexes within bounds
length? x a
length? y b
gt.i x y
ift [set.i x y]
repeat i x [
    pick x a i
    pick y b i
    eq.i x y
    breakf
]
; i = first non-equal index

const char *sqlite3_libversion(void);	sqlite3_libversion() function 
returns a pointer to the sqlite3_version string constant.

int sqlite3_libversion_number(void);	sqlite3_libversion_number() 
interface returns an integer equal to SQLITE_VERSION_NUMBER.

Maxim, I'm a little unclear about that. Does it mean:
f: func [val /option = 77][print option]
f 123 
; ==> 77
f/option 123 88
; ==> 88


So is it that just the presence of the equal sign '= after a refinement 
in the func spec block creates the closure instead of a normal function 
?

I've been wondering about an extension to EXTRACT as I haven't been 
able to find this particular functionality anywhere else. If it exists, 
then I'm wrong and you can ignore this.


I would like to propose adding a /size refinement to set the number 
of values extracted at each point. This would make it very easy to 
split a string in equal-sized chunks. It could also be used to retrieve 
equal sized parts of a set of database records. Combining this with 
/index, I think this could be very useful.

Here's how I would like it to work:

>> block: [1 2 3 4 5 6 7 8 9]
>> extract block 2
== [1 3 5 7 9]
>> extract block 4
== [1 5 9]
>> extract/index block 2 2
== [2 4 6 8 none]

The refinement at work:

>> extract/size block 4 2
== [[1 2] [5 6] [9 none]]
>> num: to-string 123456789
== "123456789"
>> extract num 3
== [#"1" #"4" #"7"]
>> extract/size num 3 1
== ["1" "4" "7"]
>> extract/size num 3 2
== ["12" "45" "78"]
>> extract/size num 3 3
== ["123" "456" "789"]
>> extract/size num 3 5
== ["12345" "45678" "789"]
>> extract/size/index num 3 5 2
== ["23456" "56789" "89"]
>> extract/size num 3 12
== ["123456789"]

/size would always return a block of series.

Looks like it could be useful Henrik. I might call the refinement 
/part, to match other funcs. For the case of splitting a series into 
equal-sized pieces, or a fixed number of pieces, here's what I use:

Just considering equality with the CHAR! type.  We think it might 
be better to move the currently simple, case-insensitive equality 
test to strict-equal.

Alright, off to Rambo then. (I recall discussions all about equality 
and strict-equal a long time ago.)

yes... but equal is a function... not an op ;-)

Perhaps they should be equal.

perhaps it's equal in speed, I don't know. odd though, I can't see 
what's so slow about that code, other than the newline insertion 
thing

Eh, the baseline is centered in each cell, right? And you're asking 
each word to be centered within its cell with equal space above and 
below the text?

Here's my thinking on priority on the plugin project:

 1. IE plugin for 1.3.2 -- we'll have this online within a couple 
 of days.

 2. Mozilla plugin for 1.3.2 -- features equivalent to the IE plugin, 
 although we may need to chop a few things out (do-browser for instance).

 3. IE plugin for 1.3.3 -- the most important new features we can 
 include in a relatively short time-frame release.

 4. Mozilla plugin for 1.3.3 -- again, features equivalent to the 
 IE plugin, but this is equal priority with the next item.

 4. IE plugin for REBOL 3.0 -- new features that will ship with REBOL 
 3.0 (multithreading/multiple instances per browser, etc.)
	5. Mozilla plugin for REBOL 3.0 -- features equivalent to IE

(I want to change the above priority list. Mozilla 1.3.2 and IE 1.3.3 
are equal priority, pri 2)

all members of a pipes are equal owners of the same value.

Is there anything that would cause Cheyenne to crash? I've not yet 
tracked down the bug, but every time I click a specific link on one 
of my .rsp pages, it just dies and needs to be restarted. Unfortunately 
it's now gone so far that it seems not to want to serve pages anymore 
even though it's running. Under OSX, I get this log output:


Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68212 PPID 68210 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68211 PPID 68209 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68210 PPID 1 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68209 PPID 1 
rebol


Are there any file permissions, that if set wrong, would cause cheyenne 
to stop serving pages?

29/10/08 21.56.24 com.apple.launchd[1] (com.rebol.cheyenne[65863]) 
Stray process with PGID equal to this dead job: PID 65868 PPID 65866 
rebol

Is the situation wrt the range of intensity really as described in 
the article? I seem to recall that the receptors for the three colors 
in the retina are not all equal in terms of sensitivity. In particular, 
the eye is supposedly more sensitive to green. Why the assumption 
that the three colors should have the same exponential scale?