Up to this point, the foreign function system did not allow using callbacks via Engine::runFunctionObject() until after Engine::execute() or Engine::run() (which calls Engine::execute()) had completed. My recent update changes that and makes recursive execution of opcodes easier.
For the second time, I’m changing the foreign function interface. (Actually, I already did.) It’s a rather sudden announcement, but since no one else besides me is using the language that I know of, I can get away with things like this.
Pointers are always a pain. I have found the only safe ways to work with them that both avoids memory leaks and segfaults. Unfortunately, there are some things lost that even ruin some expectations in Copper.
My old documentation was hand-coded in HTML. I thought that would be the right way to go at first because, after all, the language was “simple”. Then again, how can anything be simple when it’s over 6000 lines of code? Having become tired of coding documentation, I decided to switch to markup, and with a shiny new logo and a nice docs generator, I now have more professional-looking documentation on Github.
In addition to a memory-saving function for adding foreign functions and a new system function for returning members in a list, Copper now has stack tracing!
Every good interpreted language needs to have a way to add hooks. Copper used to have one a long time ago, but it hadn’t been rewritten when I made significant changes to the engine. As of today, the callback system has been rebuilt and working!
Floating new objects are those things you create on the heap and then toss around your program as if they weren’t tied to any particular location. It’s nice to delegate the job of specific object creation to some function and have it return the packaged data with a special interface for accessing only the parts we need. … Or in other words, object factories. Object factories require the heap.