freenode/#mezzano - IRC Chatlog
Search
12:08:19
froggey
iirc it expects keyboard scancode set 1, with translation enabled in the controller
13:32:21
froggey
no, they shouldn't sleep. they should poll the status port until the timeout has elapsed
13:34:26
fitzsim
OK, the buffer cleaning code I added sleeps 1ms between polls, and polls up to 400 times before giving up
13:35:52
fitzsim
yeah, I was more confirming the use of (safe-sleep 0.001) is OK to use in this context
14:28:29
fitzsim
fittestbits__: for the hardware I'm on, which is UHCI-based, USB input devices don't work yet
20:05:45
froggey
fitzsim: sorry, calling safe-sleep isn't going to work. it needs interrupts enabled but ps/2-input-wait is called from inside a without-interrupts section
20:33:29
fitzsim
I am using it in the controller reset logic, but I didn't do any interrupt disablement there
21:35:20
fittestbits__
fitzsim: I'm not planning to work on UHCI any time soon. So if someone else wants to work on it that would be great. But I do expect to work on it at some point.
21:36:48
fittestbits__
froggey: I'm running into a problem building the cold boot image. I have some new code: (setf (get :integer 'encode-binary) #'(lambda ...)).
21:37:41
fittestbits__
I'm getting the error: The function (COMMON-LISP:SETF COMMON-LISP:GET) is undefined.
21:38:35
fittestbits__
I did have to wrap an (eval-when (:compile-toplevel. ...) ...) around it. As a macro uses those functions.
21:44:22
froggey
fittestbits__: is that at the file top level? wrapping the setf in a function and calling that instead should work
21:45:11
fittestbits__
Yes, it is at top level. OK, so wrap it in a function, then call the function from top level?
21:46:21
froggey
top-level forms get expanded by the cross-compiler's macroexpand, but the bodies of functions evaluated at compile time use the host's macros
21:46:52
froggey
on mezzano (setf (get ...)) expands to a call to (setf get), but other implementations do things differently and it ends up not working right
21:48:00
froggey
but I'd also strongly recommend against using plists at all as they can't be made thread-safe
21:50:27
fittestbits__
Hmm. Interesting. Makes sense. Thanks. I'll have to think about switching to a hash table.
21:52:09
froggey
internally plists are implemented using a hash-table anyway, so there's not going to be any performance difference
21:52:45
fittestbits__
The code I'm working on is a macro which defines a class along with some functions for converting between the class variables and a byte array.
21:53:37
fittestbits__
The basic code comes with conversion routines for standard types, unsigned-byte 16, unsigned-byte 32, etc.
21:54:41
fittestbits__
But I wanted the user to be able to add additional types, for example, crc-32 over some portion of the buffer, that is application specific.
21:55:51
froggey
maybe a generic function with methods that using eql specializers would work better?
21:57:52
froggey
actually that won't work if you're doing it at cross-compile-time, generic functions don't work there
21:59:16
fittestbits__
Not even using the same trick of wrapping the definitions in side a function?