Articles

"Some people don't understand the iterative nature of art, design and game design."

"Instead, they try to reach the final version on the first try and get frustrated when it's not as good as they thought."

"Aim for the best you can, but know that you will have to iterate, work on it again. Know that it'll get better on the next step!"

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.

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

"The best way to learn is to just go out and make stuff, collaborate with people who are better than you at different things, and experiment."

"That's what I've found, at least. Just be around people who are awesome and learn off them. Trade ideas around and try stuff."

"Everything I do, I've learned from friends, collaborators, people I look up to, and personal experiments. Just going out and trying stuff."

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.

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.

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!

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.

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.

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).

While preparing my next post about ooc documentation yet again, I stumbled upon an old ooc quine of mine. Here it is in integrality for your pleasure:

q := 34 as Char
l := [
"q := 34 as Char"
"l := ["
"]"
"for (i in 0..2) {"
"    l[i] println()"
"}"
"for (i in 0..12) {"
"    q print(); l[i] print(); q println()"
"}"
"for (i in 2..12) {"
"    l[i] println()"
"}"
]
for (i in 0..2) {
    l[i] println()
}
for (i in 0..12) {
    q print(); l[i] print(); q println()
}
for (i in 2..12) {
    l[i] println()
}