World: r3wp

the load "#[function! [] []]" bug is know too, but anyway, I am reminding 
it here

I haven't found much else wrong.

This is a problem that has occurred since View 1.2.100 or before 
(but seems not a problem in View 1.2.48 or 1.2.54)
I see a difference between these two:
	request-file/keep
	request-file/keep/file %hello

The first one remembers the directory of previous invocations, but 
the second one doesn't.

I think when the /FILE refinement is used, it just ignores the previous 
directory, reasoning that the user is passing in the "current directory" 
via %hello
That seems simplistic.

I would prefer if REQUEST-FILE would check the /FILE refinement's 
NAME argument to see if it contains a path or is just a single file.
When it is a path, then it is OK to use it.

When it is just a single file, then it should use the previous directory.

Anton, if that applies to 1.3.2 too, then please make sure it is 
in RAMBO.

is there going to be official 2.7 release soon or what?

dunno if RAMBOed, but there is a difference in callback! vs callback 
between 2.6 and 2.7

and I hope timezone gets fixed finally after all those years

Gabriele, yes it does apply to 1.3.2 and also 2.7.5

Ok, posted bug report.

Petr: first of all, we don't want 2.7 to introduce new bugs. (2.7 
is a merge of a number of branches of the code - Carl really needed 
to do this to simplify things - so there are many things that can 
break in such a scenario). Then, we want it to fix a few bugs too. 
:)

but we want 2.7 to fix certain bugs, no?

of course. as i said, first we must remove the bugs introduced by 
the merge, then we start fixing bugs that were in 1.3.2 already.

Gabriele: I noticed that two ROUND test cases ceased to work in 2.7 
- this signals, that comparison in 2.7 isn't equivalent to comparison 
in 1.3.2

Is it better?

Brian: if your question is related to my post, then I would answer: 
it depends. The cases are:

not negative? 1E-8 - abs 0.9999999 - mod 99999999.9999999 1
0.1 == round/even/to 0.1 1E-16

Dang, I'd have to refresh my math memory to know what the answers 
to those should be. Still, my preference is to have comparison work 
correctly, and if it didn't before, break backwards compatibility 
and fix the code that depended on the bad comparisons. There can't 
be much of that...

Err on the side of more correct :)

my preference is to have comparison work correctly

 - this may be a matter of preference, as it looks. Both versions 
 yield:

0.1 + 0.1 + 0.1 = 0.3 ; == true
zero? 0.1 + 0.1 + 0.1 - 0.3 ; == false

:-)

Where are fixed-point or BCD numbers when you need them? :)

This is just madness. Why do we still put up with this ?

Because 0.1 is a floating-point value in REBOL, and for that matter 
one that can't be represented exactly, much like 1/3 in decimal.

anton, this is a problem in all floating point... I had serious issues 
in compiling earthquake data over a 30 second period... adding each 
change over and over could amount to moving a building a foot away 
 !

because all of the small discrepancies eventually add-up.

>> 0.1 + 0.1 + 0.1 - 0.3
== 5.55111512312578E-17

That's not zero! Anyone can see that! ;-)

I think, it's ok, because the way floating-point works. One could 
just do
>> 0.1 + 0.1 + 0.1 - 0.3 < 1e-10
== true
and that's almost zero, right? :-)

in high-end 3D and games you live with this imperfection daily.

Just like the real world. Imperfection!

hehe should we define an 'ALMOST func  ?

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