{進捗記録}{進捗}{希哲16年3月19日}{希哲16年3月18日}{Aejs 整備}{希哲16年3月19日の開発}{希哲16年3月19日の進捗}{恐らくは}{同一事象}{@tgt_evt.bld..off()}(76)

{希哲16年3月19日3歩 K#F85E/E74C-D3A4}

Aejs 整備

途中で終了

昨日ボタン要素分類名置換した時に上手く事象処理出来ないという問題少し時間を取られたが,事象委譲元1つ組み合わせには1つの聴取子をあて,聴取子内で処理分けることにしていったん解決した

この問題は,以下のように,同一要素を指す .foo.bar発泡事象祖先要素 prn委譲した場合起こる

prn.on_clk( '.foo', fn_foo )
   .on_clk( '.bar', fn_bar );

この時,fn_foo() 内で .foo.bar遅延なく)置換すると,.barclick 事象向け聴取子実行されてしまう恐らくは発泡捕捉した時点での分類名だから?)似たような問題以前にもあったが,未解決だった希哲14年10月27日16歩

最初は不可解な現象だったが,だんだん Aejs の事象委譲原因があることが分かってきた。ただ,久しぶりに @tgt_evt.bld..on()読み直したものの,目立った論理的欠陥無かった捕捉した事象判定をしているだけの単純な仕組みなので,同一事象同一要素に対して聴取子分ける使い方自体が問題のような気がしてきた大張り考える余計な処理加えたくない

読み込み中...
{整清記録}{整清}{iw}{ネット環境整備}{上がった}{急ぐこと}{使えていない}{一連の}{時間はかからなかった}{簡単な}(54)

{希哲15年10月26日の整清 K#F85E/E74C-B2DE}

ネット環境整備仕上げなど。

無線 LAN 子機Archer T2U Nano から Archer T4U Plus換装し,USB 配線整理

T4U Plusドライバrtl88x2bu簡単な引装インストールのみで認識され,その他設定引き継げたので,動かすまでに時間はかからなかったUSB 配線整理USB 3.0 ポート認識不良についての調査未解決時間がかかった

iw で見る限り信号強度若干改善に留まったものの,たまに不安定化することもなくなり,平均的通信速度上がったのか,以前の光回線有線 LAN と比べても遜色ない体感速度になった。T2U Nano不安定化アンテナ性能問題という見立て当たったようだ。

もう数日様子を見たいが,すっきり身軽になり,これだけの通信品質確保出来たのだから,一連のネット環境整備は今のところ大成功と言ってよさそうだ。

あと気になるのは各機器耐久性と,まだ USB 3.0 ポート使えていないことくらいで,特に急ぐことはない。

T2U Nano手頃な予備として保管しておく。

{進捗記録}{進捗}{Slackware 時代}{ネット環境整備}{希哲15年10月26日の開発}{希哲15年10月26日の整清}{内部配線}{試していない}{良い復習}{弄っていなかった}(70)

{希哲15年10月26日9歩 K#F85E/E74C-A67B}

ネット環境整備配線整理過程SLFS における USB 3.0 ポート認識不良についての調査始めたものの,未解決保留

主力機には筐体前面背面にそれぞれ2つずつ USB 3.0 ポートがあるが,Linux では Slackware 時代からいまいち使えた試しがない。それもそのはずで,どうも USB 3.0 ホストコントローラー認識されていない最初から Windows仮想機でしか入れていないので,Linux 固有問題かもしれない。

lspci では Etron TechnologyEJ168 が見えるがドライバ表示がなく lsusb では表示されない。

怪しいのは UEFI核脳構配起動応付あたりだが,今のところよく分かっていない。UEFI 設定見直した明らかおかしい所は見つからなかった

核脳構配では,そもそも USB 3.0有効にしていなかったので CONFIG_USB_XHCI_HCD=yCONFIG_USB_XHCI_PCI=y加えて核脳再構築をしたが,相変わらず。更に CONFIG_USB_XHCI_PLATFORM=y を加えても変わらなかった

これまで使っていた Linux 核脳 vmlinuz-4.9.9-slfs-t2希哲11年6月28日備立したもので,しばらく弄っていなかったので,良い復習にはなった。今回の備立は一応 vmlinuz-4.9.9-slfs-t3 としておいた。今後何かと調整しやすくなるだろう。

起動応付変更はまだ試していないが,急ぐことでもないので今日はこの辺でやめておいた。

内部配線問題もありそうな気がしてきたので,今度の主力機清掃時に確認してみる。

{最古}{希哲8年}{希哲6年}{希哲2年}{}{侍救い}{一日一文}{サービス}{デライト}{カタカナ語}(67)

{希哲館訳語の原点,サブスクと待っ読(まっとく) K#F85E/E74C-B90D}

先日,デライトでも RSS 対応をした。以下のように,任意の輪郭一覧RSS で「待っ読(まっとく)ことが出来る。

この「待っ読」,フィードにおける〈subscribe〉あるいは〈subscription〉翻訳語として昔考案したものだ。

今のようにデルンデライト)で何でもかんでも記録するようになる前だったので,正確な考案時期は忘れてしまったが,デルンが実用化した希哲6(2012)年より前だったことは間違いない。ただ,しばらくはの一つだったようで,希哲8(2014)年に改めて採用することを決めている〈subscribe〉を「待っ読」と訳す

今となっては希哲館訳語蓄積膨大なものとなったが,そのほとんどはデルン実用化後に出来たものだ。「待っ読」は独自性を持つ最古の希哲館訳語と言える。「希哲館訳語の原点」と言っても過言ではない


この「待っ読」,すでにお気付きかもしれないが「積ん読」にちなんだものだ。

そもそも〈subscribe〉翻訳語を考えるきっかけは,phpBB3 という掲示板スクリプト日本語パックを作りたいと思ったことだった。希哲館事業発足間もない希哲2(2008)年のことだ。

phpBB3 は,希哲館情報交換のために使える掲示板として当時は有力な選択肢だった。かねてより必要を感じていた翻訳語整備も兼ねていた。今はデライトがあるが,このデライトを実現するためにデルンの実用化を目指すことになり,この望事プロジェクト自体は立ち消えとなった。

その中にこの用語があったが,直訳の「購読」では明らかに不自然だった。散々考えた挙句,投げ遣り気味に「積ん読」と訳すことを考えたRSS フィード等の “Subscribe” は「積ん読 (つんどく)」か。これは流石に無理があったものの,しばらくして「待っ読」の元になったわけだ。

読み込み中...
{未解決}

{}