... until the collector arrives ...

This "blog" is really just a scratchpad of mine. There is not much of general interest here. Most of the content is scribbled down "live" as I discover things I want to remember. I rarely go back to correct mistakes in older entries. You have been warned :)


Functional Programming Interview Question

I was reading a blog on fsharp.it that concerned a functional programming interview question. The challenge was to write a Haskell program that count occurrences of words in a text file. The blog posting exhibited an F# program to solve the problem, and briefly spoke to the comparison between functional and imperative style.

From time to time I like to tackle these toy problems in Mathematica. Mathematica is neither functional nor imperative, but rather is based upon pattern transformations. My solution to the programming problem in Mathematica was this:

  Import["http://www.starling-software.com/employment/input.txt", "Lines"],
  {"NUMBERS" -> {}, "ANIMALS" -> {}}
} //. {
  {{}, _, cs_} :> (cs /. (a_ -> b_) :> (a -> Tally@Sort@b)),
  {{c_, ws___}, _, cs:{___, c_ -> _, ___}} :> {{ws}, c, cs},
  {{w_, ws___}, c_, {cs1___, c_ -> {seen___}, cs2___}} :> {{ws}, c, {cs1, c->{w, seen}, cs2}}

The output from this code is:


This code uses an idiom in Mathematica that, without getting into details, repeatedly transforms an initial state until a desired final state is reached. If you know the idiom, the transformation is expressed fairly directly. If you don't know the idiom, the code is gibberish and looks like I'm trying to program without using identifiers.

All of this raises interesting questions about conciseness in programming. Functional code (and transformation code) is often radically shorter than an imperative equivalent. However, readability can suffer drastically, especially if the reader has not internalized the idioms used. It is going to be interesting to see how the current wave of interest in functional languages impacts the mainstream.



Jonathan Kohl has had a great experience with JBroFuzz.  He said that it found fuzzing-type bugs that slipped through penetration testing, security testing, static analysis tools, walkthroughs and defensive coding.  One must consider, however, the user of the tool as well...

ADO Unwelcome Asynchronous Statement Execution

Using ADO, if you use Command.Execute to execute a statement that does not return a result set, then that statement will be executed asynchronously.  The function call returns immediately.  I suppose this behaviour is defensible because the return value of the function is a recordset whose status you can query.  However, if you use the flag adExecuteNoRecords and do not specify any of the flags adAsyncExecute or adAsyncFetch or adAsyncFetchNonBlocking, then you might expect the command to execute synchronously.  In fact, it does not.  The documentation was no help -- through experimentation, I found that I could achieve synchrony by calling NextRecordSet on the returned recordset.  I could have just accepted the asynchronous behaviour and blocked until I received a completion event, had I not been using JScript that cannot interact with ADO events.

It seems questionable that Command.Execute executes asynchronously by default.  But it is negligent that none of the ADO documentation even hints that this is the case, let alone lacks any advice on how to perform synchronous operations.


Subtle Eclipse and OSGI Plug-In Dependency Problems

Using Eclipse 3.4.2, I found a couple of nasty bugs involving package dependencies.  Let's say I have the following situation:

  • two plug-ins plugin.a and plugin.b
  • plugin.a exports the package a.ui and has a non-exported package a.model
  • a public class, a.ui.Ui, has a method with the signature a.model.Model getModel()

In plugin.b, there is some code that looks like this:

a.ui.UI ui = ...;
if (ui.getModel().hasSomeProperty()) ...

The Eclipse compiler accepts this code.  It should not, since ui.getModel() returns an object of type a.model.Model, and the a.model package is not exported from the plug-in.  In fact, if I rewrite this code like this...

a.ui.Ui ui = ...;
a.model.Model model = ui.getModel(); // error flagged here
if (model.hasSomeProperty()) ...

... then Eclipse will complain about the second line, saying that a.model.Model is not visible.  It will offer a quick fix to export the a.model package from the plug-in.

Okay, so the compiler doesn't catch this.  Big deal!  You'll find out about your problem when the OSGI run-time tries to load the a.model.Model class, right?  Wrong!  OSGI will sometimes catch the error, and sometimes not.  Specifically, if the class a.model.Model is loaded for the very first time by code that exhibits this error, then OSGI will correctly identify that an access rule has been broken.  But if the class has already been loaded, then OSGI does not perform access checking at all.  Once a class is loaded, then that class can be accessed by any bundle that depends upon the containing bundle -- whether or not the containing package is exported.  So much for OSGI security!

This combination of bugs has an insidious effect to which I fell victim.  In my case, the code was "broken" but it "worked" because the affected class had already been loaded long before the code was invoked.  I made an apparently minor change to the affected class and suddenly a mysterious ClassNotFoundException appeared at runtime (the change had subtly altered the class-loading order).

I'm more worried about situations where the class-loading order is sensitive to actions taken by the user.  If the user performs actions in one order, everything works.  If the user tries a different order, then ClassNotFoundException.  I suppose this occurrence is rare enough that we don't have to concern ourselves about it (famous last words).

Another argument in favour of the Law of Demeter ;)

Blog Archive