[doxygen] 入門

色々調べた結果採用する方向です

まず、なんとかFORTRANのコードで基本的なhtml出力は得られたのでメモ。

[1] Installation

sudo apt-get install doxygen

 でOK

[2] Minimum use

fortranのコードがある場所で

doxygen -g hoge.conf

これで、標準的な出力設定ファイルが生成される。名前は、任意でOK.
次に、自分用にカスタマイズする。以下にオリジナルとカスタマイズ後のファイルの差分を示す。
ポイントは、「OPTIMIZEU_FOR_FORTRAN」や「EXTRACT_ALL」をYESにして、
「FILE_PATTERNS」に「*.f」を設定している点です。また、コードを表示するために「SOURCE_BROWSER」と「INLINE_SOURCES」をYESにします。

また、ソースに書式通りにコメントを書き込みます。下記に例を示す。
そして、

doxygen hoge.conf

とすると./html/index.htmlが出力されます。
今回の投稿は、最小限の使用ですので今後は下記についてが課題になると思います。

■出力ディレクトリ等の設定
■latex経由のPDF出力

---- 設定ファイルの差分---

*** org.conf 2012-07-28 13:39:06.803258079 +0900
--- common.conf 2012-07-28 13:36:44.702147423 +0900
***************
*** 25,31 ****
  # The PROJECT_NAME tag is a single word (or a sequence of words surrounded
  # by quotes) that should identify the project.
  
! PROJECT_NAME           =
  
  # The PROJECT_NUMBER tag can be used to enter a project or revision number.
  # This could be handy for archiving the generated documentation or
--- 25,31 ----
  # The PROJECT_NAME tag is a single word (or a sequence of words surrounded
  # by quotes) that should identify the project.
  
! PROJECT_NAME           = "First use of doxygen"
  
  # The PROJECT_NUMBER tag can be used to enter a project or revision number.
  # This could be handy for archiving the generated documentation or
***************
*** 199,205 ****
  # sources only. Doxygen will then generate output that is more tailored for
  # Fortran.
  
! OPTIMIZE_FOR_FORTRAN   = NO
  
  # Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
  # sources. Doxygen will then generate output that is tailored for
--- 199,205 ----
  # sources only. Doxygen will then generate output that is more tailored for
  # Fortran.
  
! OPTIMIZE_FOR_FORTRAN   = YES
  
  # Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
  # sources. Doxygen will then generate output that is tailored for
***************
*** 297,313 ****
  # Private class members and static file members will be hidden unless
  # the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
  
! EXTRACT_ALL            = NO
  
  # If the EXTRACT_PRIVATE tag is set to YES all private members of a class
  # will be included in the documentation.
  
! EXTRACT_PRIVATE        = NO
  
  # If the EXTRACT_STATIC tag is set to YES all static members of a file
  # will be included in the documentation.
  
! EXTRACT_STATIC         = NO
  
  # If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
  # defined locally in source files will be included in the documentation.
--- 297,313 ----
  # Private class members and static file members will be hidden unless
  # the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
  
! EXTRACT_ALL            = YES
  
  # If the EXTRACT_PRIVATE tag is set to YES all private members of a class
  # will be included in the documentation.
  
! EXTRACT_PRIVATE        = YES
  
  # If the EXTRACT_STATIC tag is set to YES all static members of a file
  # will be included in the documentation.
  
! EXTRACT_STATIC         = YES
  
  # If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
  # defined locally in source files will be included in the documentation.
***************
*** 591,597 ****
  # *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
  # *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py *.f90
  
! FILE_PATTERNS          =
  
  # The RECURSIVE tag can be used to turn specify whether or not subdirectories
  # should be searched for input files as well. Possible values are YES and NO.
--- 591,597 ----
  # *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
  # *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py *.f90
  
! FILE_PATTERNS          = *.f
  
  # The RECURSIVE tag can be used to turn specify whether or not subdirectories
  # should be searched for input files as well. Possible values are YES and NO.
***************
*** 690,701 ****
  # Note: To get rid of all source code in the generated output, make sure also
  # VERBATIM_HEADERS is set to NO.
  
! SOURCE_BROWSER         = NO
  
  # Setting the INLINE_SOURCES tag to YES will include the body
  # of functions and classes directly in the documentation.
  
! INLINE_SOURCES         = NO
  
  # Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
  # doxygen to hide any special comment blocks from generated source code
--- 690,701 ----
  # Note: To get rid of all source code in the generated output, make sure also
  # VERBATIM_HEADERS is set to NO.
  
! SOURCE_BROWSER         = YES
  
  # Setting the INLINE_SOURCES tag to YES will include the body
  # of functions and classes directly in the documentation.
  
! INLINE_SOURCES         = YES
  
  # Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
  # doxygen to hide any special comment blocks from generated source code
***************
*** 1389,1395 ****
  # toolkit from AT&T and Lucent Bell Labs. The other options in this section
  # have no effect if this option is set to NO (the default)
  
! HAVE_DOT               = NO
  
  # By default doxygen will write a font called FreeSans.ttf to the output
  # directory and reference it in all dot files that doxygen generates. This
--- 1389,1395 ----
  # toolkit from AT&T and Lucent Bell Labs. The other options in this section
  # have no effect if this option is set to NO (the default)
  
! HAVE_DOT               = YES
  
  # By default doxygen will write a font called FreeSans.ttf to the output
  # directory and reference it in all dot files that doxygen generates. This
***************
*** 1464,1470 ****
  # the time of a run. So in most cases it will be better to enable call graphs
  # for selected functions only using the \callgraph command.
  
! CALL_GRAPH             = NO
  
  # If the CALLER_GRAPH and HAVE_DOT tags are set to YES then
  # doxygen will generate a caller dependency graph for every global function
--- 1464,1470 ----
  # the time of a run. So in most cases it will be better to enable call graphs
  # for selected functions only using the \callgraph command.
  
! CALL_GRAPH             = YES
  
  # If the CALLER_GRAPH and HAVE_DOT tags are set to YES then
  # doxygen will generate a caller dependency graph for every global function
***************
*** 1472,1478 ****
  # the time of a run. So in most cases it will be better to enable caller
  # graphs for selected functions only using the \callergraph command.
  
! CALLER_GRAPH           = NO
  
  # If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
  # will graphical hierarchy of all classes instead of a textual one.
--- 1472,1478 ----
  # the time of a run. So in most cases it will be better to enable caller
  # graphs for selected functions only using the \callergraph command.
  
! CALLER_GRAPH           = YES
  
  # If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
  # will graphical hierarchy of all classes instead of a textual one.

ソースコメント記入例

      
　　　!-----------------------------------------------------------
      ! MODULE: test program
      !> @author
      !> Author name
      !
      ! DESCRIPTION:
      !> test program for using doxigen 
      ! REVISION HISTORY:
      ! 16 Apr 2012 - Initial Version
      ! TODO_28_jul_2012 - add explain of subroutine add - todo1
      !-----------------------------------------------------------
      program test
      integer a,b
      a=1
      b=2
      write(*,*) a
      call add(a)
      write(*,*) a
      call add(b)
      end
      !> Subroutine add
      !> @param[in] sa you want to add 1
      !> @brief 
      ! add 1 to argument
      subroutine add(sa)
      integer sa
      sa = sa + 1
      end

[memo] コードドキュメンテーションツールとか

FORTRANにも対応しているjavadoc的なツールが必要になったので調べたメモ

■doxygen
詳細調査中
■sphinx
こちらは、javadoc的なツールではないが、この言語(?)でドキュメントかいておけば、htmlページとかPDFとかlatexやmanとかにコンバートできるよ的なツール
一瞬思ったけどTeXでいいよなこれ

[win7]勝手にウィンドウを最大化しないようにする

めずらしくいや初めてかもしれない　Windowsネタ

「Windowsは、こっちが予期しないことを勝手にしがちで、したいことがしづらい」

のいい例

「Windows 7」においてウィンドウをデスクトップの端に持って行ったときに最大化かってにさせない方法

コントロールパネル（非カテゴリ表示）を開き

コントロール パネル\すべてのコントロール パネル項目\コンピューターの簡単操作センター\

をたどり。

「マウスを使いやすくする」を開く。

そして、「ウィンドウが画面の端に移動されたときに自動的に整列されないようにします」
のチェックを入れる。




ちなみにLinux含めUNIX LIKEなOSは、
「こっちが、指示した事だけを黙々とこなし、こっちがしたい事ができる」

[tcsh] 設定ファイルロードプライオリティ

bashの次は、
tcsh

ログインシェルの場合
/etc/csh.cshrc
  ↓
/etc/csh.login
  ↓
~/.tcshrc
  ↓
~/.login

ログインシェル以外は、
/etc/csh.cshrc
  ↓
~/.tcshrc 又は ~/cshrc

[シェル] プロンプト

今回は、プロンプトのカスタマイズ、cシェル系とbシェル系で異なる。

まずは、bシェル系　シェル変数「PS1」に設定する。
  PS1="\u@\H:\w$ "

cシェル系は、シェル変数「prompt」に設定する。
自分の場合

  set prompt="%n@%m:%~%# "

%n : 自分のアカウント名
%m : ホスト名
%# : スーパーユーザーならば「#」一般ユーザーならば「>」を表示

[bash] 設定ファイルロードプライオリティ

自分は、主にUbuntuでcシェル派だったが仕事でRHELの環境でbashを使わざるをえない機会があって今回意識させられた。




まずは、Ubuntuの場合、


bash（ログインシェル）の設定ファイルは以下の順序で読み込まれる。
1) /etc/profile  
    ↓
2) /etc/bash.bashrc
    ↓
3) ~/.bash_profile (ある場合)
    ↓
4)~/.bashrc (ある場合)
    ↓
5)~/.bash_login (ある場合)
    ↓
6)~/.profile (ある場合) 


bash(ログインシェルではない場合)
1)/etc/bash.bashrc
    ↓
2)~/.bashrc

Ubuntuの場合ログインシェルにしろログインシェルでないにしろ~/.bashrcは読み込まれる。
しかし、RHELは違った。むしろ、Ubuntuがいろいろ調べると"異端"な感想を持った。

ログインシェルの場合~/.bashrcは読み込まれないということである。
つまり、一般的なUNIX互換な環境では、
ログインシェルの場合

1) /etc/profile  
    ↓
2) ~/.bash_profile (ある場合)

    ↓
3)~/.bash_login (ある場合)
    ↓
4)~/.profile (ある場合)


であり、
ログインシェルでない場合。
1)~/.bashrc


となるらしい。
つまり、RHELの場合、ユーザー固有のシェルの設定は、~/.bash_profileに書くこととなる。

[システム設計哲学]MediaWikiに見る

タイトル中の"システム"とは、広義の意味であり、

広辞苑によると

複数の要素が有機的に関係しあい、全体としてまとまった機能を発揮している要素の集合体

とある。さらに私的には、最後の「の集合体」を削除した意味としたい。つまり、複数の要素の集合も要素という風に解釈するのである（再帰的な表現）。

さらに、”システム設計哲学”という専門用語自体あるかどうか定かではない。

なんだかここまで書いただけでもカオス感たっぷりだが、何回か投稿を重ねるうえでこの私の考える”システム設計哲学”を定かなものとして（体系立てて）いきたい。


その第1回目は、MediaWikiを通した考察。Wikiエンジンは、MediaWiki以外にも有名どころでは、PukiWikiなど多数あるが、ほかのWikiエンジンに同様の仕組みがあるか知らなく、MediaWikiに限定する必要はないのかもしれないがあえてMediaWikiに限定した。


MediaWikiは、WikiPediaのWikiエンジンとして採用されていることは、みなさんご存じであろう。


私は、Wikiのページ間の関連のさせかたとして、階層構造をもたせるのが良いのではないかといつも感じでいた。


しかし、本家WikiPediaでは、ページ間に階層構造なんて持たせていない。


なぜのなか？もやもやしていた。




それを最近あるブログの投稿がすっきりさせてくれた。


http://blog.livedoor.jp/lionkid/archives/3096475.html

とくに最後のこの一文。

複雑系は、階層を持たない平坦なページを使い、タグでグループ分けするのが基本だ。

ここでは、哲学的に昇華させるとすれば下記だと思う。

「巨大なシステムの要素は、階層構造で整理するのではなく、それぞれの要素の属性のみでかんりするのが良い。」

しかし、こう書いておきながらもこの一文は、私が傾倒する "UNIX哲学"とは、相容れない部分もあるのではとも考えてしまう。

まだまだ、考察が足りない。

Bloggerへ投稿するコードのハイライト化

常々しなければと思っていて暇だったのでやってみた。 コードを見やすくするためのプラグインの追加。 自分が入れたのは、「SYNTAX HIGHLIGHTER　Ver.3」

基本的には、参考サイトを訪れてそこに書いてある通りにやればいい。

まず、お好みのテーマを決める。
そして、次は、対応させたい言語を選択して、JavaScriptへのリンクのコードを生成。そのコードをBloggerのテンプレートの</head>直前に挿入。

投稿時は、下記のようにする。


<pre class="brush:c;">int main(int argc,char **argv){
    printf("Hello Worild!!\n");
    return 0;
}
</pre>



以下サンプル

int main(int argc,char **argv){
    printf("Hello Worild!!\n");
    return 0;
}

参考サイト: http://www.way2blogging.org/2011/03/how-to-add-syntax-highlighterv3-to.html

[expect] 対話的コマンド

UNIX哲学　においては、バッチ処理の妨げになる極力対話的なインターフェースは避けるようかかれていますが、やはり世の中には、対話処理が必要な場面もある。

ということで今回は、expectコマンドを知ったのでメモしておく。
先に参考にさせていただいたサイトを示しておく。

http://202.253.248.12/gijutu/expect/howto-expect.html#b-interact

expectコマンドの基本を押さえるべくヤマハルーターにtelnetでログインして「show enviroment」コマンドを実行してログアウトするというお題を設定。

expectコマンドは、-cオプションを用いる方法、スクリプトファイルにする方法（#!/usr/bin/expect）、シェルスクリプトでヒアドキュメントとする方法等が考えられるが。

今回は、そんなに長くないコードであるため、シェルスクリプト内にヒアドキュメントで埋め込む方法とした。


<pre class="brush:shell">

set RHOST="192.168.100.1"
set RUSER="hoge"
set RPASSWD="hoge"
expect <<EOF
  set timeout -1
  spawn telnet $RHOST
  expect "Username: "
  send "$RUSER\n"
  expect "Password: "
  send "$RPASSWD\n"
  expect ">"
  send "show environment\n"
  expect ">"
  send "quit\n"
  expect ">"
EOF

</pre>