The finest meta-program in the history of anything:
Cellular Automaton Knitting with Perl.
Thank you, wikipedia.
ADDENDUM:
So that I also have something to contribute, here is rule 30 used as a random number generator, written by yours truly. (Though the idea of doing so certainly isn't mine.) Anyone care to suggest an optimization?
( C source code for pseudo random number generation from a elementary cellular automaton. )
For anyone who was every curious how computers generate random numbers, I will say that this is a slow and very complicated way of doing so; it isn't a good learning tool on the topic.
|
I'm working on a document where I need to typeset something in Old English. Particularly, I need to type an eth. There are at least two Old English fonts for TeX available, my pick being Computer Modern Old English.
I'm surprised to find that my TeX distribution doesn't include (that I can find) any Old English fonts. I have to install it by hand. This is actually the first time I've had to do something like this--Things as obscure as Linear A are included by default.
I never thought I'd have to learn how to install a new font into TeX.
EDIT: Elvish is also included by default. I'm clearly missing something here.
|
For years I've been asked why I wrote a particular piece of code a certain way, and I've often responded with "Oh, I've studied a lot of Lisp and it influenced the way I write code."
Now, after asking how to port some code to an upcoming release of chicken (A Scheme compiler, Scheme being a dialect of Lisp), I've been asked why I wrote a particular piece of code a certain way.
This is either a new low or a new high.
I never thought the lisp community would grow so quickly that the way they wrote code would perceptively change. I could have guessed I would like it better the way it was though. damn kids schemers.
|
I'm having a problem that has blocked me on two separate projects. I can't seem to rotate a postscript file, after trying several tools that should be able to do it.
I have one eps file, 8.5" x 5.5". I'd like to rotate it anti-clockwise 90 degrees, so I can insert it into a booklet. The booklet is typeset in TeX, so I'm including the graphic using \special. The booklet is then converted from dvi to postscript (with the eps file being included at that point), and then to pdf for printing.
In another case, I have a TeX file with the paper size set to 5.5" x 4.25". I have four pages, and I want to rotate each of them clockwise 90 degrees and print them on 8.5" x 11" paper four to a page. The command psnup is working fine for laying them out four to a page, but again I can't succeed in rotating them.
The first command I really need to work as part of a pipeline, though I would accept an interactive tool to solve the second problem.
Anyone have any success or pointers on rotating documents in postscript? Anyone had to work *around* not being able to rotate documents in postscript?
|
![[Edge-Notched Card]](http://www.c0redump.org/img/lj/edgecard.jpg) I love archaic technology. I particularly love archaic computation devices. I've been making a game recently of teaching myself as many of them as possible. I'm fairly handy on an abacus, which is really great at addition and complement subtraction. It is relatively harder to perform multiplication and division on such a device, which led to explore Napier's bones. I'm currently building a set of them out of wood.
I've been spending time as well teaching myself how to use a slide rule. That has been fairly slow going, as the surviving references tend to be elementary or presume you are being guided by an expert. I still have a few aha moments to go before I'll really get them.
As well, I've been spending time brainstorming mechanical retrieval systems. Being able to do math quickly is fine, but not if you don't have a way to organize your work. I've particularly been browsing through books on data structures and asking: "What data structures make sense to someone with no background in computers? What of these have physical analogs that make sense to people--that you could put a physical representation of it in front of them and have them get it? Finally, which of *these* work the same mechanically or electrically?
Things like hash tables are right out. Binary trees don't fair much better. Dictionaries are good candidates, but if you're talking about adding and subtracting pages, they work differently electronically and mechanically. I'm currently exploring directed acyclic graphs (my personal favourite data structure) built out of hemp rope and alphabet beads. I want to use it to track interdependent projects that change over time. I've also been brainstorming stack computers built out of washers and a series of metal dowel rods. The intended use is tracking matrix-like calculations, particularly accounting problems.
I love all of these things. I can take contemporary notions of computation--particularly I can take a computational approach to solving problems, but do so with tools from a previous era. Our ideas and the tools we use to express them are often so intertwined that we lose sight of the problem we're working on. It is much easier to solve problems a tool is designed to solve, whether that is the problem we're having or not.
Changing the tool is a great way to see how your problem(s) change with it, and through that development much simpler problems. It lets you see how much stuff you thought was essential to your problem is actually noise.
I recently came across notched index cards, a system for retrieving information using boolean logic. Better yet, it allows for searches on unsorted data. I had previously written off that problem as too complex for meatspace. Which limited me to picking one way to sort something and living with it.
With these, you can "tag" cards with multiple symbols, throw them all in a pile, and then retrieve all cards with a particular tag. When you're done, they go back in the pile in any order you'd like. It is a really great system for keeping brainstorming notes that haven't congealed into clear categories.
Or if you're just looking to have fun, you could use these to organize information for a role-playing game.
squee.
|
![[OpenBSD]](http://www.c0redump.org/img/lj/puf200X172.gif) I'm ridiculously happy with this change, just committed to OpenBSD: Xorg maps keyboard according to wscons setting.
Basically, there are two separate "displays" on a Unix system. The old console interface, which is text-only, and X Windows, which is a graphical windowing system. Both of them have separate ways of configuring keyboard input. I remap my keyboard to dvorak, which means I have to do it once for the console and once for X11.
As well, of late, the X project has been putting a lot of work into making the windowing system run without a configuration file. This is great until you need to change something. Any one change you need and all of the sudden you're running with a configuration file.
The most common thing I or anyone else has to change is the keymap. With this patch about the only other thing I could ask for is sticky key support on the console which is also promoted into X11.
I've been using OpenBSD for many years now, having migrated to it from Linux. I really love Linux, but I've watched the community around it change as it has grown in popularity and found commercial success. Using OpenBSD feels like running Debian did a decade ago--instead of trying to catch up with the huge volume of change and growth, they focus on integrating the resources they have. Maximizing how well everything works together.
OpenBSD has remained consistently the same since before I started using it. This is deeply valuable to me, even when that sameness includes things I'd rather do without (CVS comes to mind). I try to create a sense of deep time in the tools I use. I've been using the same tools, or at least the same techniques, since switching to Unix well long ago now. I want to cultivate an environment where those tools are still relevant to me and the world decades from now. I don't need e-mail to be reinvented every few years, I need that to be a solved problem and to move on.
On a personal level, that is a lot of what open source is about for me. That I can participate in a community of interest centered around a particular solution. That solution stays relevant so long as the participants consider it relevant. I don't have to reinvent my computing environment just because some shiny new tool doesn't play well with the ones I've already got.![[dilbert cartoon]](http://www.c0redump.org/img/lj/dilbert_unix.png)
|
On Sunday, two of ![[info]](http://l-stat.livejournal.com/img/userinfo.gif) yarrowkat's friends in the art department (Julia and Josh) stopped by to photo us in her yurt. They're doing a photo series on people in mobile housing. As they were setting up, Julia snapped tons of photos with a digital camera, while Josh painstakingly set up what can only be described as an ancient camera.
He spent so much time doing it that he started to get ribbed for the fact that the digital camera had already been through dozens of shots, and he was only going to get one or two. All the same, I found myself relating deeply to the act of interacting with the camera.
It wasn't the picture so much as the process. I often find myself doing things the hard way because I can control and understand the process as I'm doing it. People watching me work on my computer are equally split between "Wow, I can't believe how much work that just took you." and "Wow, that was completely amazing."
Which is a long way to get to my point. I just finished my taxes today. I probably didn't do them right. This is my first year dealing with a K-1. The IRS publishes a great document on how to take a K-1 and translate it into fields on your 1040. Following these instructions from a wizard designed to hide all that complexity from me was a complete pain. With the added bonus that I couldn't really check whether it was right.
Next year, I'm going to give Open Source Tax Solver a go. It's designed for people that don't mind reading IRS publications. After my experience using a program trying to *hide* that from me, I'm so ready to try something that isn't shy about presuming you know what you're doing.
For some reason, I think this has something to do with spending an hour with an archaic camera. But I can't explain how.
|
I've been researching local filesystem search utilities of late. I'm interested in finding stuff in my home directory without actually remembering where I stashed it. I've wanted to create a local search index for some time, but never put any energy into it until now.
I'm currently testing doodle. There are lots of programs in this space. Many of them are designed to serve search requests to a webserver.
I was looking for a tool with a good abstraction between file types and the core engine (doodle uses libextractor). I'm not really interested in searching non-text files, but being able to filter out stuff based on file type or path information is nice. I don't want to search for a function in a C file and get the svn cached copy, the object file, and the actual file containing the function I'm looking for.
I was also interested in a tool that I could understand the index algorithm. Suffix trees are my second favourite subject in computer science, behind graphs. Both are basically made of magic: they allow computers to do things *fast* that are nearly impossible for humans. I won't be able to help poking around the source code.
Finally, I wanted something I could use from the command-line. doodle isn't quite as good as namazu in this regard, but it is a lot smaller and I think better designed.
Anyone else used tools like this? It is all new to me.
|
|