dragoncoder047

Aha! Maybe is something else. I also uncommented the `Serial.println` debugging statements and they produced this output: ``` 8990> (defmacro foo (aa bb) `(defmacro ,aa () `(princ ,,bb))) foo 8956>...

> I'm not very good at debugging other people's code, and I don't really understand Dave Astel's routines, but I had a look at it and couldn't see anything obviously...

And I also forgot to mention this earlier -- @technoblogy if it is possible (I can't) this issue should probably be moved to my repository as opposed to this one...

> Sorry, I'm not sure how to do that in GitHub. I have been able to move issues between other repositories **I** own (there would be a "-> Transfer this...

I took another look and noticed some [missing GCStack pushes](https://github.com/dragoncoder047/ulisp-esp32/blob/104b85436f59cb0d7d2e4d2e046b708944cdcd72/ulisp-esp32.ino#L5051) in the section added to `eval()` that handles macros, and yet it still produces this bug. @dastels, would you mind...

> GCStack has been there from the beginning, but perhaps a problem has arisen due to the change to long symbols. Now that I think of it, long symbols existed...

> Are you sure that @dastel's code was finished and fully functional? Do you have examples showing it working on an earlier version of uLisp? If not, I'm not sure...

> it gives an error on LispWorks Common Lisp. Probably because: * he used `@` as a replacement for `,@` since he didn't bother with the the `LastChar` jiggery needed...

Whether it ends up in official uLisp or not, I found that @Goheeca and @m-g-r implemented `(unwind-protect)` and a few other error-related functions. See these two links: * https://github.com/Goheeca/redbear_duo-uLisp/commit/4894c13 *...

Duplicate of #24. there is a patch there already.