Oh, the irony!

Installing the first Oracle-branded JVM release ... the installer offers to install Microsoft's Bing toolbar ... the next page offers to install openoffice, billing it as a free alternative to Microsoft Office. I'm flying on the back of a pig.

Convert set of images to a multi-page PDF

#!/usr/bin/python
# Creates a single PDF file from multiple images. 
# Required ubuntu packages:
#       pdfjam
#       sam2p
#   - Thanks to http://typethinker.blogspot.com/2009/06/creating-multi-page-pdf-from-images.html

import sys
import subprocess
import tempfile
import os

images = []
pdfs = []
print(len(sys.argv))
outputFile = sys.argv.pop()
print(len(sys.argv))


for next in range(1, len(sys.argv)):
 image = sys.argv[next]
 print(image)
 images.append(image)
 
for image in images:
 pdf = tempfile.mkstemp(suffix=".pdf")[1]
 pdfs.append(pdf)
 print(pdf)
 print(image + "->" + pdf)
 #subprocess.call(["/usr/bin/sam2p", image, pdf.name])
 subprocess.call(["/usr/bin/sam2p", "-pdf:b2", image, pdf])

print("JOINING PDFS: ")
print(pdfs)
print(" as " + outputFile)

p = ["/usr/bin/pdfjoin", "--outfile", outputFile]

p += pdfs
print(pdfs)
print(p)
subprocess.call(p) 

print("Cleaning Up")
for pdf in pdfs:
 os.remove(pdf)

An iPhone Perspective

"Getting an iPhone is like walking into a cool, refreshing pond, which just happens to be full of leeches. You'll be comfortable as long as your body can generate blood fast enough." - derGoldstein (slashdot.org) (from a comment on this slashdot article).


Very insightful.  The blood is the money you have to pay.  The device is great, but there is always the blood loss.

Ubuntu + Latitude e6500 trackpoint: I'm not the only one!

It seems I'm not the only ubuntu (or even linux) user out there having troubles with the trackpoint (aka 'stick', 'joystick', 'pointing stick') on the Latitude e6500.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
http://bugzilla.kernel.org/show_bug.cgi?id=12577

I had recently come to the conclusion that the problems I was experiencing were somehow related to my sweaty thumb brushing against the trackpad when I hold down the left trackpoint button.  These ubuntu/linux bug-reports/issues confirmed that.  So, while I wait for 'they' to work-out a proven fix, I've adopted a ghetto work-around: I taped a piece of paper over the trackpad (I only use the trackpoint).

Scala: accessor/mutator access control

I spent a few minutes this evening digging in to Scala (http://scala-lang.org). What follows is the results of my initial investigation into the world of accessor/mutator methods and how to control access to them at compile time. WARNING: I'm just a scala noob!

Declaring a variable in scala implicitly creates accessor/mutator methods for that data. If I'm understanding things correctly, all variable references (i.e. assigns, accesses) are actually implicit calls to those methods. For example, in the following snippet, the last line is implicitly calling the implicit name() accessor method in the 'Dude' class.

  class Dude (firstname: String, lastname: String){
    var name: String = firstname + " " + lastname;
  }
 
  var joe = new Dude("Joe", "Brown")
  print(joe.name)

I like this, in as much as it seems on the surface to eliminate the need for boilerplate getter/setter methods. However, I am a huge fan of access modifiers, mainly because they make code more readable in that they communicate design intent. For example, I rarely code java classes these days with knee-jerk 'setter' methods: I only add setters if I have made a conscious decision to allow other classes to write to the property in question. Additionally, I disdain the knee-jerk use of the 'get/set' convention for accessor/mutator names. So my java code tends to look like this a lot:

class Dude {
  private String name;

  public Dude(String firstname, String lastname){
       this.name = firstname + " " + lastname;
  }

  public String name(){
      return name;
  }
}

So, naturally, I would not find implicit accessor/mutator creation to be of much benefit in the "eliminates boilerplate code" departement, unless the syntax enables you to succinctly specify different access modifiers for the implicit accessor vs the implicit mutator for a given variable. In other words, I would like to be able to expose an internal variable as a read-only property using syntax something like:

  class Dude (firstname: String, lastname: String){
    private(public read) var name: String = firstname + " " + lastname;
  }

As it turns out, it appears that this is not possible. You can only specify one access modifier on a variable, and that modifier applies to both the accessor and the mutator. So, making a variable 'private' implies a private accessor method, so the only way to make it read only is to add the boilerplate accessor:

  class Dude (firstname: String, lastname: String){
    private var name: String = firstname + " " + lastname;

    def name() : String = name

  }

Unfortunately, the compiler will reject that code, complaining that "Method name is defined twice". This is because the name of my special accessor method clashes with the name of the implicit accessor. Thus, I have to resort to using "special" names for my private variables, like so:

  class Dude (firstname: String, lastname: String){
    private var myName: String = firstname + " " + lastname;

    def name() : String = myName

  }

It seems to me that this restriction would tend to push one toward adopting coding conventions for naming private variables in such cases. This would almost surely consist of adding superfluous characters to the variable name. For example, naming all private variables with a leading underscore (yuk!). It just seems needless and confusing.

So, I'm faced with the prospect of both A) still having to code the accessor explicitly (albeit with a more finger-friendly syntax than java) AND B) having to come up with separate names for the 'internal' variable and the 'public' accessor. A is acceptable, but B is really crappy. It seems to me that they could solve B by having the compiler use any explicitly defined acessors instead of the implicit one (thereby avoiding the name conflict). If it made things easier on the compiler, I would be fine with some sort of 'implicit accessor override' syntax, like so:

  class Dude (firstname: String, lastname: String){
    private var name: String = firstname + " " + lastname;

    public def-read name: String = name;
  }

However, I prefer my "private(public read)" idea better, as it is more concise.

Terminator

This looks useful:

http://www.tenshu.net/terminator/