Custom Query (1030 matches)
Results (526 - 528 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #679 | fixed | (expt 2 #c(-2d0 -1d0)) inaccurate | ||
| Description |
CCL 1.4 and 1.5 (32 bit) on Mac OS X 10.5 gives
The correct answer should be closer to
as produced by cmucl and clisp. Perhaps a contagion problem? |
|||
| #680 | fixed | ccl:send-to says it can take a string arg, but it really can't. | ||
| Description |
Welcome to Clozure Common Lisp Version 1.6-dev-r13678M (DarwinX8664)! ? (defparameter *s* (make-socket :type :datagram)) *S* ? (send-to *s* "hey" 3 :remote-host "127.0.0.1" :remote-port 12345) > Error: value "hey" is not of the expected type (OR (ARRAY CHARACTER) > (ARRAY (UNSIGNED-BYTE 8)) > (ARRAY (SIGNED-BYTE 8))). > While executing: VERIFY-SOCKET-BUFFER, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > verify-socket-buffer is actually checking for an 8-bit subtag, and with this new-fangled unicode thing, that doesn't include strings. My first inclination is to say that i/o on datagram sockets is done in octects. This requires the user to use encode-string-to-octects/decode-string-from-octets explicitly. It might also be work to pay attention to the socket object's external format and encode the string on the user's behalf, but if Gilgamesh wants to send a cuneiform string "foo", then the actual buffer length in octets isn't going to be 3. |
|||
| #681 | invalid | Error rebuilding 64bit ccl on ubuntu 10.4 | ||
| Description |
Running (rebuild-ccl :full t) leads to m4 -DLINUX -DX86 -DX8664 -DHAVE_TLS -I../ ../pad.s --64 -o x86-spjump64.0 (and 2 other calls to m4) /bin/sh: m4: not found (then much cc -c and repeated complaints about not finding m4) then many undefined references starting with get_mxcsr Just before make: quits there is collect2: ld returned 1 exit status |
|||
