Pyritz's Blog

Remember To Not Forget About Memory

pyritz — Tue, 07 Jul 2009 18:25:21 +0000

Memory related problems (leaks, overwrites, etc.) are some of the most difficult to debug in a live realtime system. So, don’t forget about that while designing and developing. In addition to making these problems impossible to exist (use static memory allocation, one allocation and deallocation point, etc.) as a solution, build into the system memory transparencies and tracability. Need to fill in quite a bit of detail here, but this is without a doubt a worthwhile exercise.

Why Problems

pyritz — Fri, 03 Jul 2009 21:02:56 +0000

After reviewing a document recently, what kept going through my mind was, “What problem is being solved here?” To me this is the most critical “section” of the document, and without it, the document is like a boat adrift. It’s like laying the detail bricks with no foundation. At AT&T Bell Laboratories (previously, or more presently, Lucent Technologies and now Alcatel-Lucent and soon to be Alcatel without Lucent or the Naperville branch — but that’s another post, note that I sentimentally still like to think of those better days when Bell Labs was still Bell Labs), we used to have what was refererred to as the Switching Architecture Review Board (SARB). The SARB regularly reviewed new projects within the company and assessed their viability technically, marketwise, etc. The very first requirement of the SARB reviewers was a concise statement of the problem being solved. If the project was unable to concisely state the problem to the satisfaction of the SARB reviewers, the meeting was re-scheduled or the project just went away. It’s clear to me now, after years of working on large complex software projects, that the SARB was very wise. There’s much more to say on this, but that’s all for now — except to say that I prefer (and have found very helpful) to use a sort of pattern like approach to analyze and document the problem. I use the following headings:

Problem Statement – concise (no more that one paragraph)
Forces – what forces/constraints apply? Note that these usually (in fact if they don’t, something is wrong) work against each other and must be reconciled
Proposed Solution

That’s it.

Language Extensions

pyritz — Thu, 02 Jul 2009 17:30:42 +0000

I think there is great potential for creating language extensions (as opposed to creating a new domain specific language or DSL). My point is that a general purpose language (GPL) is usually the least common denominator for any software project. The GPL is expressed in text and is not therefore bound to any of the usual constraints — e.g., IDE, platform, OS, etc. — and the associated costs. Developers are free to use their editor of choice (or an IDE) as well. The problem, of course, is that the GPL cannot express project (even beyond domain) specific concepts. Libraries and frameworks fall short because they are themselves constrained by the GPL. Language extensions on the other hand provide a means of fine tuning the GPL with project specific constructs.

Ruby Line Parser

pyritz — Wed, 01 Jul 2009 21:58:49 +0000

I’ve been working on a ruby based line parser. A much better way to talk about this would be to show you the code, however, the code is under corporate lock and key presently. Here are some highlihts:

Base classes are defined for inner/parent and leaf nodes
Application classes inherit from the base nodes
Each application node specifies a match rule that includes a regular expression match and delimiters (e.g., {} )
Nodes can also have “match types” (an array of node types) that can be children. This essentially represents the grammar.

The first application was the extension of an existing real time testing language. Some of the development details include:

test driven development using runit and my custom cppunit
because a “heavy” infrastructure is required for the testing environment, I simulated most of it with additional code generation — i.e., I generated quite a bit of C++ wiring code and code that the custom cppunit tool used for its generation. So there were three levels of code generation involved.
created a new testing language to facilitate specifying c++ tests in a concise and easy to read format.

I am now further convinced (although I was already pretty much over the edge) that test driven development is a key factor in writing maintainable and essential code.

Hello world!

pyritz — Wed, 01 Jul 2009 21:11:55 +0000

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!