World: r3wp

almost? #"a" "a"  
==true

i would prefer precision over speed.

>> almost-zero?: func [v][v < 1e-10]
>> almost-zero? 0.1 + 0.1 + 0.1 - 0.3
== true

I believe they call the minimum value that floating point values 
can differ before they register as different: Epsilon.

but like brian said... 0.1 cannot  be reprensented in binary ... 
precision is not the issue... you'll never get to that amount exactly.

which is why BCD exists.  these actually are a base-ten counting 
system.

Right! I haven't studied floating-point closely, but it's something 
about powers of 2 added together, and that'll never end up for some 
values.

I guess, we can think of it this way: some values like 0.1 to computer 
floating-point system is like square-root 2 or pi to our human base-ten 
system.

is the standard double type used in other languages BCD encoded?

There are just some real numbers, that we can't write down with our 
base-ten system. The same way, computers can't handle some values 
completely.

ICarii, no, generally double in other languages is the same exact 
type as decimal! in REBOL - for that matter, REBOL uses C double 
internally for decimal! values. BCD is fairly rare outside of programming 
libraries and languages made for financial use, like COBOL.

Yes, I know the *technical reason* why ! :) (we have of course been 
over this before, several times). It was just blowing some steam. 
Never mind me.

ICarii > "i would prefer precision over speed." - - I would prefere 
speed over precision. But I'm not making any financial calcultions:-)

I would prefer good enough on both, but failing that I would prefer 
known limits that can be adjusted for in planning.

I just posted a few bugs about the plugin being quite shorthanded 
with the event it receives from the various browsers.

for example, I just discovered that the "enter/return" key is not 
trapped within fields (so by extension isn't sent to the plugin) 
within Internet Explorer.  This specific case is not an issue within 
firefox... but then, neither receive scroll-wheel events... and others 
have posted that the alt+ctrl+shift keys are not detected, and there 
are other event issues too IIRC.

this is quite serious IMHO.

this sort of brings back the "nice toy" effect of REBOL within the 
plugin.  :-(

Are these events handled by other plugins, like Flash and Java applets?

ah... "enter" key... yes  for sure.

I can't be sure... as I'm no flash expert, but my gut feeling is 
that since actual controls do receive the events... object controls 
should also be able to receive them ... I posted the bug mainly to 
make sure the enter key isn't forgotten... cause that is quite weird.

There's a small but significant "bug" in prot-esmtp.r that for most 
users doesn't matter.

the protocol sends a terminating "." to signify the end of an email. 
 But this is not correct.  The RFC specifies that you should send 
crlf "." crlf

and what is actually being sent is  .. lf "." lf

gmail just hangs on this because it is expecting to see crlf "." 
crlf

Is it sending lf or is it sending the platform-specific line ending?

Now if you send  crlf "." crlf to smtp.gmail.com, gmail just then 
drops the line on you.

because the port is opened with /lines, it is actually sending crlf 
"." crlf lf

which gmail does not like at all.

so, you have to send crlf ".^M" instead !

I think you can open a port with /lines in a way that specifies the 
line ending string.

I've only tested this on windows .. will have to see what core does 
on linux

but all the internet protocols use crlf and not lf

It seems to me that crlf should be specified as the line ending for 
most internet protocols.

yes

Sorry, you just said that.

took me a few days of puzzling what was going on.

of course ethereal turned out to be no help because I was tracing 
ssl.

This seems like an easy fix to someone who has the time, the SDK 
source and the inclination.

Yep

most of us are missing all three

I'm just missing the time (and the need).

wait! i know why that is happening.

the default for tcp:// is CRLF

BUT the default for ssl:// is LF! that is a bug i reported some time 
ago. (it created problems for https:// too)

you can workaround it by adding a  /with refinement to the open (it 
will not hurt tcp either)

http://www.rebol.net/cgi-bin/rambo.r?id=3532&

Can such /with refinements be added to the default protocols built 
on SSL? It shouldn't hurt when the ssl:// default is eventually fixed.

it was added to http, it should to any other protocol that uses ssl.

but the bug should really be fixed! i have reported it in 2004 ;)

Good to know!