RE: [racket-users] second->date

: Re: [racket-users] second->date There was an overflow problem in the part that tries to prepare a 64-bit value to put into the 32-bit halves of `FILETIME`. I've pushed a repair. Thanks for the report and help! At Fri, 19 Feb 2016 18:06:55 -0500, Jon Zeppieri wrote: > Er, no. Dis

Re: [racket-users] second->date

There was an overflow problem in the part that tries to prepare a 64-bit value to put into the 32-bit halves of `FILETIME`. I've pushed a repair. Thanks for the report and help! At Fri, 19 Feb 2016 18:06:55 -0500, Jon Zeppieri wrote: > Er, no. Disregard that. That'll teach me to talk about the Wi

Re: [racket-users] second->date

seconds->date: > (seconds->date (sub1 (expt 2 50)) #f) (date* 3 57 18 25 9 35680317 2 267 #f 0 0 "UTC") ... the results are the same. -Jon > > > -- > *From:* Jon Zeppieri [mailto:zeppi...@gmail.com] > *Sent:* viernes, 19 de feb

RE: [racket-users] second->date

tly) 35680317? Jos _ From: Jon Zeppieri [mailto:zeppi...@gmail.com] Sent: viernes, 19 de febrero de 2016 23:31 To: Jos Koot Cc: Racket Users Subject: Re: [racket-users] second->date I'm not especially familiar with the code in question, but it looks to me like some time-handling

Re: [racket-users] second->date

Er, no. Disregard that. That'll teach me to talk about the Windows API when I know nothing about it. Apparently, the FILETIME type is divided into two 32-bit values. At any rate, there is a bug, but I don't know where it is. -Jon On Fri, Feb 19, 2016 at 5:31 PM, Jon Zeppieri wrote: > I'm not

Re: [racket-users] second->date

I'm not especially familiar with the code in question, but it looks to me like some time-handling code in fun.c assumes 32-bit values. I'm referring to this: [ https://github.com/racket/racket/blob/50db01bf2c7c57fd5c7c662307d517ce2c29c279/racket/src/racket/src/fun.c#L9981 ]. On a 64-bit system, mz