Tag: Copper

Build Apps with Curri and Cupric Bridge, Now Online!

Good news! CupricBridge and Curri are now online! CupricBridge is a wrapper for the Irrlicht engine GUI system, but it also provides a serialization interface implementation that will work with scene objects. Curri is a project containing the boilerplate code for creating applications with Copper, CupricBridge, and Irrlicht engine.

Continue reading “Build Apps with Curri and Cupric Bridge, Now Online!”

Progress Report #10 – Filling in Gaps

New changes this week in Copper fill in some of the gaps that show up when trying to use Copper for real-world projects. The first of these is the indication of the support of multiple interfaces, which solves the dilemma of distinguishing between polymorphic objects turned into Copper objects. The second is the addition of a system function that enables the sharing of user-created function bodies.

In other notes, the string_map extension received a bug fix for not correctly returning when “exit” was called in the middle of the callback function it was given.

Continue reading “Progress Report #10 – Filling in Gaps”

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…

Continue reading “Progress Report #9”

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.

Continue reading “Progress Report #8”