Category Archives: Pontificating

Heroes of Yore

Bible, Family|Bible|More, Pontificating

I suppose, if asked to name a hero from the Bible, that many people would choose David. After all, he killed giants, wrote inspiring poetry, and became a glorious king. He represents the pinnacle of Old Testament Israel. But is that really what makes him a hero?

Over the last few months, I have been listening to Charles Swindoll’s book David, A Man of Passion and Destiny, on my bike commutes, and it has been an illuminating experience. David is, like just about every significant person recorded in the Bible, all too human. His passion is his strength and his downfall. The narrative in no way glosses over these failures, which is a big part of what makes the history so compelling. However, as a historical account, it is easy to miss the emotion and the import of key events.

Buried in the middle of a paragraph are a handful of words which I think represent David’s most heroic moment. These few words are uttered by David during the height of his reign as king, after the following story is related to him:

There were two men in a certain city, the one rich and the other poor. The rich man had very many flocks and herds, but the poor man had nothing but one little ewe lamb, which he had bought. And he brought it up, and it grew up with him and with his children. It used to eat of his morsel and drink from his cup and lie in his arms, and it was like a daughter to him.

Now there came a traveler to the rich man, and he was unwilling to take one of his own flock or herd to prepare for the guest who had come to him, but he took the poor man’s lamb and prepared it for the man who had come to him.

Do you know who told this story and why? It was told to David by Nathan, a prophet, after David slept with a married woman and subsequently had her husband killed (read the full story).

Now David was at the height of his power. His wrongdoing has just been uncovered by Nathan. It would have been well within his ability to have had Nathan killed. But he didn’t kill Nathan. Instead he stopped and said: “I have sinned.” Just step back for a moment and think about that. When is the last time you heard one of our political leaders take responsibility for their actions like that? How hard is it to admit that you are wrong; and even harder when you have every facility within your grasp to avoid it?  David didn’t even have an opposition party to denounce him: he was king and could do whatever he wanted.

That’s heroism.

More on the pngimage unit in Delphi XE2

Bugs, Computing, Delphi, Pontificating

After submitting the issue reported in How not to do exception classes in a Delphi library to Embarcadero (QC102796) they asked me for a test case.  Didn’t make much sense to me but I duly wrote one and am about to submit it.  However, in the process I collected a lot more information about work that should have been done on the Vcl.Imaging.pngimage unit when it was integrated into the Delphi source. Here’s the full list of the exception classes and what should be done with them.

  • EPNGError should inherit from EInvalidGraphicOperation or be eliminated as it raises inappropriate exceptions
  • EPngUnexpectedEnd should inherit from EInvalidGraphic
  • EPngInvalidCRC should inherit from EInvalidGraphic
  • EPngInvalidIHDR should inherit from EInvalidGraphic
  • EPNGMissingMultipleIDAT should inherit from EInvalidGraphic
  • EPNGZLIBError should inherit from EInvalidGraphic
  • EPNGInvalidPalette should inherit from EInvalidGraphic
  • EPNGInvalidFileHeader should inherit from EInvalidGraphic
  • EPNGInvalidFileHeader should inherit from EInvalidGraphic
  • EPNGSizeExceeds should inherit from EInvalidGraphic
  • EPNGMissingPalette is unused and should be deleted
  • EPNGUnknownCriticalChunk should inherit from EInvalidGraphic
  • EPNGUnknownCompression should inherit from EInvalidGraphic
  • EPNGUnknownInterlace should inherit from EInvalidGraphic
  • EPNGNoImageData should inherit from EInvalidGraphic
  • EPNGHeaderNotPresent should inherit from EInvalidGraphic

The following three exceptions are really reimplementations of existing exception classes and should be abolished entirely:

  • EPNGOutMemory should just really be replaced with RaiseLastOSError.  Or, if backward compatibility for this exception is really needed then inherit from EOutOfMemory
  • EPNGNotExists is not used unless USEDELPHI is not defined, which it is…
  • EPNGCouldNotLoadResource masks a number of other exceptions and should if possible be removed entirely.  The code in question re-raises an exception and buries the original error with an entirely unhelpful secondary exception (and what is that exit; doing in there?).
  try 
    ResStream := TResourceStream.Create(Instance, Name, RT_RCDATA); 
  except
    RaiseError(EPNGCouldNotLoadResource, EPNGCouldNotLoadResourceText);   
    exit; 
  end;

Finally, these three need to inherit from EInvalidGraphicOperation:

  • EPNGCannotChangeTransparent should inherit from EInvalidGraphicOperation
  • EPNGInvalidNewSize should inherit from EInvalidGraphicOperation
  • EPNGInvalidSpec should inherit from EInvalidGraphicOperation

In a number of locations EPNGError and Exception are also raised (albeit sometimes in code that is $ifdef‘d out of use), often with blank error messages!  For example:

    case BitDepth of 
      {Only supported by COLOR_PALETTE}
      1: DetectPixelFormat := pf1bit; 
      2, 4: DetectPixelFormat := pf4bit; 
      {8 may be palette or r, g, b values} 
      8, 16: 
        case ColorType of 
          COLOR_RGB, COLOR_GRAYSCALE: DetectPixelFormat := pf24bit; 
          COLOR_PALETTE: DetectPixelFormat := pf8bit; 
          else raise Exception.Create('');
        end {case ColorFormat of} 
        else raise Exception.Create('');
    end {case BitDepth of}

Finally, the unit reimplements a bunch of standard Delphi VCL functionality that is inappropriate to keep within the Delphi VCL codebase, including core classes such as TStream.  While these are not compiled in because they surrounded by $ifdef statements, all this code should really be stripped out for maintenance and code cleanliness/readability reasons.  Thus, all code surrounded by $ifndef UseDelphi should be deleted. This is not a systematic review of the issues in the Vcl.Imaging.pngimage unit; it’s more just a rant and giving a heads up about the quality of this unit.  Embarcadero, please clean this unit up!

How not to do exception classes in a Delphi library

Computing, Development, Pontificating

The pngimage unit in Delphi includes a bunch of exception classes to handle error conditions when handling PNG files.  That’s great, except for one problem: all the classes inherit from Exception instead of an abstract EPNGException.  Of course it would be even better to inherit from a hierarchy of abstract exception classes.

Frankly I don’t care if the image is corrupt because it has an unknown critical chunk, or if it is corrupt because it has no image data.  All I care about is that my application cannot load an image and I need that condition handled gently.

Basically, not using a hierarchy of classes means that error handling code in applications loading PNG files must either be too broad and generic (on E:Exception), or too specific (on E:EPNGUnknownCriticalChunk).  Future changes to the PNG class library for additional exception types when loading a PNG file would require every developer to add additional exception checks to every location where PNG files are loaded in order to handle that error, when in nearly every case the developer really just wants to handle EInvalidGraphic!

Even worse, this means that generic code for loading images must be overloaded with knowledge about PNG exception types, or else risk masking more serious errors such as access violations with an overarching on E:Exception clause!

So here’s the current complete list that the developer must be aware of:

EPNGOutMemory = class(Exception);
EPngError = class(Exception);
EPngUnexpectedEnd = class(Exception);
EPngInvalidCRC = class(Exception);
EPngInvalidIHDR = class(Exception);
EPNGMissingMultipleIDAT = class(Exception);
EPNGZLIBError = class(Exception);
EPNGInvalidPalette = class(Exception);
EPNGInvalidFileHeader = class(Exception);
EPNGIHDRNotFirst = class(Exception);
EPNGNotExists = class(Exception);
EPNGSizeExceeds = class(Exception);
EPNGMissingPalette = class(Exception);
EPNGUnknownCriticalChunk = class(Exception);
EPNGUnknownCompression = class(Exception);
EPNGUnknownInterlace = class(Exception);
EPNGNoImageData = class(Exception);
EPNGCouldNotLoadResource = class(Exception);
EPNGCannotChangeTransparent = class(Exception);
EPNGHeaderNotPresent = class(Exception);
EPNGInvalidNewSize = class(Exception);
EPNGInvalidSpec = class(Exception);

I’m disappointed that when this code was acquired and integrated into the Delphi source code, that this level of basic tidy up was not done.

Being badly behaved, or Copenhagenizing Hobart

Cycling, Pontificating

I was involved in an interesting twitter conversation yesterday and I felt a blog post arising from it. It started with a tweet from Mikael Colville-Andersen aka @copenhagenize:

'Badly behaved' cyclists are just cyclists without proper, well-designed infrastructure.

Tim Stredwick, our local Hobart bike hero also known as @bicycle_tim, retweeted this (without the Salon article link unfortunately, so I missed that):

That’s where I first saw it, and then I reacted (perhaps a little strongly…):

That's bollocks. What about badly behaved car drivers? No, in both cases it's just inconsiderate behaviour.

The conversation continued thus:

The thing is, I think it is an unhelpful position for a cycling advocate to take in Hobart. In Hobart, the car is still king. Bicycle infrastructure is in its infancy. A cultural shift is needed for safer roads in Hobart.

It’s unhelpful if anti-bike people read this message: they’ll just see it as excusing what they see as the typical cyclist’s behaviour, and use it as one more reason to push for having bicycles removed from the road entirely.  Bike registration anyone?

But it’s also unhelpful for those who already ride antisocially: they can use it to justify their own poor behaviour, viz. “Even @copenhagenize says its not my fault I’m riding the way I am: the infrastructure made me do it.”

The dialogue on cycling in Australia and especially in Hobart is currently stuck in a pretty pointless us-vs-them cycle. Bad behaviour is endemic and increasing on the roads, and it’s certainly not just limited to people on bicycles. Of course discourtesy is by no means unique to Hobart but here are some examples of the attitudes that are part of the problem:

  • Selfish driving: on a multi-lane road, if you indicate to change lanes, it is common for a driver in that lane to hurriedly close up the space you planned to merge into.  I have not seen this particular behaviour elsewhere.
  • Bike rage: verbal abuse for not giving way to a “faster rider” is not infrequent on the most comprehensive part of Hobart’s cycling infrastructure — the Intercity Cycleway. I’ve often heard riders complaining about children on bikes and mums with prams on the cycleway (it’s a shared use path).
  • Aggressive driving: road rage is a daily sight despite the shortest commutes of any capital city in Australia.
  • A tit-for-tat response to discourtesy from other riders and drivers; we all trip up on this one; I know I do. Take a chill pill, Marc!
  • Dangerous overtaking (illegally, even on blind corners) and speed; Tasmanians drive much too fast for the conditions. Both of these issues are very visible on highways in Tasmania, car vs car, even without bicycles in the equation.

Now Australia has a peculiar attitude to road rules. People get very upset when anyone else is seen violating a rule (for example, speeding) but the rules are still seen as unfair and even decried as illogical by many. It seems this knee jerk reaction is amplified when it comes to cyclists who disobey them — running red lights, riding triple file (actually this seems rare to me but it is often cited as people become more aware that double file is legal)… And, “how dare he ride without a helmet!” Does it impact you if he does that?

A quote from the 2011 AAMI Crash Index sums it up:

“When we cut someone off, it is because we are in a hurry; when someone else does it to us, it is because they are a jerk.”

But even the most relaxed of my non-cycling friends complain about the behaviour of cyclists. While most of them support the creation of great bicycle infrastructure, they’d probably be offended to hear this sentiment from a cycling advocate and may even question if cyclists “deserve the infrastructure” if they are going to ride so badly in the first place.

Last year, Jan Gehl was commissioned to prepare a report for Hobart and there was a strong negative reaction from some segments of the population. All while they complain about traffic jams and other drivers of course… Part of his report dealt with cycling but he outlined the need for a much greater cultural shift than a bit of cycling infrastructure! I personally think Jan Gehl’s report is fantastic and would love to see it all come fruition, but it seems I am in the minority in Hobart.

It’s not all doom and gloom. Attitudes on the roads in Hobart have improved in the last 5 years. The number of cyclists on the roads is increasing dramatically. Aspects of Jan Gehl’s report are being acted on by the council. But there’s a heck of a long way to go.

So how does this all come together? Better cycling infrastructure is going to increase the number of riders on the roads, but I don’t think it’s necessarily going to change the behaviour of those who already ride discourteously. They’ll just be a smaller proportion of the cyclists out there. Courtesy on our roads is part of a cultural shift that must come from within the society. I think those of us who are cycling advocates need to always be aware of the deep seated resentment towards those who ride badly, which impacts all cyclists, and not be seen to condone this discourtesy, even if the original argument has some validity!