HowTo Fix: MacBook Pro and Dell 2711 DisplayPort Issues

I chose to get the Dell U2711 mostly due to PC compatibility and price advantages over the Cinema Display. However, having a MacBook Pro I wanted to also connect it to  my nice display. I ordered a Mini-DisplayPort to DisplayPort cable and all worked fine until one day it didn’t. The screen was black and no signal was being delivered between my MacBook Pro and the display. I tested with my girlfriend’s computer and the problem persisted. I ordered yet another cable and the problem still persisted!

I knew something was wrong with the display. Finally I solved my problem in the most simple way:

While the monitor was on, I pulled the U2711′s power cable and waited about 15-30 seconds. I plugged the monitor back in and switch to DisplayPort and it worked perfected!

Obviously something is wrong with Dell’s monitor in this instance, but this simple fix should help everyone having headaches with this like me.

HowTo Fix: Slow SSD Boot Times in Mac OS X

I recently bought a ssd for my macbook pro and noticed after installing and reformatting, the boot times were slow … about as slow as my hdd or even slower. If you have an SSD, you can except boot times around 15 seconds or so. If you are encountering boot times of 35+ seconds, you may have the same problem I had. I was able to solve the problem by following these steps:

1. System Preferences -> Startup Disk. Make sure that your SSD drive is selected.
2. Open Disk Utility and select your drive, and click “Repair Disk Permissions”
3. Reset your PRAM
4. Reset your SMC

The final step of reseting the SMC finally fixed this for me, but I had tried all the steps before hand, so I cannot be sure which will work for you. If you have any comments, please post for the benefit of all readers.

Identity and The Transporter Problem

I recently had a discussion with some colleagues at work about Star Trek and the Transporter Problem. I’m sure if you stumbled across this article, you likely understand what the Transporter does on Star Trek. The problem is the question of whether or not such a device, one that makes you disappear and reappear somewhere else, actually kills the first person.  Commonly phrased: Is the person who comes out of the transporter, the same one who stepped in?

Read More

Type Hiding With “Template Impl” Pattern

I recently encountered an design requirement for a library which required relatively fast handling of certain callbacks. I wanted, if possible, to avoid any vtable lookups introduced by virtual function calls. The scenario goes like this:

There exists a class called Connection. Connection will receive data from the network and handle certain message events (it is responsible for parsing and getting these messages from the network somehow). On certain messages, it relies on a delegate object to act as a functor or handler it can invoke callbacks on. These callbacks will handle and future processing of handling of the messages. Also, since these methods get called frequently, we want these calls to be as fast as possible, i.e. avoid function calls. The question is, can we create Connection such that he invokes callbacks without vtable lookups and such that we can create multiple instances of him and store them all in a common Connection collection? The answer is yes, with a little bit of ingenuity.

The trick lies in using Pimpl idiom and some templating. Here is an example:

Connection.h

class Connection {
public:
  template<typename T> Connection(const T & callbackobj);

private:
  class Impl;
  Impl * impl_;
};

Connection.cpp

#include "Connection.h"

class Connection::Impl {
};

template <typename T>
class NotifyingImpl : public Connection::Impl {
public:
  NotifyingImpl(const T & cbobj) : cb_(cbobj) {}

  void handle_message(const T & m) { cb_(m); }

private:
  const T & cb_;
};

template<typename T> Connection::Connection(const T & cbobj) : impl_(new NotifyingImpl<T>(cbobj)) {}

What we’ve done here is taken advantage of the implementations polymorphism to allow the storage of internal templates in a common template-free container. So long as the calls and behavior of NotifyingImpl does not need to be exposed in Connection’s interface, we need not expose it to the user and it is free to deal with any other classes. Only the contructor need know at compile time what possible “implementations” it will be created with. The internals will be self managed. This way the callbacks in NotifyingImpl will be fast. If our Connection requires an interface that needs to interact with NotifyingImpl, we will have to create virtual methods since it will require run-time analysis of which possible (of many implementations) to use and we don’t know the type when calling. Alternatively, we can take the pseudo-CRTP route and fake them passing the template parameter around with each method and casting (though we had better be sure we get the types right).

This model is useful since it separates having to statically know the handler type or define a virtual interface, so we can still perform testing cleanly.

Note: you’ll have to reference included the Templated Impl in the header or include the cpp file when you build, since all template definitions need to be known before you build object files (remember the compiler is creating code for you).

I find this method useful when the implementation needs to handle callbacks quickly and you don’t need to expose this in the interface or need to store multiple implementations in a single stl container.