World: r3wp
[Core] Discuss core issues
older newer | first last |
Anton 3-Nov-2006 [5959] | 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.) |
Gabriele 3-Nov-2006 [5960] | 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. |
sqlab 4-Nov-2006 [5961] | Since Rambo #3739 is still around, I never use write/append, but my own version with open/seek. |
Louis 4-Nov-2006 [5962] | Anton and Gabriele, thanks. |
Graham 4-Nov-2006 [5963] | >> age: 28-Dec-1923 == 28-Dec-1923 >> difference now age ** Math Error: Math or number overflow ** Near: difference now age |
PeterWood 4-Nov-2006 [5964x3] | 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 | |
Graham 4-Nov-2006 [5967] | should this be rambo'd ? |
Anton 5-Nov-2006 [5968] | If not in Rambo already, yes. |
Gabriele 5-Nov-2006 [5969x5] | 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. | |
Gregg 5-Nov-2006 [5974] | 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. |
Maxim 5-Nov-2006 [5975] | time fot 64 bits ints.... and people asked... do we need them? |
Gregg 6-Nov-2006 [5976] | I'm not sure this issue means we need 64-bit ints. |
Maxim 7-Nov-2006 [5977] | 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. |
Anton 7-Nov-2006 [5978] | now/precise |
Maxim 7-Nov-2006 [5979] | precise add floating point sub seconds. |
Anton 7-Nov-2006 [5980] | I think the minimum time unit is milliseconds - thousandths of a second. |
Geomol 7-Nov-2006 [5981] | 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 |
Anton 7-Nov-2006 [5982] | 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. |
Ladislav 7-Nov-2006 [5983] | 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 |
Pekr 7-Nov-2006 [5984] | Linux has much more precise timer (or it just simply returns more digits for now/time/precise) |
Ladislav 7-Nov-2006 [5985] | not just more digits, it has got a "lower basic quantum" too |
Gregg 7-Nov-2006 [5986] | 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. |
Maxim 7-Nov-2006 [5987x4] | 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! | |
Ladislav 7-Nov-2006 [5991] | to-integer - what do you want to get? |
Maxim 7-Nov-2006 [5992] | an error! obviously. |
Gregg 7-Nov-2006 [5993] | 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. |
Maxim 7-Nov-2006 [5994x4] | 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. | |
:-( | |
Henrik 7-Nov-2006 [5998] | I have to agree that this is not correct behavior. |
Maxim 7-Nov-2006 [5999] | the data is not of REBOL origin. and has to be spitted out the same, cause it will break the external tool's understanding of the value... |
Gregg 7-Nov-2006 [6000x2] | What's the actual issue? I agree that it's not correct, but maybe there's an easier way to solve your current problem. |
Or maybe we can all learn what not to do if we try something similar. | |
Maxim 7-Nov-2006 [6002x3] | I can work around it (obviously).. but its just a core REBOL consistency issue. its semantically unacceptable for a function called to-INTEGER to return anything else than an integer. imagine if to-string decided to return words sometimes... its the same dangerous issue. |
many places this can be a total fuck up imagine this: as-integer: func [value][ any [ attempt [to-integer value] 0 ] ] here we end up with a broken logic and impending doom...not of our fault. | |
so for now, we should all do this IMHO: to-integer to-integer value | |
Ladislav 7-Nov-2006 [6005] | how could that help you? |
Maxim 7-Nov-2006 [6006x2] | it raises the error overflow error. |
the way to-integer is implemented right now it should be called to-number | |
Gregg 7-Nov-2006 [6008] | to-integer is consistent as long as the value being given to it is within the bounds of 32-bit integer; outside that range, all bets are off. Your solution isn't going to help you, or catch other errors, e.g.: >> to-integer to-integer "2147483646344.0" == -1656 >> to-integer to-integer "2147483648343.0" == 343 |
older newer | first last |