You are viewing archaelus

Previous 10

May. 20th, 2008

iCal, iSync, displayAlarms, so much hate

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 to in {
    "" = Basso;
    "" = "";
    owner =     (
    sound = Basso;
    triggerduration = -1200;

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


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

Feb. 8th, 2008

Tracking Erlang/OTP

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.

2007-05-03 When should I write a gen_server?

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

Nov. 19th, 2007

2007-11-19 Debian Linux ulimit -n nofile madness

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.

Jun. 28th, 2007

2007-06-28 And this is why you want Erlang

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@> Pdu = <pasted data>.

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


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.

Jun. 23rd, 2007

2007-06-23 lolcat

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

Jun. 13th, 2007

Posted using LJ Talk...

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 :)

May. 31st, 2007

2007-05-31 MORE CORES!

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.

May. 30th, 2007

2007-05-30 Paul Vixie on DNS

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

May. 23rd, 2007

2007-05-23 apt-get hatred (Fix that darn control file)

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.

Previous 10