Rakuten.karma++; /* again */

去年のタダ飯に味をしめて，今年のタダ飯も喰いに行ってきた．

地元が大宮の隣なので会場の品川まで結構時間がかかる．なので，去年の経験を生かして本を持って行く事にした．読んでた本は学生時代に哲学の講義で使っていたカール・R・ポパーの「推測と反駁」．学生の頃は原本を持ってなかったけれど，最近amazonでポチった．が，出掛けに持って行く厚さじゃねぇな，コレは． :D

会場では相変わらず中の人たちがそこら中に立っててカタい感じ．キョドるからあーゆーの苦手なんだよなぁ，俺だけか？あんま勉強会とかイベントとかの経験が豊富な方じゃないけど，技術オタク歓迎の休日のイベントの割にはビジネス(?)な対応すんの面倒臭ぇなぁ，と思う．何時の間にか楽天の中の人になってたカーネル読書会の中の人は今回のプレゼンで「ここの芸風を変える」とか抽象的な事を言っていたけど，こーゆートコは多分変わらんのだろうなぁ，とか思った．blogかなんかで，懇親会で社会人的挨拶をして知り合いを作れみたいな事を言ってた様な気がするし．まぁ，そーゆー雰囲気を意図しているスポンサーなのだろうから，別にわざわざテキトーにやる様に方向転換する必要も無いだろうけど．

誤解の無い様に言っておくと，LTやらパネルディスカッションやらに笑えるネタは結構あったし，スポンサーが企業だから運営側の対応もとても良い．何よりタダ飯を喰わしてくれるのはすばらしい．金がかからないと言う理由ではなくて，この手のイベントでは他に類を見ないほど，驚くくらいゲストに待遇が良い．

仕事も趣味の範囲も全く違う関係でLLはマジメにやってねぇし，サーバの管理なんかしたこともねぇから，Web 2.0な匂いのするイベントの内容を説明するのも何なので，前から感じてたこの辺りの事でも書いてみるか．

この手の技術オタク系イベント(?)には，スポンサーが意図する雰囲気と言うか，やる側が作り出す雰囲気みたいなモノがある，と個人的には思っていたりする．楽天のヤツは金を払って行く技術系セミナーに近い「いらっしゃいませ，本日は御越し頂き，誠にありがとうございます」的な雰囲気．会社でその手の金のかかるセミナーに行っていたり，その延長として参加している様な人達から見れば，こーゆー雰囲気は結構歓迎されるだろうし，学生でこの手のインフラ系(?)を目指している様なsysadminの卵にも好印象だろうと思う，例えイベントのプログラムの半分以上が自社社員のオレオレ発表だったとしても，だ．

でも，ゲストに対する待遇と言う点では楽天のヤツは良い意味で非常に異色だと思う．そしてそう言う雰囲気を期待している人達がテキトーな雰囲気のイベントに来てしまうと，理不尽に気分を害す．「このイベントって来る価値無くね？」みたいに．この傾向はテキトーな雰囲気を期待している俺みたいなイイ加減なヤツが待遇の良さに慣れなくてキョドるみたいなどーでもよろしい症状より深刻だったりする．

ま，端的に言うとそーゆーテキトーな雰囲気のイベントに参加しなくなったり，あからさまに否定したりする訳ですね，ハイ．参加しなくなるだけなら構わねぇんだが，そーゆー人達の一部はテキトーにやられるのが我慢ならんのか，テキトーな雰囲気のイベントそのものをあからさまに否定したりしている．不良社員のオレが言うのも何だか，それこそ人間なってなくね？

テキトーな雰囲気ってのはやる気が無ぇのとは違う．せっかくの休日に地元でない会場までわざわざ出てきていて，イベント前まで何かしら用意しているのが暗にそれを物語っている．展示されたりしている内容が陳腐に見えたり，話している内容が低レベルだと思ったりしたら，間違い無く手前の目と耳が腐ってる．勿論，なんちゃって展示やオレオレ発表みたいなのもあるけど，そりゃあ，ただのネタだろ，懇親会でも参加して話題にでもすればいいじゃねぇか．

ブース内の内輪で盛り上がってるだけ？普段，ネットでユルく繋がってる技術オタク同士がリアルで顔を会わせたらそう言う感じになっても仕方無ぇだろ．テキトーな雰囲気のイベントだと，やる方の目的の半分以上はそれなんだし．そう言う人種に客商売みたいな対人スキルを過度に期待すんなよ．

技術スキルを教えて貰いにイベントに参加している？どんな雰囲気の技術オタク系イベントでも，イベントに参加したくらいでほいほい技術スキルが上がるなら，エンジニアは誰も苦労なんかしてねぇよ．そこで今まで知らなかった事を知ったり出来たら，単に幸運なだけだろ．しかもその幸運も単なるきっかけでしかなくて，マジに知りたかったらあとで自分でゴニョる事が絶対必要だろ．一日ぽっち休日を潰したくらいで技術スキルがぽんぽん上がるとでも思ってんのか？エンジニアの世界，なめてんじゃねぇぞ．もっと楽に稼げる職業にジョブチェンジした方が良いよ，そんなの職業があるのか知らんけど．

マジメにやってるカタいイベントなら，普段聞けない業務のアノネノネみたいな話が聞けるって？そんなことあるかよ，寝言は寝て言えよ．本当にアレな話を公のイベントでマイクに向かって喋る訳ねぇだろ，常識的に考えて．そう言う事はお互いに名前くらいは覚えていて，何度か懇親会とかで一緒にツルめる様になって，かつ酒の所為か何かで口が滑ったらあるかもしれねぇが．

業務上のマズい所や失敗ってのは，普通の技術スキル以上に共有するがとても難しいモノの一つだろ．まさかとは思うが，そーゆーのに興味のある輩で品質管理とか信頼性の本を一冊も読んだ事がないとか言うのは無しだぜ？ちなみにISO 9001の監査とか会社でやったとか，あんなモノはノーカウントだ．あれは大抵の営利企業なら言われなくてもやっている事しか決めてないし，言っちゃあなんだが取得がほぼ形骸化しているから，あっても無くても大した意味なんか無い，と個人的には思っている．「ここで言うのは何なんだけど，実は．．．」的なマズい所や失敗について知りたいのは未然防止の一部を形成するけれど，本当に一片の野次馬根性も無く，そう言う経験を正当に扱う意図があるのかをもう一度マジメに考えた方が良い．取り敢えず，日科技連の品質管理とか信頼性の本とかを読めば良いよ．変な事を期待してケチつけてんじゃねぇぞ．

まぁ，要するに何が言いたかったのかと言うと，多分，来週のOSCはテキトーな雰囲気の方です．雰囲気が楽天のヤツとちょっと違うだろうけど，「やる方も来る方もせっかく休日を使って来てるんだから，おもしろおかしければそれで良くね？」って事です． :P

cat $f && sleep 1h ;

今日，10/10は萌の日らしいので，大宮にある猫カフェの猫家でムニョって来た．

夕方だったので，茶々様は寝てた． :DDD

if (strcmp(to_string(getMIME(&spec)), "text/plain")) { ... }

仕様をtext/plainで渋くキメる． :DDD

AAがポイントだな．書くの結構大変だけどvisioとかsvg系のモノより楽だと思う．
あんまり複雑なのは書けないから，シンプルに仕上げるにはどうしたら良いか考える様になるしな．

あとは全部英語で書ければpure ASCIIで蝶portableなんだが，日本語のUTF-8なのが課題かなぁ．

MeasureSLOC(&AL9); /* 2009/08 */

AでLで9なdiffstat，8月分．
[diffstat for AL9, for 2009/08.]

 bench/BENCH_BER_IF_REG.vhd    |    4 
 bench/BENCH_CLDPCDOP.vhd      |   22 +-
 bench/BENCH_LDPCDDB.vhd       |   25 +-
 bench/BENCH_LDPCTX2LDPCRX.vhd |   18 +
 bench/BENCH_PE2RST.vhd        |    4 
 bench/BENCH_S2BER_IF.vhd      |    4 
 bench/BENCH_TMCC_DBPSK.vhd    |  286 ++++++++++++++++++++++++++
 vhdl/BER_IF_REG.vhd           |   62 +++++
 vhdl/CLDPCDOP.vhd             |   31 ++
 vhdl/COMMON_TYPE_PKG.vhd      |    7 
 vhdl/COS_VLSX4_MEM.vhd        |   15 +
 vhdl/FP1_LDPCRX.vhd           |   73 +++---
 vhdl/FP1_LDPCTX.vhd           |   27 +-
 vhdl/FP2_LDPCRX.vhd           |   61 +++++
 vhdl/FP3_LDPCRX.vhd           |   12 +
 vhdl/FP4_LDPCRX.vhd           |   13 +
 vhdl/IMUX4SELDPCDIPM.vhd      |  453 ++++++++++++++++++++++++++++++++++++++++++
 vhdl/PE2RST.vhd               |  130 +++++++-----
 vhdl/RX_LX_FEBE.vhd           |   62 ++++-
 vhdl/S2BER_IF.vhd             |    8 
 vhdl/SELDPCDIPM.vhd           |   74 ++++++
 vhdl/TSR_CLK-iff.vhd          |   16 +
 vhdl/TSR_CLK.vhd              |   17 +
 vhdl/UACCUM.vhd               |   52 +++-
 24 files changed, 1325 insertions(+), 151 deletions(-)

2kSLOC逝ってないNA!!1 :DDD
453SLOCのIMUX4SELDPCDIPMに10000bit以上のテスト用軟判定bitが入っているとか，tricky過ぎるぜ．
一つだけ問題が残っているんだが，そろそろ飽きたので次に逝きたい所だ．
[ZOMG, under 2kSLOC!!1 :DDD
My tricky code does embed over 10000 soft-decision bits for hardware debugging into IMUX4SELDPCDIPM that is only 453 SLOC.
I'm still fighting w/ t3h last issue atm. HOW BOLING!!1]

MeasureSLOC(&AL9); /* 2009/07 */

AでLで9なdiffstat，7月分．
[diffstat for AL9, for 2009/07.]

 bench/BENCH_AFIFO.vhd         |    6 
 bench/BENCH_BER_IF_CLK.vhd    |   16 
 bench/BENCH_CLDPCDOP.vhd      |    3 
 bench/BENCH_EDGE_DELAY.vhd    |   67 ++++
 bench/BENCH_FCO.vhd           |   14 
 bench/BENCH_HS_BUS.vhd        |   33 +-
 bench/BENCH_LDPCDDB.vhd       |    3 
 bench/BENCH_LDPCTX2LDPCRX.vhd |    6 
 bench/BENCH_PE2RST.vhd        |   81 +++-
 bench/BENCH_SFIFO.vhd         |    6 
 bench/BENCH_TX_SMAP.vhd       |    6 
 bench/BENCH_UDACCUM.vhd       |  100 ------
 stim/STIM_RX_DATA_CARR.vhd    |   10 
 stim/STIM_TX_DATA_CARR.vhd    |   10 
 vhdl/BER_IF_CLK.vhd           |   87 ++---
 vhdl/BER_IF_REG.vhd           |  120 +++----
 vhdl/COS_VLSX4_MEM.vhd        |  690 ++++++++++++++++++++++--------------------
 vhdl/EDGE_DELAY-stub.vhd      |   71 ++++
 vhdl/EDGE_DELAY.vhd           |  163 +++++++++
 vhdl/FP1_LDPCRX.vhd           |   81 ++++
 vhdl/FP1_LDPCTX.vhd           |   49 ++
 vhdl/FP2_LDPCRX.vhd           |  122 +++++--
 vhdl/FP3_LDPCRX.vhd           |   15 
 vhdl/FP4_LDPCRX.vhd           |   13 
 vhdl/HS_BUS.vhd               |   72 ++++
 vhdl/LDPCD.vhd                |    6 
 vhdl/PE2RST.vhd               |  180 +++++++---
 vhdl/RX_LX_FEBE.vhd           |  100 ++++--
 vhdl/S2BER_IF.vhd             |   40 --
 vhdl/SB_MASTER.vhd            |   42 ++
 vhdl/TSR_CLK-iff.vhd          |  312 ++++++++++++++++++
 vhdl/TSR_CLK.vhd              |   32 +
 vhdl/TX_SX_FEBE.vhd           |   42 +-
 vhdl/UACCUM.vhd               |  224 +++++++++++++
 vhdl/UDACCUM.vhd              |  270 ----------------
 35 files changed, 2029 insertions(+), 1063 deletions(-)

やっぱ，10kSLOC逝ってないZE!!1 :DDD
つーか，実機デバッグの所為で先月は少なすぎだな．
でもコイツももうそろそろ仕上げです． :)
[ZOMG, under 10kSLOC AGAIN!!1 :DDD
B/c I'm really being busy for debugging on real hardware ATM.
So MAH TIME IZ GETTING NEER!!1 :DDD]

doFlame(&numeric_std);

#vhdlのnumeric_stdな猿共と再度flameしてみた． :P

07/25 21:03:01 hiyuh
     hmm
07/25 21:03:31 hiyuh
     i did migrate std_logic_arith to numeric_std on my current proj.
07/25 21:04:06 hiyuh
     but i think numeric_std still sux in my style/use.
07/25 21:04:49 hiyuh
     anybody have good example code which use numeric_std elegant?
07/25 21:04:56 hiyuh
     s/use/uses/
07/25 21:06:39 hiyuh
     MatthiasM, NULL[0] ^^ :)
07/25 21:06:44 MatthiasM
     :)
07/25 21:07:25 MatthiasM
     there is not much to say - if you have a signal/variable which is
     used in computations, then declare it as (un)signed
07/25 21:07:29 Sordran_
     hiyuh:
     http://www.dz.ee.ethz.ch/en/information/hdl-help/vhdl-sources.html
07/25 21:12:00 hiyuh
     hmm
07/25 22:17:16 bpadalino
     hiyuh: yeah, what's the issue ?
07/25 22:21:23 hiyuh
     one of issues I hate numeric_std is it breaks port compatibilty.
07/25 22:21:26 hiyuh
     b/c all of mine was std_logic, std_logic_vector, range constrained
     integer or custom type.
07/25 22:22:22 hiyuh
     i know inner std_logic_vector() wrapping makes it compatible,
     but it's very eyesore.
07/25 22:24:00 bpadalino
     so don't convert to slv at the port level
07/25 22:24:08 bpadalino
     if it's an unsigned number - keep it an unsigned number
07/25 22:24:14 bpadalino
     preserve context as much as possible
07/25 22:28:13 hiyuh
     nope, for lazy simulation, I did input ascending/descending number
     to data port. it's data, not unsigned/signed.
07/25 22:31:26 hiyuh
     and another one I hate is to declare unsigned/signed signal/variable
     and computing w/o unsigned()/signed().
07/25 22:32:21 bpadalino
     you can always overload your functions .. and add your own package
07/25 22:33:12 hiyuh
     if you recommend overloading, i won't use numeric_std TBH.
07/25 22:33:26 hiyuh
     it's pain to me atm.
07/25 22:33:44 bpadalino
     numeric_std removes ambiguity from your code - if you find it to
     be a pain, then live with the ambiguity
07/25 22:34:40 hiyuh
     then plz show me that ambiguity which comes from std_logic_arith?
07/25 22:35:56 bpadalino
     a <= b + x"abcd"
07/25 22:35:58 bpadalino
     what did i  just do
07/25 22:38:27 hiyuh
     every time I compute std_logic_vector, I always do it w/ explicit
     unsigned()/signed(). and also I don't use hexadecimal/binary
     presented std_logic_vector for any computation.
07/25 22:39:45 bpadalino
     congrats - but it doesn't remove the ambiguity that can happen
07/25 22:39:47 bpadalino
     use whatever you want
07/25 22:41:17 hiyuh
     promote me more, why that doesn't remove the ambiguity?
07/25 22:42:45 bpadalino
     because you can still abuse it
07/25 22:44:38 hiyuh
     hmm
07/25 22:48:17 bpadalino
     i understand numeric_std makes your code look "ugly" if you do a
     lot of casting
07/25 22:48:47 bpadalino
     answer is to do less casting
07/25 22:54:48 hiyuh
     I'd like to say trivial explicit casting is not eyesore to me.
07/25 22:54:57 hiyuh
     atm i don't like numeric_std's implicit type guessing to compute.
07/25 22:55:02 hiyuh
     b/c to see which function is used, it needs to see their
     declarations.
07/25 22:55:49 bpadalino
     guessing ?
07/25 22:56:39 hiyuh
     signal a : signed; signal b : signed; signal c : signed; ... some
     line of code ... c <= a + b; -- numeric_std use.
07/25 22:59:10 hiyuh
     + of "a + b" is "signed + signed". but to figure out that, it needs
     to see their declaration.
07/25 22:59:40 MatthiasM
     the issue why code may look ugly is that it is not cleanly designed -
     eg when writing software you have to carefully define the types of
     variables, parameters and return values
07/25 23:00:05 bpadalino
     how is that not any different than how it would happen with
     std_logic_arith ?
07/25 23:01:16 hiyuh
     my std_logic_arith use looks like,
07/25 23:01:17 hiyuh
     signal a : std_logic_vector; signal b : std_logic_vector; signal
     c : std_logic_vector; ... some lines of code ... c <= signed(a)
     + signed(b);
07/25 23:02:00 bpadalino
     is a or b or c a signed or unsigned number ?
07/25 23:02:05 bpadalino
     wow, that's all sorts of crazy
07/25 23:03:19 bpadalino
     nothing stops you from going c <= unsigned(a) + signed(b) ;
07/25 23:03:24 bpadalino
     so it's really just a bunch of bits
07/25 23:04:22 hiyuh
     I mean arg type and computation is one set.
07/25 23:04:26 hiyuh
     signal a : signed; signal b : signed; signal c : signed;
     ... some line of code ... c <= signed(std_logic_vector(a)) +
     unsigned(std_logic_vector(b));
07/25 23:04:41 hiyuh
     is it valid for numeric_std?
07/25 23:04:56 bpadalino
     yes
07/25 23:05:24 hiyuh
     if so, declaration is not for force to use proper computation.
07/25 23:06:07 bpadalino
     if i saw unsigned(std_logic_vector(b)) in a code review, i think
     my red flags would go up
07/25 23:06:18 bpadalino
     but if i saw signed(b) - i wouldn't think twice
07/25 23:06:40 bpadalino
     numeric_std doesn't stop you from being an idiot - it just makes
     it harder
07/25 23:07:17 hiyuh
     yeah
07/25 23:08:33 bpadalino
     they're supposed to be a set of functions which help you
07/25 23:08:42 bpadalino
     if you don't find them helpful, don't use them
07/25 23:09:22 hiyuh
     but if i stick std_logic_arith, MatthiasM will bitch me. :P
07/25 23:09:52 MatthiasM
     sure
07/25 23:14:30 bpadalino
     so learn to quit writing ambiguous code
07/25 23:16:09 hiyuh
     signal a : signed; signal b : signed; signal c : signed; ... some
     line of code ... c <= a + b; -- (1)
07/25 23:16:12 hiyuh
     signal a : std_logic_vector; signal b : std_logic_vector; signal
     c : std_logic_vector; ... some lines of code ... c <= signed(a) +
     signed(b); -- (2)
07/25 23:16:54 hiyuh
     to review code, (1) needs to check declaration and computation. (2)
     needs to check computation only.
07/25 23:17:27 hiyuh
     that's why I hate numeric_std atm.
07/25 23:17:30 bpadalino
     d <= unsigned(a) + signed(b) ;
07/25 23:17:45 bpadalino
     does not enforce that a is a signed type
07/25 23:18:07 bpadalino
     if you want to be loose, and not have matthiam bitch at you -
     use verilog
07/25 23:18:15 bpadalino
     but in a strongly typed language, learn to deal with it
07/25 23:18:17 MatthiasM
     hiyuh: with (2) you have to check that a is used in the same way
     everywhere
07/25 23:18:52 bpadalino
     also - if you pass a out a port as a slv, there is no guarantee it
     will be maintained as that representation later on
07/25 23:19:00 bpadalino
     which only causes more confusion
07/25 23:19:53 MatthiasM
     the only place where you should keep using SLV is at the top level -
     because post fitting timing simulation is loosing the port type -
     and then your testbench doesn't work anymore :(
07/25 23:20:15 bpadalino
     :(
07/25 23:21:16 hiyuh
     MatthiasM: (1) is same b/c think that crappy code like,
07/25 23:21:21 hiyuh
     signal a : signed; signal b : signed; signal c : signed;
     ... some line of code ... c <= signed(std_logic_vector(a)) +
     unsigned(std_logic_vector(b)); -- (3)
07/25 23:21:39 bpadalino
     hiyuh, if you want to shoot yourself in the foot easier, i think
     aliases might make your life more hellish
07/25 23:22:03 MatthiasM
     hiyuh: if I would have to review your code and it contains such a
     thing - you would rewrite it again
07/25 23:27:21 hiyuh
     bpadalino: if you declare port as signed/unsigned, it doesn't force
     to use that type. b/c there is idiot casts.
07/25 23:27:48 bpadalino
     hiyuh, like i said - you can always be an idiot, numeric_std just
     makes it harder
07/25 23:28:42 hiyuh
     and it does also analyze harder. that's why I hate numeric_std.
07/25 23:30:19 hiyuh
     if declaration can not force proper type use, i think type in
     declaration is redundant info.
07/25 23:31:24 hiyuh
     if using numeric_std doesn't allow any casting, it make sense.
07/25 23:31:36 hiyuh
     but it's not.
07/25 23:32:04 MatthiasM
     hiyuh: well - do what you want - but spot anoyng everyone with your
     bad design
07/25 23:32:11 MatthiasM
     *stop
07/25 23:34:27 hiyuh
     annoy?
07/25 23:34:29 hiyuh
     I'm really talking in technical view.
07/25 23:34:31 bpadalino
     you know, no reason to even use std_logic_vectors since we're just
     going down to bits ...
07/25 23:34:37 bpadalino
     so lets just do std_logic
07/25 23:35:52 bpadalino
     hiyuh, you want to be stuck in a type you can't get out of ?
07/25 23:36:05 bpadalino
     or would you rather be forced to think about the computation you're
     doing ?
07/25 23:46:51 hiyuh
     well. you're talking about bit to std_logic migration?
07/25 23:47:12 hiyuh
     you mean it's same wrt migration std_logic_arith to numeric_std?
07/25 23:48:09 hiyuh
     btw sorry for my bad english.
07/25 23:48:51 bpadalino
     i am saying you can use whatever you like - but your arguments
     are weak
07/25 23:49:07 hiyuh
     hmm
07/25 23:50:02 hiyuh
     maybe, it's b/c i have little experience w/ numeric_std.
07/25 23:50:50 hiyuh
     so I should read more elegant std_logic_arith to numeric_std
     migration examples.
07/25 23:51:08 bpadalino
     there's nothing elegant about it
07/25 23:51:26 hiyuh
     why?
07/25 23:51:51 bpadalino
     the way you're doing it, trust me - there's no elegant way about it
07/25 23:51:59 bpadalino
     all your base types are slv ..
07/25 23:52:06 bpadalino
     so you will have to cast everything
07/25 23:52:20 bpadalino
     first to get to something workable, then back to your slv base type
07/25 23:52:35 bpadalino
     you're really doing a lot of work to lose intent and context of
     the code
07/25 23:52:54 bpadalino
     lets write a c program where all we use are char's .. and cast
     everything when we need it to be something else
07/25 23:53:11 hiyuh
     nope, I cloned my proj for the migration test. I'm using mercurial.
07/25 23:53:43 bpadalino
     scm has nothing to do with elegance or porting poorly written code
     to using numeric_std
07/25 23:59:17 hiyuh
     well, I've just done to migrate std_logic_arith to numeric_std
     already.
07/26 00:00:14 hiyuh
     it takes about 1 hour or so. but i think it's ugly.
07/26 00:01:55 hiyuh
     to motivate myself more, I'm talking here.
07/26 00:02:54 hiyuh
     I beleive my code base is not poor you think.
07/26 00:02:57 hiyuh
     it works w/ 2 boards which each one has 4 virtex4.
07/26 00:03:08 hiyuh
     all ones are written in two-process method.
07/26 00:08:03 bpadalino
     sounds great when you're the only person working on the code
07/26 00:08:04 bpadalino
     keep it up
07/26 00:10:08 hiyuh
     yup, it was coded by me only.
07/26 00:29:23 bpadalino
     if you're the only person, write it any way you want
07/26 00:34:19 hiyuh
     ok, thank you for taking your time.

取り敢えず，再確認出来た事としては技術的な話をしている時に"stop annoying"とか"trust me"とかふざけた事を言う奴の意見は聴くに値しないと言う事だな．
結局，suckless.orgのstyle guideが言う様にconsistencyが重要だとすれば，自分のstyleと相容れないpackageを無理に使う事はないって事になるのかな？
つー訳で，やっぱり私は当分の間はnumeric_stdにmigrateする事はありません． :P

doFlame(&std_logic_arith);

取り敢えず，KMSがmodeset=0で動く様になったと思ったら#vhdlにnumeric_stdな猿が居たのでflameしてみた． :P

07/19 02:35:22 jv
    MatthiasM: Why is logic_arith so pervasive?
07/19 02:35:41 MatthiasM
    ?
07/19 02:46:31 jv
    MatthiasM: why people keep using std_logic_artih
07/19 02:46:56 MatthiasM
    maybe because neither Xilinx or Altera updated their language
    templates

07/19 03:27:50 hiyuh
    jv: MatthiasM: promote me numeric_std more. then I'll switch from
    sticking std_logic_arith.
07/19 03:28:21 MatthiasM
    hiyuh: simple - no help for everyone who uses std_logic_arith :P
07/19 03:28:40 hiyuh
    ha
07/19 03:30:21 NULL[0]
    we need to open a new channel for that: #vhdl-93
07/19 03:30:55 MatthiasM
    or #vhdl-only-for-std_numeric-users
07/19 03:31:12 hiyuh
    there is no system doesn't support std_logic_arith and
    numeric_std. monkey is just saying "it's t3h standard".
07/19 03:32:05 NULL[0]
    a 15 years old tool supporting only vhdl-87 will not support
    numeric_std ;p
07/19 03:32:35 hiyuh
    no, that kind of craps are not system anymore. :p
07/19 03:36:29 hiyuh
    anyway, vhdl-93/2002 doesn't bother to use std_logic_arith, iirc.
07/19 03:36:58 NULL[0]
    because it is not necessary anymore
07/19 03:39:00 hiyuh
    so plz, promote me in technical view. numeric_std is different from
    std_logic_arith. why I should migrate?
07/19 03:39:15 hiyuh
    s/I should/should I/
07/19 03:39:50 NULL[0]
    one is a standard the other one a de facto standard that will
    hopefully be deprecated soon ;)
07/19 03:40:27 NULL[0]
    unfortunately it will never happen ;/
07/19 03:41:05 hiyuh
    yup, de facto standard won't be deprecated. b/c monky is just saying
    "it's t3h standard".
07/19 03:41:20 hiyuh
    so plz promote me more.
07/19 03:42:07 NULL[0]
    I don't really care :p, I have seen only 1 stupid case combining
    std_logic_signed and std_logic_unsigned which broke the code
07/19 03:43:05 NULL[0]
    something impossible with numeric_std ;)
07/19 03:43:12 NULL[0]
    alone
07/19 03:44:43 hiyuh
    std_logic_arith is not std_logic_{signed,unsigned}.
07/19 03:44:45 hiyuh
    mixing them does overload some functions in current vhdl standard,
    it just makes noobs confuse.
07/19 03:45:17 NULL[0]
    std_logic_(un)signed is part of the synopsys libraries like
    std_logic_arith
07/19 03:45:50 hiyuh
    nope, they are separated, iirc.
07/19 03:46:08 NULL[0]
    library IEEE;
07/19 03:46:08 NULL[0]
    use IEEE.std_logic_1164.all;
07/19 03:46:08 NULL[0]
    use IEEE.std_logic_arith.all;
07/19 03:46:24 NULL[0]
    that's the beginning of std_logic_signed
07/19 03:46:37 NULL[0]
    -- Copyright (c) 1990, 1991, 1992 by Synopsys, Inc. --
07/19 03:49:10 hiyuh
    http://pastebin.com/m545ddbec
07/19 03:49:54 NULL[0]
    and ?
07/19 03:51:13 hiyuh
    synopsys/std_logic_arith.vhdl has only "use ieee.std_logic_1164.all;"
07/19 03:51:23 hiyuh
    so, they are separated.
07/19 03:51:40 NULL[0]
    std_logic_(un)signed is a wrapper applied on std_logic_arith
07/19 03:52:43 hiyuh
    heh
07/19 03:53:00 hiyuh
    but i don't use std_logic_unsigned/std_logic_signed to avoid overload
    problem.
07/19 03:54:34 NULL[0]
    std_logic_arith and numeric_std have more or less the same
    functionalities, so there is no reason to use the library which is
    not standard in newer code
07/19 03:55:24 hiyuh
    again, plz promote me more.
07/19 03:55:37 hiyuh
    in technical view.
07/19 03:56:05 hiyuh
    std_logic_arith and numeric_std have more or less the same
    functionalities, so there is no reason to migrate the library which
    is not de facto standard.
07/19 03:57:09 hiyuh
    NULL[0]: so what you said is "in technical"?
07/19 03:57:22 hiyuh
    i don't think so.
07/19 03:57:28 MatthiasM
    hiyuh: numeric_std has resize
07/19 03:57:51 MatthiasM
    and shift_left/right with warnings when the numerical value changed
    because of overflow
07/19 03:58:01 hiyuh
    heh
07/19 03:58:23 MatthiasM
    eg resize(to_unsigned(10, 4), 3) gives a warning in simulation
07/19 03:58:45 MatthiasM
    but resize(to_unsigned(10, 5), 4) is ok

07/19 04:02:52 hiyuh
    yo, |fred| :)
07/19 04:03:14 |fred|
    perfect timing to disappear ;o)
07/19 04:03:22 hiyuh
    lol
07/19 04:33:26 |fred|
    hiyuh: I have actually right now to follow a guideline forbidding
    numeric_std :)
07/19 04:34:00 hiyuh
    lol
07/19 04:34:59 hiyuh
    k, i'll switch to numeric_std at next proj.
07/19 04:35:01 hiyuh
    :D

他人に新しいモノをすすめる時には，trivialでtechnicalな利点を根拠に持たないとダメだと思う．
"it's t3h standard!!1"は"but ITJUSTWORKS(tm)"で一蹴される阿呆に共通する特徴．
んな事を言ったって，我らが仮想敵なボスの無意味に保守的な態度に対向出来る訳無ぇだろよ，カスが．
でも，実を言うとstd_logic_arithに気に入らない所もあるので，今度から numeric_stdを使ってみっかな．
std_logic_arithにしがみついているのは，#vhdlでは少数派の様だし． :P

migrate2KMS(&nouveau); Firmware.karma--;

nouveauがKMSに移行しろと言うのでゴニョる．
見ての通り大変な事になっとるので，もう少し弄る予定ナリよ． :DDD


一ヶ月程ハマっていた問題の原因らしきモノが発覚．
結論から言うと，on-chip firmwareが腐っている臭い．
取り敢えず，コードに罵詈雑言を埋め込んでおこう． :P

勿論，スタイルはtwo-process手法をベースにmultiple CDCとlegacy/tech-specific blobに対応．
問題は抽象化レベルが高くて理解出来る人が少ない事か？

addSpice(&OSS, aBUG);

NWCCの中の人とのメールの一部．

バグってんのはバグってんのでおもしろいモノだと思う．
でも，faultless golden codeを書いてやろうとする気概は常に持ちたいもんだ．
特に仕事でコード書いている時は"ぷろふぇっしょなる"として扱われている事を念頭において欲しいよなぁ．

最近，会社でVHDLを教える機会があって，アレなコードを見る度に罵詈雑言(?)を吐く不良社員ぶりを発揮していたのだが，そうやって温室培養し過ぎると，負の遺産であるウンコなコードに耐性が無くなってしまうと言う弱点もある事に気づいた．
大人の事情もあるし，そう言う腐りかけの生ゴミにあんまり手を触れない様に，異臭のするカビがこっちにも移ってしまわない様に，巧く扱う方法も教えていかねばならんね．
なんとこの世は{生,逝}き難い事か！！1 :P

MeasureSLOC(&AL9); /* 2009/06 */

AでLで9なdiffstat，6月分．
[diffstat for AL9, for 2009/06.]

 bench/BENCH_AFIFO.vhd         |    2 
 bench/BENCH_BCMUX.vhd         |    2 
 bench/BENCH_CLDPCDOP.vhd      |    9 
 bench/BENCH_LDPCDDB.vhd       |  126 +-
 bench/BENCH_LDPCTX.vhd        |  720 --------------
 bench/BENCH_LDPCTX2LDPCRX.vhd | 1846 +++++++++++++++++++++++++++++++++++++
 bench/BENCH_S2BER_IF.vhd      |  194 +++
 bench/BENCH_SB.vhd            |  345 ++++---
 bench/BENCH_SFIFO.vhd         |    2 
 bench/BENCH_XQUEUE.vhd        |    2 
 bench/LDPCRX_MEM.vhd          |  187 +++
 bench/LDPCTX_MEM.vhd          |    4 
 stim/STIM_TX_DATA_CARR.vhd    |    2 
 vhdl/BCBOOL.vhd               |  172 +++
 vhdl/BCMUX.vhd                |  160 +++
 vhdl/BER_IF_CLK.vhd           |   26 
 vhdl/BER_IF_REG.vhd           |   94 +
 vhdl/CLDPCDOP.vhd             |    3 
 vhdl/COS_VLSX4_MEM.vhd        |  838 +++++++++++++++++
 vhdl/ELDPCDII.vhd             |  202 ----
 vhdl/ELDPCDIP.vhd             |  204 ++++
 vhdl/FP1_LDPCRX.vhd           | 2004 ++++++++++++++++++++++-------------------
 vhdl/FP1_LDPCTX.vhd           |   79 +
 vhdl/FP2_LDPCRX.vhd           | 2052 ++++++++++++++++++++++++------------------
 vhdl/FP2_LDPCTX.vhd           |   79 +
 vhdl/FP3_LDPCRX.vhd           |  489 ++++++----
 vhdl/FP3_LDPCTX.vhd           |    6 
 vhdl/FP4_LDPCRX.vhd           |  471 ++++++---
 vhdl/FP4_LDPCTX.vhd           |    6 
 vhdl/HD2BO.vhd                |   11 
 vhdl/LEDIND.vhd               |  180 +++
 vhdl/LLR2SC.vhd               |   31 
 vhdl/PSQUASH.vhd              |   22 
 vhdl/RX_LX_FEBE.vhd           |   92 +
 vhdl/S2BER_IF.vhd             |   22 
 vhdl/SBSSBDD.vhd              |   19 
 vhdl/SB_MASTER.vhd            |  145 ++
 vhdl/SB_SLAVE.vhd             |   45 
 vhdl/SELDPCDIIM.vhd           |  571 -----------
 vhdl/SELDPCDIPM.vhd           |  845 +++++++++++++++++
 vhdl/TSR_CLK.vhd              |   32 
 vhdl/TX_SX_FEBE.vhd           |   34 
 vhdl/XDPRAM.vhd               |    2 
 vhdl/XDYNSR.vhd               |    2 
 vhdl/XQUEUE.vhd               |    2 
 vhdl/XSPRAM.vhd               |    2 
 vhdl/XSPSR.vhd                |    2 
 vhdl/XSSSR.vhd                |    2 
 48 files changed, 8288 insertions(+), 4099 deletions(-)

やっぱ，10kSLOC逝ってないZE!!1 :DDD
受信側のtop wrapperをrewriteしたのが一番大変だったかのぅ．
[ZOMG, under 10kSLOC AGAIN!!1 :DDD
Rewriting RX's top wrappers were rather big to me.]

wmii.karma++; /* Cygwin/X */

Virtex4 LX200 6個分のボードレベルシミュレーション中，暇だったのでテキトーにportingしてたら，なんか動いたらしい． :DDD

EGIT_TREE="1337" emerge x11-drivers/xf86-video-nouveau

　ボブ「やあ，ジョニー，聞いてくれよ．」
ジョニー「なんだい，ボブ．」
　　ボブ「最近，nouveauがGallium3Dな感じでイケてるじゃん．」
ジョニー「mesa/mesaのmasterにも入ったしね．」
　　ボブ「そうそう．」
ジョニー「xf86-video-nvも粛正されたらしいって聞いたよ？」
　　ボブ「うん，x11 overlayの方は何気にGallium3D capableなんだ．」
ジョニー「へー．」
　　ボブ「で，件のgit live ebuildを調子に乗ってガンガンemergeしてたんだけど．．．」
ジョニー「それで？」
　　ボブ「Xが起動しなくなっちゃたんだよ！」
ジョニー「あら，まあ．」
　　ボブ「なぁ，どうしたらいい？」
ジョニー「んー，upstream dev的にはgit bisectしろって言いたい所だけど．」
　　ボブ「あー，やっぱり？」
ジョニー「今までは動いてたんだよね？」
　　ボブ「うん．」
ジョニー「とりあえず，動けばいいの？」
　　ボブ「うん．」
ジョニー「DRMとDRIとDDXのどれが壊れたの？」
　　ボブ「drm.koとnouveau.koはキチンとmodprobeされてる．dmesgで確認したよ．」
ジョニー「じゃあ，DRMは大丈夫そうだね，mesa/drmは最近更新されてないし．」
　　ボブ「DRIならruntimeでswrastにfallbackするはずだから，これは保留だね．」
ジョニー「/var/log/Xorg.0.logは何て言ってるの？」
　　ボブ「なんかBIOSがどうのこうのってメッセージを出して死んでるみたい．」
ジョニー「それ，先頭にNOUVEAU([0-9]*)ってのが付いてる？」
　　ボブ「うん．」
ジョニー「きみ，ppc32だったね？」
　　ボブ「うん，x86が嫌いだからね．」
ジョニー「多分，DDXのnv_bios.cが壊れたんだね．」
　　ボブ「そうなの？」
ジョニー「最近，KMSやwfb関連で色々手が入ってるのさ！」
　　ボブ「へー．」
ジョニー「勘でbisectするとbad commitはこれかな？」

bios: use image from PRAMIN in preference to PROM on NV50

　　ボブ「じゃあ，無難にこの辺りに戻せばいいのかな？」

Add DVI-A output info for Mac card missing bios tables (#21273)

ジョニー「試してみよう．」
　　ボブ「どうやるんだい？」
ジョニー「こうさ！」

EGIT_TREE="b7e3306ddc3693699f6f9de7b22913ee22ed31ed" \
    emerge --oneshot =x11-drivers/xf86-video-nouveau-9999

　　ボブ「なるほど，EGIT_TREEで特定のcommit revisionを指定してあげればいいんだね．」
ジョニー「うん，x11-drivers/xf86-video-nouveauはgit.eclassを使ってるからね．」
　　ボブ「と言うか，EGIT_TREEなのにtree revisionじゃだめなの？」
ジョニー「commit revisionじゃなきゃだめだよ」
　　ボブ「なんで？」
ジョニー「gitはUIがbad designだからじゃない？　平たく言えば，仕様かな？」
　　ボブ「あー，仕様なら仕方ないかー．」

　　　　＝＝＝ emerge実行 & X再起動 ===

　　ボブ「おー，ジョニー，動いたよ！」
ジョニー「じゃあ，またricerな生活を満喫出来るね！」
　　ボブ「ああ，やっぱりGentooは最高だね！」

# 2009/06/17 ちと修正． :)

MeasureSLOC(&AL9); /* 2009/05 */

AでLで9なdiffstat，5月分．
[diffstat for AL9, for 2009/05.]

 b/bench/BENCH_CLDPCDOP.vhd      |  364 +++++++++
 b/bench/BENCH_LDPCTX.vhd        |  720 +++++++++++++++++++
 b/bench/LDPCTX_MEM.vhd          |  191 +++++
 b/bench/MT48LC16M16A2x1.vhd     |  234 ++++++
 b/stim/STIM_FCOD_DATA.vhd       |  217 +++++
 b/vhdl/RX_LX_FEBE.vhd           |  602 ++++++++++++++++
 bench/BENCH_LDPCDDB.vhd         |   84 +-
 bench/BENCH_LDPCEDB.vhd         |    5 
 bench/BENCH_SB.vhd              |  170 +++-
 bench/BENCH_TSR_CLK.vhd         |   44 -
 bench/METABENCH_LDPCDDB.vhd     |   58 -
 bench/METAMETABENCH_LDPCDDB.vhd |   12 
 vhdl/CLDPCDOP.vhd               |    5 
 vhdl/CSSSTM.vhd                 |    3 
 vhdl/ELDPCDII.vhd               |  110 +-
 vhdl/FP1_LDPCTX.vhd             | 1474 +++++++++++++++++-----------------------
 vhdl/FP2_LDPCTX.vhd             | 1026 +++++++++++++++------------
 vhdl/FP3_LDPCTX.vhd             |  130 ++-
 vhdl/FP4_LDPCTX.vhd             |  132 ++-
 vhdl/LDPCD-stub.vhd             |    4 
 vhdl/LDPCD.vhd                  |   85 +-
 vhdl/LDPCE-stub.vhd             |   30 
 vhdl/LDPCE.vhd                  |   60 +
 vhdl/LDPCEDB.vhd                |    6 
 vhdl/PN_BLOB.vhd                |   46 -
 vhdl/SELDPCDIIM.vhd             |    6 
 vhdl/TSR_CLK.vhd                |  149 ++--
 vhdl/TX_SRC_MUX.vhd             |    7 
 vhdl/TX_SX_FEBE.vhd             |  157 ++--
 vhdl/UDACCUM.vhd                |  137 ++-
 30 files changed, 4485 insertions(+), 1783 deletions(-)

やっぱ，10kSLOC逝ってないNE!!1 :DDD
残るは受信側なのでもう一息．
[ZOMG, under 10kSLOC AGAIN!!1 :DDD
'kay, rest parts I have to code is RX's.]

downstream = dup(upstream);

s9fesのさきっぽを追っかけてるらしいdebianな人が「オレのとdupってるぜ！！1」とか言うのでその返事．

きっと親切心でメールをくれたんだと思うんだけど，オレはさきっぽを追っかける事自体が目的みたいなもんだからdupしてても一向に構わんのだけどなぁ．
結局upstreamの中の人が気に入ればdownstreamのchangesetはupstreamにmergeされて，結果全てのdownstreamに還元される訳だし，DSCMってそう言う為のモノじゃねぇの？

つーか，なんでみんなgit使ってんだよ！！1 :DDD

Me -= Blood; Me +=Coffee; Me += GyouZa;

高専時代の知り合いから電話があった．
オレと違って大学に編入した後で修士まで行ったらしく，しかもオレの今の仕事の分野に近いトコロをゴニョっていた様で妙に話が合って蝶意外．

が，メインはそっちじゃなくて，高尚なものではないけど抽象的な人生相談(?)の様なモノだった．
例の如く不況の煽りを受けて修士を出てから就職した会社のある部門が無くなるそうで．
「オレはエラくもないし，職は斡旋出来ないぜー」とか言ったら，もう幾つか内定は貰っているが，いい機会だから色々考えたいんだとか．
で，高専時代でもオタク全開だったオレが今は何をやらかしているのかとか聞きたかったらしい．
ふむふむ．．．ぬるへそ，ぬるへそ．．．
．．．って，オタクのまんまに決まってんじゃん，変わりゃしねぇよ． :DDD

つー訳で，オレはヒキコモリなハズなんだが，土日連続で外出すると言う異例の事態に．
駅で待ち合わせをしている間のヒマつぶしに献血して，合流してから"どとぉる"なコーヒーと餃子メインの店のメシをゴチになってきた．
オレの話が参考になったかどうか分からんけど，彼はオレよりずっと英語出来るし，スゲェイケメンなので大丈夫じゃね？ :DDD

別れ際，「今度就職祝いしてくれー」とか言ってた．
今日のお返しにメシくらいおごってやるさ．
まぁ，頑張れや． :)

HikiKomori | ~HikiKomori

会社に案内が来てて，ボスが「暇なら行けば？」みたいな事を言っていたので，俺はひきこもりなはずなんだが，今日はNHK放送研究所の技研公開に行ってきた．
休日なので一般の人が蝶いっぱい．

見栄えのするブツの方に人が集まってたけど，仕事でお手伝いさせてもらったブツの展示をメインに見てきた．
アンテナの受信信号を並列に記録するHDDレコーダのお化けを拵えてリアルタイム復調してた，地味にすげぇ． :DDD

それにしてもあの辺は雰囲気がおしゃれ(?)過ぎて，なんか落ち着かない．
んー，どうしたもんかなぁ．

USE=-gold emerge sys-devel/binutils

　ボブ「やぁ，ジョニー，聞いてくれよ．」
ジョニー「なんだい，ボブ．」
　　ボブ「IUSE=goldなsys-devel/binutilsを見つけたので，chrootもせずにemergeしたんだ．」
ジョニー「へぇ，それはなんともricerらしいじゃないか．」
　　ボブ「だけどさ，続いてemergeしようとしたsys-apps/shadowのeconfがコケるんだ．」
ジョニー「それはまたどうして？」
　　ボブ「僕も変だなと思って，手元の自分のCのプログラムをコンパイルしてみたんだ．」
ジョニー「それで？」
　　ボブ「なんと何もコンパイル出来なくなってたんだよ！」
ジョニー「なんてこった！」
　　ボブ「慌ててUSE=-goldでsys-devel/binutilsをemergeしなおそうとしたんだけど．」
ジョニー「ダメだったと．」
　　ボブ「そうなんだ．」
ジョニー「なるほど．」
　　ボブ「なぁ，ジョニー，どうしたいいと思う？」
ジョニー「そんな時はricerなオレ達の強い味方，tinderbox.dev.gentoo.orgの出番さ．」
　　ボブ「何だいそれは？」
ジョニー「systemでstableなブツやクロスコンパイラのバイナリなんかを提供しているトコさ．」
　　ボブ「へぇ，普段自前でしかコンパイルしないから知らなかったよ．」
ジョニー「で，コイツをPORTAGE_BINHOSTで指定して-gKでemergeすれば良いんじゃないかな？」
　　ボブ「具体的には僕の場合はどうやるんだい？」
ジョニー「君はなぜかppc32だったよね？」
　　ボブ「うん，x86が嫌いだからね．」
ジョニー「ならこうさ！」

PORTAGE_BINHOST=http://tinderbox.dev.gentoo.org/default-linux/powerpc/ppc32 \
    emerge -gK =sys-devel/binutils-2.18-r3

　　ボブ「へぇ，いつもemergeするのとあんまり変わらないね．」
ジョニー「これで少し古いけどsys-devel/binutilsは治ったハズだよ．」
　　ボブ「なるほど，これで改めてUSE=-goldでsys-devel/binutilsをemergeすれば良いんだね！」
ジョニー「そうさ，簡単だろ？」
　　ボブ「ああ，やっぱりGentooは最高だね！」

Barcamp.Tokyo[2009] = BenTou + Curry;

waitingだったんだけど，「それでも大丈夫だから来い」みたいなことを言われたのでBarcamp Tokyo 2009に行ってきた．
TLUG並に外国人参加率が高くて，そこら中でネイティブっぽい人達の英語が炸裂してて，俺もPowerBoook弄ってまともに話を聞いていない事も相俟って当社比2倍で訳分からんかった．

あるbrainstormingで「barcampの日本人参加率を上げようぜ」みたいなネタが出て，ありえないぐらいマシンガンかましている人がいたが，正直何を言いたいのかさっぱり聞き取れんかった．
これは新手のプレイだね，間違い無い．

つーか，良く考えたら何で日本人参加率を上げたいんだろう？
彼らが都合の良い英語をプロトコルに使って，実のある話が出来れば日本人参加率が低くても良さそうなもんだけどなぁ．
仮に日本語でのプレゼンやら質疑応答を許可したとしても，そこら中でマシンガンかましているのが大多数だったら，普段英語なんか使う機会が殆ど無い日本人の参加率が上がる訳無ぇだろ，とかここではdisってみる．
少なくとも俺には「郷には入れば郷に従え」ってのが強迫観念みたいに頭から離れんよ．

言い訳しておくと，俺はコードのコメントは悉く英語だし，情報が英語で書かれていても知りたい情報なら読むし，IRCで1337 speakでフザケてたりするけど，耳と口は英語化してないんだよなぁ．
大抵の日本人はコードのコメントは日本語だし，情報が英語で書かれていたら読むのを躊躇うし，IRCで1337 speakなんかしないので，もっと英語化はしていないと思うんよ．

だから，向こうがマシンガンを捨ててカタナに装備を変えるか，こっちがカタナを捨ててマシンガンを装備するかのどちらかをしないと同じ戦場でまともに戦えない．
で，不味い事にマシンガンの方が戦力的に見て圧倒的に有利と言う現状がある訳で，極一部のサムライはカタナを捨ててマシンガンを装備するけど，残りの人達はカタナを持ったまま突撃するか，出島を作って鎖国するか，カタナを捨てて畑を耕してる．

brainstormingは基本的に否定/批判を排したブツだから，その場でどうこうってのはやらなかったし，する気も無かったけど，あそこでマシンガンぶっ放してた人達は最初からマシンガンだけしか装備していなかったとか，ただ単にカタナで斬り合った経験が無いだけだったりしねぇ？
それを一方的に「fair playじゃねぇ！！1」とか言う気は無いし，俺はカタナが結構好きだから別に構わないけど，同じ戦場でまともに戦う事を一番に望んでいるなら，マシンガンをぶっ放してた方はカタナも装備してみようとか，カタナでしか斬り合いした事が無いならマシンガンでもぶっ放してみようとか，っつー言う気概くらいはあっても良いと思うんだよね．

そう言う意味では拙い日本語でコミュニケーションをしようとしてくれるガイジンさんにはとても感謝したいし，俺のbr0ken Englishでも良いなら受け答えしてあげたいと思う．
ま，中々巧く話が進まない所もあってもどかしいけど，だがそれが良い． :)

ああ，そうそう．昼飯の弁当と夕食のカレーはタダ飯だったのでこんなタイトルになってます．深い意味はありません． :DDD

wm.lineage->next();

graphvizがタルくなったので，inkscapeを乗り換えた．
んで，色着けて線が交わらない様にしてみた． :)
SVGはここに晒しておこう．
[using inkscape instead of graphviz, then colorize and flatten. :)
want SVG? here it is.]

線はそれなりに関連があるって事で，必ずしもforkやrewriteを意味する分けでは無かったりする．
タイル型WMでないモノも入っていたり，そもそもWMじゃないモノも入っているがそれなりに意味がある．
[lines just indicate their relation, not only fork/rewrite.
There is some non-tiling WMs, more over few ones are not WM.
But they're worth to mention for explaining about recent GUI improvement for experienced users.]

あとはmultitalkの資料が間に合うかどうかだな． :p
[hmm, making presentation 2D map by multitalk? oh well. :P]

TLUG.NomiKai++; synthSound(&hardware);

TLUGに行ってきた．
BarCamp-Tokyo2009の中の人がHypertextについて話してたのと，XMLとSQLの香りがするsemantic webの話だった．
皆さんはレイヤが高いですな，あいかわらず． :)
飲み会/二次会ではshojiさんのSunオフレコ話とかJARIさん（北欧のイケメン）のアレとか色々．

帰ってからmatsuuさんのBarCamp-Tokyo2009用の下ごしらえっぽいモノとして，それっぽいgraphvizな絵をでっち上げた．
多分，もうちっと弄る．


上の絵をでっち上げていたら，#vhdlでhardware sound synthesize野郎が現れていた． :DDD

05/10 03:54:30 mad
    I'm planning on making sound generation stuff
05/10 03:56:23 mad
    most of that stuff is based around a phase register being incremented
    by the frequency on each sound cycle (which is pretty low rate -
    typically around 44khz)
05/10 04:02:43 bpadalino
    sounds like a cordic should help you out
05/10 04:04:46 hiyuh
    cordic is not for making sound, imho.
05/10 04:09:48 hiyuh
    that sounds like singletone, variable freq in narrow range, and
    presicion is not so important.
05/10 04:10:38 hiyuh
    maybe, making rom-based nco is enough to do.
05/10 04:14:39 bpadalino
    i don't know if a saw wave would sound very good, but as a phase
    accumulator - a cordic sounds like it would work well
05/10 04:30:24 hiyuh
    I meant cordic is expensive for that use.
05/10 04:30:29 hiyuh
    and saw wave + filter for singletone is not a possibility, anyway.
05/10 04:32:34 hiyuh
    phase accum -> sin or cos rom in appropriate precision -> singletone,
    it's simple rom-based nco.
05/10 04:40:47 bpadalino
    you really think a cordic is that expensive ?
05/10 04:51:49 hiyuh
    bpadalino: yes
05/10 04:51:58 bpadalino
    interesting
05/10 04:55:54 bpadalino
    hiyuh, so if you wanted to create 20 tones, how would you go about
    doing that ?
05/10 04:57:07 hiyuh
    20 tones in same time?
05/10 04:57:31 bpadalino
    yeah
05/10 04:59:05 hiyuh
    these tones are elaborate-time fixed or run-time fixed?
05/10 05:00:05 hiyuh
    I meant these tones are fixed before logic synthesize, or not.
05/10 05:00:29 bpadalino
    runtime fixed tones .. frequency fixed before synthesis, but phase
    programmable ..
05/10 05:00:44 bpadalino
    and i want the sum of the 20 tones on the output
05/10 05:07:54 hiyuh
    you mean "amplitude * (sin(2*pi*f1*t + theta1(t)) + ... sin(2*pi*f20*t
    + theta20(t)))"?
05/10 05:09:10 bpadalino
    yeah
05/10 05:10:53 hiyuh
    if I were you, I'd like to make semi-fixed digital filter or just
    do IFFT.
05/10 05:12:42 bpadalino
    that's what i had figured before, but i was just curious what someone
    else might have thought
05/10 05:13:00 hiyuh
    heh
05/10 05:14:18 bpadalino
    i would like to do my own generic systolic FFT sometime ... i think
    that might be fun
05/10 05:16:23 mad
    the tones parameters are written to at performance time
05/10 05:18:05 mad
    It's for music generation, so the applicable freqs are about 20hz to
    20khz (although tones over something like 4khz aren't particularly
    musical)
05/10 05:19:17 anonissimus
    mad: but as harmonics they are
05/10 05:19:33 mad
    Precision has to be at least 1%, esp. in the "most common range"
    (around 50hz ~ 1000hz)
05/10 05:19:50 mad
    anonissimus: yeah, but those are generated from another process
05/10 05:21:16 anonissimus
    ah
05/10 05:21:38 anonissimus
    know more on music than on generting it with hardware :)
05/10 05:21:57 mad
    My plan is: start with pure phase accumulator, then twist the phase
    around in a couple of functions (incl. one that uses multiplication),
    then use sine wave/funky waveform LUT, apply volume and panning,
    sum the channels together, DAC
05/10 05:24:12 mad
    Uses about 140 bits of registers per channel
05/10 05:27:44 mad
    A real practical design would actually be sample based instead
    (with samples in RAM)
05/10 05:29:23 hiyuh
    you know, your plan violates my assumption that described in the
    above expr.
05/10 05:29:25 hiyuh
    so what I was saying is not good way for you.
05/10 05:29:59 mad
    mm, right
05/10 05:31:35 mad
    sound synthesis isn't so hard because the sampling rate is low
    anyways... and you can do it well in software if you have enough CPU
05/10 05:32:14 hiyuh
    yeah, that's why soft synth is popular atm.
05/10 05:32:40 mad
    no kidding, since it pretty much solves it

つまり，敢えてsoftware sound synthesizeしないっつーことですか？
そいつは物好きだなぁ． :)