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.
Tag: scripting language
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.
One of the features I had been meaning to get around to for some time was improvements to the logging. The original system had one enum value per error. It gets quite tedious pretty quickly when you have to write out redundant messages with only a single word changed. Since it would be nice to have the messages be localized (i.e. translated into different languages), I used an enum, but obviously, I needed to shorten the process.
The result of my long evening of work was a rewrite of part of the logging system that resulting in an easily extensible interface for which I created pretty print logging (which you can see in the feature image of this post).
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.
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?
I do love languages, and (as I wrote in my very first post on this blog) Copper has its origins in Goldfish, a language initially intended for AI. In a way, making a language was still on the bucket list, so the things I said in that post are not lie, but there is more to the story.