A hackers guide would be good. Just more we need help with. The wiki could use more tutorials too.

I believe there's an unofficial todo on the wiki and one in the source?

Grepping for todo is epic fail.

c:\mingw\LIBS\A5GIT\allegro>grep -r -E -I -n "todo" .\*.*
.\demos/speed/speed.txt:137:Still todo: more interesting enemy movememnt, you dying.

c:\mingw\LIBS\A5GIT\allegro>

Seriously, things that need to be done in the code should be marked with a TODO somewhere or be on an official list somewhere.

NuGet isn't all that awesome. It's nothing like package managers as *nix users understand them. It's more or less just an "app store" for Visual Studio add-ons. I don't think it would be a good way to distribute Allegro (for one, you'd still have to build all of the dependencies and bundle them inside it, unless you want to create and maintain different packages for each dependency). MSYS2 is probably a better solution to that problem, but I haven't tried it yet.

I have created an Xcode project template: https://github.com/arvidsson/Allegro-Xcode-Project-Template

I created this a few years ago but got no response. It seems to still work with Xcode 6 and Yosemite. I copied a lot of stuff from how SFML did their project template. I put it on my github again - feel free to test if you have a mac!

That's really great. It would be great if 5.1.9/5.2.0 came out because then this could be modified to be both an osx and an ios template.

I installed Unity the other day to see how easy it is to port.

When you use Unity, it's so easy to take your project and have it generate an XCode project with all the libraries and frameworks all nice and linked up.

It would be great if somehow Allegro could have this too. We need more automation. I really wish I had a clue on how to do something like that because that's something I would be very interested in contributing to.

We need to automate building somehow, but after that, we really need to make it easier to deploy. I have been working on a project for over 4 years and have only ever used it on Windows because I can't figure out how I would keep my MSVC, XCode, Eclipse etc projects synchronized. That's a big edge that Unity has that I think a library like Allegro should have.

That's kind of how MS operates. Make something today, deprecate it tomorrow.

I stopped concerning myself with learning their APIs after they deprecated Managed DirectX. The target moves too fast for me.

Oh really???

Never used it before, but I've just been able to install latest boost binaries seamlessy with NuGet. Allegro should be harder to install since it has a bunch of dependencies, but it seems doable.

I bet the file growth is exponential and I bet it's because after it is finished writing all the TODO to TODO.txt it notices that TODO.txt was created/has changed and parses it again, adding all the TODO from TODO.txt again to TODO.txt, notices that TODO.txt has changed and parses it again, adding all the... you get the idea.

Changing the output to ../TODO.txt should prevent it if it is that.

Ah, that was it. Thanks Dennis!

Although it still seems like a bug, recursively searching the file that you are creating and then adding to it and then searching it again, and then adding to it... even if it is in the search directory.

Edit for Trent
-r is for recursive search
-E is for regular expression (not used this time)
-i is for ignore case
-n is for displaying the line number.

It's not a bug. You're just doing it wrong. grep(1) has no idea that you're writing TODO.txt. Your shell opens a file handle for "TODO.txt", and binds grep(1)'s stdout file handle to it. grep(1) is still just writing to stdout. There are various --exclude options to prevent that, or you can do as Dennis suggested and write that file to a path that isn't being scanned.

grep(1) never searches the file again. It never gets to stop because every time it writes something to TODO.txt the file gets larger, guaranteeing that the next read operation will succeed with more data. It isn't until the file system fills up and the write operation fails that grep(1) finally signals an error and exits.

bash(1) appears to glob the arguments to grep(1) before opening the TODO.txt file so as long as that file doesn't exist before you start that should also suffice. If you ever try again without cleaning up the original file you will again find yourself re-cursing indefinitely. The power of this is one of the many things that make stdio great.

There is no bug. There is only PEBKAC.

If you want to unravel the mystery add echo before the command to expand it for you. Your shell should be globbing for you. grep(1) has no idea that you said .*.*. All it sees is . .. foo.txt bar.txt ...etc.... Again, grep(1) has absolutely no idea which file the shell told it to write to. It is exactly as I said, PEBKAC. In fact, it doesn't even have to be a file on disk. It can be anything a file handle can refer to. It could be an IP socket, a UNIX socket, a pipe, or even a device. To *nix systems the differences are transparent to the API. Though in some cases you can try to figure it out by going above and beyond and using platform specifics, but in this case I don't even think grep(1) can identify the file system path. A file handle generally refers to an inode, not a file path. *nix systems resolve names into inodes. That allows you to unlink (i.e., "delete") the named file while another program has a handle to it and is reading or writing to it. I don't think there's even a way to ask the kernel "which inode is this?" because again it isn't guaranteed to be one. And even if it could, an inode can have many names (i.e., paths in the file system) referring to it. In any case, it goes above and beyond the scope of grep(1) to be that extra curricular. It's generally up to the user to make reasonable requests (special files can read different than what was written to them).