World: r3wp

you mean like an xor type thing?

I don't know exactly, but I remember reading that its not a real 
encryption system.

I had just found something via  search it looked like Carl was question 
about it and answered something along the lines of XOR.  Not sure 
if the function has evolved since then or not.

ok Thanks Maxim.

Encloak  -- http://www.rebol.net/cookbook/recipes/0023.html-- Carl 
says


Newer versions of REBOL include "cloaking" functions for encrypting 
and decrypting strings. These functions do not provide full strength 
encryption such as Blowfish, AES, or RSA as found in REBOL/Command, 
nevertheless they can be useful for hiding passwords and other values. 
(That's why we call it cloaking rather than encrypting.)

so basically, usefull for hidding data from familly and friends, 
but not from your neighbourhood (or company) hacker  ;-)

well, the safety of XOR is the safety of the passphrase. if it is 
random and same length as data, then it's the safest possible. :)

There are things stronger than encloak in the Library

http://www.rebol.org/cgi-bin/cgiwrap/rebol/search.r?find=encryption

Am I correct is assuming that data is more apt to actually be written 
to disk using write/direct than using write with the direct refinement?

with = without

No, /direct just allows control of rebol's memory buffer. Rebol goes 
out to the host filesystem via host OS API calls. The host filesystem 
may still not actually write the data to disk immediately. To be 
sure of an immediate write, you would flush the disk cache, using 
a mechanism provided by the host OS and filesystem. (eg. in WinXP, 
if you disable one of the harddisks, it flushes the cache, then spins 
the disk down. There must be another way to flush the disk, but I 
never learned that.)

in principle, there should be little difference. since write always 
creates a new file, and immediately closes the file port, they should 
basically be the same. I also assume that /append implies /direct 
in some way.

Since Rambo #3739 is still around, I never use write/append, but 
my own version with open/seek.

Anton and Gabriele, thanks.

>> age: 28-Dec-1923
== 28-Dec-1923
>> difference now age
** Math Error: Math or number overflow
** Near: difference now age

It appears to be a problem with the +-50 year window around the current 
year which Rebol uses to assign the century to two-digit years:

>> date-of-birth: 28-dec-1923
== 28-Dec-1923
>> age: func [dob [Date!] /local cutoff] [
[    cutoff: now
[    cutoff/year: cutoff/year - 50
[    either dob < cutoff [
[        return (now - cutoff) + ((cutoff - 1) - dob)][
[        return now - dob]
[    ]
>> age date-of-birth
== 30262

The calculation of the cutoff is not quite correct as on checking 
I found that Rebol sets the 50 year window at the start of the current 
year not from the current date.

>> date-of-birth: 28-dec-1923
== 28-Dec-1923
>> age: func [dob [date!] /local cutoff] [
[    cutoff: 1-1-06
[    cutoff/year: now/year - 50
[    either dob < cutoff
[    [return (now - cutoff) + ((cutoff - 1) - dob)]
[    [return now -dob]
[    ]
>> age date-of-birth
== 30262

should this be rambo'd ?

If not in Rambo already, yes.

graham, i think the problem there is that time! values cannot hold 
that much hours.

>> now - 28-dec-1923
== 30263

(days)

>> difference now 1-nov-1938
== 596192:12:37

there's probably not much more room than some 600k hours.

When I did a date-to-epoch func, I used ATTEMPT with DIFFERENCE and, 
if that failed, used subtraction to get the number of days, then 
multiplied by 86400.0.

time fot 64 bits ints.... and people asked... do we need them?

I'm not sure this issue means we need 64-bit ints.

by all accounts, time is expressed in seconds internally .  and guess 
what! 600000 hours is 2.16 Gs..  just above 2^31 (2.14 Gs)..   so 
if we had 64 bits, then we could hold the date and calculate it with 
other values.

now/precise

precise add floating point sub seconds.

I think the minimum time unit is milliseconds - thousandths of a 
second.

Is time quantisized? ;-)

Anton, that might be right under Windows. I think, under UNIX (Linux, 
OS X, etc.) the minimum time unit is less than that. Under OS X:
>> now/time/precise
== 17:28:10.349125

That's interesting. I don't know about OS X, but that *could* be 
just the rebol OS X beta molding of the seconds floating point number.

time really is quantized depending on the OS. XP SP 2 has got a bigger 
quantum than XP SP 1, which was 10 milliseconds IIRC

Linux has much more precise timer (or it just simply returns more 
digits for now/time/precise)

not just more digits, it has got a "lower basic quantum" too

Max, what I mean is that this isn't a showstopper. Adding 64-bit 
ints for this case doesn't seem worth it. There are other, more important, 
reasons to go there; I just don't think this issue is that important.

OUCH !!! to-integer error! 

>> to-integer "2147483648"
==  2147483648.0

@ Gregg: well it depends on what you are doing.  any serious date 
management will eventually break if its trying to calculate anything 
remotely old  :-(


having to work around something as basic like this is anoying.. (although 
like you say, possible)

I just ramboed my discovery, as I did not find any reference to it 
in searching to-integer

this is a very dangerous bug for any dialect writer... beware!

to-integer - what do you want to get?

an error! obviously.

It will only break if you try to do it this way. I haven't heard 
of many places where this is an issue, and it isn't hard to work 
around if you really need to.

if I try to use the decimal and converting it to integer it will 
return the error.

to-integer  2147483648.0
** Math Error: Math or number overflow
** Where: to-integer
** Near: to integer! :value

so we must not allow different type! representation of a value be 
considered different through the most basic type converting natives.

its an issue when you load data and make a dialect loader.  It just 
fucked up a week's work ... now I have to completely change the way 
I handle Integers...  had this broken early on, it would not even 
have slown me down.

:-(

I have to agree that this is not correct behavior.