Bytecode is great for tiny domain languages and I use them in many projects.
Ultima IV used one to animate sprites on it's title screen map. For the next version of XU4 I implemented three bytecode interpreters to script the entire title sequence. There's a high level presentation interpreter, a GPU rendering interpreter, and one for the Ultima IV bytecode.
The website is completely broken with Firefox. Search results do not appear on the screen - you must scroll down to see results. Clicking on the asset images does nothing so they cannot be downloaded.
When using Chrome the layout and interaction works, but even then browsing is a poor experience as only four items can be seen at once so lots of scrolling is needed.
Sheesh... modern web design is a disaster. This sort of collection could really use static pages with labels as links and small thumbnails showing at least 50 items per page.
Sorry to hear that. We don't have a developer on the team. Lennart (from AmbientCG) has great skills in development, and he perfected their website. We're hiring freelancers to update our website, but with limited resources. Still, we're always looking for ways to improve our website for our users.
The most desired C++ feature I'd like to see is the automatic typedef'ing of structures. Does anyone know why such a fundamental thing hasn't been implemented yet?
C++ doesn't exactly do "automatic typedef'ing of structures".
The difference is that in C++, if you define a type "struct foo", you can refer to it either as "struct foo" or as "foo" (likewise for class, union, and enum).
In C, if you define a type "struct foo", its name is "struct foo". If you want to call it "foo", you have to define an alias using "typedef".
Personally, I see "struct foo" as a perfectly valid name. I seldom feel the need to define another name for it. (typedef is the only way that a C type's name can be a single user-defined identifier; "int", "char" et al are keywords.)
I'll define a typedef for a struct type only if the code that uses it shouldn't know that it's a struct type.
Yes, it's a little extra typing. I save up the keystrokes I save by typing "{" rather than "BEGIN" and use them to type "struct". 8-)}
This is a matter of personal taste, and if you want to call it "foo", there are common idioms for doing that.
So you want Vec to refer to struct Vec but only if there is no other type Vec defined before or until one is defined later? That would work, but might be a bit confusing.
C++ has struct & typedef and things work quite naturally. It always seemed like an obvious thing to bring to C, but I'm not sure about the nuances of the rules governing this.
Could you please give an example of what would break? Perhaps I'm being dense, but it seems a new C standard supporting this would still compile existing code just as C++ can.
Yes, that declarative style makes more sense to me than a forwards build statement of steps.
I developed my own tool for building C/C++ projects which follows this style. It automatically handles things like Qt moc and scans the source files for headers, so in your example even the hdrs line can be omitted.
Recently someone has been trying to build a Nix package of an open source game I maintain, so I had a brief look at the project.
It does appear to be an experiment in package management that got out of hand.
Basic usability is lacking, as I was unable to even get a listing of available packages on a NixOS virtual machine due to nix-env requiring well over 1GB of RAM. This flagrant waste of resources doesn't inspire confidence in the quality of the tools.
I'd rather see existing packaging data leveraged rather than adding a new language to the mix. Something like a translator or interpreter for RPM .spec files, for example.
Listing all packages is a bit of a weak spot. The entire package set is described in a lazy, functional language and listing or searching it requires evaluating the entire thing. A normal build will only require evaluating a small subset of the entire package list. `nix search` should have caching of results but it still requires evaluation to be populated.
Good stuff. I may make use of the .ini parser as my current one doesn't handle sections.
There are a growing number of stand alone support modules in my projects that I need to publish as a collection some day. Here's a couple links to some of them:
Ultima IV used one to animate sprites on it's title screen map. For the next version of XU4 I implemented three bytecode interpreters to script the entire title sequence. There's a high level presentation interpreter, a GPU rendering interpreter, and one for the Ultima IV bytecode.