Minamalist

I like small software.

Remember the metric "LOC"  ( Lines Of Code).   That's not a battle cry;  I have no desire to return to that era.

I used to drive managers crazy when asked how many lines of code it would take to implement a feature.
Q:  How much larger will the code base be?
A:  It will be smaller.

How can you measure an employee who gives answers like that?  Do we penalize them for reducing the inventory?  What about the answer "None".  It's not needed;   it's already in the base product.  We need to document it.

Is that zero productivity, or infinite productivity?

Looking at the script I wrote to extract dbx from the Oracle Studio Distribution, I questioned why I did it that way.  The motivations were:

  • To retain the original structure of the distributed product.
  • To permit the code to be patched;  Studio patches would expect the original  directory layout?

Nah ... you're not going to buy Oracle Support for 22MB of code, are you. 
We don't need to be a slave to the original directory structure imposed by tar.
How can we make this more simple, and easier to understand.

I wrote a script ( dirstats ), to provide metrics on a distribution directory.
Here are the results for the full Studio 12.3 extraction from the downloaded tar file:

bash-2.05$ time dirstats studio12u3
   Size    Dirs   Links   Files Path
   1.6G    1049    4255   10056 studio12u3

Now the A/B test for the dbx extraction:

bash-3.00$ dirstats studio*
   Size    Dirs   Links   Files Path
    22M      34      28      53 studio12.3
    16M      20       4      32 studio12.3a  # 64-bit dbx failed.
    17M      22      11      44 studio12.3b  # Latest version

Same executables, directory is smaller with fewer directories, links and files..

The unpackDbx script becomes much simpler;  after I untar the selected files, 12 lines of script were used to match the distributed directory directory structure that used symlinks. The structure build by tar:

cd studio12.3 ; ls
   READMEs bin lib man prod share

(cd share ; tar -cf - man ) | tar -xvf - ; rm -fr share
(cd prod  ; tar -cf - man ) | tar -xvf - ; rm -fr prod/man
for f in c++filt getmsg version whatdir; do mv prod/bin/$f bin ; done
for f in dem dwarfdump; do (cd bin;  ln -fs ../prod/bin/$f . ) ; done

That didn't work out.  The prod/bin and prod/lib structures needed to be retained because of symbolic links, so I remained faithful to the original directory, because there were dlopen constructs that didn't work.  The only simplification was merging the man page directories.

There;  I fixed it.  We don't need the ./share or  ./prod/man directories.  The result is more simple. 
Aside: executables remain in ./prod/bin, with symlinks to ./bin.
dlopen i
s used  by these executables to open path relative libraries (.so) in ./prod/lib,
and also architecture dependent (sparcv9) executables for 64-bit.

Here are the lines of code removed from
unpackDbx.sh

mkdir -p man/man1 man/man4 lib/sys/v9 lib/v9
(cd bin; ln -s ../prod/bin/* . )
(cd man/man1; ln -s  ../../prod/man/man1/* . )
(cd man/man1; ln -s ../../share/man/man1/* . )
(cd man/man4; ln -s ../../share/man/man4/* . )
/usr/bin/catman -w -M man
(cd lib;        ln -s    ../prod/lib/* .    ; ln -fs libdwarf.so.1 libdwarf.so)
(cd lib/v9;     ln -s ../../prod/lib/v9/* . ; ln -fs libdwarf.so.1 libdwarf.so)
(cd lib/sys;    ln -s ../../prod/lib/sys/* . )
(cd lib/sys/v9; ln -s ../../../prod/lib/sys/v9/* . )
(cd lib/locale/C/LC_MESSAGES; ln -s ../../../../prod/lib/locale/C/LC_MESSAGES/* . )     

War story:

I was in a code review, when one participant complained the code was too hard to read.
The author's response:  "It should be hard to read, it was hard to write."  -RS

Comments:

Post a Comment:
Comments are closed for this entry.
About

Dick Dunbar
is an escalation engineer working in the Customer Engineering & Advocacy Lab (CEAL team)
for Oracle Analytics and Performance Management.
I live and work in Santa Cruz, California.
I'll share the techniques I use to detect, avoid and repair problems.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today