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 <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> 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