最初にリリースした2.00.0.Beta01にアラームリストが読み込まれる際にアラームリスト含まれている サウンドファイルが当該フォルダから削除されていた場合にクラッシュする不具合がありました。
読み込み時に整合性を確認して該当するアラーム項目をスキップします。 対応版は2.00.0.Beta01Build10以降でバージョンで修正が入っています。 よろしくお願いします。
バージョン1.01をGoogleDriveへアップしました。 https://drive.google.com/file/d/1aGwXq5Be176m496EcjwHX3ykhKktvfUv/view?usp=share_link 主な変更点はアプリからボタンクリックで直接マウント出来るようになりました。
この為にはサーバとクライアント間で鍵を共有しておく必要があります。 個々のケースでの設定は各自でお調べ下さい。 ガイドとしては １，クライアント側で秘密鍵と公開鍵を生成する ２，サーバ側へ公開鍵をコピーする ３，クライアント側とサーバ側で各々の鍵を利用するように設定する 以上です。
利用するサーバ情報を登録ファイルに記述しておけば、数回のクリックでデスクトップに マウント出来ます。
当方はターミナル（iTerm2）にエイリアス登録して、ssh接続とディレクトリの マウントを一度に行い、サーバのメンテなどに使用しています。
尚、sshfsやmacFUSE上の問題点や制限事項などをドキュメントを しっかり確認して下さい。
でわでわ
過去にShellクラスを使った時と違っていて、１ラインごとにコマンドをShellへ送ると、状態遷移していないと 言うことが判りました。
そこで、Shellを非同期で使うのでは無く、対話型にして使う事でこの問題を回避したAsyncShell(改)を作っています。 インスタンスを作る時にパラメータで使い分けるように仕様としていますので、使い勝手は変わらないと思います。
また、このSyncShellを用いる事で、アプリ内から直接sshfsでマウントする事が出来るようになります。 多少の作業を行ってから改訂版アプリをアップします。
大事な点を忘れていました。開発者の署名は付いていません。また、Appleの公証も得ていませんので、通常は起動出来ないと 思われます。 (Sentinel.app)等を利用しないと使えないので、ご注意を！
sshfsを利用したマウントコマンドを作成するヘルパーアプリの プロジェクトファイルをGoogleドライブにアップしました。 動作するアプリ本体も同梱していますが、いくつか注意点を挙げます。
このプロジェクトは単独ではビルド出来ません。 いくつかの独自作成のクラスを省いています。 省いた主なクラスは以下の2個です。 ・IntervalTimerクラス ・AsyncShellクラス 今回のsshfsマウントコマンドの生成に関する部分では無いので スキルを磨く為に独自で実装出来れば、嬉しいです。
・IntervalTimerクラス Timerを継承して、ハンドラを使いやすくするためのクラス
・AsyncShellクラス ShellとIntervalTimerを使って、外部から（このクラスを利用するメソッド等） 送られたShellコマンドを順次Shellへ投げて、その応答を読み出し依頼が 来るまで捧持しておく。 ヒント： １，Arrayを継承したQueueクラスを実現すると意外と簡単かも ２，TimerクラスとShellクラスをきちんと理解しましょう
Xojo標準の機能を利用するだけで、簡単にアプリが作成できます。 再配布はご遠慮下さい。著作権は留保しますが、ソースは自由に お使い下さい。現状はBSDライセンスを想定しています。
では、以下のリンクからお楽しみ下さい。 https://drive.google.com/file/d/1J0JT3rjiz_Wyye98yw5wh2PasG5jzfUp/view?usp=share_link
ごめんなさい。 スクラッチで直接書いたので、Function宣言を忘れていました。 Sub FormatString( nFormatStr As String, ParamArray inParam As String ) ↓ Function FormatString( nFormatStr As String, ParamArray inParam As String ) です。
Xojoでこのまま通ると思いますが、使用される場合はご注意を！
XojoにはC言語の標準関数であるprintfやsprintf等の不定数の引数を持つものはありません。 引数を省略する事の出来るメソッドはあります。
sprintfが使えないと色々と不便なので、似た様なメソッドを作成しました。 ParamArrayを使う事で引数の個数を特定せずに実装出来ます。
Sub FormatString( nFormatStr As String, ParamArray inParam As String )
Var theResultStr As String = "" Var theTempStr() As String
theTempStr = inFormatStr.Split( "%s" ) If ( theTempStr.Count >= inParam.Count ) Then //書式の挿入箇所と引数の両方が無くなるまでコピーする Do If ( theTempStr.Count > 0 ) And ( inParam.Count > 0 ) Then theResultStr = theResultStr + theTempStr( 0 ) + inParam( 0 )
theTempStr.RemoveAt( 0 ) inParam.RemoveAt( 0 )
ElseIf ( theTempStr.Count > 0 ) Then theResultStr = theResultStr + theTempStr( 0 ) theTempStr.RemoveAt( 0 )
ElseIf ( inParam.Count > 0 ) Then theResultStr = theResultStr + inParam( 0 ) inParam.RemoveAt( 0 ) Else Exit End If
loop until ( theTempStr.Count < 0 ) And ( inParam.Count < 0 )
Else // パラメーターの個数とformatの指示が一致しない Return( "" ) End If
Return( theResultStr )
End Sub
Stringに限定する事で処理を簡単に出来ます。 整数などを渡したい場合は FromatString( "This Is Int Value = %s" , theIntValue.ToString("Format") ) とすれば良いだけです。
補足の補足 カスタムアイコンの指定に関しては、私のmacOS26.2の 環境では全く動作せず、「そんなオプションは知らない」と 怒られるだけでした
-o volicon=と言う文字列はオプション処理を行う 部分には存在しませんでした。 iconpath=はあるのですが、同様に上手く動作しません。
コードから読み取ったのは'-o Module=volicon,volicon='という 指定方法で正しくカスタムアイコン指定が出来るようになりました。
xojo Rel.2024r3でThreadに新しい機能が追加されました。
ThreadクラスがPreemptive機能をサポートします。 デフォルトではCooperativeですが、IDEで設定を変更する事でPreemptiveに する事が出来ます。
Preemptive threadsを使うにはいくつか注意点があります。
Preemptiveスレッドを作成するには、Type プロパティを Preemptive に設定します。 実行時にスレッドのタイプを変更できますが、スレッド内のTypeプロパティのみが変更可能です。 実行中の他のスレッドのTypeプロパティを変更しない様に注意が必要です。（してしまうと、クラッシュします） また、ロック中（セマフォアやクリチカルセッション中）にTypeを切り替えるとクラッシュしたりロック （フリーズ）します。
デフォルトでは、スレッドはcooperativeであり、全てがアプリと同じCPUコアで実行されリソースも 共有しています。 これは、実行すべき処理が多いほどスレッドが完了するまでに時間が掛かります。
Preemptiveスレッドはアプリ自体とは別のCPUコアで実行する事が出来ます。 そのため、CPUコアに余裕があれば、cooperativeスレッドよりも速く実行できる事です。
Preemptiveスレッドは、スレッド間やアプリとの間でメモリを共有しません。 つまり、スレッド内のコードはアプリの他のオブジェクト等のメモリにアクセス出来ません。
＊個人的な見解ですが＊、セマフォアやクリチカルセッションを使う事で ArrayやDictionaryを扱える筈です。 その際はセマフォアやクリチカルセッションのTypeプロパティをPreemptiveにする必要が有ります。 これを忘れるとIllegalLockingExceptionになるようです。
xojoがサポートする機能のいくつかはPreemptiveスレッドから利用出来ません。 （この項目に関して、特定の情報は見つけられなかったです。）
cooperativeスレッドと同様に、UIに直接アクセス出来ません。 Runtime.IterateObjectsメソッドとXojoScriptは、Preemptiveスレッドで安全に使用できません。
閑話休題
とっても面倒くさい様な話を降り出したのですが、何かおかしいぞと思ったアナタ！ ヨクゾ気付きました。エライ、エライ、 なでなでしてあげます(^o^)
昨今のパソコンはCPU等が高機能化し、4コアや8コア程度は当たり前、お金を出し惜しみしなければ 32コアとか128コアとかのCPUを選ぶ事も出来ます。
但し、WindowsのクライアントOSは32コアを超えるCPUコアはサポートされず、使用されません。
であるのであれば、そんな時間のかかる場合はコンパイラやOSが適当に割り振ってくれても 良いのでは無いかと思いませんか？
まぁ、そう考えるのが普通ですな！
でも、現状のOSやコンパイラは、 ・どの部分が時間のかかる処理か や ・どの部分が別のコアに割り当てても問題が無いか を判断する事がいまだ出来ていません。
ですので、プログラムを記述する我々が適切に明確な指示をしない事には プログラムの分離はできないのです。
21世紀になったら、どら衛門や100万馬力のロボットが出来ていて、プログラミングから開放されると 夢見ていた自分を殴ってやりたいです。😂
〜〜蛇足〜〜 確かにコンパイラの最適化は進歩しました。インテルのコンパイラなどはベンチマークテストのコードを 何事もなかったかの様に処理して、ほとんど空のコードを吐き出して、唖然としました。
昔々、パソコンがまだ一般的じゃなかった頃、会社で導入したコンピュータでとあるシュミレータを 作って居た頃でも、並列化の部分はゴリゴリと手作業で書いていました。
WindowsもmacOSもAPIやライブラリは豊富にそろっていますが、基本的な部分はIBMのOS/370や DECのVMSとそうは変わっていないように思えます。
ですので、若い方々の努力の参考になれば幸いです。<m(__)m>
XojoのThreadクラスを知っていますか？
Threadクラスと聞いても、何の事かも判らないし、得体の知れない物と思われているかも判りませんが、 簡単な例を上げてみると： 通常のプログラムは １）ユーザから何かの入力を受けて、加工を施してから画面に表示します。 また ２）ファイルやネットワークからデータを読み込んで、加工して画面に表示したり、 別のファイルに書き出したりします。
この様な場合に、加工すべきデータが数十〜数百の程度だと現状のパソコンでも、 処理内容にも拠りますがほぼ数秒以内に結果が得られます。
しかし
加工すべき元データが数万〜数千万の単位になると、数分もしくは数時間掛かるかも知れません。 その作業時間にユーザからのアクションである各種イベントが処理されなくなると、どうなるでしょうか？ ・プログラムが暴走orハングアップしたのか？ ・何か間違った捜査をしてしまったのでは無いか？ ・指定すべきデータを間違ったのでやり直したい！ 等と言う状況になるかも…
そのような場合に役立つのが、Threadクラスや別途説明するWorkerクラスです。 （今回はThreadクラスの説明ですので、Workerクラスは別の機会にします）
加工処理に時間がかかる場合、ユーザに状況を把握してもらうため ・ダイアログウィンドウ等を表示して、全データ件数の内の何件目を処理しているのかを表示する。 ・ユーザからの途中での停止、中断等のアクションを受けて、適切な対応をする。 みたいな動作をする事が望ましいと考えられます。
そこで、アプリケーションの本来の流れはダイアログウィンドウを表示し、データ加工の進行状況を 更新しつつ、イベントを適切に処理しておく事で、ユーザはいつでもアプリケーションを安心して 使用できます。
本来の流れとは別に（Threadクラスを用いて）データ加工を順次行う事で、プログラムの流れを分離して 簡潔な構成にして、作成が容易になり、バグの発生も軽減できる事が期待できます。
但し、Threadの処理内ではThread SafeなAPIしか呼び出す事が出来ません。 具体的には画面への表示更新などはThread Safeでは無いので、呼び出す事は出来ません。 ご注意ください。
xojoの日本語フォーラムもありますが、最近はほとんど使われていないようです。
xojoのオープンソースなプロジェクトがいくつかあるそうなので、xojo.comのドキュメントサイトも見てください。
https://documentation.xojo.com/resources/third_party/open_source_projects.html
最初にリリースした2.00.0.Beta01にアラームリストが読み込まれる際にアラームリスト含まれている
サウンドファイルが当該フォルダから削除されていた場合にクラッシュする不具合がありました。
読み込み時に整合性を確認して該当するアラーム項目をスキップします。
対応版は2.00.0.Beta01Build10以降でバージョンで修正が入っています。
よろしくお願いします。
バージョン1.01をGoogleDriveへアップしました。
https://drive.google.com/file/d/1aGwXq5Be176m496EcjwHX3ykhKktvfUv/view?usp=share_link
主な変更点はアプリからボタンクリックで直接マウント出来るようになりました。
この為にはサーバとクライアント間で鍵を共有しておく必要があります。
個々のケースでの設定は各自でお調べ下さい。
ガイドとしては
１，クライアント側で秘密鍵と公開鍵を生成する
２，サーバ側へ公開鍵をコピーする
３，クライアント側とサーバ側で各々の鍵を利用するように設定する
以上です。
利用するサーバ情報を登録ファイルに記述しておけば、数回のクリックでデスクトップに
マウント出来ます。
当方はターミナル（iTerm2）にエイリアス登録して、ssh接続とディレクトリの
マウントを一度に行い、サーバのメンテなどに使用しています。
尚、sshfsやmacFUSE上の問題点や制限事項などをドキュメントを
しっかり確認して下さい。
でわでわ
過去にShellクラスを使った時と違っていて、１ラインごとにコマンドをShellへ送ると、状態遷移していないと
言うことが判りました。
そこで、Shellを非同期で使うのでは無く、対話型にして使う事でこの問題を回避したAsyncShell(改)を作っています。
インスタンスを作る時にパラメータで使い分けるように仕様としていますので、使い勝手は変わらないと思います。
また、このSyncShellを用いる事で、アプリ内から直接sshfsでマウントする事が出来るようになります。
多少の作業を行ってから改訂版アプリをアップします。
でわでわ
大事な点を忘れていました。開発者の署名は付いていません。また、Appleの公証も得ていませんので、通常は起動出来ないと
思われます。
(Sentinel.app)等を利用しないと使えないので、ご注意を！
sshfsを利用したマウントコマンドを作成するヘルパーアプリの
プロジェクトファイルをGoogleドライブにアップしました。
動作するアプリ本体も同梱していますが、いくつか注意点を挙げます。
このプロジェクトは単独ではビルド出来ません。
いくつかの独自作成のクラスを省いています。
省いた主なクラスは以下の2個です。
・IntervalTimerクラス
・AsyncShellクラス
今回のsshfsマウントコマンドの生成に関する部分では無いので
スキルを磨く為に独自で実装出来れば、嬉しいです。
・IntervalTimerクラス
Timerを継承して、ハンドラを使いやすくするためのクラス
・AsyncShellクラス
ShellとIntervalTimerを使って、外部から（このクラスを利用するメソッド等）
送られたShellコマンドを順次Shellへ投げて、その応答を読み出し依頼が
来るまで捧持しておく。
ヒント：
１，Arrayを継承したQueueクラスを実現すると意外と簡単かも
２，TimerクラスとShellクラスをきちんと理解しましょう
Xojo標準の機能を利用するだけで、簡単にアプリが作成できます。
再配布はご遠慮下さい。著作権は留保しますが、ソースは自由に
お使い下さい。現状はBSDライセンスを想定しています。
では、以下のリンクからお楽しみ下さい。
https://drive.google.com/file/d/1J0JT3rjiz_Wyye98yw5wh2PasG5jzfUp/view?usp=share_link
ごめんなさい。
スクラッチで直接書いたので、Function宣言を忘れていました。
Sub FormatString( nFormatStr As String, ParamArray inParam As String )
↓
Function FormatString( nFormatStr As String, ParamArray inParam As String )
です。
Xojoでこのまま通ると思いますが、使用される場合はご注意を！
XojoにはC言語の標準関数であるprintfやsprintf等の不定数の引数を持つものはありません。
引数を省略する事の出来るメソッドはあります。
sprintfが使えないと色々と不便なので、似た様なメソッドを作成しました。
ParamArrayを使う事で引数の個数を特定せずに実装出来ます。
Sub FormatString( nFormatStr As String, ParamArray inParam As String )
Var theResultStr As String = ""
Var theTempStr() As String
theTempStr = inFormatStr.Split( "%s" )
If ( theTempStr.Count >= inParam.Count ) Then
//書式の挿入箇所と引数の両方が無くなるまでコピーする
Do
If ( theTempStr.Count > 0 ) And ( inParam.Count > 0 ) Then
theResultStr = theResultStr + theTempStr( 0 ) + inParam( 0 )
theTempStr.RemoveAt( 0 )
inParam.RemoveAt( 0 )
ElseIf ( theTempStr.Count > 0 ) Then
theResultStr = theResultStr + theTempStr( 0 )
theTempStr.RemoveAt( 0 )
ElseIf ( inParam.Count > 0 ) Then
theResultStr = theResultStr + inParam( 0 )
inParam.RemoveAt( 0 )
Else
Exit
End If
loop until ( theTempStr.Count < 0 ) And ( inParam.Count < 0 )
Else
// パラメーターの個数とformatの指示が一致しない
Return( "" )
End If
Return( theResultStr )
End Sub
Stringに限定する事で処理を簡単に出来ます。
整数などを渡したい場合は
FromatString( "This Is Int Value = %s" , theIntValue.ToString("Format") )
とすれば良いだけです。
補足の補足
カスタムアイコンの指定に関しては、私のmacOS26.2の
環境では全く動作せず、「そんなオプションは知らない」と
怒られるだけでした
-o volicon=と言う文字列はオプション処理を行う
部分には存在しませんでした。
iconpath=はあるのですが、同様に上手く動作しません。
コードから読み取ったのは'-o Module=volicon,volicon='という
指定方法で正しくカスタムアイコン指定が出来るようになりました。
xojo Rel.2024r3でThreadに新しい機能が追加されました。
ThreadクラスがPreemptive機能をサポートします。
デフォルトではCooperativeですが、IDEで設定を変更する事でPreemptiveに
する事が出来ます。
Preemptive threadsを使うにはいくつか注意点があります。
Preemptiveスレッドを作成するには、Type プロパティを Preemptive に設定します。
実行時にスレッドのタイプを変更できますが、スレッド内のTypeプロパティのみが変更可能です。
実行中の他のスレッドのTypeプロパティを変更しない様に注意が必要です。（してしまうと、クラッシュします）
また、ロック中（セマフォアやクリチカルセッション中）にTypeを切り替えるとクラッシュしたりロック
（フリーズ）します。
デフォルトでは、スレッドはcooperativeであり、全てがアプリと同じCPUコアで実行されリソースも
共有しています。
これは、実行すべき処理が多いほどスレッドが完了するまでに時間が掛かります。
Preemptiveスレッドはアプリ自体とは別のCPUコアで実行する事が出来ます。
そのため、CPUコアに余裕があれば、cooperativeスレッドよりも速く実行できる事です。
Preemptiveスレッドは、スレッド間やアプリとの間でメモリを共有しません。
つまり、スレッド内のコードはアプリの他のオブジェクト等のメモリにアクセス出来ません。
＊個人的な見解ですが＊、セマフォアやクリチカルセッションを使う事で
ArrayやDictionaryを扱える筈です。
その際はセマフォアやクリチカルセッションのTypeプロパティをPreemptiveにする必要が有ります。
これを忘れるとIllegalLockingExceptionになるようです。
xojoがサポートする機能のいくつかはPreemptiveスレッドから利用出来ません。
（この項目に関して、特定の情報は見つけられなかったです。）
cooperativeスレッドと同様に、UIに直接アクセス出来ません。
Runtime.IterateObjectsメソッドとXojoScriptは、Preemptiveスレッドで安全に使用できません。
閑話休題
とっても面倒くさい様な話を降り出したのですが、何かおかしいぞと思ったアナタ！
ヨクゾ気付きました。エライ、エライ、 なでなでしてあげます(^o^)
昨今のパソコンはCPU等が高機能化し、4コアや8コア程度は当たり前、お金を出し惜しみしなければ
32コアとか128コアとかのCPUを選ぶ事も出来ます。
但し、WindowsのクライアントOSは32コアを超えるCPUコアはサポートされず、使用されません。
であるのであれば、そんな時間のかかる場合はコンパイラやOSが適当に割り振ってくれても
良いのでは無いかと思いませんか？
まぁ、そう考えるのが普通ですな！
でも、現状のOSやコンパイラは、
・どの部分が時間のかかる処理か
や
・どの部分が別のコアに割り当てても問題が無いか
を判断する事がいまだ出来ていません。
ですので、プログラムを記述する我々が適切に明確な指示をしない事には
プログラムの分離はできないのです。
21世紀になったら、どら衛門や100万馬力のロボットが出来ていて、プログラミングから開放されると
夢見ていた自分を殴ってやりたいです。😂
〜〜蛇足〜〜
確かにコンパイラの最適化は進歩しました。インテルのコンパイラなどはベンチマークテストのコードを
何事もなかったかの様に処理して、ほとんど空のコードを吐き出して、唖然としました。
昔々、パソコンがまだ一般的じゃなかった頃、会社で導入したコンピュータでとあるシュミレータを
作って居た頃でも、並列化の部分はゴリゴリと手作業で書いていました。
WindowsもmacOSもAPIやライブラリは豊富にそろっていますが、基本的な部分はIBMのOS/370や
DECのVMSとそうは変わっていないように思えます。
ですので、若い方々の努力の参考になれば幸いです。<m(__)m>
XojoのThreadクラスを知っていますか？
Threadクラスと聞いても、何の事かも判らないし、得体の知れない物と思われているかも判りませんが、
簡単な例を上げてみると：
通常のプログラムは
１）ユーザから何かの入力を受けて、加工を施してから画面に表示します。
また
２）ファイルやネットワークからデータを読み込んで、加工して画面に表示したり、
別のファイルに書き出したりします。
この様な場合に、加工すべきデータが数十〜数百の程度だと現状のパソコンでも、
処理内容にも拠りますがほぼ数秒以内に結果が得られます。
しかし
加工すべき元データが数万〜数千万の単位になると、数分もしくは数時間掛かるかも知れません。
その作業時間にユーザからのアクションである各種イベントが処理されなくなると、どうなるでしょうか？
・プログラムが暴走orハングアップしたのか？
・何か間違った捜査をしてしまったのでは無いか？
・指定すべきデータを間違ったのでやり直したい！
等と言う状況になるかも…
そのような場合に役立つのが、Threadクラスや別途説明するWorkerクラスです。
（今回はThreadクラスの説明ですので、Workerクラスは別の機会にします）
加工処理に時間がかかる場合、ユーザに状況を把握してもらうため
・ダイアログウィンドウ等を表示して、全データ件数の内の何件目を処理しているのかを表示する。
・ユーザからの途中での停止、中断等のアクションを受けて、適切な対応をする。
みたいな動作をする事が望ましいと考えられます。
そこで、アプリケーションの本来の流れはダイアログウィンドウを表示し、データ加工の進行状況を
更新しつつ、イベントを適切に処理しておく事で、ユーザはいつでもアプリケーションを安心して
使用できます。
本来の流れとは別に（Threadクラスを用いて）データ加工を順次行う事で、プログラムの流れを分離して
簡潔な構成にして、作成が容易になり、バグの発生も軽減できる事が期待できます。
但し、Threadの処理内ではThread SafeなAPIしか呼び出す事が出来ません。
具体的には画面への表示更新などはThread Safeでは無いので、呼び出す事は出来ません。
ご注意ください。
xojoの日本語フォーラムもありますが、最近はほとんど使われていないようです。
xojoのオープンソースなプロジェクトがいくつかあるそうなので、xojo.comのドキュメントサイトも見てください。
https://documentation.xojo.com/resources/third_party/open_source_projects.html