Problem with TRANSFER seems to be that its first use was prior to its Macro Definition. Placing the Macro Definition ahead of first use clears up the problem. But system is still hung waiting for a network connection…
- DM
On Dec 18, 2017, at 14:11, David McClain dbm@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 <dbm@refined-audiometrics.com mailto:dbm@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