Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(require osc) fails on 32-bit arm (e.g. raspberry pi 2), possibly x86 as well #5

Open
yurkobb opened this issue Jul 15, 2023 · 5 comments

Comments

@yurkobb
Copy link

yurkobb commented Jul 15, 2023

The following line in osc/osc-time.rkt fails on raspberry pi 2 (debian buster, racket 7.2):

;; seconds are measured since January 1, 1900, GMT, meaning
;; that they'll run out in 2036 or so. Oh well.
(define OSC-EPOCH-SECONDS (find-seconds 0 0 0 1 1 1900 #f))

With the following error:

pi@raspberrypi:~ $ racket
Welcome to Racket v7.2.
> (require racket/date)
> (find-seconds 0 0 0 1 1 1900 #f)
; find-seconds: non-existent date
;   wanted: (0 0 0 1 1 1900)
;   nearest below: -2147483648 is (52 45 20 13 12 1901)
;   nearest above: -2147483647 is (53 45 20 13 12 1901)
; [,bt for context]

I worked around by hard-coding the value -2208988800 instead, and the package works fine. Maybe it does make sense to simply use the fixed value?

@jbclements
Copy link
Owner

I just tried and failed to reproduce this on a VPS running Debian Buster & Racket v7.2:

root@super-tmp:/usr/racket/bin# cat > /tmp/foo.rkt
#lang racket

(require racket/date)

(find-seconds 0 0 0 1 1 1900 #f)
root@super-tmp:/usr/racket/bin# ./racket /tmp/foo.rkt
-2208988800
root@super-tmp:/usr/racket/bin# ./racket -v
Welcome to Racket v7.2.
root@super-tmp:/usr/racket/bin# cat /etc/debian_version
10.13

... so it appears to me that this might actually be a problem with your raspberry pi, or at a minimum some interaction between your raspberry pi and racket and the operating system. There's clearly also something very fishy about the fact that -2147483648 and -2147483647 both map to December 13, 1901.

@yurkobb
Copy link
Author

yurkobb commented Jul 17, 2023

I just tried and failed to reproduce this on a VPS running Debian Buster & Racket v7.2:

Was it x86 or x86_64?

My hypothesis was that, according to the documentation of find-seconds:

If the platform cannot represent the specified date, an error is signaled, otherwise an integer is returned.

...since 1900 can't be represented by a 32-bit time_t (the lowest value, according to Wikipedia, is Friday 1901-12-13), it might be returning the error only on 32-bit systems.

@yurkobb
Copy link
Author

yurkobb commented Jul 17, 2023

Reproduced on debian buster x86 running in a container:

$> podman run --name debian-x86 -it --rm --arch i386 debian:buster
root@75b690b95ea0:/# apt update && apt install -y racketapt update && apt install -y racket
<...>
root@75b690b95ea0:/# racket
Welcome to Racket v7.2.
; Warning: no readline support (ffi-lib: couldn't open "libedit.so.3" (libedit.so.3: cannot open shared object file: No such file or directory))
> (require racket/date)
> (find-seconds 0 0 0 1 1 1900 #f)
; find-seconds: non-existent date
;   wanted: (0 0 0 1 1 1900)
;   nearest below: -2147483648 is (52 45 20 13 12 1901)
;   nearest above: -2147483647 is (53 45 20 13 12 1901)
; [,bt for context]

Same with debian unstable & racket 8.7.

@jbclements
Copy link
Owner

Ah! My fault, missed the 32-bit information, should have read the title of the issue and not just the comment text.

My inclination would be to trap this error and return the hard-coded constant only when the date 1900 can't be found, does that make sense to you?

@yurkobb
Copy link
Author

yurkobb commented Jul 23, 2023

My inclination would be to trap this error and return the hard-coded constant only when the date 1900 can't be found, does that make sense to you?

Yeah, sure!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants