Blindly Coding (Posts about release)

A Libaudioverse Preview

Austin Hicks — Sun, 24 Aug 2014 13:45:00 GMT

Note: it was pointed out to me that I forgot to mention enum34 in the readme. If you were getting errors about not being able to import enum, installing enum34 (not enum, enum34) will fix them.

I haven't spoken about Libaudioverse much, primarily because I find code much more valuable than articles on a blog. You can run the former. You can use the former for cool games and technologies. But Libaudioverse is now at the point where I can and should talk about it more. So I shall. And perhaps more importantly, I have something I can release. It's not alpha-quality, thus the term preview. But it can give you a feel for what this will be, and it has some cool example programs. If you want to skip straight to the preview and not read the rest of this post, you can get the windows binaries here.

Lambdatask and Monitors in C++: Combining Advanced Language Features for a Simple Interface

Austin Hicks — Thu, 17 Jul 2014 20:00:00 GMT

Lambdatask is a project that I was hoping to put off for a while. C++11 provides many useful thread primitives, but has major shortcomings. The most notable of these is the lack of concurrent and threadsafe data structures in the standard library. I'm not sure who thought it'd be a good idea not to seriously consider at least making std::queue threadsafe, but it's not and we get to live with that.

Unfortunately, among a bunch of features that Libaudioverse needs, threadsafe queues is one of them. More unfortunately, it needs them now so I can implement callbacks properly. I have identified three reusable things that it would be incredibly useful to have, the first two of which are surprisingly simple: a monitor, a threadsafe queue, and a library for the automatic parallelization of tasks with dependencies on other tasks. These libraries exist in various forms, but my research failed to turn up any that use only C++11 features. A library using only C++11 features will run on the 5 major platforms, and more are being added as we speak.

It is monitors that I want to talk about today. The code in lambdatask marks my transition from intermediate to advanced C++ developer. This alone isn't worth a blog post, but how the Monitor<T> works in Lambdatask is. The code here took me about 3 hours to work out, and I can thank here for the idea and this Stack Overflow question for the last piece of the puzzle.

Unspoken 0.11

Austin Hicks — Wed, 09 Apr 2014 18:30:00 GMT

I've put a new release of unspoken up. This one fixes the inability of Unspoken to play sounds when the review cursor isn't following the system carrot or the system focus. It is here.

Let me know if it has bugs.

Clang_helper and the new camlorn_audio

Austin Hicks — Tue, 25 Mar 2014 21:50:00 GMT

Clang_helper, here, is now useful and is also extracting everything available in the OpenAL headers except for comments. It's still a bit rough around the edges, but is definitely workable, especially once I write a better abstraction around C types. Currently, they are strings, all be it standardized-ish ones.

C++ support is unfortunately nontrivial, and probably won't be happening soon. I believe, however, that I can get it understanding and describing C structs. The problem withC++ support is that it is incredibly hard to abstract things without losing meaningful information. As the primary purposes of this project are automatic code generation for languages supporting C FFI and automatic code generation of C functions into C++ classes, this is not a current goal.

The Camlorn_audio approach is going to be a bit unusual: wrap C++ classes into C functions automatically without human intervension, store information on them, and then spit out bindings-at all points in this process, the Camlorn_audio build system will have information on the functions it's generating for itself, and won't need to read the class. Basically, there will be some templates and some yml files, and code will come out the other end. Classes will be declared in yml instead of C++-this gives me sanity, for the moment.

That said, expect me to backtrack on this in a few months and actually implement C++ support into clang_helper. It would be cool if it could, but I am currently at a loss as to how to not lose necessary information. C++ is incredibly complex, and automated C++->C generation in the general case is a hard problem. Simple things like vector<int> start to illustrate this-what about vector<vector<int>>? How about vector<string>? Each of these quickly becomes a special marshalling case as to how to convert the data. It probably requires some sort of dynamic pipeline that can reconfigure itself, at the least. The only way it can be easily done is to limit oneself to some subset-C++ classes that make use of only pointers and C types shouldn't be so bad, and basically staying away from templates is required. Good luck on finding libraries meeting them in the wild, though. Things you can't touch include, well, the Stl. There go half the nice things in the language.

If my current rate of programming skill increase continues, I may be able to handle this in the near future. They say that the worst programmer you know is yourself from 10 years ago; the worst programmer I know is myself from 6 months ago.

Also, the point of not using swig for Camlorn_audio which already handles that difficulty: being able to do things Swig can't, by storing meaningful information (for example, throwing exceptions in languages that support it and being able to not need precompiled C extensions for some things). The meaningful information is not included with C++.

I stand at the point of being able to begin on the Camlorn_audio rewrite, and believe that it will go much faster than the first time. It will probably also be an order of magnitude smaller: the scripts to generate things should be on the order of a few hundred lines, not a few thousand. It will still depend on Boost for the time being, as well as Libsndfile (removing the Libsndfile dependency is a goal; there's no good way around Boost until everyone has C++ 11 capable compilers). I will probably not use SCons. I might write my own small build system, as I've probably got a fairly major nonstandard build step.

In regards to the MMO: I'm trying to get this done first, as the MMO keeps running up against "X needs to be a feature in Camlorn_audio". Most notably, callbacks. I'll discuss my plans for dealing with callbacks another time once I finish figuring them out.