World: r3wp

Sorry, it is strict-not-equal? that has the bug:
>> strict-not-equal? 1 2
== false

STRICT-NOT-EQUAL? only checks types with integer! values. Use NOT 
STRICT-EQUAL? instead.

ok

Something funny. (We had a long discussion about this in R3-alpha.):

>> 0.3 - 0.2 - 0.1 = 0.0
== false

This is also false in e.g. the C language.

It's a floating point thing - 0.1 can't be represented exactly in 
IEE754 floats.

yes

>> $3.0 - $2.0 - $1.0
== $0

use money! datatype if you need precision

Those aren't IEEE754 :)

Or you could use fixnums: integer! and a scale.

In REBOL:
>> 0.1 + 0.1 + 0.1 = 0.3
== true


In C, this is not true. So REBOL tries to cope with this problem, 
but don't do it 100%.

In e.g. Python, my last test is also not true.

But Python is also a bit strange, it seems. From Python prompt:

>>> 0.1 + 0.1
0.20000000000000001
>>> 0.1 + 0.1 == 0.2
True
>>> 0.1 + 0.1 + 0.1
0.30000000000000004
>>> 0.1 + 0.1 + 0.1 == 0.3
False

Ah, maybe it's not so strange. C does the same.

anyone remember where the parse demos showed a calculator dialect 
?

just need simple arithmetic

This? http://www.rebol.com/docs/core23/rebolcore-15.html#section-6

yes .. thanks

saves me a few mins writing my own !

I was trying to help new guy on ML, and just would like to ask - 
why is there a difference in evaluation when printing a block, and 
printing first block?

>> colors: [red green blue]
== [red green blue]
>> print colors
255.0.0 0.255.0 0.0.255
>> print first colors
red

so 'first does not reduce the value, while print itself does?

it doesn't come from print behavior
but, it's how reduce works
reduce first [red]

>> a: 1

== 1

>> type? a

== integer!

>> type? 'a
== word!

>> b: [a
]
== [a
]
>> type? first b

== word!

>> print a

1

>> print first b

a

>> print 'a

a

Help says print does an evaluate (presumably a reduce) if the value 
to print is a block....So it is documented behavior:
  http://www.rebol.com/docs/words/wprint.html

ok, thanks ....

Hi!
Does Rebol suport AUTH=NTLM in IMAP protocol?
Thanks in advance!

I think not. In the past, Doc did some tests, but not sure ...

http://softinnov.org/rebol/ntlm.shtml

Thanks Pekr - I already saw it, but I am thinking how to use them 
in case of IMAP.

Is it just like opening port?

Don't know - never worked with it ...

trouble with double caret afer forming a string from block.

print y: form [KBE RKH CSCD IDJ MNOV LCAPB CWCO ^DJA]
KBE RKH CSCD IDJ MNOV LCAPB CWCO ^^DJA

how can I avoid the double caret?

form, mold or composing the string via foreach etc. doesn't work 
here.

>> print y: form [KBE RKH CSCD IDJ MNOV LCAPB CWCO ^DJA]

KBE RKH CSCD IDJ MNOV LCAPB CWCO ^DJA

sorry I mean a probe... -> probe y: form  [KBE RKH CSCD IDJ MNOV 
LCAPB CWCO ^DJA]

Any time the string is displayed literally (such as at the console, 
or mold/save) will you see the double caret.  Internally it's a single 
caret.

there is no double caret in the string 
^^
 is only one char!

You can - print replace/all mold this_string "^^^^" "^^"

As chris states, there is a difference between how rebol show some 
chars and how they are kept internally

But there's no way other than a rewrite to get 'probe to display 
a single caret.

same behavior with tab, newline,...
a tab is showed as "^-" but internally it's only one char!

ahh I see. I need this string to compose a url and get a error. thought 
by 'probe the second phantom caret was the failure.

What is the error?

looks like rebol doesn't accept the caret with a url

must be encoded

>> http://foo^bar
== http://foo^bar
>> to-string http://foo^bar
== "http://foo^^bar"
>> load to-string http://foo^bar
== http://foo^bar

I think it's 'net-utils/url-parser/parse-url that breaks it.

(this is used by the builtin schemes)

yes, made a string and then to-url. this helps if the caret is hex-encoded 
 %E5

will check for lower level open port...

chris, is your previous replace/all snippet working ?

ok, the parse needs "^^" "%E5"