I’ve been using what I assume is a form of unit tests during the later stages of each implementation. What happens is that the output of my Perl implementation is compared to the C’s, if a difference is found processing stops and the two data structures are printed. Once I’ve brought the Perl inline with the C I test again, rinse and repeat. Each time the time between failures increases.

For the other data structures processing everything never took more than a minute, with combos it takes up to seven minutes to process everything. As I work on brining the Perl inine with the C I find myself sitting for increasing lengths of time. Thus satisfaction, the knowledge that the longer it takes the better the Perl has gotten, =}

Yesterday I ran into a conundrum processing the constraints of options. I had a solution but I wasn’t happy with the cleanness of it. I slept on it and this morning I’ve got something I’m much happier with.

Instead of summering the constraints in a structure like this:

driver => option =>  printer => [sense, default]

I used a structure like:

printer=> driver => option => [sense, default]

If a constraint does not specify a printer then it goes under the ‘*’ printer hash, like wise a driver can also be ‘*’.

This also allows me to simplify retrieving the constraints by merging it with the operation that determines which options to inspect for a particular driver printer pair. This happens in the function getOptions($relations, $printerName, $driverName), which now only merges the lists of options from the three possibilities (driver, printer, and driver-printer) overwriting keys with those of more specific possibilities.

Now I can move onto equivalency testing of parseCombo and the C implementation.

Edit: The solution I ended up going with.

Constraints are a element in the Option XMLs and determine what options match a driver / printer combo. They like this:

'constraints' => [
			  {
				'printer' => 'printer/Lexmark-Z12',
				'sense' => 0
			  },
			  {
				'printer' => 'printer/Lexmark-Z31',
				'sense' => 0
			  },
			  {
				'printer' => 'printer/Lexmark-Z31',
				'sense' => 1
				'driver' = > 'lxm3200-tweeked'
			  }
			],

While they look simple I’ve run into a problem, how best to fit this into a data structure for easy lookup.

The printer and driver XMLs contain no references to options. Instead an option contains these constraints which specify which drivers and printer pairs apply to the option. Unfortunately generating a combo is driven based on the driver and printer data. Because of this we have to compute an in memory cache of these constraints in order to match a combo to its options (or reprocess the entire set of option xmls for each combo (which would be absurd (rather like these nested parenthesise( ( ))). The data structure of this cache is that has me troubled. I have a working structure, but I’m sure that if I was a better computer scientist I would have known something better than this:

'hpdj' => {
	'7' => {
	   'HP-DeskJet_540' => [
						   1,
						   'ev/137'
						 ],
	   '*' => [
				1,
				'ev/140'
			  ],

		 },
	'94' => {
		'*' => [
				 1,
				 '60'
			   ]
	  },
	},
'deskjet' => {
   '6' => {
		  '*' => [
				   1,
				   'ev/130'
				 ]
		},
   'GS-HalftoningAlgorithm-Gray' => {
		'*' => [
				 1,
				 'ev/GS-HalftoningAlgorithm-Gray-Standard'
			   ]
		}
	},
'printers' => {
	'HP-DeskJet_500' => {
			   '6' => {
				  '*' => [
						   1,
						   'ev/130'
						 ]
				},
		},
	},

So let it be said, even in a project as code monkey as processing XML computer science finds a way to sneek in.

Compared to parsing printers and drivers generating, the Overview is definitely more complex. For Printers, Drivers, and Options XMLs (the “primary” XMLs) only occasional processing was necessary. This leaves Overview to simply process the data into the overview structure. By lines of code about half of Overview is spent removing excess keys, a simple matter.

The complexity arises from the need to combine printers with drivers that support them. We get this compatibility information from two places, the printers which contain a list of drivers, and the drivers which contain a list of printers. Only one XML needs to claim compatibility to establish a relationship. Thus this relationship need not be mutual, a driver may claim to support a printer yet the printer could claim to be a brick. As well if a driver references a printer for which we have no XML we create a new in memory entry for this otherwise unknown printer.

The simplest approach would be to compute the relationships as a discrete step. This would leave you with an algo similar to this:

Build hash of Printers
Build hash of Drivers
Compute relationships
Compile based on relationships

Your Compute relationships algo could be quite naive, with hashes we get unique entries quite easily. You might end up with a structure like this:

'printer' => {'driver'=>'', 'driver' =>'', 'driver'=>''};

Having Computer Relationships be a descrete step makes conceptualization easier but nothing says it has to be desecrate. Once we know of a relationship we can act on it. This does complicate the algo as we now need to avoid mutual relationships from causing a driver getting added twice. In my implementation we do this by removing the reference to a printer in the driver if it exists.

Upto this morning my implementation had a logic defect in that it assumed a reference to a driver in the printer was a mutual relationship. Thus once it was done processing the relationships it computed from printers it assumed that any references in drivers were ONLY to printers without XMLs. Essentially I had not considered that a driver may reference a printer while the same printer may not reference the driver. With hind-sight the deficiency is obvious, unfortunately the downside of not treating Relationship Computation as a discrete step is that your relationship algo gets spread over more code, and thus harder to conceptualize.

If I were to re-implement Overview I would have Compute Relationships as a discrete step.This would have saved me about two days of debugging with only slightly increased complexity in the Combine step. In the end I am only out the debugging time and I do have a computationally more effective function and have learned to keep steps discrete in the future, a fair trade.