Lispian Random meanderings on whatever catches my fancy

Revisiting Code of Yore

I’ve started a new job. I’m now working with some of smartest people I’ve ever worked with, an impressive lot. One of them I owe a lot. He was a former prof. And he still makes my head spin with how easily he handles technology and how it can be applied to the real world. But what really gets me is that he remembers everything be it technology from the 70s or technology from yesterday. And he knows how to apply it individually or in concert to any given problem.

It’s made me do something I should have done a long time ago, take a step back. I’ve been so close to problems that I’ve just been running. Running to stand still, as the old saying goes. I think it was partially the environment I found myself in. I needed to focus on getting work in and out as quickly as possible that I would grasp onto the first reasonable solution and run with it. Luckily, most of the time it was the optimal or near-optimal solution. But sometimes it wasn’t.

The other day I realized that a few technologies I haven’t used in years — decades — were possibly very useful for some tasks I had. One of them is an old compiler technology. It allowed for the creation of parsers quickly and easily, much more so than lex and yacc. I dug into my archives and discovered, much to my chagrin, that they were damaged. No matter, I had older backups. They too were corrupt. It seems that I’d been backing up a long-corrupt copy of the software. I was bummed.

I knew others may have kept copies so I asked around if they had old copies. The answer was that none had. Then one of my old friends said he’d been sent a copy by a mutual friend who was sorting his archives. He sent it along. Eureka!  An old, but hopefully salvageable, copy! I created a directory, dumped it in and attempted to compile it. No go. Something was amiss. A quick look at one of the .h files quickly showed it corrupted. Argh! No justice!

My only hope now was that my corrupted copies were corrupted elsewhere. Unfortunately, my versions were for another style of parser generator and not the one I was sent. I figured I’d reconstitute the corrupt .h file best I could. I went at it. And then started dealing with the various errors and general C nastiness that occurs when you attempt to compile a decades old K&R style program. Joy.

Little by little I got it to work. Then I got to one file that had a comment in it. With my name affixed. It seems that the copy I was sent was actually the translation I had performed from the original Pascal version to C. The corrupt version I had was of another instantiation of said program that was originally coded in Fortran, that I, too, had converted to C. The file I was staring at was the dependency file. It had dependencies for a wide variety of ancient machines from Honeywell CP-6 to PDP-11 based Unix, VAX-based Unix, old BSD Sun, Amiga, Windows 3.1, DOS, and on and on and on. I looked at it, fired up Google, and quickly replaced all the dependencies with modern code. In one place I was able to eliminate hundreds of lines of weird system dependent code with a simple variadic macro! Woo hoo!

I compiled it, it compiled, then sort of ran and then seg-faulted. Luckily I more or less knew why — damn pointers! — fixed it and ran and it worked!

Now, I have an old version that doesn’t even support include files. But that’s OK. One of the things that isn’t corrupt is the modern parser generator, so I can bootstrap myself a modern version! That’s a job for the coming weeks.

And why am I all enamoured with this old parser generator? Because of what my old prof mentioned regarding a problem I’d had with building a policy editor at my old startup. I tried a number of ways, none worked. He looked at me and simply said: Decision Tables. I nearly knocked myself out with the forehead slap. Duh. Sometimes old technology can solve a new conundrum. This old parser generator is fast, slick and easily extensible. It’s perfect for the Relational Growth Grammars I want to play around with. If it does what I think it can do for me, it’ll save me oodles of time and provide me with a flexible solution to creating parsers for growth grammars as opposed to what many people do at present which is create custom parsers for each problem set.

Time will tell. But right now I’m looking at some operational code, a set of algorithms and ideas to implement, and possibly a revival of some old code for a new purpose. And, yes, I’ve backed it up. I’m not so stupid as to not do that this time around!

Comments are closed.

August 2010
« Jul   Sep »