HP S5-1050JPが壊れた

久しぶりに起動したらログイン画面の後デスクトップは出るけどそこから進まない（スタートボタンやタスクバーにマウスホバーすると砂時計)

まあ同じ古いのでも程度がかなり良いDELL vostro 270sにかえようとおもっていたのでちょうどよいかと一昨日は思っていた
しかし確定申告の準備をと悠長なことを考えていて青ざめた
会計ソフトの内容のバックアップが取ってない
（壊れることを想定してない）

Officeのプロダクトキーが取ってないのはどうにかなるか程度に考えていて楽観視していたけどこんなところに恐ろしく大きな落とし穴があった。こうなるとなんとか再起動に成功させて会計ソフトのデータを抜いて別のPCでやるしかない。
まあしかたが無いのでいろいろ試してみよう

(200229)
けちってつくもんなんですね。
車が盗まれました。朝気が付いたらあるべき場所に無い！
で、被害届けとか出して防犯カメラの映像提出してしばらく
したら別県の県警から電話で見つかったからすぐに現場検証に来てと
電車で雨の中行ったらまあそれは大変でした。ナンバープレートの指差し写真から始まり車台番号、各装備、損傷個所、遺留品など指差しの様子を撮影され関係者指紋とかで「僕は何もやっていない！」って言いたくなるほど指先から手のひらまで指紋、掌紋の採取をされ最後は結構な枚数の書類を書いてレッカーに愛車（元かも）を引き渡して夜にやっと
帰宅でした。
まだ腹立ちは起きてこないですがただただ驚きの一日でした。
これで鎮静化してくれれば良いですけど。

これらの顛末は後日に

道草は犬も食わぬ の？

pythonはその使用の仕方を考えると往年のBASICに似ていると思った

で、類似性として対話処理と簡易な文法と気軽に使えるグラフィクスについて調べようとしていた
特にpythonと引き合いに出すのはどのBASICが良いかを考えてみた
調べているうちに訳が分からくなってちょっとプログラムを動かしてみようと思ってmandelbrot集合を描画させてみた

まずはtiny basic for windowsで下図

描画は23秒台でこの手のソフトとしてはまあまあ早い方なのかな

このBASICや十進BASICは教育関係の方が開発されたものでHELPや関連資料が多くてプログラムを組むには良いけどN-BASICなど往年のBASICとの文法の共通性は薄い、とはいえ行番号を普通に受け付け動いてくれる　描写される画面が１つではなくてテキストが出力される画面とグラフィックが描画される画面が別なのは往年のBASICしか知らない人（そんな人がどれぐらいいるのかは不明だけど）が使うとちょっと面食らうかもね　時間計測はその日の0時を出発点とする経過時間を返すtimer関数があって、いい感じです

次は十進BASIC

描画は今回調べた中では最速

本来はJISのFULL BASICを教えるための環境

したがって旧来のN-BASICなどを動かすにはメニューで

オプション→文法→MicrosoftBASIC互換　とする必要がある

TIME関数というtbwのtimer関数があって計測は楽だった

ただJIS FullBASICは自分の中ではいつ使うのかわからない

多分上記のモード以外では絶対に触らないと思う

（きょう日、代入文にLETなんてつけるやついますか？）

次はMBASIC86

速度は決して速くない（描画時間28分58秒[=1738秒]）

N86-BASICとの互換性は高そう（そのせいで時間計測はTIME$を表示して手計算)

多分N86BASICの資産のあるひとはありがたいはず

（そんなに突っ込んで調べてません)

編集が専用画面でできるのはちょっとありがたい　使い分けで混乱

99BASICってのもあります

グラフィック周りでちょっと独自の命令を使うと画面のように11秒で描画は完了する　これはかなり早い

width文で128,40とか指定できて文字の情報の多い画面を作れるのは場合によっては嬉しいはず

たしかファイル周りのn88basicとの互換性が低い傾向

最後は日本語nbasic for windows95

もしかすると互換性は高いのかもしれない

（もちろん試してません）

しかしこの程度の画面描画で63分16秒(=3796秒)はあまりにも時間が掛かりすぎ

これではちょっと時間のかかる処理のデバッグをやる気がなくなってしまう

それとエラーメッセージの信用性がちょっと低くて「えーそんなエラーじゃないよね」って言いたくなる時も・・

このBASICもwidth 128,45とかできるのはいい感じ

処理系名	所要時間(Sec)	RATIO
十進BASIC	4.30	1.0
99BASIC	11.00	2.6
TinyBASIC for Win	23.48	5.5
MBASIC86	1738.00	404.2
N88互換BASIC	3796.00	882.8

まあ今時、行番号付きのBASICしかわからない人が（多分自分と同様に相当高齢だと推察もできるので今更）新しい言語を学ぶかどうか、またBASIC以来、ほかの言語に触れる機会が当然あったにもかかわらずそれをしてこなかったわけなのでこんな考察が必要かどうかも怪しく思える

でもせっかく時間を使いまた開発の環境を改めて触ってみた結果を一応記すと現状で1つを選ぶならN88互換BASICなのかなと思う。

（時間が掛かる考察は今後レガシなBASICではやりません！！！！）

(200301)

直前の部分でN88互換BASICが使えるようなことを書いたがちょっとしたコンソール風の画面を作ろうとしてlocate ,,1でカーソルがオンに出来ないことを知りました。せめて互換を謳うのなら・・

止めましょう　そんな期待はしてはいけなかったのですね。

速度につき同じようなことを(191229)のエントリーでも書いてます。

やはり最近使っている言語たちに比べたら遅いですね。
上記のエントリーの結果表と比べてもMBASIC86でエミュレータanex86上のn88basicよりも3.5倍くらい時間がかかってます。
N88互換BASICに至っては・・・
多分早く動かすことが目的じゃないんでしょうね。はい

あーあ、本筋じゃないことに1日を費やしてしまいました

本当に寄り道好きで困ったものです

(200218)

N88互換BASICと99BASICのヘルプが .HLP形式で参照できなかったのだがこちらのWin8.1用のWinHLP32.EXE(64bit用)のインストールバッチを利用させてもらったら見えるようになった。

公平に機能を検証するにはやはり特定の命令の利用が可能かどうかわかるって大事だよね。

現在、臭気抜き中

図書館からも借りているのだが
「退屈なことはpythonにやらせよう」を古本で買った
バリバリのプログラム書ではなかったので古本にしたのだがちょっとカビっぽい所謂古本臭いにおいがした。
で、ネットで調べた脱臭方法でただいま臭い抜き中である
で、読む気満々だったので図書館に寄った際にみたら珍しく棚に並んでいたので借りてきた
複雑でない方法で実生活の（まあPC上のことだけだけど)面倒で退屈なことをpythonのスクリプトに肩代わりしてもらおうって趣旨の書籍だ

でもこの考え方ってその昔unixとc言語が出てきたころに似ている
その頃はコンピュータを触る人＝プログラムが書ける人という図式だったのだけどawkやgrepなどとunixの標準入出力を組み合わせて仕事を簡単にしようという流れが出てノンプログラマもコンピュータを突くようなシーンが拡大された
pythonでどれほどの人が自動化に成功するかわからないがきっとできる人とやらない人の格差が広がるんだろうね

おいら柔軟剤のにおい大嫌いなんだけど臭い抜きをすると黴臭さはかなり抑えられるもののちょっと柔軟剤チックなにおいがしばらくする
黴臭さよりましだと思って我慢することにしました
ちょい、つらい

嗚呼、Bugや

VisualStudio上でIronpythonを弄ってみた
１）GUIの設計画面がでないー全部コードで書くしかない
２）出来て当たり前のことがエラーになる
　　例えばWindows.Formsを利用してみるとForm上のコントロール
　　が参照できない（for c in self.Controlsで探るとあるのだが・・）
結果ちょっと深いところを弄ろうとすると途端にエラーで止まる

Accessのエラーを吐いてもDebugでソースをたどれるとかC#の実行前にやばそうなところがみんな指示されると楽だなあと思う
ちょっと今のところこれ以上は手が出ない
面白そうなテーマだったけど「C#に励めよ」との天の声としておこう

高DPIに対応したWindowsFormを書く

C#で思考したいと思っている
つまり何か新しい仕組みのコードを書くときにまずC#が思い浮かぶようになりたい。そのためにこれまで他の言語やVBAで書いてきたものを置き換えるようなこともしたいと思う。

しかしC#の技術でもWindowsFormではちょっと古くてまだXAMLベースで記述のできるWPFの方が良いという意見が散見される。
特にWindowsFormではBugが改訂されないままになっているコントロールもあるような情報もある。まだC#に不慣れだしこれまでの組み方と近いWindowsFormから馴染んでいきたい気持ちは強い。
でもWPFに早く移行しないといけないという気持ちもあるその理由が高DPIの画面が残念と言うことが大きかった。

見映えは大事です。お客さんは見かけに結構左右されます。
そりゃ誰だって毎日使うシステムの表示はくっきりと見えて美しい方がうれしいはず。で、WindowsFormはちょっと残念だと思ってそれならWPFでも使うかって漠然と考えてました。
そんな時に見つけたのがQiitaのこの記事「Windows Formsアプリケーションの高DPI対応」
でちょっと実験的に書いたFormをDPI対処ありなしでビルトして見た。

左がこれまでのWindowsFormの画面で右が高DPIに対応させたもの。
こんだけくっきり感がちがうともう全てのプロジェクトで使いたくなりますね。やっぱりせっかくシステムを書くのなら喜んで使ってもらいたいもの。

ただ業務でよく利用する明細をうまく書こうとするとWPFなのかな
やっぱり覚えるか?

java再び

今日は「再び」シリーズか？
oracleから有償宣言されたdjkに代わるopenjdkとapacheに放出されたnetbeansがそろそろ落ち着いてきたようなのでjythonと共に再インストール並びに実験をしてみることにした。
jdkはjava javac 共に-versionで"13.0.2" 2020-01-14
netbeansは11.2で7とか８とか言ってた頃よりは随分進んだ
いろいろ過去のソースなどを食わせてみよう

(200206)
朝起きて早速古いnetbeansのプロジェクトを食わせたがエラー発生でコンパイルできない。何やら設定のxmlの中でエラーが出ている模様
原因がわかるのに時間がちょっと要りそうだったのでとりあえずマンデル集合描画のために新しいフォームをささっと作ってソースだけ移行してやってみた。
めっちゃ早いなこいつ

ごくごく普通に書いて100mSを軽く下回るって相当早い感じです

C#で同じ書き方をするとwinformで170~180ｍSぐらい


jythonはまだ手が付いてない　後日報告
(200210)
jythonに手を付けるつもりがあれこれ調べているうちに.netの技術で書いたironpythonに気持ちが行ってしまいついついインストールしてしまいました
ライブラリーをインポートして簡単にGUIが開いたりREPLからコントロールを足したりするのはどっちも同じ感じで遊べて素敵

AutoIt3 を再び

顧客I社の用件でLINEを用いた勤怠管理を行いたいので
AutoIt3を用いて自動化の実験をしたい
（もちろん出来ればそのまま実用化したい）

AutoItは言わばWin32apiに薄い皮をかぶせてBASIC的な文法で動かせるようにしたものー一応コンパイルも出きるっぽい

勤怠管理として
１）配車表などに基づきモーニングコール的な起床確認を行う
２）LINEでの報告を聞いてWebソフトで勤怠データを入力する
の2点を行っている（別所さんと深夜組）

WebソフトからCSVを取り出して勤怠の粗データにしたい。

Webソフトの入力が文字入力でその時点の時刻とペアのデータだけなのでデータの入力が煩雑で面倒っぽい
これを
１）配車表のデータベースにしたがい自動でLINEの画面呼び出し(起床)
２）出退勤のLINE着信時にAutoItで作ったボタンを押すと画面を読み取ってWebアプリに登録（必要によりローカルDBにも登録）
３）Webアプリの備考など必要により登録してから登録ボタンを押す
４）２）－３）繰り返し
と出来たらいいなと思う

AutoItでどこまでやれるか考えてみたい
(200207) なんか前にmandelbrotの描画もやってたみたいだけどソースが無いので書いてみた
細かい書き方を忘れてて時間が結構かかった

およそ１分は速くない。でもこの手のソフトとしては許容範囲か？

(180103)にも同様の画像を上げているけどソースが無い

　－＞これは管理の力の欠如

画面を見ると結構エッジが甘いので繰り返し回数が少なく思う(50回以下か？）

この時の記録が29秒ぐらいと記述してあるが今回のものがとりわけ遅いわけでもないのだろう
(200212) 上記の古い方のソースが見つかったので検証してみた。
今回の描画ではこちらのサイトを参考にさせてもらいながらgdiを直接叩いて描画をしている。結果として1ラインごとの書き込みが見えるのだがそこに時間が掛かっているようだ。
古い方(180103)の方はautoitのライブラリーのグラフィックを使っている。画面の準備がバッファ上でできてから実際の画面を描いているようで結果として23sec vs 60secのような差がついているように見える。
ただmandelbrot集合の計算式や描画エリアの範囲は共通なのでautoit3の純粋なライブラリー(GUICtrlSetGraphic)を使う方が速いがdotの描画が実体として短い直線で近似しているようでmandel集合の輪郭が甘く見える。

raspiでハイレゾ音源実験 その後

本日、秋月よりrpi zero wh＋ケース マイクロSD(16GB) 電源(5V3A)
などが到着　早速実験。
まずVolumio1.55はそのままでは起動しない。やってみてしまった。
（情報源:http://www.smartphone-zine.com/audio-visual/pizeroaudio )また上記によると結構いろいろと大変なようだ
（さらにWHは無線LANまわりなどで追い込みが必要らしい
　情報源: https://www.omorodive.com/2018/02/volumio-155raspberry-pi-zero-w.html)
　　※※あす上記のサイトのイメージで1.55の実験をするつもり
どうも相当根性がないとrasp zero WH＋volumio1.55は難しそう
で今はあきらめてvolumio2で仕切り直し

volumio2を入れてやったらいろいろと接続をためしてどうにか音出しに成功！大変うれしい　しかしv2は予想通りめっちゃ重い
そしてNASの中のすべてのフォルダを認識してはくれない
現状で18のアーティスト、260のアルバム、1598の楽曲と言う感じ
再スキャンで増えるみたいなので再度スキャンを実行中(これまた時間が）

しかし出てきた音については見通しの良い小音量でも細かいところの聞きやすい良い音だと思ったのでもう少し使いやすくしてものにしたい。
最悪raspi3B+程度を考えても良いと思う。
（余るであろうrasp1Bとrasp zeroWH）については別の使い道を模索

明日も少しいじってみたい。

時は経って翌朝です
スキャンが完了した状態で使ってみるとVolumio2そんなに悲観するほど遅くないじゃんって感じでした
もちろん音量を変えたり曲を追加したりキューを入れ替えたりは結構な遅延があるのだけど音楽を普通に楽しむ分には十分な気がしてきた

高性能なSoCでリアルタイムリサンプリングをするのでなければこれで十分な感じだ　しばらくはこれで聞いてみよう
※Volumio2の利用での注意点はHotspotをW.LAN設定時に切ること
これを忘れるとつながらなくなって最初からになる

最初に使っていたRasPi1Bは別の使い道を探す
RasPi1Bに2x4=８Pinのピンコネクターをつけて音源をこれにしてRPiZeroはヘッドホン音源にするのも良いなとか余計なことを考え始めている　－　大変危険です