Category: Article

Introducing my Concours

Here is a photo of the 2005 Kawasaki Concours that I bought last week:

I can’t wait to get her cleaned up, my riding gear sorted out, and out on the road again.
Addendum: 08/29/10
The previous owner included some nice gear with the bike:

  • Rifle Windshield
  • Throttlemeister Cruise Control
  • GenMar Bar Risers
  • Cee Bailey Bag Liners
  • Mag’s Bags Gear Bag
  • Passenger backrest
  • CoverMax cover

Motorcycling Enterprises’ Safe Rider Course

Not having ridden for 12 years or so, I thought it would be good to get back in the saddle again with some off-street street-time and re-learning of good safety habits already under my belt. Luckily for me a slot opened up in Motorcycling Enterprises’ Safe Rider Course. It was a lot of fun.
The teachers provided excellent in-classroom and on-the-track training; balancing good exercises with 1-on-1 attention that made a big difference in how quickly you acquired the skill(s).
Unfortunately for others I’m sad to see that they are retiring this year. While there are plenty of MSF certified classes out there, I’m still hoping that their trainers decide to take over their business.

DrScheme Style Buffer Evaluation for OCaml in Emacs

When you want to evaluate code inside of DrScheme, you hit the F5 key and the entire editor buffer gets evaluated inside of a new REPL. Unlike Emacs, the ability to send the current expression, region, or buffer to the REPL isn’t available. It might sound constricting, but in practice it is very nice because you are always working with the most up-to-date versions of your definitions. It might sound slow to start a new REPL on each run, but it isn’t; on my older desktop the new REPL comes up before my finger even comes off of the F5 key. This approach seemed like a nice to have for working with OCaml in Tuareg mode on Emacs, so I pieced together a function to do so against Tuareg 1.45.6:

(defun tuareg-eval-buffer-drscheme-style ()
  "Send the buffer to a brand new Tuareg Interactive process."
  (interactive)
  (tuareg-kill-caml)
  (sleep-for 0.25)
  (if (get-buffer tuareg-interactive-buffer-name)
      (kill-buffer tuareg-interactive-buffer-name))
  (tuareg-eval-buffer)
  (switch-to-buffer tuareg-interactive-buffer-name))

Out of the box Tuareg mode will ask you what program name to run to start OCaml each and every time you evaluate the buffer, even when the variable storing that name is defined. I didn’t find a way to avoid this prompt so I patched Tuareg such that it will not ask you if a value is already defined for the program name. Here is the patch.
Thus far it has been nice to have the option of evaluating the whole buffer in a new REPL in addition to the existing incremental evaluation options.

Is OCaml's standard library its weakest link?

In this post I read that:

OCaml’s standard library is one of its weakest parts. Always use extensions to the std library.

Searching around the net I find ExtLib, Batteries, and Janestreet.
I’m not sure what “weakest link” meant in the original post so I will leave it wide open for any concerns that people have. Perhaps it means that it does not have enough functionality? Or slow? Or there is something odd about the APIs?
It is true that OCaml’s standard library is its weakest link?

Running Ocamlbrowser with OCaml 3.11.2 on Cygwin 1.72

After building OCaml 3.11.2 from source on Cygwin 1.72 I tried running ocamlbrowser and got the error:

Fatal error: exception Protocol.TkError("Can't find a usable init.tcl in the following directories:
C:/cygwin/share/tcl8.4
C:/cygwin/home/rettkeg/ocaml/build/ocaml-3.11.2/share/tcl8.4
C:/cygwin/home/rettkeg/ocaml/build/ocaml-3.11.2/usr/share/tcl8.4
C:/cygwin/home/rettkeg/o

The solution is can be found here:

export TCL_LIBRARY=/usr/share/tcl8.4

Windows XP RunAs feature is horribly broken

Switching back to Windows XP from the Mac has been educational. Along with learning a lot more about Cygin than I had ever known before, I’m discovering new features-to-be-avoided in Windows XP. Here is a biggie: “Run As”.
Windows allows you to execute programs with another user’s credentials. You are probability thinking “Simple right?”. Well, it isn’t. Using this feature seems to consistently corrupt the RunAs-ed user’s profile. Corrupted profiles seem to be a mysterious thing with little to no way to fix them; creating a new profile is basically the only solution. In my case I restored from a nightly backup (because I know stuff like this is bound to happen on Windows). My takeaway:
Disable RunAs on Windows!
Here is how.

How are DLLs used on Cygwin 1.7?

Over the weekend I needed to set up a R6RS Scheme interpreter on Cygwin. It came down to either PLT or Ikarus. Both seem to be straightforward builds but I couldn’t make PLT happy so I went with Ikarus instead. It was a very simple and straightforward configuration and took maybe a minute to build. Once things were clearly working fine I figured I would try to get some of Ed’s OpenGL (box2d-lite and agave) demos running just for the fun of it.
Both of the programs depend on the GL and GLUT libraries. At runtime the correct DLL is loaded depending on the OS type. There wasn’t a setting for Cygwin so I added one. The thing was that I specified the wrong file name: /usr/lib/libGL.dll.a and /usr/lib/libglut.dll.a.
It was an uneducated guess in the first place. I figured there would be a one to one mapping. After Marco kindly kicked my butt on the Ikarus list though, by asking some basic questions like has it ever worked and have I checked out the difference in error messages, I got me thinking that I should have read up on this.
The Cygwin documentation here and the Redhat documentation here seem to explain it… Windows DLLs need additional information to be linked against. On Cygwin, when GCC sees .dll.a files it “knows” how to get the additional data out of them in case you want to link to Win32. Reading on in the Redhat documentation, it lists the DLL search path when you specify -L argument for GCC. In that list I saw that /bin is included. That surprised me.
It turns out that on Cygwin, DLLs that are not compiled to work with Win32 are located there. At least, this is my understanding. When you link to these DLLs though, the OpenGL demos work just fine on Cygwin with Ikarus.
Is this also your understanding? I need to dig in more to this topic.
I had been trying to get so many things working this weekend that I didn’t invest the amount of the time that this deserved, or most of those things for that matter.