This does not look difficult since NSTextView has a method to override named “drawInsertionPointInRect:color:turnedOn:”. Actually just drawing “thick” insertion point  is not difficult. But just overriding the method results in strange behaviour and not beautiful at all. Here I show what I tried and how I achieve the transparent thick insertion point.

If you are just interested in “how”, skip the part explaining what I tried and see the section “Solution” at the end of this post. There is a code for it. I tested the code in OS X 10.8 and also I must note that the code uses NSTextView’s internal method to override. This means that you may not use the code if you want your app to be in AppStore.

First attempt

As everyone can think of I first tried to subclass NSTextView and override “drawInsertionPointInRect:color:turnedOn:” (will be referred as “drawIPR” in this post). The code looks like following.

-(void)drawInsertionPointInRect:(NSRect)rect color:(NSColor)color turnedOn:(BOOL)flag {
    // Calculate the rect of a character under the insertion point
    NSRange charRange = NSMakeRange(self.selectedRange.location, 1);
    NSRect glyphRect = [[self layoutManager] boundingRectForGlyphRange:charRange inTextContainer:[self textContainer]];
    if( glyphRect.size.width == 0 ||
       [[NSCharacterSet newlineCharacterSet] characterIsMember:[[self string] characterAtIndex:self.selectedRange.location]]){
        // This handles when the insertion point is at the end of line where we cannot find any character to cover by a caret.
        // We keep the original width (1.0)
        glyphRect = rect;
    }
    [super drawInsertionPointInRect:glyphRect color:color turnedOn:flag];
}

This works somehow. But there are unacceptable problems.

1. No transparency. A caret completely fill the rect and we can not recognise the character under the caret.(Since the caret is blinking you still can see the character but not really beautiful)
2. When you move a cursor it draws thin(origina size) insertion point. You will see why this happens later.

Character ‘p’ is covered by a caret

OK. I have 2 problems. Solve them one by one.

Transparent color

So I tried to set the color’s alpha value. It’s like this.

-(void)drawInsertionPointInRect:(NSRect)rect color:(NSColor*)color turnedOn:(BOOL)flag {
    // Calculate the rect of a character under the insertion point
    NSRange charRange = NSMakeRange(self.selectedRange.location, 1);
    NSRect glyphRect = [[self layoutManager] boundingRectForGlyphRange:charRange inTextContainer:[self textContainer]];
    if( glyphRect.size.width == 0 ||
       [[NSCharacterSet newlineCharacterSet] characterIsMember:[[self string] characterAtIndex:self.selectedRange.location]]){
        // This handles when the insertion point is at the end of line where we cannot find any character to cover by a caret.
        // We keep the original width (1.0)
        glyphRect = rect;
    }
    // Set alpha of the color here.
    color = [color colorWithAlphaComponent:0.5]; // <--- newly added.
    [super drawInsertionPointInRect:glyphRect color:color turnedOn:flag];
}

Unfortunately this does not change anything. The reason is that inside the “drawIPR” in NSTextView it use NSRectFill to draw the insertion point and the alpha value of the color is completely ignored.

Drawing a caret by myself

Since the implementation of the “drawIRP” in NSTextView draws a caret by NSRectFill we can not use it to draw transparent caret. OK. We can re-implement the whole of the method. To re-implement it we have to know how the method works. It takes 3 arguments “rect”,”color” and “turnedOn”. the “rect” and “color” are apparent. The “turnedOn” argument specifies whether we should draw insertion point or clear the insertion point. The method is called with the “turnedOn” arugument set to YES and NO by turns, which results in blinking a caret. So the implementation should be like following.

-(void)drawInsertionPointInRect:(NSRect)rect color:(NSColor*)color turnedOn:(BOOL)flag {
    NSRange charRange = NSMakeRange(self.selectedRange.location, 1);
    NSRect glyphRect = [[self layoutManager] boundingRectForGlyphRange:charRange inTextContainer:[self textContainer]];
    if( glyphRect.size.width == 0 ||
       [[NSCharacterSet newlineCharacterSet] characterIsMember:[[self string] characterAtIndex:self.selectedRange.location]]){
        glyphRect = rect;
    }
    
    if( flag ){
        // Draw a caret
        color = [color colorWithAlphaComponent:0.5];
        [color set];
        NSRectFillUsingOperation(glyphRect,  NSCompositeSourceOver);
    }
    else{
        // Clear a caret
        // We have to redraw the character under the caret.
        // We should use "setNeedsDisplayInRect:" if possible. But to do so we have to keep the rect we drew somewhere.
        // This kind of optimisation is off topic of this post so just update the whole rect.
        [self setNeedsDisplay:YES];
    }
}

Yes, this solves the problem No.1 but not No.2. ( I think NSTextView’s implementation should be changed as this code works perfectly because this is the official way to override drawing insertion point).

The code above draws/clears a caret(with thick and transparency) correctly but when you move a cursor you see a caret without the thickness. Why? The reason why this happens is because NSTextView uses internal method to draw a caret and it is called when you move a cursor to redraw the caret immediately. The internal method is named “_drawInsertionPointInRect:color:”. Note that it starts with “_” and does not have “turenedOn” argument. (will be referred as “_drawIPR” in this post). The code in NSTextView should be like following according to my observation of the behavior. ( This is really simplified to make the point clear though. )

// This is guessed code of NSTextView implementation

// Private method to draw a caret.
// Note that this method only does "drawing". It does NOT have "turnedOn" flag.
-(void)_drawInsertionPointInRect:(NSRect)rect color:(NSColor*)color{
       [color set];
       NSRectFill(rect);
}

- (void)drawInsertionPointInRect:(NSRect)rect color:(NSColor*)color turnedOn:(BOOL)flag{
    if( flag ){
       // Call the internal method to draw insertion point 
       [_drawInsertionPointInRect:rect color:color]
    }else{
       [self setNeedsDisplayInRect:rect];
    }
}

// When you move a cursor, _drawRect (this is also an internal method) draws insertion point.
- (void)_drawRect:(NSRect)rect clip:(NSRect)clip{
    // At some point in this method...
    [self _drawInsertionPointInRect:NSMakeRect(x,y,1.0,height) color:_color];
}

The important points are

• “_drawIPR” is called from multiple methods (not only from “drawIPR” but also from _drawRect:clip:)
• In _drawRect:clip: it calls “_drawIPR” with hard coded width.

Overriding _drawInsertionPointInRect:color:

OK. So NSTextView uses “_drawIPR” to draw insertion point anyway. How about just overriding “_drawIPR” instead of “drawIPR”. The code should be like…

-(void)_drawInsertionPointInRect:(NSRect)rect color:(NSColor*)color{
    NSRange charRange = NSMakeRange(self.selectedRange.location, 1);
    NSRect glyphRect = [[self layoutManager] boundingRectForGlyphRange:charRange inTextContainer:[self textContainer]];
    if( glyphRect.size.width == 0 ||
       [[NSCharacterSet newlineCharacterSet] characterIsMember:[[self string] characterAtIndex:self.selectedRange.location]]){
        glyphRect = rect;
    }
    color = [color colorWithAlphaComponent:0.5];
    [color set];
    NSRectFillUsingOperation(glyphRect, NSCompositeSourceOver);
    // We do not call super calls since the method in the super class uses NSRectFill and calling it results in filling the rect with the color without transparency.
}

Note that we are not overriding “drawIPR”. This results in drawing a thick and transparent caret whenever NSTextView draws a caret. Unfortunately this leads another problem. The code is only “drawing” a caret but not “clearing” a caret to blink a caret. So once the caret is drawn the caret stays there and there is no blinking. Furthermore if you move a caret, all the characters the caret passes will be covered by the drawing and stays there.

Drawn carets are not cleared

The reason why the caret is not cleared correctly is because NSTextView does not know the rect which should be cleared. NSTextView tries to clear the area NSTextView draws a caret (which is a thin caret).

Clearing thick caret

Now the problem is clearing caret. The clearing a caret is done in “drawIPR” when the “turnedOn” argument is NO. We can tell NSTextView to redraw the view by calling “setNeedsDisplay” as we already saw.

Solution

The following code works well.

-(void)_drawInsertionPointInRect:(NSRect)rect color:(NSColor*)color{
    NSRange charRange = NSMakeRange(self.selectedRange.location, 1);
    NSRect glyphRect = [[self layoutManager] boundingRectForGlyphRange:charRange inTextContainer:[self textContainer]];
    if( glyphRect.size.width == 0 ||
       [[NSCharacterSet newlineCharacterSet] characterIsMember:[[self string] characterAtIndex:self.selectedRange.location]] ){
        glyphRect = rect;
    }
    color = [color colorWithAlphaComponent:0.5];
    [color set];
    NSRectFillUsingOperation(glyphRect, NSCompositeSourceOver);
    // We do not call super calls since the method in the super class uses NSRectFill and calling it results in filling the rect with the color without transparency.
}

- (void)drawInsertionPointInRect:(NSRect)rect color:(NSColor *)color turnedOn:(BOOL)flag{
    // Call super class first.
    [super drawInsertionPointInRect:rect color:color turnedOn:flag];
    // Then tell the view to redraw to clear a caret.
    if( !flag ){
        [self setNeedsDisplay:YES];
    }
}

The problem I can think of is that “setNeedsDisplay:YES” is not really optimised way to redraw the view since we are just interested in clearing the rect of a caret but not entire view. What we have to do for it is to keep the rect of a caret in a instance variable (by adding to the class) and call “setNeedsDisplayInRect:” to redraw that area.

(Appendix)Further investigation

I also did some further investigation for NSTextView internal.
The root of the problem of not clearing a caret is that NSTextView keeps the rect of a caret rect in an internal variable and use it to clear the caret. If we can update it by ourselves the problem should be solved. By using some Objective-C runtime functions I reverse engineered NSTextView class and I found the followings.

• NSTextView has a private variable named “_ivars”
• “_ivars” is a instence of NSTextViewIvars .
• NSTextViewIvars has several variables (maybe 12 variables).
• One of them is named “_insertionPointRect”
  (I found “_insertionPointRectCache” too but do not know how this is used)

And also I found that after calling “_drawIPR” of NSTextView the value of the “_insertionPointRect” is updated.

Another solution (not recommended)

(If you are coming from top to get the code which works, use the code in “Solution” section.)
So what we should do is

• Override “_drawIPR”
• In “_drawIPR”, draw thick/transparent caret.
• In “_drawIPR”, update “_insertionPointRect” to remember the rect of our caret.

So the code I got to achieve from this investigation is…

-(void)_drawInsertionPointInRect:(NSRect)rect color:(NSColor*)color{
    NSRange charRange = NSMakeRange(self.selectedRange.location, 1);
    NSRect glyphRect = [[self layoutManager] boundingRectForGlyphRange:charRange inTextContainer:[self textContainer]];
    if( glyphRect.size.width == 0 ||
       [[NSCharacterSet newlineCharacterSet] characterIsMember:[[self string] characterAtIndex:self.selectedRange.location]] ){
        glyphRect = rect;
    }
    color = [color colorWithAlphaComponent:0.5];
    [color set];
    NSRectFillUsingOperation(glyphRect, NSCompositeSourceOver);
    // Update internal variables (_insertionPointRect) in NSTextView
    id nsTextViewIvars;
    object_getInstanceVariable(self, "_ivars", (void**)&nsTextViewIvars);
    [nsTextViewIvars setValue:[NSValue valueWithRect:glyphRect] forKey:@"_insertionPointRect"];
}
// And you do not need to override "drawIPR" since NSTextView automatically clears a caret.

Yes. This clears a caret we draw correctly. But I sometimes see a caret draws several times at one time when you move a caret. Not too bad but not as beautiful as the code in “Solution” section.

Thank you for reading and I hope this helps you.

XcodeでのVimキーバインドを実現するXVimの開発経緯と使い方をご紹介したいと思います。まず初めにURLだけ貼っておきます。
https://github.com/Jugglershu/XVim

さて、本題。ちょうど今から1年前、僕は友達ともにiOS向けアプリの作成を趣味で行っていました。当時僕はMacはあまり使ったことがなく、Objective-Cの個性あふれるシンタックスに苦しんでおりました。iOSアプリの開発なので、当然Xcodeを使うわけですが、シンタックスに苦しんでいるところへXcodeではデフォルトだとVimのキーバインドではなくEmacsのそれとなっており、そのままだと使い物になりません。

Vimのキーバインドにするにはどうしたらいいのか友人に聞いたら、「ない」との答え・・・またまた〜、そんなことないでしょ〜。まあきっとどこかの誰かがそういうの作ってくれてるよと、軽い気持ちでググり、いまどきVimキーバインドがないなんて、そんなわけが・・・「ほんまや！」

というわけで、ないわけです。とても不思議です。世界中のVimプログラマはどうやってiOSアプリを書いているのでしょうか。確かにVimオンリーで書くという選択肢もありそうです。実際、Cocoa.vimなるプラグインもあった（いまも動く？）ようですが、ちょっと使ってみた感じだとあまりうまく動きませんでした。なにより、Xcodeの補完機能や、その場でエラー・ワーニングチェックなどiOSアプリを書く上では非常に有効な機能を捨ててしまうのはあまりにも惜しいです。

しかし、なぜXcode向けのVimキーバインド（プラグイン）が存在しないのか。もしかするとXcodeがプラグインに正式に対応していないというのが大きな理由かもしれません。実際プラグインの作り方に関するドキュメントなどはどこにもありません。幸い、これまでWindowsでAPIフックなどのプログラムを書いてきたこともあり、自分で作ったライブラリさえXcodeプロセスに読み込ませられれば、あとはなんとかできる自信があったため、とにかくその方法を探しました。実はXcodeは内部的にはプラグインのサポートがされているようで、その機能を使うことでXcodeのプラグインを読み込ませることができることがわかりました。

ただし、分かっているのは作ったプラグインがロードされ、初期化時に特定のメソッドが呼び出されることだけです。ここからはひたすら試行錯誤。幸いObjective-Cは動的バインド言語であり、Xcodeのクラスやメソッドの名前などはすべて確認することができ、またどのようなメソッドが呼び出されているかも簡単なコードを追加するだけで確認できます。また、特定のクラスのメソッドのフックもバイナリを直接編集することなくObjective-Cのライタイムを頼って実現することができます。

そこから2週間ほどかけてとりあえず動くものを作りました。うれしいことに、テキスト編集自体の機能はNSTextViewやXcodeが内部的に使っているDVTSourceTextViewクラスに実装されており、キーイベントに対応させてそれらを呼び出すことで基本的な編集機能は実装できました。

それからいろいろな方の協力もあり、現在は以下の様にステータスバーがあったり、太いカーソルになったりと見た目も良くなっております。

だいぶ、Vimの話からずれてしまいました。ここからはXVimの便利な機能をご紹介したいと思います。XVimはVimのキーバインドを実現するためのものなので、Xcode上でVimのキーバインドで編集できることはごく標準的な機能です（まだまだ対応していないバインドはありますが）。一方でXcode特有の機能を使うために実装したXVim特有のコマンドもあります。

最も個人的に使う頻度が高いのが、メニューの特定のコマンドを呼び出すコマンド

:xccmd

です。Cocoaアプリではメニュー内の各項目にはAction名が割り振られているため、そのアクション名を指定することでメニュー上にあるコマンドはすべて実行することができます。たとえば、

:xccmd jumpToNextCounterpart

と入力した場合、.hと.mファイルの切り替えを行います。切り替えのためだけにこれを打ち込むのはばかばかしいので、XVimの.vimrcにあたる、.xvimrcファイルを作成し

nmap <c-n> :xccmd jumpToNextCounterpart<CR>

と書いておきます。これでによって、この機能を呼び出すことができるのです。
xccmdの引数部分はhttps://github.com/JugglerShu/XVim/blob/master/Documents/Developers/MenuActionList.txt
に一覧があります。

ほかには、開発時によく行うビルドと実行はそれぞれ

:make<br>:run<br>

で起動できるようになっています。もちろん上に書いたように自分の好きなキーを割り当ててもよいです。メニューのショートカットについてはXcode自体に設定があるのでそれを利用しても良いですが、XVimで設定するとnmap, imapなどに対応している点が良い点だと思います（と言いつつ、個人的にはこれら違いによるショートカットを使っていなかったりしますが。）

もう一つ有効な機能として、

:xhelp

コマンドがあります。これはクイックヘルプを呼び出すために実装してあるコマンドです（:xccmdコマンドでも実行できます。）これは現在のカーソル位置にあるメソッドやクラスのヘルプをその場に表示してくれるというもので、引数の意味などを確認するのにとても便利です。

一部のキーバインドは、Vimの定義ではなくXcodeの機能で置き換えれています。”gd”が、典型的な例で、Vimでは”Goto locfal Declaration.”ということで、宣言へのジャンプとなっていますが、これはXVimではXcodeの”Jump to Definition”を呼び出すようになっています。そのため、定義部分で入力すれば、宣言部分にジャンプしますし、宣言部分で入力すれば定義部分にジャンプします。またカーソル下のファイル名のオープンはVimではgfですが、Xcodeではこの”Jump to Definition”でジャンプできるため、ファイル名上にカーソルを置いて、”gd”コマンドでヘッダファイルのオープンなどができます。

このように、Vimキーバインドプラグインですが、Xcodeとうまく連携するようにということを意識して作成しています。現在の機能一覧は以下を参照してください。
FeatureList

さて、XVimの開発状況なのですが、最近ちょっと滞っております。というのもこれ以上機能を追加しようとすると少しバグが多く発生するような状況になってきており、少し根本的な設計見直しが必要と判断しているためです。現在github上の別ブランチにて作業をしておりmasterはあまり更新されておりません。ただし、比較的安定しているはずですので、しばらくはそちらを利用していただくのが良いと思います。

今後開発予定の機能としては、矩形選択、検索・置換機能の強化が大きなところとなりそうです。対応コマンドの充実などやりたいことはたくさんあるのですが、なかなか前に進めない状況だったりもします。

なお、XcodeのVimキーバインドとして、最近ライバルが出現しました。http://viciousapp.com/がそれです。ちなみに20ドルだそうです。負けないように頑張りたいと思います。

Vim Advent Calendar 2012 明日は@sonotsさんです。

方法は簡単でKeyRemap4MacBookProをインストールして、あとは設定で
”Change Control_L Key”の中から、Command_Lと入れ替えるものにチェックを入れれれば良い。

でも、いろいろオプションがあって、たとえば、”Emacs以外は入れ替え”とか、”TerminalとChromeとRemoteDesctop以外は入れ替え”とかがある。

僕はTerminalとかはそのままControlキーはControlキーとして使いたかったので
“except Terminal,Virtual Machine, RDC”
のものを選択した。

これでほとんどの場合には満足できたのだけれど、１つだけ満足できない所が。
MacVimでControlとCommandが入れ替わってしまう。
Terminal上で操作するVimは上記設定で問題なくControlキーはそのままになるのだけれど、
MacVimはそうなってくれない。

調べてみると自分で設定を書けるらしい。いろいろ戸惑ったものの、結果以下のようなXMLをprivate.xmlとして保存しておけば大丈夫ということがわかった。これを読み込むとMyKeyMapという項目が追加されるのでそれにチェックすればOK
（この場合、規定で入っているChange Control_L Keyは使わず自分の設定のものだけにチェックつける)

<code><br><?xml version="1.0"?><br><item><br> <name>KeyRemap4MacBook Developer</name><br> <list><br>  <item><br>   <name>MyKeyMap</name><br>   <list><br>    <item><br>     <name>Control_L to Command_L (except VI, Terminal, Virtual Machine, RDC)</name><br>     <identifier>remap.MycontrolL2commandL_extermvm</identifier><br>     <not>VI, TERMINAL, VIRTUALMACHINE, REMOTEDESKTOPCONNECTION</not><br>     <autogen>--KeyToKey-- KeyCode::CONTROL_L, KeyCode::COMMAND_L</autogen><br>    </item><br>   </list><br>  </item><br> </list><br></item><br><br><br></code>

<code>
<br>#ifndef __HEAPSORT_H__
<br>#define __HEAPSORT_H__
<br><br>template <typename t><br>void MaxHeapify( T* target, unsigned int index , unsigned int length) {
<br>	unsigned int l = index	unsigned int r = (index	unsigned int max = index;
<br>	if( l 		max = l;
<br>	}
<br>	if( r 		max = r;
<br>	}
<br>	if( index != max ){
<br>		T tmp = target[index];
<br>		target[index] = target[max];
<br>		target[max] = tmp;
<br>		MaxHeapify( target, max, length );	
<br>	}
<br><br>	return;
<br>}
<br><br>template <typename t><br>void BuildMaxHeap( T* target, unsigned int length ){
<br>	for( unsigned int i = (length-1)/2; true ; i-- ){
<br>		MaxHeapify( target, i, length );
<br>		if( 0 == i ){
<br>			break;
<br>		}
<br>	}
<br>}
<br><br><br>template <typename t><br>void HeapSort( T* target, unsigned int length){
<br>	BuildMaxHeap( target , length );
<br>	while(length != 0 ){
<br>		T tmp = target[length-1]; 
<br>		target[length-1] = target[0];
<br>		target[0] = tmp;
<br>		length--;
<br>		MaxHeapify(target, 0, length );
<br>	}
<br>}
<br><br>#endif
<br><br><br></typename></typename></typename></code>

includeしてから次ように使う。

<code>
<br>unsigned char buf[] = {5,7,10,8,11};
<br>HeapSort( buf, 5 );
<br>//ここでbuf内はソート済み。
<br></code>

早すぎたり遅すぎたり。気にしすぎなのもしれないけど。

今日、だれかのつぶやきで、
—–
「決まってるから」「みんなそうだから」「いつもそうだから」じゃなくて、ちゃんと自分の頭で考えるっていうのを、みんなでもう一度取り戻した方がいいよね。
—–
というのが、あったのだけれど、どちらかというと僕はそれをやってないというより、できない。
周りの人たちが何を考えているかを察する能力が異常に低いのだと思う。

プログラマとかやっている人たちの中にはそういう人が多かったりする。

二つあって、どちらも同じような目的のために確認している。

１つ目は、後からテストコードを書く場合は、テストコードがどのように実行できるかを想像しながら実装する。すると、テストしたい部分を自然に切り離しながら実装したくなる。自動的にテストしにくい部分がどんどん一か所にまとめられていって、結果として後からいろいろ変更したり、機能追加がしやすくなる。

２つ目は、今追加しようとしている機能をOFFにしようとしたとき、どれくらいの場所を修正しなくてはいけないかを考える。１行コメントアウトするだけでそれができるのがベスト。できなくても、１ファイルの１ブロック（画面内で確認できる範囲）を修正すれば機能をOFFにできればまあ、問題ないレベル。
１ファイルの複数個所、という場合には、まず設計を見直す。OSの仕組みなどにより、どうしてもそうせざる負えない場合には、よくコメントを書いておくなりドキュメントしておくなりしないといけない。
複数ファイルを直さなきゃいけない場合は、１度よく設計を考え直した方がいいかもしれない。もうそれしか方法がないときだけ、コメントを付けて、どことどこに対応関係があるかを書いておく。
複数ファイルの複数個所を直さないと機能をOFFにできないとか、こういう状況になったら、そもそも何かがおかしいと思った方がいい。だいたい１つのファイルに複数の機能が同時に実装されていたり、２つのファイル（モジュール）が互いに依存しあっていたり、機能の定義があいまいだったりするのが原因で、その後その上にいろいろ機能を追加していけばしていくほど、バグは多くなる。

さて、このルータ、初期状態だとIPアドレスが振られていない。つまり自宅のネットワークに繋いでも、そこにIP層レベルのアクセスはできない。
じゃあ、どうやってIPアドレスを振るのかといえば、基本的にはシリアルケーブルを繋いで、terminal経由で設定する。
ただ、いまどきシリアル端子なんて持ってるPCの方が少ない。僕の使ってるPCも例外ではなくそんなものはもってない。

以前に設定したときは、USBとシリアルの変換コネクタとケーブルを買ってきて設定した。
今回、もう一つ新しくRTX1000を買って、実家とのVPN接続をさせておこうと考え、設定しようとしたのだが、昔買ったはずのケーブルが見つからない。

で、そういう場合にRARPDを用いてIPアドレスを振る方法があるということを知り、今回やってみた。

基本的には以下のページの通り。
http://www.inohome.net/kuma/blog/archives/2006/12/post_606.html

ただし、1つはまったところがあったのでメモ。
ここで使っているRARPDというソフトウェアが「No unique Registry key for TCP/IP over LAN」というエラーを出して終了してしまう。
レジストリキーが複数あるってことなんだろうけど、よく分からない。
うれしいことに、RAPRDにはソースコードが付いてくる。というわけで見てみると、どうやらEthernetのインターフェースをレジストリから探していて、それが複数見つかった場合にはエラーを出すらしいと言うことが分かった。

確かに、僕のPCにはEthernetアダプタが2つついている。VMWareの仮想デバイスとかもあるから、その辺りも関係しているかもしれない。

ということで、メインのネットワーク以外はすべて無効にした。

こんな感じで。それで起動したらちゃんと動いて、みごとにRTX1000にIPアドレスを振ることができた。

これができればRTX1000を設定するのにシリアル端子は必要ないってことだ。

今回は、東京にいながら、その恐怖を感じたせいか、その悲しさがものすごく大きい。
今回もある意味では、僕が感じられることは人ごとレベルでしかないのだろう。
結局東京ではその悲惨さはわからないかもしれない。それでも今まで感じたものよりずっと大きな感情的な動きがある。

一人でも多くの人が助かってほしいと思う。

こういうことを目の当たりにすると、僕たちが普段考えている幸せや、生きていく上で大切なことが何なのかということを考えさせられる。
人が、その人の一生を豊かに、幸せに生きていくと言うことと、自分が今毎日の生活の中で行っていることの間に大きな忘れ去られた空間が広がっているのではないだろうかと感じた。
忘れてしまうのだと思う。

家族とともに、いろんな困難を乗り越えて毎日生きていくこと、生きていけること。それが何より重要なことであり、それがすべてなのだと思った。それ以外のことは、おまけみたいなものなんだ。