Absolute path resolver

I was looked for some utility to resolve absolute path of file or directory. I found namei but it result returns in form

$ namei /etc/gdc
f: /etc/gdc
d /
d etc
l gdc -> /home/hynek/.gdc
d /
d home
d hynek
l .gdc -> work/tiger/bear/common/etc/gdc
  d work
  d tiger
  l bear -> bear.trunk/
    d bear.trunk
  d common
  d etc
  d gdc

but I suspected something more like

$ abs_path /etc/gdc
/home/hynek/work/tiger/bear.trunk/common/etc/gdc

I haven't found anything better than make alias in my ~/.bashrc

alias abs_path='perl -MCwd -le'\''print Cwd::abs_path($_) foreach @ARGV'\'

Edit: As ZD notice readlink -f does same work. Thanks. readlink -m and readlink -e works as well but differs if some parts missing. I have decided to use

alias abs_path='readlink -m'

Erlang history summary by J. Armstrong

Joe Armstrong posts nice summary of Erlang history.

The transition was easy - they paid to do this. It became a real shipping project when they decided to use Erlang for the AXD301 - at that stage they put in the necessary $$$'s.

Now why did they choose Erlang for this project? - because all other alternatives had failed - ie it was not the strength of Erlang that was the deciding factor - rather the non-existence of alternatives.

Now how come the Erlang stuff was developed in the first place?

This was a happy accident - In the early 1980's a computer science lab was formed - most of the guys in the newly formed lab had zero experience with technology transfer, so we all thought that all we had to do was "invert stuff" and then "sell the idea to the management" nobody told us that this was like permanently banging your hand against a brick wall.

Inventing stuff is the easy bit ...

The selling stuff was tricky - we were very bad at this but very optimistic (still am :-) - we made all the classic mistakes - insulting people - getting into technical wars -

The turning point came when Erlang was banned - at the time we were very pissed off but like most carefull considered management decsions the net result was the exact opposite of what was planned - the consequences of the ban were difficult to forsee - but chaos was created - so things changed rapidly.

Thinking back the *important* things were:

• enthusiasm and optimism (believe in what you do)
• serendipity
• chaos
• smart people
• finance

I think we systematically under-rate the significance of chance and chaos. Most significant change takes place in very short time periods of chaos. Erlang had many periods when nothing happened for years then rapid changes could take place in very short time periods, always when a crisis occurred (ie Erlang was banned, a big project failed etc).

Moral - forget about careful planning and move quickly when a crisis occurs - trust your gut feelings.

Cheers

/Joe Armstrong

History of Erlang

Joe Armstrong wrote nice article about Erlang History. It's worth reading whole article but I found most funny and nice part it's end.

6.4 Finally

It is perhaps interesting to note that the two most significant factors that led to the spread of Erlang were:

• The collapse of the AXE-N project.
• The Erlang ban.

Both of these factors were outside our control and were unplanned. These factors were far more significant than all the things we did plan for and were within our control. We were fortuitously able to take advantage of the collapse of the AXE-N project by rushing in when the project failed. That we were able to do so was more a matter of luck than planning. Had the collapse occurred at a different site then this would not have happened. We were able to step in only because the collapse of the project happened in the building where we worked so we knew all about it. Eventually Ericsson did the right thing (using the right technology for the job) for the wrong reasons (competing technologies failed). One day I hope they will do the right things for the right reasons.

My interests

Matin Hassman in his blog post wrote about the Wordle. This is nice toy tool to for generating “word clouds” from text. I have generated two from my bookmarkas and shared items in google reader.

Bookmarks

Shared Items

Beust Challenge in Erlang

There was a challenge posted by Cedric Beust. I tried reuse my older solution of permutation generator and aplly this aproach on this issue. Here is result:

-module(cbchallenge).

-export([test/1]).

combine(Sufix, 0, Acc, _L) ->
   accept(list_to_integer(lists:reverse(Sufix)), Acc);
combine(Sufix, N, Acc, L) ->
   combine(Sufix, N, Acc, L, []).

combine(_Sufix, _N, Acc, [], _D) -> Acc;
combine(Sufix, N, Acc, [X | T], D) ->
   combine(Sufix, N,
     _NewAcc = combine([X | Sufix], N - 1, Acc,
         lists:reverse(D, T)),
     T, [X | D]).

accept(X, {Count, undefined}) -> {Count + 1, {X, 0}};
accept(X, {Count, {Last, MaxDistance}})
   when X - Last > MaxDistance ->
   {Count + 1, {X, X - Last}};
accept(X, {Count, {_, MaxDistance}}) ->
   {Count + 1, {X, MaxDistance}}.

count(Log10) ->
   {Count, {_, MaxDistance}} = combine([], Log10,
     {0, undefined}, lists:seq($1, $9),
     [$0]),
   {Count, MaxDistance}.

test(MaxLog10) ->
   lists:foldl(fun (Log10, AccIn) ->
   collectResult(count(Log10), AccIn)
  end,
  {0, 0}, lists:seq(1, MaxLog10)).

collectResult({Count, Max}, {OldCount, OldMax})
   when Max > OldMax ->
   {OldCount + Count, Max};
collectResult({Count, _}, {OldCount, Max}) ->
   {OldCount + Count, Max}.

It is more than twice faster than Kevin's crazybob solution on my laptop (kevin ~18s, mine ~8.5s).

> [{X, timer:tc(cbchallenge, test, [X])} || X<-lists:seq(1,10)].
[{1,{16,{9,1}}},
 {2,{52,{90,2}}},
 {3,{420,{738,11}}},
 {4,{3073,{5274,105}}},
 {5,{20019,{32490,1047}}},
 {6,{105757,{168570,10469}}},
 {7,{459955,{712890,104691}}},
 {8,{1587747,{2345850,1046913}}},
 {9,{4522205,{5611770,10469135}}},
 {10,{8563146,{8877690,104691357}}}]

I guess, there is much more faster solution closer to original crazybob's solution which is arithmetical and applicable just only to numbers. My approach is applicable to any non repeated combination of members of any set, but slower.

Arc - mostly macros and syntactic sugar

Stefan Tilkov said about Arc:

After a quick glance at the tutorial, the most intriguing bit seems to be the support for macros, which work (almost) like function definitions. Interesting, but nothing that gets me overly excited.

I have same experinece. I read tutorial two days ago and I think it is mostly only scheme with macros and syntactic sugar. I am not so much familiar with lisp and scheme, but I think there is nothing what can't be done almost same simply in scheme or other lisp dialects. Updated: Steve dekorte think similar:

My own impression of Arc is that it's not significantly different from Scheme.

How much cores are using WF solutions

Tim Bray published WF XI: Results and I would like to know how much of all these CPU cores each solution uses. Than I compute this table:

Name            Language    Elapsed     User        System  Parallel CPU work
-----------------------------------------------------------------------------
clv5            Gawk        46.73       40.63       6.1         1
tbray5          Erlang      01:04.32    35:33.35    00:45.84    33.88
wfinder1_1      Erlang      6.46        34.07       8.02        6.52
report-counts   Ruby        01:43.71    01:27.11    00:16.60    1
?               Groovy      02:21.83    02:22.97    00:19.95    1.15
wf_p            Ruby        50.16       37.58       12.5        1
wf-2            Python      41.04       34.8        6.24        1
wf-6(2)         Python      16.91       3.62        1.86        0.32
wf-6(4)         Python      9.08        3.66        1.89        0.61
wf-6(8)         Python      5.81        *           *           *
wf-6(16)        Python      4.38        *           *           *
wf              OCaml       49.69       41.94       7.75        1
widefinder      PHP         01:29.81    01:23.10    00:06.71    1
wf_pichi3       Erlang      8.28        51.98       9.38        7.41
tbray5          Erlang      00:20.74    03:51.33    00:08:00    34.3

Nice, that erlang implementations can use cores well, but in this task is not so much good generally. Erlang manages parallel processes well, but those processes can be better written in other languages and used as ports. Especially when this task is string operations on big amount of data.