World: r3wp

no native CGI support in R3


True, although that "native" support is barely needed. `get-env` 
and `system/ports/input` are basically all you need. I am running 
several R3 CGIs which work just fine.

well................ carl where are you ?????

Ladislav, how do we now access the R3 GUI and the REBOL core on which 
it runs?

Singy, it should be on saphirion.com, but there are some server problems 
currently.

No server problems: http://www.saphirion.com/development/r3-gui/

Thanks Robert - that works fine - now :) Henrik was correct at the 
time, the server was having problems - it is what prompted my question.

I just noticed Bohdan Lechnowsky saying following on Facebook: "I 
know for a fact that Carl was working on R3 this past weekend." Any 
insider info on that?

Who is this person?

Found out.

Bo did a talk at REBOL/Collaboration 2004 and is quoted in the notes. 
 Oh yeah, here's his bio... http://www.efishantsea.com/devcon2004/bios.html

a quote from there ... http://www.efishantsea.com/devcon2004/bloopers.html

Bo lives in Ukiah as well.

Bo used to work for RT, afaik.

Yeah, he was in quality assurance and testing

In R3, upper- and lowercase chars are equal, which leads to:

>> #"a" = #"A"
== true
>> #"a" > #"A" 
== true

Isn't that a mistake?

no...

no...

>> #"a" == #"A"
== false

>> #"a" == #"a"
== true

But how can something both be equal and larger than something else 
(using normal equal)? Think about it! Look at strings:

>> "a" = "A"
== true
>> "a" > "A" 
== false

(I wouldn't go for this solution for chars though.)

Because chars can be used as numbers, this rule leads to strange 
things like:

>> a: #"a"
== #"a"
>> b: #"A"
== #"A"
>> a = b
== true
>> (1 * a) = (1 * b)
== false

How would you otherwise compare single upper and lowercase chars, 
then?

Like in R2, I guess.


You could convert them to strings. And some functions, like PARSE, 
deal with it. I'm not 100% sure, it's the best way, but it's better 
than this, I think.

I don't necessarily agree. In fact, when there is already a case 
sensitive solution (==), this seems meaningful enough, if you want 
a fast and memory efficient case-insensitive comparison.

Already documented:

http://curecode.org/rebol3/ticket.rsp?id=1497&cursor=13

I'm pretty sure the current behaviour is the better one.... and why 
something can be larger?
>> to-integer #"a"
== 97
>> to-integer #"A"
== 65

>> (1 * #"a") = (1 * to integer! #"a")
== true

Consistency between the behavior of = between characters and strings 
is really important. R3 is better than R2 in that regard.

= isn't "normal equal", it's approximate equal. All four of the equivalences 
are "normal", for different circumstances.

I guess, the question is, whether chars should be more number-like 
or more string-like. In R2, chars are number-like except in maybe 
PARSE, where they are string-like:

>> parse "a" [#"A"]
== true

even if:

>> #"a" = #"A"
== false


In R3, chars are somewhere in between being number-like and string-like, 
as I see it. We can still do much calculations with chars, but not 
all:

>> 2 * #"a"
== 194
>> 2 ** #"a"

** Script error: ** does not allow char! for its exponent argument


The last is possible in R2. If chars should be more string-like, 
then make them so, Carl! This is really confusing:

>> "a" > "A"
== false
>> #"a" > #"A"
== true

There was a big debate about this before we hammered down the current 
equivalence hierarchy, including the operators. There was even a 
suggestion to have ~= refer to EQUAL?, making = refer to EQUIV?, 
but we finally decided that the paying attention to binding and exact 
IEEE754 equivalence was too advanced for most uses, so = was assigned 
to the most forgiving form of equality. Many other languages with 
an equivalence hierarchy have made a similar choice, so it shouldn't 
be too surprising.

The last is only confusing, if chars are considered string-like, 
as in R3. In R2, #"a" being greater than #"A" makes good sense.

In general, doing math with char! values without explicitly converting 
them is kind of bad form; it leads to developer confusion. The main 
reason you'd do this is because of the awkwardness of combining operator 
and prefix expressions without parentheses. It's interesting that 
it still works in some cases, but not in others. Considering characters 
to be number-like is a bit weird, a bit too C-like for my tastes.

For instance:
>> 1 + #"a"
== 98
>> #"a" + 1
== #"b"


The latter looks alright to me, the former looks weird, like a to-integer 
is missing. Can't say why though. I know why the result is an integer! 
(the left side sets the datatype returned most of the time), but 
any math that treats a char! as a number rather than as a non-numeric 
ordinal value just seems weird to me.

Alright, not "most of the time", just in this case. For others:
>> 1 + 1.0
== 2.0
>> 1 + $1
== $2
>> 1 + 100%
== 2.0


Maybe that's why it seems weird. I guess that since R3 char! values 
are currently limited to the codepoints in the BMP they are 16 bits, 
so converting back to char! would be a potential loss of range. It 
could go either way, so I guess the datatype-on-the-left rule is 
a way for the developer to specify which they want. And that rule 
applies to string types too (for INSERT and APPEND), so it's not 
completely weird.

Now this looks completely weird:
>> #"a" + #"b"
== #"A"


Having ordinal values that you wouldn't think of being numbers act 
like numbers seems really weird to me. I can accept that #"a" > #"A", 
but treating them like numbers without explicit conversion seems 
strange to me. I get similarly creeped out by multiplying one money! 
by another; I have to remember that despite the "$", and "money!" 
name, they aren't really money (a measure of quantity), they are 
just another numeric encoding that enables more precise decimal math 
than decimal! (another name that seems off to me, since its values 
are floating-point binary, not decimal).

I don't like this inconsistency though:
>> "a" > "A"
== false
>> #"a" > #"A"
== true

Too bad we don't have a hierarchy of inequalities. Only two levels 
would be needed. Maybe a /case option to the functions that the the 
operators map to? Is it even possible to map an op! to a function 
that can take an option?

Perhaps the relative comparison functions could be made to all be 
case-insensitive (for datatypes that have case defined as a concept), 
and have additional STRICT-* case-sensitive functions which would 
combine the functions and STRICT-NOT-EQUAL?.

We have a ticket for an improved equality comparison hierarchy:
http://www.curecode.org/rebol3/ticket.rsp?id=1834

I think that would nicely fit with a inequality comperison hierarchy 
as well (strict vs non-strict).

Nicely fit with an inequality comparison hierarchy
, of course. Bad typing day, I guess.

The term "relative comparison hierarchy" may be better, since it 
wouldn't include NOT-EQUAL? and such.

The STRICT-* relative comparison functions wouldn't have operators, 
unless we could come up with some that don't look like line noise 
(or worse: Perl).

Andreas, given that Carl is one of the ones who was tripping over 
the equivalence hierarchy (that he helped decide on) that ticket 
looks pretty promising. The caveat is that Ladislav is the one who 
would likely be doing the work, and he seems to need some convincing. 
Plus, it would require a new R3 release, not just a host kit update.

Ladislav is the one who would likely be doing the work, and he seems 
to need some convincing

 - I do agree, that LESSER? etc. functions having two versions (or 
 a refinement, or something) would be useful.

I was talking about http://issue.cc/r3/1834but that's good to hear 
too :)

hello

hello

A test of SIZE-TEXT shows a bug in R2. This should hopefully not 
be present in R3.

The test to run:

f: make system/standard/font [name: "Verdana" size: 12]
g: make gob! []
t: import 'text
g/text: bind [font f bold true text "Boo"] t
probe size-text g				; I get 26x14 here
g/text: bind [font f bold false text "Boo"] t
probe size-text g				; I get 25x14 here


It's possible that the result may vary, but the bold version should 
produce a wider size than the normal one. if you can test this similarly 
to what you did for R2, that would be great. Thanks.

R3 2.100.110.3.1 on Win 7 gives 27x14 for plain and 26x14 for bold 
text (both 1x0 bigger than yours).