archaelus

tell application "iCal" you FAIL AT LIFE!!!!111!!!one
end tell.

So. iCal refuses to sync properly, saying:

2008-05-20 17:02:17:870|iCalExternalSync|945|10a640|Miscellaneous| SyncServices precondition failure in [ISyncInstrumentedSession pushChangesFromRecord:withIdentifier:]: you can't change the record's entity name from com.apple.calendars.DisplayAlarm to com.apple.calendars.AudioAlarm in {
    "com.apple.ical.sound" = Basso;
    "com.apple.syncservices.RecordEntityName" = "com.apple.calendars.AudioAlarm";
    owner =     (
        "Event/p146"
    );
    sound = Basso;
    triggerduration = -1200;
}

As far as I can tell, all my display alarms are FUBAR and need to be purged.

Violently.

And believe me I've tried every icbu backup/restore, synchrospector munging, pull the truth, sync forcing trick I can think of.

Applescript to the rescue:

tell application "iCal"
	repeat with myevent in every event in every calendar
		set dispAlarms to count of display alarms in myevent
		if (dispAlarms) > 0 then
			log "Found event with display events"
			log (get summary of myevent)
			log dispAlarms
			delete display alarms in myevent
			log (get count of display alarms in myevent)
		end if
	end repeat
end tell

tell off corporation "Apple"
     if (you can't let me recover from sync errors without writing applescript) then
         castigate "Apple" with "You fail at life too."
     end if
end tell off

I'm going to try tracking the Erlang/OTP source tree and the helpful posts on erlang-patches in my git repository. I already have to do this for macports - odbc still doesn't really build out of the box on Mac OS - and the main configure script needs a few --with-gd=/Library/DarwinPorts arguments for my idiosyncratic macports installation.

I also have a few odd patchsets, such as Ulf Wiger's gproc - an extended process registry for OTP systems that I hope will one day be included in the standard distribution.

Maybe I could add the EEPs as branches too.

I’ve been writing Erlang code for a little while now and generally stick to OTP style systems. I find that I have a subconcious set of rules for deciding what kind of process to build for particular tasks - below are some of the guidelines I’ve come up with. This list is incomplete and I’d greatly appreciate feedback on it.

Signs you should write a gen_fsm:
* Your process responds to the same message in (radically?) different ways depending on the current state.
* You need to manage a collection of timers that depend on what state the process is in.

Signs you should write a gen_server:
* Your process always reponds to the same message in the same way.
* You mainly do a request-reply (call) style operations
* You're going to give the process a registered name.
* Your process is not going to trap exits
* Your process will be long lived
* Your process will be started by a supervisor

Signs you should write a gen_event:
* You want to modify SASL log handling.
* ???

Signs you should write a plain old process:
* You don't listen for requests from other processes (except perhaps replies)
* You don't fit neatly into any of the other boxes
* You are a worker process that makes blocking requests to other processes
* The rules for starting or restarting the process are complicated.
* The process does a number of different activities during its lifetime

So you want to increase the maximum allowed number of file descriptors per process under debian linux?
Edit /etc/security/limits.conf and add a line like “ - nofile -”. Which means set the hard and soft (first “-”) nofile limits to unlimited (second “-”).

To test, restart sshd then log out and back in. You should now see ulimit -n unlimited when you run “ulimit -a”.

Note: The sshd restart is important if you’re testing this remotely - the visible ulimits won’t change until you restart sshd, logout and log back in.

Tags: debian, rant, ulimit

I've had one of these “And _this_ is why you want erlang” moments.

I have a system under test which it's not convenient to recompile right now (I'm doing exploratory experimental surgery on the codebase and not using git as much as I should). I finally have the client connected to it and it starts crashing. Hmm. Read the OTP logs...

(erms@testbox)> rb:rescan([{max, 20}]), rb:show().

...

exited: {undef,[{erms_smpp,pdu_to_msg, [...]},...]}

...

Right. Missing function. Could have sworn I wrote that. Check dev box. Yup - sure did. Left it out of the deployment. Boh. MaHa!

devbox $ scp ebin/erms_smpp.beam testbox:

(erms@testbox)> code:load_abs(”/home/me/erms_smpp”).

Hot code loading saves my bacon once again.

Hmm, system still not looking right - messages are delaying an hour before delivery. Hrm. Time to fire up the text mode debugger from the runtime_tools package.

(erms@testbox)>  G = group_leader(), dbg:tracer(process, {fun(M,_) -> io:format(G, “~n~p Trace: ~p~n“, [calendar:local_time(), M]), 0 end, 0}).

(erms@testbox)> dbg:tp(erms_smsc,handle_operation, dbg:fun2ms(fun ([{submit_sm, _, Pdu}, _, _]) -> Pdu end)).

(erms@testbox)> dbg:p(whereis(erms_smsc)).

These calls set up a tracer that writes messages like “<time> Trace: <message” to the console (in my case a remote shell, hence the fancy group_leader bits), sets a trace on calls to erms_smsc:handle_operation with a match spec looking for submit_sm arguments, and sets trace flags on the 'erms_smsc' process.

... Lots of trace data ...

... call to submit_sm with the Pdu we want ...

Now I can copy the literal Pdu (the important piece of data that has the delivery and expiry times that are getting confused), and paste it to a local node and examine it closely.

(erms@127.0.0.1)> Pdu = <pasted data>.

(erms@127.0.0.1)> erms_smpp:pdu_timing(dict:from_list(Pdu)).

{undefined,{{2007,6,28},{5,24,28}}}

Well, erms_smpp seems to have the Delivery and Expiry times the right way round. Hrm. I wonder if erms_smsc is swapping them. *check source* Yup, sure is.

*hackety clickety fixety*

scp ebin/erms_smsc.ebin testbox:

(erms@testbox)> code:load_abs(”/home/me/erms_smsc”), code:purge(erms_smsg).

*watch trace data*

(erms@testbox)> rb:rescan(), rb:show().

And now we can confirm it's fixed. Time to shut down the tracing.

(erms@testbox)> dbg:stop_clear().

Now I can sit back, relax, and lament that if my next project isn't in erlang I'm going to have to fall back to stone-age print-f style debugging.

Ok, fine - I too have succumbed to lolcat syndrome....

There's a cat licking my head. (It's certainly weird, but oddly not as distracting from erlirc hacking as I thought it would be :)

Note to self: Must find out if Erlang runs on Octeon MIPS64 chips, because if it can then there are lots of options for high density computing.

8 Cores / U
You can already buy standard 2U boxes with single Octeon chips (16 cores) in the Lanner MR-950 or the Movadis Revolution X16 box - this works out to 16 Cores per box for 8 Cores / U. (Or a Portwell KLIN-6030 or KLIN-6020)

16 Cores / U
Upon closer inspection of the datasheet, the X16 has a 1U option for the same 16 chip. Bah, too easy.

32 Cores / U
Can we go to 32? I could get all the cores/rackunit in the world by sticking Lanbird NS0216s into a 2U AdvancedTCA chassis (example from ELMA). That's something like 64 MIPS64 cores in 2U of rackspace.

Portwell sells a 5U 5 ATCA card chassis which gives 32 Core / U.

Or with AMC format gear you could take a 2U 4Slot Chassis and stick 4 Radisys Promentum AMC-7211 cards into it. This again gives 32 cores per unit of rackspace. Can we do better?

64 Cores / U
24 Radisys AMC Cards in an Artesync EMC6200 gives 64 Cores per U (6U chassis)?

Anyway, enough drooling over ludicrous numbers of processors. Back to work.

Paul Vixie has written an article that explains the internet's domain name system (DNS).

apt-get install <something>
...
Reading Package Lists... Done
Building Dependency Tree... Done
You might want to run `apt-get -f install' to correct these:
The following packages have unmet dependencies:
...

So, I installed a package with unmet dependancies (i.e. I know that the dependancies in the deb are too strict and the installed versions will surfice - etch package on sarge that depends on not particularly different libc and not a lot else). Apt now refuses to install anything because it's whining about allegedly broken dependancies. (Also, what on earth was dpkg --force-dependancies doing if not... forcing the dependancies?!?)

apt-get -f install
Would you like to remove the packages you went to a lot of trouble to install? (Y/n/NO. NO! WHY WOULD I WANT THAT)

The suggested resolution method is... unhelpful (unless you did all this by accident I suppose, or someone else did it to you).

EVIL Plan: Modify the dependancies of the deb! MUAHAHAHAHA!
dpkg-deb --extract <deb> <directory>
vim <directory/DEBIAN/control
echo “MUAHAHAHAHA I'm modifiying your dependancies HAhaHa etc.”
dpkg-deb --build <deb> <directory>
dpkg -i <deb>
echo “Sweet sweet victory is mine!”

apt-get -f install
Everything is fine.
You win.

And now a plea to package maintainers: please don't specify the exact version of common libraries (such as libssl and libc) that you have on your system as the minimum - it makes back porting unnecessarily hard.

Paul Mackay's article on “Why has the actor model not succeeded?” is interesting reading for an Erlang programmer. Coming to Erlang from an object oriented(ish) background, I've come across the problems with not being able to inherit behaviours when writing actors/erlang processes.

S is for simple more or less sums up my experience of SOAP. I probably wouldn't be quite so polite.

Bill de hÓra sums up with this on the entire WS-* process.

I just saw Hugh Darwen's “Having a blunderful time” article on reddit and thought I'd share.

In this email, Ulf Wiger illustrates the differences between using process dictionaries and ETS tables:

Comparing the process dictionary an ets, there are
pros and cons with each:

- process dictionary is a linear hash table, like
ets sets (but not exactly the same implementation)

- there's no copying when accessing the process
dictionary, but then again, there is GC. With ets,
it's the other way around. (We have code where the
process heap is sized so that all garbage of
short-lived processes fits on the heap. This means
no copying - no GC).

- ets tables can be made to survive a process crash
(by making some other process the owner). This can
be a good thing, but forces you to use public ets
tables (bad thing). I believe most ets tables in
use are public, which in a sense makes them worse
than the process dictionaries.

- On a few occasions, it is actually useful to let
several processes write to the same ets table,
but in most cases where it's contemplated, it's
a very bad idea.

- The contents of the process dictionary is included
in crash reports, while the contents of ets tables
are automatically wiped out when the owner dies -
bad for debugging, unless you make another process
the owner, and make the table public, so you can
write to it (which means everyone else can write
to it too - bad)

- Of course, storing huge amounts of data in the
proc dict is bad because (a) it's GC:d, and
(b) all the data is dumped into the SASL crash
reports, which are (by default) pretty-printed
to the tty - potential diaster.

- ets has much better search and fold facilities
(the process dictionary has practically none).

- Allowing many processes to write from an ets
table _can_ be very useful. This could be done
with the process dictionary as well, but at
the moment, the only option available is to
read the entire dictionary at once (through
process_info(P, dictionary). This involves
a copy, btw, just like with ets.

I found a link to Hakan Mattson's Mnesia internals slides on erlang-projects today. It's pretty interesting reading about the different distributed transation manager protocols in use in Mnesia, but I think the slides would benefit greatly from having Hakan's talk to go with them.

Mr. Language Person would probably endorse these products and/or services:
• The Guardian Unlimited Style Guide
• The Economist Style Guide

Rinkworks has an interesting article on contranyms - words that are their own antonyms.

Dylan is alive and well - Network Night Vision is a new Wireshark-like network protocol sniffer GUI written entirely in open dylan. Now if only there were a Cocoa backend for DUIM.

I endorse the following products and/or services:
• Sam Flynn Scott
• Age Pryor, Octopus, Jazz Firefly
• Dylan Moran

Though I'd endorse them even more if they'd actually update their respective websites... Seriously, why do I have to keep an eye peeled for new posters around town to keep up with gigs? The dark pre-internet times want their non electronic information transfer methods back.

At last, a version of distel (erlang IDE/interaction for Emacs) that really works (for me :) !
http://code.google.com/p/distel/

It doesn't have wrangler (and thus fancy refactorings), but not having to exit emacs to interact with a running erlang system is just plain cool.

Age Pryor just played a gig at Mighty Mighty to celebrate the release of his new album Shanks' Pony.

Age and co. played all the songs from the new album, some old favourites from Fly My Pretties and coaxed Tessa Rain up on stage for their ever amazing King Of You All. Go buy Shank's Pony - King of you all is worth it alone :)