With library importing complete, I now need to get resolving working. This should be extremely simple, since I just need to look at the imports in an assembly context and then check the library for hashes at those paths; all of this functionality should already exist.

---

Turns out yes, it was trivial. Generating the source.co.resolve file seems to be working seamlessly. At this point I should be able to import everything.

---

Now that the lower level hurdles are out of the way, I’m running into an issue with my macro symbol transformer. I was actually trying to render macros inside of macros, but I actually will have situations where the labels in a macro are not resolvable until being rendered from a routine or assembly.

So really, I need to rethink my approach to labels inside a macro symbol, and also to how I think about linking to other macros. Labels for non-symbols should probably just be taken as is: no rendering is necessary in the symbol. For routine calls, if the name is fully resolved we link to a hash. If not, we take it as is to be resolved at render time. For macros, we do the same, but we *also* need to check if all of the parameters resolve to actually render it. If all the information is there to render, we always render.

---

This plan worked out, and now assembly works. There are still many little bugs to work through in both the assembler and the VM, and my example program still doesn’t execute to completion yet, but this was the first time that co source code compiled to bytecode that actually executed on the virtual machine. It’s all downhill (read: tooling) from here!