How to eject CD drive in OS X

Press F12 for a few seconds.

Then (hopefully) your CD (or DVD) drive will eject.

Wait, why is this considered "not in the manual" ?

Well, today I had to insert a DVD into my optical drive but its physical eject button was not working anymore.

Since I was booted into OS X at the time, I decided to look around for any sign of said optical drive.

But no. Nada. Zip.



This simple & intuitive task in Windows & Linux proved to be surprisingly complicated in OS X. Funny (well ... not at the time though).

So, I went to the Terminal and typed :

eject /dev/cdrom

It replied saying "eject" wasn't found. True enough, the following returned zilch :

find / -name 'eject' -print

Finally succumbed and Googled instead. Then stumbled upon the F12 trick.

Of course once the optical drive isn't empty, then only Finder displays it as a mounted drive !



This, from a premium priced boutique OS :/

I have other gripes concerning OS X but I'll save it for later (... the fan boys are everywhere)

Solution to "Invalid thread access" in eRCP

In Embedded Rich Client Platform, i.e. eRCP, an "Invalid thread access" exception is produced when any class that extends ViewPart executes a new thread the conventional way in method

public void createPartControl(Composite parent)

What do I mean by "executes a new thread the conventional way" ? Well here's an example (let's say we have a class or subclass WeatherData which implements Runnable) :

// This will produce an "Invalid thread access" error
Thread thread = new Thread(new WeatherData());

To eliminate the "Invalid thread access" issue, use this instead :

parent.getDisplay().syncExec(new WeatherData());

Interesting PushRegistry behaviour in Nokia N95

Based on my observation, the PushRegistry feature in Nokia N95 acts unpredictably when the device misses one or more SMS meant for a listening port, i.e. most probably because the device was switched off.

Perhaps a little story would be in order :)

OK, say on your Nokia N95 device, there is a MIDlet which listens for incoming SMS at port 8044.

Now lets send a series of SMS targeted at port 8044 above.

SMS A was sent to the device when it was switched on. MIDlet wakes up ok.

Let's switched off the device.

Send SMS B to said device

Send another SMS, C.

And another one, D.

Now switch on the device.

Your MIDlet may or may not be awaken at this point (even if it does wake up, the content you get may come from either SMS B, C or D !).

A new SMS, E, is sent to the device.

Now you'll discover that the MIDlet will wake up but the contents you see may come from SMS B, C, or D.

Let's say when E was sent, your MIDlet displays content from B instead, not the one in E.

Now another new SMS, F, gets pushed to the device. You'll discover that the contents of SMS C will be displayed instead of the one in F ! (Interestingly if SMS E, resulted in D being displayed, then SMS F will display the contents in SMS E.)

As you can see, the order is intact i.e. SMS B followed by C etc. However, you're not getting the actual SMS which wakes up the MIDlet.

Weird. Very very weird.

Is it a firmware bug ? Could it be the carrier ? Honestly I can't be sure :/

Solution ? Uninstall & reinstall the MIDlet (and ... no, rebooting the device doesn't work either)

Of course once your MIDlet misses an SMS targeted for its PushRegistry port, then the issue pops up again. Hence, there is no solution really :(

"Must be Server" error from PushRegistry with sms

Whew ! Took 2 days to figure this out.

Recently attempted to create a MIDlet which wakes up on SMS using the PushRegistry feature in Java ME.

Kept getting "Must be Server" error at the

mc.receive()

line in following code snippet :

if (url.startsWith("sms://")) {
    MessageConnection mc = (MessageConnection) Connector.open(url);
    Message msg = mc.receive();
    String data = "";
            
    if (msg != null) {
        if (msg instanceof TextMessage) {
            form.append("TextMessage\n");
            data = ((TextMessage)msg).getPayloadText();
        }
    }
}

Turns out the JAD file of said MIDlet has the following incorrectly typed PushRegistry entry :

MIDlet-Push-1: sms://8033, org.whatever.Poink, *

There should be a ":" after the 2 "slashes" like so :

MIDlet-Push-1: sms://:8033, org.whatever.Poink, *

After the above fix, the "Must be Server" disappeared :)

Probability notations made simple

OK, this ain't Java. Nonetheless this article by Eliezer Yudkowsky really helped in me understanding probability notations (those "|" and "&") as used in Bayesian theory by presenting actual problems instead of the usual Math gobbledygook. Here's a quote :

... p(Q|P) is the proportion of things that have property Q and property P 
within all things that have P; i.e., 
the proportion of women with breast cancer and a positive mammography within 
the group of all women with positive mammographies.

If there are

641 women with breast cancer and positive mammographies,
7915 women with positive mammographies, and
89,031 women,

then p(Q&P) is the probability of getting one of those 641 women 
if you're picking at random from the entire group of 89,031,

while p(Q|P) is the probability of getting one of those 641 women 
if you're picking at random from the smaller group of 7915.

Here's another quote :

In a sense, p(Q|P)really means p(Q&P|P), but specifying the extra P all the 
time would be redundant.  You already know it has property P, so the property 
you're investigating is Q - even though you're looking at the size of group 
Q&P within group P, not the size of group Q within group P (which would be 
nonsense).  

This is what it means to take the property on the right-hand side as given; 
it means you know you're working only within the group of things that have 
property P.  When you constrict your focus of attention to see only this 
smaller group, many other probabilities change. If you're taking P as given,
then p(Q&P) equals just p(Q) - at least, relative to the group P.  
The old p(Q), the frequency of 

"things that have property Q within the entire sample", 

is revised to the new frequency of 

"things that have property Q within the subsample of things that have property P".

If P is given, if P is our entire world, then looking for Q&P 
is the same as looking for just Q.