Oracleのメッセージキューイング機能をJavaで使ってみる

みなさんは、「メッセージキューイング」というジャンルのソフトウェアをご存知でしょうか。IBMのMQシリーズなどがその代表格ですよね。システム間でデータを非同期にやり取りする際に、「キュー」という概念を導入し、送受信が確実に行われることを保証する、案件によっては非常に有用な機能です。

私にとっては非常に悔しいことに、メッセージキューイングを実現するためのソフトウェアって、どれも非常に高価なんですよね。もちろんコストに見合った機能を持っているからなのですが、それでも予算の絶対額が限られているプロジェクトではなかなか手が出せません。ですが! なんと有り難いことにOracleにはこのメッセージキューイング機能が、「アドバンストキュー」という名前で用意されています(Oracle8以降)。

それでは、Oracleのテーブルなどを利用してデータの送受信を行なう方法と、アドバンストキューイングを使う方法との違いは何なのでしょうか(通常のメッセージキューイングソフトを使える人はそちらを使うでしょうからあえて比較しません^^)。

メリットとしては、

• コーディングの量が減少する
• キューの基本的な機能を実装しているため、他のミドルウェアへの以降も行ないやすい

といったものがあるでしょうし、デメリットとしては、

• 実績が少ない。実際、使っている事例を聞くことはほとんど無い。

というのが最大のものでしょう。ともあれ、使ってみることはそれほど難しくないので、まずは試してみるというのも悪い選択ではないと思います。

231位じゃだめですか？ Amazonクラウドが1兆FLOPSを超えるスーパーコンピュータ並の「クラスターGPUインスタンス」を提供。1時間たったの172円 － Publickey

231位じゃだめですか？ Amazonクラウドが1兆FLOPSを超えるスーパーコンピュータ並の「クラスターGPUインスタンス」を提供。1時間たったの172円 － Publickey

2010年11月16日

個人でもスーパーコンピュータの性能でトップ500に入るマシンを借りることができる時代になりました。しかも1時間あたりわずか172円。

Amazonクラウドは、ハイパフォーマンスコンピューティング（超高速計算）のために提供してきた「クラスターコンピュートインスタンス」に、グラフィックスカードに搭載されているGPUの能力を一般的な計算処理に使う「GPGPU（General Purpose GPU）」の機能を備えた「クラスターGPUインスタンス」の提供を開始したと発表しました。

Verilog-HDL 入門

verilog-HDL 入門

---

1．始めに

本文書では verilog-HDL を用いてハードウエアを記述するために必要な 基礎を説明する。 とりあえず、なにがしかのハードウエアを記述し論理合成や テストを行えるようになることが目標である。verilog-HDL の詳細な文法については規格書や各種参考書を見て欲しい。

2. verilog-HDL の成り立ち

verilog-HDL は旧 Gateway Design Automation 社のシミュレータ専用言語であった。 元々はシミュレーション言語であるから、 ハードウエアを効率的に記述することは主目的では無かった。 しかし、これに論理合成ツールが加わることによって、HDL を用いて ハードウエアを記述し設計することが現実的になった。 このため大いに広まり、現在では IEEE の規格の一つになっている。

しかし、シミュレーション言語である verilog-HDL を 無理矢理ハードウエア記述に使っているため、 現実のハードウエアとの間に一部不整合が有る。 この点をふまえて、ハードウエア記述源として用いる場合には、 非効率なハードウエアを記述しないように注意する必要がある。

なお、より効率的な記述を取り入れると共に、 このような不整合を解消する試みとして Systemverilog が規格化されている。

3. verilog-HDL によるハードウエア記述の構造

図1.に verilog-HDL によってハードウエアを記述した場合の構造を示す。 verilog-HDL ではモジュール(module)と呼ばれる単位によって構造を記述する。 各部品をモジュールとして記述し、 このモジュールを繋ぎ合わせることによって全体を構成する。 繋ぎ合わせる時に実際に呼び出される実態をインスタンス(instance)と言う。 このように、モジュールはハードウエアの記述を行うだけで、実態としては働かない。 例えば、同一の構造をもった演算器を複数設置する場合、 その演算器の機能を記述するのがモジュールで、演算器1、演算器2と 名前を付けて設置されるものがインスタンスである。 インスタンス中でさらに別のインスタンスを呼び出す事もできる。 (再帰的呼び出しはできない)。

注意すべきは、ハードウエア記述言語は、一般的な 手続き型プログラミングとは全く違うということである。 古典的な手続き型プログラミングでは、 関数インスタンスが多少の内部状態を持つことが有っても、 各々の関数が呼び出されない限りその働きを気にする必要は無い。 これに対し、ハードウエアでは各々の構成要素は常に動いている。 全てが並列に動いていると言い換えても良い。 どちらかと言えば、イベント駆動型プログラミングにおいて、 そこらじゅうでイベントが起こっている状態に近い。

したがって、ハードウエア記述言語では常に各々の部品の動作に気を使う必要がある。 この点においては物理的なハードウエアの性質と何ら変わることはない。 結局ハードウエア記述言語というのは、 別々に動作する部品を設計しそれらを繋ぎ合わせる作業を、 文字を用いて行うための手段である。

4. モジュール

ここでは verilog-HDL の基本であるモジュールについて説明する。 まず、モジュールの構造の概要について述べ、 単純な 4 bit カウンタを例にモジュール内の構造を大まかに説明する。 細かい記述法については後続の節を参照して欲しい。

4.1 モジュールの基本構造

モジュールの構造の概要をリスト1に示す。 モジュールは大まかにいって、ポート記述、 変数記述、組み合わせ回路記述、順序回路記述から成る。 厳密にはこれは正しくないが、 ディジタル LSI を記述するという目的から見たときは、 このように考えて問題無い。

 リスト1 モジュールの構造の概要 module counter4(ポート名, ポート名,,, );    ポート記述     変数記述     組み合わせ回路記述     always 文      begin        順序回路記述      end endmodule 

4 bit カウンタを記述したモジュールをリスト2 に示す。"//"以降行末まではコメントである。 ここでは、細かい記述はともかく、モジュール内の構造に注目して欲しい。

 リスト2 モジュール記述の例 // 4 bit simple counter module counter4(                 //*************** port name list **************                 clk, // clock                 rst, // reset                 count // counter output                 //*********************************************                 );    //************** port definition **************    input clk, rst; // clock, reset    output [3:0] count; // counter output    //*********************************************     //*********** parameter declaration ***********    reg [3:0]         counter; // count register     wire [3:0]         count_tmp; // count up value    //*********************************************     //********* combination logic circuit *********    assign         count = counter; // connect to output    assign         count_tmp = counter + 1'b1; // count up    //*********************************************     //*************** state machine ***************    always @(posedge clk or negedge rst)      begin         if (~rst) // reset           begin              counter  

4.2 モジュール文

モジュールは module 文で始まり、endmodule 文で終わる。 module 文ではモジュール名を示し、つづく括弧内で引数として入出力ポート名を示す。

4.3 ポート属性記述部

module 文の直後にポートの属性とビット幅を記述する。 通常使うポートの属性は、input, output, inout の 3 つである。 ビット幅は通常 [ビット幅-1 :0] のように上位下位の順で指定する。 ビット幅が同じ場合は、"input clk, rst;" のように続けて記述できる。

4.4 変数定義部

言語仕様上は変数定義はモジュール内のどこでも記述できる。 モジュールが小さい場合はポート属性記述の次に変数定義を行うことが多い。 モジュールが大きい場合は、変数定義とその変数の使用場所があまり離れないように記述した方が良い。

4.5 組み合わせ回路記述部

変数定義部の後に組み合わせ回路を記述する事が多い。 リスト2 中では assign 文を用いて簡単な組み合わせ回路を表現している。 この assign 文を用いるか、function を用いて組み合わせ回路を記述する。 assign 文と function 文については後述する。

always 文を用いて組み合わせ回路を記述することもできるが、 記述が繁雑になる上に 論理合成で思わぬ結果が出ることもある。 always 文で組み合わせ回路を記述するのは避けた方が賢明である。

4.6 順序回路記述部

順序回路を含まないモジュールの場合は記述しない。順序回路を含む場合は、 多くの場合モジュールの最後に always 文を用いて順序回路を記述する。

always @( に続く信号名はセンシティビティリストと呼ばれる。 always 文はこのセンシティビティリストに記述された信号が変化したときのみ動作する。 posedge, negedge は各信号の立ち上がりで反応するか立ち下がりで反応するかを指定する。

論理合成をを用いて大規模なディジタル LSI を設計する事を考えると、 このセンシティビティリストにクロックとリセット 以外の信号を混ぜるのは避けた方が良い。

要するに普通にディジタル LSI を設計している場合には、 リセットする順序回路部分は always @(posedge clk or negedge rst) で始め、 リセットしない順序回路は always @(posedge clk) で始めると憶えれば良い。

(注)リセット信号は負論理であることが多い。

なお、一つのモジュール内にいくつでも always 文を記述することができるが、 繁雑さを防ぐために、できるだけ一モジュール内の always 文は 一つにまとめた方が良い。

4.7 リセット

リセット信号は実に厄介なしろものである。 現在では reset 信号は clock と同様に特別な配慮をする必要があるため、 論理合成時には理想的な信号線として扱い、 レイアウト時にリセットツリーを挿入することが一般的である。 このため、適切に遅延時間を算出するのが難しく、 リセット信号を論理に用いると静的タイミング解析時に問題が生じることがある。

例えば、リセット時に定数をレジスタ変数に代入する場合は良いが、 リスト3 のようにリセット時に変数の値を代入するような場合に問題となる。 これはチップの外から初期値を取り込むような場合に生じる。

最初のデザイン

最初のデザイン

最初のデザイン

それでは、XILINX ISEを使って開発を行うことにします。

最初に作るのは、LEDチカチカです。

本ボードには8個のLEDが搭載されているので、これをチカチカさせてみることにしましょう。

そして、基板上のプッシュスイッチが押されたら、チカチカの点滅方法を変えるようなデザインにします。

 

開発の流れは、

�/p>

（Verilog派の方はVerilog Moduleを選択し、ファイルの拡張子は.vとなります）

図7 VHDLファイルの新規作成

 

入出力ポートの定義

次の画面では、VHDLファイルで記述するモジュールの入出力ポートを定義します。

 

このサンプルデザインでは、水晶発振器からのクロックを受け取るポート、プッシュスイッチの状態を見るポート、LEDへ値を出力するポートの3種類のポートを定義します。

ポートの名前は、入出力がわかるように、末尾に_ip、_op、_bpをつけておくとよいでしょう。（_bpは双方向）

こうしておくと、回路内部の信号と外部のポートとの区別がしやすくなり、方向もわかるので便利です。

New Source Wizardの画面であ、Port Nameのところにxtalclk_ipと、pushsw_ipと、led_opの3種類のポートを定義してください。led_opは出力ポートなのでDirectionをoutに変更し、BusのチェックボックスをONにし、MSBに7、LSBに0と記述してください。

これでNextを押します。

 

図8 入出力ポートの定義

 

確認画面が出たら、Finishを押します。

図9 入出力ポートの定義の確認

 

すると、VHDLファイルの雛型が出来上がり、ISEの中で開かれます。

図10 VHDLファイルが作成されたISEプロジェクト

 

ISEのうれしいところは、この時点でVHDLの雛型が出来ていて、しかも、library IEEE・・などのおまじない構文が自動的に書かれていることです。

 

library IEEE; use IEEE.STD_LOGIC_1164.ALL;   -- Uncomment the following library declaration if using -- arithmetic functions with Signed or Unsigned values --use IEEE.NUMERIC_STD.ALL;   -- Uncomment the following library declaration if instantiating -- any Xilinx primitives in this code. --library UNISIM; --use UNISIM.VComponents.all;   entity ledchika is     Port ( xtalclk_ip : in  STD_LOGIC;            pushsw_ip : in  STD_LOGIC;            led_op : out  STD_LOGIC_VECTOR (7 downto 0)); end ledchika;   architecture Behavioral of ledchika is   begin     end Behavioral;

リスト1 新規に作成されたVHDLファイル

ここで、先頭の

use IEEE.STD_LOGIC_1164.ALL;

に加えて、

use IEEE.STD_LOGIC_ARITH.ALL;

use IEEE.STD_LOGIC_UNSIGNED.ALL;

を追加することをお勧めします。

 

また、FPGAに用意されたプリミティブを使いたい場合は、

--library UNISIM;

--use UNISIM.VComponents.all;

のコメントを外してください。

 

VHDLはarchitecture〜begin〜endという構造をしていて、architectureとbegin間では信号や定数の宣言を行い、beginとendの間では論理式の記述を行います。

architecture

PROJECT ASURA R&D Light Propagation Volumes

PROJECT ASURA R&D Light Propagation Volumes

Light Propagation VolumesXNAǼơפäƤꥯȤƤޤ˻ΤǤʤʤդ֤ޤ
ĤȡäƤä֤ɤȻפΤǡˡˤĤƤƤޤ
DirectXɤͤϡNVIDIASDK˼㤬ΤǸƤ

ޤ르ꥺγפǤʲΤ褦ʥƥåפˤʤޤ

Step.1 Reflective Shadow Map
Step.2 Radiance Injection
Step.3 Radiance Propagation
Step.4 Scene Lighting

ޤǽStep.1
Reflective Shadow Mapޤ뤳ȤϡGХåեʿ١ɶ֤ΰ֡ˡ٥ȥ롤«ˤʤΤ礷Ȥ̵Ǥflux(«ˤη׻ˡǤReflective Shadow Mapsʸ3.2Ϥ˵Ҥޤ
ֺǽˡƥԥ˱äͤ줿«׻ɬפ롣uniformʿԸˤĤƤϡȤʤ롣uniformФƤϡ«ΩγѤ뤿᥹ݥå;ǸפȽ񤤤Ƥޤ
ʤΤǡֳڤʼʿԸȤƥ饤Ȥ谷ŬꤷƤФ褤Ǥ礦ȤƼ갷ϡLight Propagation VolumesAppendix Bˤ餷᥽åɤܤäƤޤ

half GetTexelLum( const in RSMTexel texel )
{
return Luminance( texel.vColor ) * max( 0.h, dot( texel.vNormal, g_lightDir.xyz ) );
}

luminanceϵͤʤΤǡ餯Τ褦ʷ׻ˤʤȻפޤ

half Luminance( const float4 color )
{ 
return 0.299 * color.r + 0.587 * color.g + 0.114 * color.b;
}

ˡʸˤ񤤤Ƥ褦ˡΤޤޤβ(Virtual Point Light:VPL)ȤƻȤäƤޤȽŤΤǡ󥵥ץ󥰤ƽ٤ڸƤޤ
ɤAppendix B˺ܤäƤΤǡ򻲹ͤˤФ褤Ǥ礦
äƤ뤳Ȥ4ƥʬ򥵥ץ󥰤ơGetTexelLum()᥽åɤˤͤ׻Ǥ뤤ƥꤷޤˡե륿ݤޤե륿γݤϡ4ƥФƺǤ뤤ȷꤵ줿ȡ륻Ȥ2Υ׻Υ3̤ξ˿١ˡûΥ3̤ǤΤĤ뤫ȤƤޤơǸƤޤơ줿ͤϤȤǤ
Appendix BΥɤ򸫤Ȥ狼褦ˡåɰȤΤǡ餫ᥰåɤۤƤɬפޤåɥȡʬȤޤХåɤϹۤǤΤʤǤ礦

³Step.2Ǥ
󥵥ץ󥰤Reflective Shadow MapΥƥȤƳǼƤݻƤޤ
ΥƥåפǤϡƥȤƳǼ줿Ĵ´ؿǰ̤ơܥ塼ƥؤȳǼƤޤ
ޤˡ٥ȥ뤫2ޤǤSH򻻽ФޤȤϤη׻SHStep.1ǺGХåե«ФRGBʬݤ碌СĴ¤ǶͤޤޤȤϤRGBʬȤ̤ΥƥȤƵ᤿ͤ¸Ƥޤ
ΤޤޤǤϼʾˤ륢ƥեȤȯƤޤޤ򤱤뤿ˡǽäȤ餹ȤƤޤ

ϡStep.3Ǥ
̤̾ꡤǥ󥹤ãƤޤפܤФSHͤûƤФǤ
λAppendix C. Propagation scheme˺ܤäƤޤ

ǸˡStep.4
饤ƥ󥰤Ԥޤ饤ƥ󥰤Ϥäƥץã줿ǥ󥹥ܥ塼ͤȡSHѤơ饤ƥ󥰤Ԥޤ

ʤ櫓ǡΤϤ狼פȻפޤ

Light Propagation VolumesĶ³Ǥ
ꤢʤΤǡޤǾ֤Ƥ
ȡޤɽӼϥåĥάΤǡʸ򻲾ȤƤ

----------------------------------------
6.2 Geometry-aware light injection and shifting

ޤФʶֶΤˡʾ򤵤뤿˳VPL pΥǥ󥹤γƤñͤ򥷥եȤɬפޤʿ9ȡˡ桹ϡˡ˸ǥ󥹤¤ˤƺǥȾʬǤͤ˸ǥ󥹤򥷥եȤ뤳Ȥ­ޤäơǾͤΥ顼Ƴ졤¿ξˤƼʾ򤱤ޤܺ٤ʼˤĤƤAppendix C򻲾ȤƤǤ⡤ñͤǥ󥹤򥷥եȤ뤳Ȥϴ˼ʾ˾ޤʤǥ󥹥֥꡼ǥ󥰤򤱤ˤϽʬǤϤޤ

6.3 Anisotropic upsampling of radiance volume

֥5.5˽Ҥ٤Τ褦˶Ū˶줿ǥ󥹤SHΥȥ饤˥֤ϺǽŪʥǥ󥹥ܥ塼δ֡˾ޤʤʾ֥꡼ǥ󥰤Ȥä褦ʽʥƥեȤ⤷ޤʿ9ȡˡФơʤȤ3Ĥβǽˡ¸ߤޤ

ǽ1Ĥϥͥƥ֤ʥץǡʾ褦ˡǡեåǥեȤñͤ줿VPLΩĤΤǤΥեåȤ1ĤΥĹΤǡ椨ˤƶ᤯֤줿֥Ȥˤư̤Ȥʤޤäơ桹ϤΥץϻѤޤ

2ܤΥץϡñͥơˤ뤤"ǥ"[DSDD07]ȸƤФХå饤ɤä뤳ȤΩޤϡȿФ˸ȥľǡǥ󥹤γƤ⤤"ȥ饹"Ĥ褦ˤޤäơȥ饤˥֤뤳ȤϽˤʤޤˡμreflective shadow map2褹ɬפȤȤǤǽˡ̥̾󥰤ȿͤ줿饤ƥ󥰡ˡ2˥ͥƥ֤ʥ饤ȤФ̥󥰤뤳ȤǤϥƥ˥åʣäޤñͥơΤãơθǡΥͥƥ֤ʥǥ󥹤ˤĤƷ֤ޤޤ̩ȿиΥȥξˤơְäưŤ줿Τϡ⤦Ĥ򤱤ʤǤɤäƤΤǡ桹ϤΥץȤޤ

Ǹˡ桹ϵǥ󥹥ܥ塼˰¸åץץ󥰤ˡȯޤˡμʥǥˡ˱äƥȥС뤳Ȥȡǥǥ󥹤ʬ׻뤳Ȥˤäƴְä֤򸡽Ф뤳ȤǤ

桹SHФ濴κʬѤޤʿ10ȡˡn˸濴κʬϥǥ󥹤θۤ׻뤳ȤǤ

ʼ

äơºݤΥǥ󥹤ĥǥ󥹤ʬӤ뤳ȤˤꡤˤĤơΥȥ饤˥֤ǥ󥹤γƤΥƻϤޤäƤ뤫ɤ׻뤳ȤǤޤ

9ˤˡη̤򼨤ޤ

--------------------------------------

դ
Ƥ4ʾ夿äƤޤޤˤĶ򽪤Ȼפޤ

Light Propagation Volumes in CryEngine3 Ķ--

ޤ󡢤ä깹˺Ƥޤ

Light Propagation VolumesĶ³Ǥ
ꤢʤΤǡޤǾ֤Ƥ
ȡޤɽӼϥåĥάΤǡʸ򻲾ȤƤ

------------------------------------------------------

6. Improvements and Optimizations

言語設計FAQ — プログラミング言語 Go ドキュメント V0.1 Documentation

言語設計FAQ — プログラミング言語 Go ドキュメント v0.1 documentation

生立ち

このプロジェクトにはどのような歴史がありますか？

Robert Griesemer、Rob PikeおよびKen THompsonは2007年9月21日にホワイトボードに新しい言語の目標をスケッチすることを始めました。数日かけて、数ある目標から、何をするのかという計画と、この言語の美しい理想像が定まりました。他の仕事と並行して、隙間時間を利用して設計が続けられました。2008年1月までに、Kenはコンパイラについてのアイディアを追求することを始めました。それは、コンパイラの出力としてCのコードを生成することでした。この年の中頃までに、この言語はフルタイムのプロジェクトとなり、製品版コンパイラを製作するために十分な時間を費やすことになりました。2008年5月には、Ian Taylorが自主的に、ドラフト版の仕様をもとにして、GCC用のフロントエンド作りに取りかかりました。Russ Coxは2008年の終わり頃に参加し、言語とライブラリをプロトタイプから現実的な実装に導くことを助けました。

ほかにも沢山の人々にアイディアを出していただき、議論をし、ソースコードに寄与していただきました。

なぜ新しい言語を作るのですか？

Goは、既存のシステムプログラミング用言語と環境への欲求不満から生まれた言語です。プログラミングはとても難しいものとなってしまいましたが、それは言語の選択が一因でもあります。効率的なコンパイル、効率的な実行、または容易なプログラミングのいずれかを選ばなければなりません。なぜなら、主要言語において、これら3つを満たす言語は無かったからです。プログラマは、安全性と効率を楽に得ることを選択するために、C++ではなく、PythonやJavaScriptのような動的型付け言語や、C++より自由度を下げて拡張したJavaに乗り換えることが可能ではありました。

Goは、インタプリタ型の動的型付け言語の容易なプログラミングと、コンパイラ型の静的型付け言語の効率と安全性を兼ね備える試みです。また、現代的であり、ネットワークコンピューティングおよびマルチコアコンピューティングをサポートする狙いがあります。最後に、高速な実行を狙いとしています。その上で、1つのコンピュータで大きな実行可能ファイルをビルドすることが数秒で完了するのは当然のことです。これらの目標を実現するためには、数々の言語上の課題に取り組まなくてはなりません。表現力が豊かで軽量なシステム、同時並行性とガーベジコレクション、堅牢な依存関係の仕様、などなどを実現する必要があります。これらはライブラリやツールで上手に解決することは不可能です。ゆえに、新しい言語が生� ��れたのです。

Goの祖先は何ですか？

Goは基本的な文法の大部分はC言語系から受け継いでいます。また、宣言やパッケージについては、Pascal、Modula、Oberonから大きな影響を受けています。加えて、並行処理については、Tony HoareのCSP (Communicating Sequential Process) に影響を受けている言語であるNewsqueak、Limboから同じアイディアを取り入れています。しかしながら、全体としては新しい言語です。あらゆる点において、Goはプログラマが何をし、どうプログラムを作るのかということを考えられて設計されています。少なくとも私たち自身が行うプログラミングがより効率的に、より楽しくあるようにです。

What are the guiding principles in the design?

Programming today involves too much bookkeeping, repetition, and clerical work. As Dick Gabriel says, "Old programs read like quiet conversations between a well-spoken research worker and a well-studied mechanical colleague, not as a debate with a compiler. Who'd have guessed sophistication bought such noise?" The sophistication is worthwhile—no one wants to go back to the old languages—but can it be more quietly achieved?

Go attempts to reduce the amount of typing in both senses of the word. Throughout its design, we have tried to reduce clutter and complexity. There are no forward declarations and no header files; everything is declared exactly once. Initialization is expressive, automatic, and easy to use. Syntax is clean and light on keywords. Stuttering (foo.Foo* myFoo = new(foo.Foo)) is reduced by simple type derivation using the := declare-and-initialize construct. And perhaps most radically, there is no type hierarchy: types just are, they don't have to announce their relationships. These simplifications allow Go to be expressive yet comprehensible without sacrificing, well, sophistication.

Another important principle is to keep the concepts orthogonal. Methods can be implemented for any type; structures represent data while interfaces represent abstraction; and so on. Orthogonality makes it easier to understand what happens when things combine.

ロボットの亀 - どのように

つぶやき 今日はパーマ

今日はパーマ

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　写真は再使用です

今日はパーマ

キートン　　「父ちゃん、あんた昨日ブログの更新ばせんやったね」

カメロボット「おぅ、気分のわるうしてね」
　　　　　　「ブログの、更新する気のせんでくさ」

キートン　　「なんでね、」

カメロボット「母ちゃんが、あんまり、分からんこと言うけんくさ、
　　　　　　　母ちゃんば、しまきあげちゃったやね」
※　しまく＝叩く、暴力を振るう
キートン　　「嘘いいない、」

カメロボット「何でや、」

キートン　　「そーらー、分かるくさ、僕は、あんた達と一緒に住んどうとばい」

カメロボット「そーやね」

キートン　　「いったい、なんが、あったとな」

カメロボット「なーも、なかて、言い寄ろうが」

キートン　　「あんた、相棒の僕にもかくすとな」

カメロボット「風邪、風邪たい」

※まーいいたい、このうそこき、くそ親爺
　本当はなんか、あっとります

キートン　　「父ちゃん、父ちゃんちゃ」

カメロボット「なんや」「ブログ更新のことなら、なーも答えんじぇ」

キートン　　「もう、そげな事は、どうでもよか」

キートン　　「母ちゃんが、呼びよったよ」

カメロボット「なんて、母ちゃんが呼びよるて、わかった」

※なんかいな、もしかしたら、なかようしょうとか、言うっちゃなかろうね
　それなら、勝負パ○ツ、はいていかないかんね

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

キートン　　「なんやったとね、がっかりした顔ばしとうが」

カメロボット「なんやったとねも、糞もあるか」

キートン　　「どうしたとね」

カメロボット「はぁん！この前の続き、パーマに行くけん送って行けげな」

キートン　　「そげーん、頭にきとうとね」