As someone pointed out, I used the macro transfer before defining it accidentally. Sorry about, I’ve fixed that in the next version.
— Burton > On Dec 18, 2017, at 2:11 PM, David McClain <d...@refined-audiometrics.com> > wrote: > > okay, my bad… I see that the TRANSFER is part of a CASE construct. But here > is the error on initial compile buffer: > > The call (#<Function TRANSFER 422001358C> #(58 EF D8 12 7C 50 5F 84 C4 53 B3 > DE EB 5E 5 8 CB E2 ED B7 D2 75 7C 34 1D DD 8 6 C0 74 8B 5F B3 13 91 D3 BD A7 > FB E4 ...) #(5F 80 7 5C C6 4E 24 BE 27 > EA EB DE 93 B5 92 E5 27 FF BF 37 40 90 63 D0 F5 38 D5 0 DA 6E 15 62 FA B5 CC > 5 84 CC C5 A5 ...) 1) does not match definition (#<Function TRANSFER > 422001358C> FROM TO VALUE). > > Debugger points to MINE. Happens during COMPILE-FILE. > > - DM > > >> On Dec 18, 2017, at 13:49, David McClain <d...@refined-audiometrics.com >> <mailto:d...@refined-audiometrics.com>> wrote: >> >> seems to be a problem with the use of TRANSFER here: >> >> >> (defun process-coin-server-request (stream) >> (let ((request (read stream))) >> (case request >> (transfer (process-transfer-request (cdr request) stream)) >> (execute (process-execute-request (cdr request) stream)) >> (blocks (process-blocks-request (cdr request) stream))))) >> >> Also redefines BLOCK and so we probably need to declare shadowing at the >> top. >> >> Not sure what the quickload stuff was trying to accomplish, but my resident >> version of Ironclad kept shadowing anything imported by quickload. No SHA3 >> digest in my resident version, so I replaced it (for now) with the bleeding >> edge version from GitHub. That worked, as far as I can tell. >> >> Actually had to compile buffer twice in order to get past the TRANSFER error >> (not sure why that even works?) but the system appears to be hung waiting >> for some kind of network connection. Perhaps you could give us a usage hint? >> >> Cheers, >> >> - DM >
