Progress Report #9

After some critical debugging of the recently changed runFunctionObject() (used for callbacks), I decided to add a new boolean function in the spirit of doing things fast and efficiently: xall(). This function is the equivalent of any(all(…), nall(…)) where “…” represents the same arguments. Using xall() is much less error prone (since you only need to type the argument names once) and much faster because it’s all on the C++ side.

In other news…

Advertisements

foreign.run(anytime)

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.

Introducing Cupric Bridge

Recently, I utilized the serialization interface in Irrlicht to allow Copper to create GUIs. The code for this is part of my project “Cupric Bridge”. Also in this project are bindings that allow for callbacks from different types of GUI elements.

Bug Fixes (v 6-0.51)

Branch 6, version 0.51 has a couple of important bug fixes.

An old bug in Copper that had gone under the radar for a while: The system functions “all” and “any” had been flipped in functionality. Each one was doing the other’s job. The bug was probably introduced during a rewrite of those functions.

CallbackWrapper was also fixed. The Copper callback is now disowned in the destructor so its lifetime is now correctly tied to the CallbackWrapper.

Progress Report #8

That recent change I made to speed up the processing also revealed a bug that occurred whenever a function scope was resized. This led to an overhaul of the variable storage system that may or may not have been necessary but will speed things up anyways because there are fewer function calls to make.

At the same time, I’ve decided to change some language semantics. Previously, when assigning data (such as a number) to a variable, the original function was retained, but the return was now a “constant return”. This meant that calling the function on the variable would return this “constant return” rather than the function, yet the members of the original function were still accessible. This “constant return” feature was originally designed to be a shortcut, but, ironically, it goes against the intended language design because this syntactic sugar was actually intended to be a shortcut for creating a new function. Now it will be.

Allocate Little, Gain Much

Currently, I’ve been working on bindings for Copper with Irrlicht – a project I’ll probably write about later. I started to consider how much memory I was using by creating wrappings for every little thing. Naturally, I wanted things both small yet convenient. (It’s true that it would be better just to write a native GUI for Copper, but that’s asking alot out of myself.) I wanted the easiest way to have maximum control, but Irrlicht bindings send everything through a tunnel – i.e. when you want an attribute of something, you get all of the attributes. I could dump the ones I didn’t want, but what’s the point? Isn’t it faster to just load all of them into a Copper function?

That got me thinking… how much memory are Copper function-objects actually using?

Solving the Shortcut Dilemma

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.