[Chicken-users] srfi-19 time, flonums and s11n

[Shawn Rutledge]

I'm looking into ways for Scheme processes to communicate with each
other.  s11n caught my eye.  It's pretty cool in general.  One of the
first things I'm trying to write is a daemon which handles input from
/dev/input/* and provides events to another process which connects.
For the first version I just pass ASCII s-expressions back and forth,
but would prefer some compact efficient binary format.

Unix timestamps are annoying in Scheme because nowadays they take up
most of a 32-bit unsigned int, so it won't fit in a fixnum.  If I want
to pass a timeval from a C function to Scheme, I see that the
unsigned-integer32 datatype gets converted to a flonum by default:

(define (keyboard-cb kbID timeSeconds timeMicroseconds keyCode keyState)
        (printf "~a.~s: keyboard ~s key ~s state ~s~%" timeSeconds
timeMicroseconds kbID keyCode keyState)
...)

(define-external (cbKey (int kbID) (unsigned-integer32 timeSeconds)
(unsigned-integer32 timeMicroseconds) (int keyCode) (key-state
keyState)) void
        (keyboard-cb kbID timeSeconds timeMicroseconds keyCode keyState))

[fic-gta01][07:01:36 AM] ./dsinpd
waiting for connections on port 8888
connection accept from 192.168.0.200:52855; total 1 connections
0: fd 5: /dev/input/event0
   Supported event types:
      Event type 0x00  (Synch Events)
      Event type 0x01  (Keys or Buttons)
      Event type 0x05  (Unknown: 0x0005)
1: fd 6: /dev/input/event1
   Supported event types:
      Event type 0x00  (Synch Events)
      Event type 0x01  (Keys or Buttons)
      Event type 0x03  (Absolute Axes)
   tslib re-opened touchscreen as fd 6
2: fd 7: /dev/input/event2
   Supported event types:
      Event type 0x00  (Synch Events)
      Event type 0x01  (Keys or Buttons)
      Event type 0x16  (Power Management)
1188666180.0.222893: keyboard 0 key 169 state key-press
1188666180.0.425533: keyboard 0 key 169 state key-release

[proton][11:52:36 PM] telnet moko 8888
Trying 192.168.0.202...
Connected to moko.
Escape character is '^]'.
; dsinpd 0.0.1
(enqueue
  (make-event-kb
    'time
    (make-time time-utc 222893000 1188666180.0)
    'kbID
    0
    'keyCode
    169
    'keyState
    'key-press))
(enqueue
  (make-event-kb
    'time
    (make-time time-utc 425533000 1188666180.0)
    'kbID
    0
    'keyCode
    169
    'keyState
    'key-release))

I can (use numbers) and do inexact->exact but... yuck.  I also see
that just doing (use srfi-19) causes numbers-base.so to be loaded.

#;2> (define t (make-time time-utc 648571000 1188660221.0))
#;3> (bignum? (time-second t))
#t

So it uses bignums internally.

It would be nice if there were a way to keep 32-bit numbers that have
been received from C, store them that way inside the time object, pass
them across s11n that way, and only convert to bignum when you call
(time-second).  (And I assume some day Scheme will be using 64-bit
ints, when 32-bit machines are obsolete; so then bignums will no
longer be necessary to store the time, and it will also take care of
the problem with the year 2032.)

(define outp (open-output-port "s11n.dat"))
(define t (make-time time-utc 648571000 1188660221.0)
(serialize (cons 'time t) outp)
Error: (serialize) unable to serialize object - can not serialize
pointer-like object: 1188660221

So s11n doesn't handle bignums, apparently.

Maybe a time object could use a byte vector internally?

If they could have specified it with microsecond resolution rather
than nanoseconds, it could be stored internally with minutes and
microseconds-past-the-minute, and each number would fit in 28 bits.

Another workaround I'm considering is to use another binary data
format I came up with, and create it in C where 32-bit ints are OK.
Only the receiving process would need to decode the int into a bignum.

But it's still gross that I simply want to put a timestamp on every
event that will go into some sort of event queue, and for that I have
to use a bignum.

Could pick a different "zero day" - use seconds since 2000 rather than
since 1970.  By the time the problem recurs, hopefully fixnums will
always be 64-bit (or more).