Articles
Articles are single-page pieces that give a whirlwind tour of a specific topic.
They’re different from series, which go very in-depth, taking many detours.
Damian Sommer on The Yawhg
Damian Sommer did a casual AMA on Reddit recently, about his upcoming game, The Yawhg. I got to ask him a few questions. Here’s what he had to say.
What brought you out of your usual “let’s make fucked up platformers” style?
“I was just kind of tired of them. There’s still one more platformer I really want to finish, (The Clown Who Wanted Everything), but besides that, I’m just extremely bored of them now.”
The iterative nature of art
sam 0.2.0 released
Today I decided to release sam 0.2.0. There are only a handful of new features in there but it’s still releaseworthy! See the previous sam announcement for more information on the tool itself.
Source path and lib folders
Let’s take a look at what sam tells us when launching it.
sam version 0.2.0
Usage: sam [update|get|status|promote]
Commands
* update: update sam's grimoir of formulas
* get [USEFILE]: clone and/or pull all dependencies
* status [USEFILE]: display short git status of all dependencies
* promote [USEFILE]: replace read-only github url with a read-write one for given use file
* clone [--no-deps] [REPONAME]: clone a repository by its formula name
Note: All USEFILE arguments are optional. By default, the
first .use file of the current directory is used
Copyleft 2013 Amos Wenger aka @nddrylliog
oocdoc, Part 4 — sourcepath
In the previous article, We’ve built a nagaqueen-based tool that can parse one ooc file, detect class declarations and print its doc strings. Today, we’re making a bit of infrastructure for our app to support more sizable projects.
Source path and lib folders
Parsing a single file was a nice milestone, but it’s not nearly enough. We want to generate documentation for a whole project at a time: and since we’ll want to cross-link the various bits of documentation we generate, we’ll also need to parse the various dependencies (such as the ooc sdk, and any used library) so that we can resolve argument types and link them properly.
The best way to learn
oocdoc, Part 3 — parsing
In the previous article, I gave brummi a go. However, we’ve seen that it still doesn’t fit our requirements: we need a tool that’s fast, easy to install and configure, produces beautiful and usable docs.
Yesterday I started building my own documentation generator, and in this series I’ll present the challenges I face and how I solved them. This might show a few ooc tricks, perhaps some software design, some good, some bad, but overall I hope it’ll be a good read!
The shortest ooc quine
A few days ago I posted an ooc quine. But while browing HackerNews, I found an even shorter one. The shortest!
Here it is, in its full glory
Can’t see anything? That’s an empty file. It will compile and run just fine. ooc doesn’t require a main function - you can just shove code in there that will run at the program’s initialization. If there’s none, no big deal! It’ll just not run anything.
oocdoc, Part 2 — brummi
In the previous article, we saw how to use NaturalDocs, a language-agnostic documentation generator. Today we’ll see how to use brummi, a tool specific to ooc, written by Friedrich Weber.
Generating .json files
The first step to generate docs using brummi is to use rock,
to generate a set of .json files describing the code. The --backend
command-line option allows to select which backend you want rock to use
(the C backend is the default).