Month: December 2006

The operator for modular arithmetic in Erlang is rem (for remainder). Took me a while to find that one.

Should you limit the width of your source code? You can’t read code
that goes off the edge of your screen. So your font size, resolution
and monitor all combine to produce a point at which you must break (or
at least wrap) your lines of code.

I don’t like wrapping. Lines of arbitrary length that wrap wherever
I happen to have positioned the right-hand side of my window seem
messy.

Even if you have plenty of room for more columns, standardising on a smaller number means that when reviewing code
you can see changes side by side using a difference viewer.

Given that I am going to insert a line break somewhere in my code,
where should it go?

There are many possible answers.

COBOL allows approximately 66 characters for code (72 columns – space
for line numbers).

Fortran has 72 usable columns from a maximum of 80.

xterm and gnome-terminal (among others) open 80 columns wide by
default. So does emacs.

vim allows 8 columns for line numbers, leaving 72 usable columns on
a standard terminal.

80 columns was built in to Apple //e motherboard.

Sun’s Code Conventions for the Java Programming Language say:

4.1 Line Length

Avoid lines longer than 80 characters, since they’re not handled well by many terminals and tools.

Note: Examples for use in documentation should have a shorter line length-generally no more than 70 characters.

The linux kernel seems to mostly be broken at 80 columns but there are plenty of exceptions (91-column example):

File: linux/drivers/firmware/efivars.c
Line:  749

        printk(KERN_ERR "efivars: Sysfs attribute export failed with error %d.
", error);

Some people definitely go wider than 80 columns.

If you want to be able to “> ” quote in an email on an 80-column terminal without wrapping, you’ll have to limit yourself to 78, or less for nested quoting.

GNUStep coding standards say 80 columns. So do other standards (cites printing as the reason, not screen space).

72 and 80 seem to have originated with punch cards, but are by far the most common standard. So, is 72 or 80 columns old-fashioned? Pointlessly restrictive? Or is it the One True Way? Make a comment and let me know what you think!

I have exchanged approximately 50 emails with eBay over my latest bill of 1.57 GBP and a 5.00 GBP charge they added for direct debit payment being refused by my bank (it was automatically cancelled after 12 months of inactivity as is standard banking practice – eBay are well aware of this practice). The situation is still not resolved.

I couldn’t have had this experience with eBay if they weren’t (effectively) a monopoly. Almost no other company could be this daft and unresponsive and still expect my custom.

This is the dark side of the network effect: because it makes sense for everyone to be on one auction site, the top auction site quickly becomes the only auction site. Consider this my request for an eBay-killer!

The Emails

20 Oct – Invoice for 1.57 with note that it will be taken by direct debit shortly.

07 Nov – Email telling me my direct debit was declined and that I have been charged 5.00 and now owe 6.57.

I reply asking why. I also hook up my account to pay by PayPal in future as another email requests.

10 Nov – Reminder that I owe 6.57

I reply asking them to remove the 5.00 and take the 1.57 by PayPal any time they like.

15 Nov – They reply telling me my direct debit was declined.

I reply asking which bank the direct debit was with.

17 Nov – They reply a second time to my original reply with the same standard email.

I reply asking them to remove the 5.00 charge as I haven’t cancelled a direct debit and take the balance via PayPal as they can do at any time.

19 Nov – They send the standard direct debit failure message for a second time.

I reply asking which bank account they think they were taking from.

20 Nov – billing send me the invoice again.

I reply, getting somewhat frustrated, with a plea for help, my telephone number and a third request for more details on the direct debit.

21 Nov – They send me a standard reminder for payment, again.

I reply asking for the direct debit details for the fourth time.

21 Nov – Customer Support email me telling me they are happy to help and can explain everything. It’s because my direct debit was declined (no details)!

I reply asking for the direct debit details for the fifth time.

23 Nov – They send me a third standard reminder for payment (fifth, if you include invoices).

23 Nov – Customer support finally send me the details of the direct debit. I call my bank and discover that they cancelled the direct debit because of 12 months of non-use which is, “standard banking practice” and, “any company would know this”. So why did eBay try to take payment from a direct debit that they know had not been used in 12 months?

I reply asking why they have tried to take money from an out-of-use direct debit and asking for 5.00 credit.

23 Nov – They send me the same identical email a second time 7 minutes later.

26 Nov – They send me a completely blank email.

I reply asking them to try again!

27 Nov – They send the standard direct debit failure message for the third time.

I reply explaining about the direct debit cancelled as standard banking practice and asking for credit.

28 Nov – They send me a fourth standard reminder for payment.

I reply explaining the situation and asking for 5.00 credit.

29 Nov – Customer Support tell me they have passed the query to Billing.

I reply saying thanks.

29 Nov – They send me a bizarre reply telling me they are happy to have me as a member and wishing me, “Happy Trading!”

01 Dec – They send me a fifth standard reminder for payment.

I reply explaining the situation and asking for a 5.00 credit.

At this point they somehow wake up and realise they can take the money by PayPal. They take all 6.57.

03 Dec – Customer Support send me the “no instruction” email explaining why a direct debit might have been refused. Reason (1) is: “Direct Debits which have been out of use for a year or more may be automatically cancelled by your bank due to inactivity.” So they do know this happens! They just try to take payment anyway!

I reply explaining that reason (1) is the reason and asking for 5.00 credit.

03 Dec – They send me the standard direct debit refused email for the fourth time.

I reply explaining the situation and asking for 5.00 credit.

04 Dec – They reply to one of my emails asking for credit as if they haven’t read it and saying thanks for the payment it’s all sorted out now. They also tell me to disregard demands for payment because they are, “system generated”.

I am now in despair. I reply threatening Trading Standards and to contact the BBC’s Watchdog program. And explaining the situation, and asking for 5.00 credit.

05 Dec – They send me the direct debit refused email for the FIFTH time.

06 Dec – They send me the “no instruction” explanation email for the second time.

I flip out and send them a mostly-caps response begging for someone to understand me, or call me, or something. It contains the line, “COME ON I DARE YOU, SEND ME AN INTELLIGENT REPLY!”

07 Dec – Customer Support email me telling me that I will get a credit. Although they also suggest contacting my bank to find out why and include other information that is clearly redundant if they had read the email they are replying to I don’t care because I have finally made the breakthrough!

09 Dec – Customer Support reply telling me I will be credited 5.00 shortly and apologising for the delay.

I reply saying thanks.

10 Dec – Customer Support writes to me telling me that it is up to the member to make sure direct debits work and that I won’t be getting a 5.00 credit. This is in reply to my email of 01 Dec, not any of the subsequent ones, so I’m not sure how seriously to take it.

Update 2007-12-13 Email 47 – Customer Support send me the “apology for delay” email for the second time.

Update 2007-03-21: Sent a few more emails in January and a couple more in February and kind of gave up on the whole thing. They just gave me five pounds credit (not refund) this morning.

When a run-time error occurs,
that is an exception of class error,
the exit reason is a tuple {Reason,Stack}.
Reason is a term indicating the type of error:

Exit Reasons.

Reason	Type of error
badarg	Argument is of wrong type.
badarith	Argument is of wrong type in an arithmetic expression.
{badmatch,V}	Evaluation of a match expression failed. The value V did not match.
function_clause	No matching function clause is found when evaluating a function call.
{case_clause,V}	No matching branch is found when evaluating a case expression. The value V did not match.
if_clause	No true branch is found when evaluating an if expression.
{try_clause,V}	No matching branch is found when evaluating the of-section of a a try expression. The value V did not match.
undef	The function cannot be found when evaluating a function call.
{badfun,F}	There is something wrong with a fun F.
{badarity,F}	A fun is applied to the wrong number of arguments. F describes the fun and the arguments.
timeout_value	The timeout value in a receive..after expression is evaluated to something else than an integer or infinity.
noproc	Trying to link to a non-existing process.
{nocatch,V}	Trying to evaluate a throw outside a catch. V is the throw term.
system_limit	A system limit has been reached. See Efficiency Guide for information about system limits.

Stack is the stack of function calls being evaluated
when the error occurred, given as a list of tuples
{Module,Name,Arity} with the most recent function call
first. The most recent function call tuple may in some
cases be {Module,Name,[Arg]}.