World: r4wp

(Just pure line coverage.)

The number of lines in the R3 C sources which are executed at least 
once while running the test suite.

aha, interesting

my estimate: 60%

I did expect that you like this Lad. Which give a good hint, what 
kind of test-cases are missing.

What were your estimates?

I estimated 20% (based on a perceiving the C sources to contain a 
high percentage of unused code).

my estimate: 40%

Anyone else before we resolve?

I seem to be overly optimistic, but what the heck...

Ladislav, a statement you made in that Google Groups topic contradicts 
most of what you have said on the topic on other occasions:

    On the other hand, nobody doubts that the string "0.1" should suffice 
    to represent the Rebol decimal! 0.1:


That is the problem. The value 0.1 can't be precisely represented 
as an IEEE754 64bit floating point value, it can only be approximated. 
When "nobody doubts" that it can, they are wrong. MOLD not displaying 
the value with sufficient precision to show the actual value is the 
only thing that lets MOLD output a 0.1 at all. When MOLD just uses 
15 digits, it outputs "0.1", which may be what you entered, but not 
what is in memory. What is in memory is 0.10000000000000001, so if 
you have MOLD autoexpand the number of digits it uses then MOLD 0.1 
will output "0.10000000000000001".

The limit on the number of digits of precision output by MOLD is 
what lets us pretend that 0.1 is exactly representable in Rebol. 
$0.1 is exact, but 0.1 is approximate.

You already got MOLD/all changed to be this "precise enough" MOLD. 
Why are you trying to push this change into MOLD without /all?

The value 0.1 can't be precisely represented as an IEEE754 64bit 
floating point value, it can only be approximated.
 - yes, correct!


However, if you write 0.1 in Rebol, the interpreter (the LOAD function, 
usually) "understands" it somehow. What I said is that nobody doubts 
that the string "0.1" can "accurately enough represent the (above 
mentioned) Rebol value", not that the "Rebol value accurately enough 
represents the string" (I did not even define  what that means).


'When MOLD just uses 15 digits, it outputs "0.1", which may be what 
you entered, but not what is in memory. What is in memory is 0.10000000000000001, 
so if you have MOLD autoexpand the number of digits it uses then 
MOLD 0.1 will output "0.10000000000000001".' - actually, the number 
"in memory" (it does not matter where the number is, in fact, what 
matters is just that it is the IEEE-754 64-bit binary floating point 
number representing "0.1" in accordance with the IEEE-754) is 0.1000000000000000055511151231257827021181583404541015625 
in fact.

So why do you keep saying that 17 digits are sufficient to represent 
any 64bit floating pouint number?

17 digits are sufficient
 does not mean the same as "17 digits are always necessary".

Sometimes much less digits suffice.

17 digits aren't sufficient to represent the difference between 0.10000000000000001 
and 0.1000000000000000055511151231257827021181583404541015625, so 
if you say that the real IEEE754 value is 0.1000000000000000055511151231257827021181583404541015625 
then you can't show that difference in 17 digits.

You are ignoring the definitions:


1) there is the IEEE 754 "definition" specifying which number corresponds 
to 0.1 - I know (using my Rebol script), that it actually is the 
number 0.1000000000000000055511151231257827021181583404541015625

2) there is my definition specifying which strings "accurately enough" 
represents the IEEE 754 number 0.1000000000000000055511151231257827021181583404541015625. 
According to my definition (you can find it defined as a Rebol function 
in the ML) all of "0.1", "0.10000000000000001" and "0.1000000000000000055511151231257827021181583404541015625" 
"accurately enough" represent the number.

This means that any of the three strings can be used as a MOLD result 
that would be considered "accurate enough" by me.

I hope that answers your questions.

The fact is that, e.g., "0.1" is not accurate when you *want* 17 
digits of the number, but it is "accurate enough" when my definition 
of what "accurate enough" means is used.

In the same way, "0.10000000000000001" is not exact when you need 
to know how exactly the number looks, but it is again "accurate enough".

Why are you trying to push this change into MOLD without /all?

 - aha, this may be a misunderstanding. I am not that far yet. What 
 I said was that it was possible to define which string may be considered 
 "accurate enough" when representing a given Rebol value VALUE. There 
 may be more than one such string. Now it is interesting that neither 
 MOLD nor MOLD/ALL needs a longer string than the one that is already 
 "accurate enough". Thus, it might make sense to just use the shortest 
 "accurate enough" string (which may have even less than 15 digits) 
 for both MOLD and MOLD/ALL..

I see this described behaviour as the most "intelligent one" because 
it gives the "accurate enough" result, while the current (in Windows, 
that is) behaviour of MOLD is that many of its results are not "accurate 
enough" while some of the MOLD/ALL results are longer than necessary 
for being "accurate enough". Interestingly, it seems to me that e.g. 
Rebol 2.100.111.2.4 already has MOLD/ALL working this way.

err. it probably was 2.100.111.4.4

History of the problem: the whole issue originated when we found 
out that MOLD was not "accurate enough". I proposed to use a sufficient 
MOLD with 17-digit precision, which was made available by introducing 
SYSTEM/OPTIONS/DECIMAL-DIGITS, but that still did not look to be 
enough, so later on I proposed to adjust MOLD/ALL to always use 17 
digits to make sure all MOLD/ALL results will be "accurate enough".

Cyphre, how much work would it take to get https in ?  I see that 
you have tls now

would 17 digits be a minimum which we can extend using SYSTEM/OPTIONS/DECIMAL-DIGITS 
 ?

Graham, you can use HTTPS now. We don't support all cipher algos 
yet but it should work with most HTTPS connections.


We are currently looking into geting more cipher algos implemented. 
Than all HTTPS things should work.

Interesting .. didn't obviously realise that.

Are the proper source files available?

I can probe system/schemes/tls and /https

Graham, the TLS protocol scheme works transparently on tcp ports. 
So you just need to change the port/scheme from 'tcp to 'tls and 
you have the tcp connection secured. Then you can build any higher-level 
protocol over it. Having made the TLS scheme transparent I needed 
to make only few minor changes to the Gabriele's HTTP scheme to be 
able support HTTPS as well.

How did you manage this?

And are you going to implement SHA256 ?

I simply wrote the TLS scheme :-) I've also added the neccessary 
crypto algorithms at the native level (only RSA with ARC4 cipher 
suite is supported at the moment).

IMO this solution gives us much better flexibility: the encryption 
code is native(fast) and the TLS protocol logic is in REBOL so it 
is possibel to enhance it much more easily.

(so for example we can later implement also the certificate handling 
and TLS server mode)

Sure.  not needing large libraries is a plus

SHA256: yes I'd love to add it. The only problem is to get efficient 
free C implementation.

this applies also for other algorithms so any good links are welcome

so has to be compatible license and in plain C ?

I thought I found some before

I have AES algo prepared for integration. Currently we are looking 
for good implementations of: SHA256, DH and 3DES

(I guess these pieces are missing to cover TLS 1.0 cipher suite set)

Which copyrights are incompatible?

GPL

MIT or Apache

or compatible to these.

I thin BSD can fit too.