2022年2月3日木曜日

【Android USB oscilloscope】(9) Handlerが48時間わからない

余っているAndroidスマホをオシロにしよう!

Android One S5でWiFi debugできるようになりました.→こちら

進捗としては、USB COMのOPENまでは把握したのですが、受信したキャラクタをスマホに表示させるところで進捗が停まりました.

初心者がやりそうな、、、TextViewをポインタ渡し(したつもりで)back groundから表示させたらアプリが例外で停まる.なんでだろ?という行き詰まりです.

解決策はHandlerなのは判っているのですが、Handlerのハンドリングがさっぱりわからんちん.48時間経ってもわからんちん.netにある様々な説明を読んでも要領を得ません.わたしの無能さ故です.

いい加減に人生の残り時間の無駄遣いと気づいたわたしは一旦撤退します.やはりわたしには木工のセカイがお似合いだというわけで、落差が激しいですが、明日は木工リフォームに転じます.しばらくさようならObject、しばらくさようならUI、しばらくさようならThread.

ーーーー
かつてわたしは1994年頃に、MacintoshのGUI programmingに手出ししたことがありましたが、あまりにもかったるくて撤退しました.

その頃と比較したら、UIのprogrammingは雲泥の差で簡単になりましたね.喩えるならば、「こいつ動くぞ」などとVマニュアルを見ただけのアムロが敵の最新鋭兵器ザクを2機も撃破できてしまうようなお手軽さになりました.

しかし簡単になったのはボタンやTextの配置とイベント止まりであって、裏処理系はまだまだ技術者の脳内領域に留まっている感じがします.ボタンイベント→表示 なんか知ってたって役にたたんわそんなもん.裏処理系がわからんかったら事実上何もできはしない.

object指向GUI programmingの到達点は所詮は2次元どまりという気がします.Threadの裏世界を包含する4次元な開発環境を誰か構想してくれよな.

プログラマ不足説は何度も流布されたけど、その都度ソフト技術の革新で乗り越えてきました.もっと楽に、もっとお手軽に、もっとチャラく、よろしくお願いしますよ.

8へ        10へ

かしこ

18 件のコメント:

  1. その気持ちわかります〜。
    環境は違いますが、unityというかc#で受信した後、そのデータを我流で表示を試みましたが、挫折しました。デバッグコンソールにはすぐ出力できるのに。
    スレッドからグローバル変数にも書き出せないし。クライアントのエンジニアがくれた長々とした記述のモジュール使ったら難なくやり取りできましたが、ネットに転がっているようなソースではどうにもなりませんでした。世の中のメインであろうWindows環境でこれですから。
    仕事として扱っている人達の群れに身を投じないと、ギルド外にはデータの受け渡しという秘術は公開されていないのかも。

    返信削除
    返信
    1. objectに拘り過ぎて自縄自縛ってかんじなJAVAさんでした.そんなのポインタという裏口を提供してくれちゃったらそれでいいじゃんみたいな.findViewbyIDとか使わなくちゃいけないのみたいな.

      削除
    2. object化とかスレッドとかに加えて最近は仮想化もあってさらにややこしいです~。
      商売でJavascriptやc#でゴシゴシとプログラム書いている人たちは簡単にしようという発想はなさそうです。
      あちこちのライブラリとかの微妙なバージョン違いでバグが出まくっているので思い切った環境の変更とか怖くてできないと思います。
      Python系の人達は簡単にしようとていいるのですが、GUIに冷淡です。MSDOSみたいなキャラクタコンソールが好きみたい。
      うーん。

      削除
    3. Android Studioでupdate version availableとの表示が出て押したらbuild error.
      versionを古いのに戻したら治りました.dependencyがぁー

      削除
    4. オレ達ってコンピュータサイエンスが大学教育に存在しなかった時代.
      うちの大学の研究室のどこを探してもVAXとかなかったと思ふ.

      削除
    5. >objectに拘り過ぎて自縄自縛
      >ポインタという裏口を提供してくれちゃったらそれでいいじゃん
      そもそも、オブジェクト指向は、
      「ポインタにまつわる問題」(『違うタイプのポインタ』を、間違って使用して、ハマるバグ、等)を解決しようとして、作られた、という一面もあります。
      (ぶっちゃけ「オブジェクト(というかインスタンス)」は、内部的には「ポインタ」で、表されてますし。)そのために、オブジェクトには、固有の「型」があります。

      >簡単にしようという発想はなさそうです。
      本来は、
      「同じ処理を、何回も書きたくない」(もっと「簡単に」書けるように!)
      という発想で、「クラス」とか考えられたハズなんですが、却って「難しく」なってしまってる感は否めませんね。
      ※まぁイマドキのプログラムを「オブジェクト指向」の助けを借りずに構築したら「もっと複雑」になってしまい、作ることはできなかった、という説もありますが。
      例えば、昔の「BASIC」(行番号があるやつ。現在のVisualBasic とかではなく)で、「GUIプログラム」が、組めたか?というと、ちょっと疑問。
      (ちなみに、それを無理やりやってるのが、Tcl/Tkとかです。)

      削除
    6. >どこを探してもVAXとかなかった
      おそらく、ちょうどその時期に、私は某社の研修所で、
      「VAX 11/750 (Ultrix-32)」で、Unix-Shellと格闘してました。
      (まだこの頃は、GUIは一般に無かったハズ)

      削除
    7. >「オブジェクト指向」の助けを借りずに構築したら...作ることはできなかった

      そう思います.かったるくてバグバグになりそう.

      Tck/Tkってそうゆうものなんですか.名前ぐらいは知ってるってぐらい.

      VisualBasicって名付けを失敗した気がするんですよねw

      削除
    8. >「VAX 11/750 (Ultrix-32)」で、Unix-Shellと格闘

      うらやま.
      HP64000でした、その頃のわたしは.あれでも嬉しかったけど.

      削除
    9. >作ることはできなかった
      もし、1950年代に「オブジェクト指向プログラミング」があったら、
      「Multicsプロジェクトは、成功裏に終わり、世界中に広まっていた」
      かも知れません・・・
      ※現実は「Multicsプロジェクト」のようなプロジェクトをうまく行かせるために、逆に「オブジェクト指向プログラミング」のような概念が出てきたわけですが。

      削除
    10. >微妙なバージョン違いでバグが出まくっている
      まぁこれは、「オブジェクト指向」の問題ではなくて、単に、
      「ソース管理」の、問題なんですけどね・・・
      ※「オブジェクト指向」を以てしても、「仕様の複雑さ」に、人間がついて行けてないということですね。なので、もう最近は、
      「ヒトが管理すること」を諦めて、
      「コンピュータ自体を、コンピュータに管理させる」方向(いわゆる、「AI」的な発想)に、なってきてますけどね・・・
      ※そうなると、「人間」要らなくなっちゃう。人間自体の存在意義が問われてきます。

      削除
    11. >HP64000
      実は、同じ時期に、こっちも触ったことがあります。
      ※この頃は「クロス開発」が主流で、
      ・VAX 11/750 で、開発したソフト(Cとかアセンブラとか)を
      ・HP64000 に転送して、ROMに焼く
      みたいなことを、やってた記憶があります。

      削除
    12. >HP64000
      あの「緑色」の画面と、「独自メニュー」と、「ゴツイ」キーボードですね。
      ※アメリカ人は「親指」しか使わずにキーボードを打つ、(なので、ボタンが皆デカい)と聞きましたが、ホントかいな?)

      削除
    13. 親指タイプ、器用なんだか不器用なんだかよくわかじ。
      64000のKBDは堅牢で好きでした。ROMは紫外線の2016か2032でした。

      削除
  2. >世の中のメインであろうWindows環境でこれですから。
    もはや、「Windows環境」は「世の中のメイン」ではないのでは?と、思う今日この頃。

    --- それはさておき ---

    マルチ タスク/プロセス/スレッド などの用語は、「環境」によって定義が違うので、困ります。
    ※うろ覚えですが、unixのタスク≒Windowsのプロセス、だったかな? あと、言語によっても違う。同音異義語がたくさんあるので困る。
    それから、同じWindows上でも、
    ・OS(WinAPI)上のスレッド
    ・MFC/ATLのスレッド
    ・.NET Framework上のスレッド (この中でも、いろいろ種類があるし・・・)
    etc... は、互換性がないので困ります。

    >スレッドからグローバル変数にも書き出せない
    >ネットに転がっているようなソースではどうにもなりませんでした
    >クライアントのエンジニアがくれた長々とした記述のモジュール使ったら難なくやり取りできました
    もしかしたら、そのアプリ内で「独自のスレッド」を、作っていた
    (大規模フレームワークなら、そういうことをやっていることもある。)
    のかも知れませんね・・・

    返信削除
    返信
    1. >スレッドからグローバル変数にも書き出せない
      最近の言語のトレンドは、
      ・如何に「グローバル変数」を、排除するか?
      を、競い合ってる感じがしますね。まぁ、セキュリティ対策の一環なんだろうけど・・・
      ※おかげで、「他のスレッドを見に行く時」などは、一々「誰かに権限を貰ったり」「お伺いを立て(相手の機嫌を損ねると、教えてくれないんだな、これが)たり」などの「おまじない」が、たくさん必要になります。

      ※「誰でも見れる」グローバル変数などは、もう、過去の遺物となりつつあります・・・

      削除
    2. おはよーございます

      >「Windows環境」は「世の中のメイン」ではないのでは?

      いろんなOSの源はLinuxが主なんですかね、いまでは.

      windowsはofficeをコアにしたビジネスブランドにfocusしていて、サーバービジネスなどを収益の柱にしているようなイメージは感じられません.

      削除
    3. >unixのタスク≒Windowsのプロセス

      unixのプロセスは独立自尊さでは高めと思っていますがソースはわたくし.

      ソフト屋さんは勉強が大変ですね.

      回路屋としては、中学生の頃に無線機の送信受信切り替えに使ってたdiode SWが、40歳過ぎて高周波のSWをせないかんくなった時に役立ったことがあります.芸は身を助く

      グローバルに活躍する人材が求められているのにグローバル変数がパージされるとはこれいかに.いみふ~

      削除