CotEditorでオープン中の最前面の書類の内容をすべて選択してコマンド（半角→全角 文字変換）を実行するAppleScriptです。
データ処理内容の確認のためにCotEditor上で処理したときに「あれ？ 書類の内容を全選択する処理って書いたことなかったわ〜」と気づいて、慌てて書きました。
| AppleScript名：最前面のドキュメント内を全選択して全角変換.scpt |
| tell application "CotEditor" tell front document set tLen to length set aRange to {0, tLen} set range of selection to aRange change roman width selection to full end tell end tell |
KeynoteをGUI Scripting経由で操作したときに、Stream Deck制御ソフトウェアに「Keynote」プラグインが入った状態だと、異常が発生する件の続報です。
Stream Deckソフトウェアに「Keynote」操作プラグインをインストールすると、GUI Scriptingからの本物のKeynote.appにメニュー操作を要求しても「そんなものはない」と言われてしまうというのが、この問題の概要です。
elgatoに問い合わせ、Appleにバグレポートし、elgatoからは一向に返事も何も返ってこない（elgatoから返事をもらったことがない）のですが、Appleの担当者とやりとりしてこの奇怪現象の発生メカニズムが見えてきました。
Stream DeckのKeynote操作プラグインをインストールした状況でアクティビティモニタを調べると…
なんと、不可視のStream Deckプラグインのプロセスの名称が「Keynote」という名前になっていたのが原因だったようです。そこ、「Keynote_control」とか少しはひねった名前にしようよ、、、、＞elgato
どれだけ複雑で悪辣な仕組みになっているのかと思っていたら、これだけ。
Appleの担当者から提案された対策コードはこんな感じで、実際に自分で動作確認しつつ、少しだけ手直ししてみました。これで、Stream DeckのKeynote操作用プラグインの不可視プロセスが「Keynote」なんて名前で実行されていても問題ありません。いやはや。
| AppleScript名：Keynoteの各メニュータイトルをGUI Scriptingで取得する.scpt |
| tell application "System Events" set tProcList to every process whose name is "Keynote" and its background only is false if tProcList = {} then return tell (first process whose name is "Keynote" and background only is false) –ここ、変数に代入するとダメ！！ tell menu bar 1 set mList to title of every menu bar item –> {"Apple", "Keynote", "ファイル", "編集", "挿入", "スライド", "フォーマット", "配置", "表示", "再生", "共有", "ウインドウ", "ヘルプ"} end tell end tell end tell |
GUI Scriptingを（メニューやキーボードショートカットについては）ラッピングして、ファイル名に「アプリケーション名＠メニュー項目名>メニュー項目」などと書くだけで該当するメニュー項目の実行を行える「Piyo Menu Clicker v1.0 for Stream Deck」のリリース候補版を試していたら、macOS 11.5＋Keynote 11.1でエラーが出まくりました。
# その後の調査により、よりによってStream Deckの制御ソフトウェア「Stream Deck.app」が起動しているとこの問題が発生することがわかりました。Stream Deck用の制御Scriptを使おうとしたらStream Deckのソフトウェア自体が実行を邪魔していたとは….
メニューバーのメニュー項目を指し示そうとして、
| AppleScript名：Keynoteで新規書類を実行.scpt |
| activate application "Keynote" tell application "System Events" tell process "Keynote" click menu item 1 of menu 1 of menu bar item 3 of menu bar 1 end tell end tell |
のようなお気軽な内容を試してみたところ、エラーに。メニューが存在していて、GUI側からマウスで普通に操作できるのですが……
他のPagesであるとかSafariなどで同様の記述を行なってもエラーになりません。Keynoteだけ問題が発生しているようです。
| AppleScript名：Pagesで新規書類を作成.scpt |
| activate application "Pages" tell application "System Events" tell process "Pages" click menu item 1 of menu 1 of menu bar item 3 of menu bar 1 end tell end tell |
| AppleScript名：Safariで新規ウィンドウを表示.scpt |
| activate application "Safari" tell application "System Events" tell process "Safari" click menu item 1 of menu 1 of menu bar item 3 of menu bar 1 end tell end tell |
Keynoteのmenu bar 1に対してmenu bar itemのtitle（メニュー項目のテキスト）を求めると、「Apple」しか返ってきません。
tell application "System Events"
tell process "Keynote"
tell menu bar 1
set mList to title of every menu bar item
–> {"Apple"}
end tell
end tell
end tell
★Click Here to Open This Script
iOSアプリをM1 Mac上で起動した場合にこのような挙動になるのか調べてみても、ちゃんとiOSアプリもメニュー項目を取得できます。iOSアプリについては（苦労はするものの）AppleScriptから強引に操作することは可能なので、Keynoteよりは出来がいいといえます。
追記：
手元にあるバージョンの異なるmacOS環境でこの処理を試してみました。
macOS 12.0beta＋Keynote v11.1→異常
macOS 11.5＋Keynote v11.1→異常
macOS 10.15.7＋Keynote v11.1→正常
macOS 10.14.6＋Keynote v10.1→異常
macOS 10.13.6＋Keynote v9.1→正常
追記２：
異常が出ていた環境では、すべてStream Deckの制御ソフトウェアをインストールして起動していました。Stream Deck.appを終了させると問題が発生しないことを確認しました。Stream Deck Softwareのせいでした。
Stream Deckから各種ソフトウェアを操作するために作ったソフトウェアが、Stream Deckソフトウェアによって実行を阻害されているという事実の前に言葉もありません。
elgatoのWebフォームからレポートを送っていますが、elgatoにはいろいろ送っても、一度も返事をもらったことがないのでなんとも（日本代理店のソフトバンクC&Sとは確認のためにやりとりしていますが…）。
厳密に言うと、Stream Deckのオンラインストアから入手可能な「Keynote」プラグイン（Keynoteのプレゼン再生コントロールを行うelgato製のプラグイン）をインストールするとGUI ScriptingのKeynoteに対する実行が阻害されます。
–> Elgato Keynote plugin checking demo
▲まさか、elgato純正のプラグインがKeynoteへのGUI Scriptingの実行（メニューへのアクセス）を妨害しているとは思いませんでした。このプラグインはインストールしてはいけないものだと思います。機能もたいしたことはないし、害悪でしかありません。即刻Storeから撤去してほしいものです
M1 Mac miniをメインマシンに変更してはや１か月ぐらい。普段のアプリケーションを利用する使い方では、ほとんどIntel Macと差がないというか、違いが分からない感じで使えています。
M1 Mac上でAppleScriptを動かすとIntel Macの10〜77倍遅いケースがままある（Cocoa Scripting時）ので、高性能マシンに乗り換えた感じはまったくしません。KeynoteとかMail.appとかSafariが速いだけの環境です。AppleScriptでバリバリにプログラムを書いているなら、iMac Proのほうが快適でしょう。Mac Proについては……三角関数の計算を間違える問題マシンとして認識しているので、まったく食指が動きません（価格的に無理ですが）。
ただ、M1 MacはCPUが熱くならないので放熱ファンで風を送らなくてよく、夏でも静かなのは助かります。
＃ macOS 12になって、Cocoa Scripting速度が大幅に改善されたので、（OSのバグや不具合はありますが）自分の使っている範囲では高速で快適です
macOS 10.10以降、AppleScriptからオープンソース系のCocoa Frameworkが呼べるようになって、ほぼObjective-Cのコードを直接呼び出して実行できるようになって大変便利な状態になっています。Swiftで書かれたプログラムもBridging Headerを書けば呼べるらしいのですが、自分はいまひとつです。
Intel Mac環境でビルドして利用していたIntel BinaryのFrameworkを、そのまま呼び出すことはできていません。FrameworkについてはRosetta 2で翻訳されて実行できるという状況にはないので、Universal Binaryビルドを行う必要があるものと認識しています。
オープンソースのFrameworkのXcodeプロジェクトをそのまま手元に置いてあったので、Xcode 12でオープンしてビルドして、そのままAppleScriptから呼び出して実行できるものもありました。
「これなら問題なくいけるかも？」
……ある意味Yesともいえるし、Noともいえる状況です。
HTMLReader.frameworkあたりはほぼ何も考えずにUniversal Binaryビルドできました。これがないととても困るので助かります。
Intel MacとM1 Macではハードウェアの構成が違うので、そうしたIntel Macのハードウェアを前提としているものはもう、まるっきり動きません。オーディオ出力先のデバイスを変更するものは、まるっきりダメ。各種センサー類から情報を取得するもの（SMCkit）もダメでした。
Private Frameworkになりますが、ServerInformation.frameworkの中に入っている各種ハードウェアの名称テキストが、M1 Macについては入っていなかったりで。Intel Macとまるっきり同じ情報が入っているわけではないというのが意外でした。
これはFrameworkまわりの話ではありませんが、M1への移行は最新のmacOSへの移行でもあります。新しいという言葉から「改良されている」「よくなっている」と無条件に思ってしまいがちですが、「なくなっている機能がある」「削られた機能がある」という側面も無視できません。
macOSのバージョンが違えば、その構成ファイルも変わっています。とくに、Menu Extrasの構成が大きく変わっており、身近なところではScript MenuがmacOS 10.14でMenu Extrasから独立した小型アプリケーションに置き換わったりもしています。これがScript Menuだけでなく他のMenu Extrasでも同様の動きが起きており、どんどんその数が減少しています。
Menu Extrasの中の実行ファイルを呼び出しているようなScriptは、M1 MacつまりmacOS 11.x環境に持って行ったときに動かなくなります。ファイルそのものが存在していないので「当然」ではあります。
実行中のMacの製品名を求めるAppleScriptです。もともと、AppleScriptで作成して使用しているアイデアプロセッサ「Kamenoko」で行っている処理なのですが、
M1上で実行すると、製品名は間違えるわ、仕様は合っていないわで散々でした。あ、マシンのアイコンは取ってきていますね。その他のデータはマシン移行をしたときにそのまま前のマシンのデータが残っていたためでしょう。
調べてみると、M1 Macでは従来どおりの製品名データを持っていないようで、Intel Macでは取得できていた製品の名前をわかりやすく記述するデータがありません。各国語にローカライズされていて便利だったのですが。
そこで、M1 MacかどうかのCPUタイプ検出を行い、そのうえで処理を分けることにしました。動作原理上、購入してセットアップしたてのマシンでこのファイルが存在しているかどうか、検証が必要だと思います。
| AppleScript名：Macの製品名を求める（M1以降対応）v1a.scpt |
| — – Created by: Takaaki Naganoya – Created on: 2021/07/28 — – Copyright © 2021 Piyomaru Software, All Rights Reserved — use AppleScript version "2.7" — macOS 10.13 or later use framework "Foundation" use scripting additions set hRes to retModelName() of me –> "Mac mini (M1, 2020)"–macOS 11.5 –> "Mac mini Intelデュアルコアプロセッサおよび統合型グラフィックス搭載、2014年後期に投入。"–macOS 12beta –> "15インチMacBook Pro, Retinaディスプレイ, Intel Core i7 (Mid 2012)"–macOS 10.14.6 on retModelName() set cRes to CPU type of (system info) if cRes begins with "ARM" then –Apple Silicon Mac set sText to "defaults read ~/Library/Preferences/com.apple.SystemProfiler.plist" & " ’CPU Names’ | cut -sd ’＼"’ -f 4" set hRes to do shell script sText return hRes else if cRes begins with "Intel" then –Intel Mac set hRes to retModelInfo() of me return hRes end if end retModelName on retModelInfo() tell application "System Events" set osVersion to system version of (system info) end tell — macOS 10.15.3 –> 15 considering numeric strings if osVersion ≥ "10.15" then –macOS 11.0以降 set pListPath to "/System/Library/PrivateFrameworks/ServerInformation.framework/" & "Versions/A/Resources/ja.lproj/SIMachineAttributes.plist" else if osVersion > "10.14" then –macOS 10.14まで set pListPath to "/System/Library/PrivateFrameworks/ServerInformation.framework/" & "Versions/A/Resources/Japanese.lproj/SIMachineAttributes.plist" end if end considering set aRec to retDictFromPlist(pListPath) of me set hwName to (do shell script "sysctl -n hw.model") set aMachineRec to retRecordByLabel(aRec, hwName) of me set aMachineRec2 to first item of aMachineRec return |description| of _LOCALIZABLE_ of aMachineRec2 end retModelInfo on retDictFromPlist(aPath) set thePath to current application’s NSString’s stringWithString:aPath set thePath to thePath’s stringByExpandingTildeInPath() set theDict to current application’s NSDictionary’s dictionaryWithContentsOfFile:thePath return theDict as record end retDictFromPlist on retRecordByLabel(aRec as record, aKey as string) set aDic to current application’s NSDictionary’s dictionaryWithDictionary:aRec set aVal to aDic’s valueForKey:aKey return aVal as list end retRecordByLabel on retRecordByKeyPath(aRec as record, aKey as string) set aDic to current application’s NSDictionary’s dictionaryWithDictionary:aRec set aVal to aDic’s valueForKeyPath:aKey return aVal end retRecordByKeyPath –1D Listを文字列長でソート v2 on sort1DListByStringLength(aList as list, sortOrder as boolean) set aArray to current application’s NSArray’s arrayWithArray:aList set desc1 to current application’s NSSortDescriptor’s sortDescriptorWithKey:"length" ascending:sortOrder set desc2 to current application’s NSSortDescriptor’s sortDescriptorWithKey:"self" ascending:true selector:"localizedCaseInsensitiveCompare:" set bArray to aArray’s sortedArrayUsingDescriptors:{desc1, desc2} return bArray as anything end sort1DListByStringLength |
日常的に生じている不満を解消するための、ちょっとしたかき捨てScript……になるはずだったものです。
Classic Mac OSからMac OS Xへの移行後、Finderの仕様で大きく変わった点が１つあります。「同じフォルダのウィンドウを複数枚オープンできるようになった」点です。
その結果、
といったように、同じフォルダを指し示すウィンドウが何枚もたまる現象が起きています。これは別にバグでも不具合でもありません。仕様です。
この重複Windowを掃除するためのScriptを書いてみました。
| AppleScript名：ターゲットが同じWindowを取得（未遂）.scpt |
| tell application "Finder" tell window 1 set aTarg to target end tell set wList to every window whose target is equal to aTarg end tell |
何も考えずに書き始めると、こんな（↑）感じでしょう。ただ、このScriptは動きません。フィルター参照は、たとえばファイル名や拡張子、ファイル種別（kind）あたりには使えるものの、この「target」属性に対しては効きません。
そこで、仕方なくちょっと腰をすえて書いてみました。これ（↓）を動かすと、
のように重複ウィンドウが一掃されます。これでいいはずです。
| AppleScript名：targetが重複しているFinder Windowをクローズする.scpt |
| — – Created by: Takaaki Naganoya – Created on: 2021/07/22 — – Copyright © 2021 Piyomaru Software, All Rights Reserved — set clList to {} tell application "Finder" set wList to every window –> {Finder window id 1775 of application "Finder", Finder window id 1612 of application "Finder", Finder window id 1740 of application "Finder", Finder window id 1641 of application "Finder", Finder window id 1630 of application "Finder", Finder window id 1618 of application "Finder", Finder window id 1599 of application "Finder", Finder window id 1592 of application "Finder", Finder window id 1586 of application "Finder", Finder window id 1580 of application "Finder", Finder window id 1575 of application "Finder", Finder window id 1569 of application "Finder", Finder window id 1563 of application "Finder"} set tList to (target of every window) as alias list –> {alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Documents:AppleScript 12.0:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:"} –ターゲットフォルダをユニーク化 set bList to removeDuplicates(tList) of me –> {alias "Macintosh HD:Users:me:Documents:AppleScript 12.0:", alias "Macintosh HD:Users:me:Public:ドロップボックス:"} –ユニーク化したターゲットでループ repeat with i in bList set j to (contents of i) as alias set firstF to true –ウィンドウでループ repeat with ii in wList set jj to contents of ii set tmpTarg to (target of jj) as alias if tmpTarg is equal to j then –最初の１つ目のWindowだけ残す if firstF = true then set firstF to false else –２個目以降のWindowはクローズ対象リストに入れる set the end of clList to jj end if end if end repeat end repeat –クローズ対象とされるFinder Windowを順次クローズ repeat with i in clList set j to contents of i try ignoring application responses close j end ignoring end try end repeat end tell on removeDuplicates(aList) set newList to {} repeat with i from 1 to (length of aList) set anItem to item 1 of aList set aList to rest of aList if {anItem} is not in aList then set end of newList to anItem end repeat return newList end removeDuplicates |
edama2さんがコメント欄に投稿してくださったプログラムを掲載しておきます。自分が「安全のためにこのぐらいの処理は必要（かも？）」と付けまくった処理を「それ別に実際のところ必要ないんじゃない？」と省略された感じです。
あとは、edama2さんのScriptだと「最前面のWindowのtargetと同じtargetを持つWindowをクローズする」という動作ですが、自分のScriptは「targetが重複しているWindowは１つを残してあとすべてをクローズする」という動作を行うので、厳密にいえば違うものです。
| AppleScript名：targetが重複しているFinder Windowをクローズする v2.scpt |
| – Created by: edama2 – Created on: 2021/07/22 tell application "Finder" tell front window set aTarg to target end tell set aList to (every Finder window) as list repeat with num from 2 to count aList set anItem to (aList)’s item num if (anItem’s target is aTarg) then close anItem end repeat end tell |
AppleScriptのランチャーとして手軽に構成を変更して運用できるelgato Stream Deck、Mac上で利用する場合のガイド本を作成中ですが、Stream Deckソフトウェアのv5.xの登場にくわえ、新製品の「Stream Deck MK.2」が登場！
# ニュースをみつけて膝から崩れ落ちました。また追記が必要、、、
新機種のStream Deck mk.2は、従来のStream Deck（15key版）を置き換えるもののようで、あくまでデザインや些細な仕様を変更したもの、と明記されています。フェイスプレートを載せ替えなければ見た目はあまり変わりませんし、対応OSなどの動作条件も変わりません。
・USBケーブルが着脱式に変更（従来は着脱不能）
・スタンドが折りたたみ式ではなくStream Deck XL（24key版）と同様のしっかりしたものに変更。マグネットで脱着
・フェイスプレートを変更可能。７種類のデザインの異なるフェイスプレートを交換し、表面部分をカスタマイズできる（ユーザーがグラフィックを送ってカスタム印刷するという種類のものではなく、異なるデザインの交換式フェイスプレートを追加で購入できる）
深い。とてもよく顧客を見ている。これで欠品とか品薄でなければもっといいのに。
macOS 11で発生していた「NSString’s stringWithFormat:」をAppleScriptから呼び出すとクラッシュするというバグが、最新のmacOS 11.5BetaおよびmacOS 12.0Betaで修正されていることを確認しました。
→ macOS 11.5正式版がリリースされ、修正されていることを確認。逆にいえば、AppleScriptでCocoa Scriptingを用いて作ったプログラムは、macOS 11.0〜11.4の環境を動作条件から外す（動作要求条件を11.5以上にする）必要があるということです。
クラッシュしなくなりましたね。問題点について、気がついたらレポートして念押しして、修正内容を確認するという地道な作業の繰り返し、積み重ねで世界の平和が維持されているのでありました。
▲Uni Detector v1.2.1もNSString’s stringWithFormat:メソッドがクラッシュしなくなったおかげで、ちゃんとCPUアーキテクチャごとの構成比率グラフを実行してもアプリケーションごとクラッシュしなくなりました
macOS用テキストエディタ「CotEditor」の機能強化AppleScript集「Script Pack v3」の配布を開始しました。
→ 配布ページ
Script Packは従来バージョン同様に、機能強化ユーティリティScript集の「PowerPack」および、AppleScriptによる基礎的なCotEditorの操作を解説した「Basic Pack」から構成されています。macOS 10.15.xおよび11.x＋CotEditor v4.xとの組み合わせで利用することを想定しています。M1 Mac上でも動作確認ずみです。
PowerPack v3では、CotEditor上で編集中のテキストの文字種別を集計してグラフ表示させたり、編集中のテキストで使われている単語をもとにタグクラウド表示を行うなど、従来では把握しにくかったテキストの傾向をビジュアル表示する機能を追加しています。
外部アプリケーションを使わずにCSVデータのプレビュー（100行までの制限あり）、Markdownテキストのプレビューを行えるなど、CotEditorの動作速度を損うことなく大幅な機能追加を行なっています。
電子書籍の新刊を出しました。「機能強化AppleScript集 CotEditor用 PowerPack 取扱説明書」ページ数：191ページ、フォーマット：PDF＋Zipアーカイブ（PowerPack、BasicPack）となっています。
→ 販売ページ
→ お試し版書籍ダウンロード
「CotEditor」は、Github上のオープンソース・プロジェクトで公開されているmacOS用の高機能テキストエディタです。本書は、そのCotEditorに便利で強力な機能を追加できるAppleScript集「PowerPack v3」の取扱説明書です。
本書にはPowerPack v3（ソース編集可能版）＋Basic Packが含まれています。現在準備中の一般配布版のPowerPack v3は内容が見られません。ただ実行するだけです。
新たにリリースしたPowerPackバージョン3では、グラフ表示やタグクラウド表示などの「ド派手な機能」を追加。Markdown書類のプレビューやCSVデータの表プレビュー、タブ区切りテキストによるKeynote書類の生成、ミュージック.appのトラックへの歌詞データの書き込みなど、AppleScriptによる高度な処理を手軽にご堪能いただけます。
WordPressの「WordPress Popular Posts」プラグインが文字化けするようになっていたため、別のプラグインで表示するようにインストールして変更しました。
新たに導入したのは「Top 10」というプラグインです。記事ごとに閲覧回数カウントが出るとか（これは設定で消しました）、Popular Postsの計算キャッシュがクリアされたのでゼロからカウントし直しだとか、いろいろまだ試行錯誤する必要がありそうです。管理者の閲覧を除外できないっぽいので、ちょっと変わった傾向になるとは思っています。
「WordPress Popular Posts」の不具合が治ったら元に戻すことも検討しますが、突然文字化けされるよりはこちらのほうがいいでしょう。
すでにAppleにフィードバックしている内容ではあるのですが（修正されることを祈るばかりです）、NSStringのstringWithFormat:メソッドがmacOS 11ではエラーになります。エラーというよりも、実行処理系そのものがクラッシュします（確定した事実）。
これと似た記法を行う「NSPredicate predicateWithFormat:」も同様にエラーになることが判明しました。こちらはクラッシュを発生させるほどではありませんが、これまでのOSバージョンで動作していた記法がエラーになっています（勘違い）。
どうもこれらの発生原因は同じような処理の箇所のように見えるため、macOS 11では「withFormat:」のAPIが、AppleScriptからScripting Bridge経由で呼び出すと一律にエラーになるものと想像しています。
→ テストに使用したScriptに間違いがあって、macOS 10.15以前では「たまたま動いていた」ということがわかりました。「NSPredicate predicateWithFormat:」自体でエラーが出ていたのではなく、その中に書いていたPredicate文に間違いがあったことがわかりました（確認・確定した事実）
Shane StanleyのFrameworkバイナリ入りAppleScript Library「Bridge Plus」「Myriad Tables Lib」「SQLite Lib2」がApple Silicon対応していました。
それぞれ単独の配布アーカイブではApple Silicon対応していないのですが、「Shane’s Script Library Pack」でまとめて配布されているものはApple Silicon対応のUniversal Binaryでビルドされています。
インストーラーはAppleScriptアプレットになっており、実行すると……これらのライブラリがインストールされていません。このため、Shane Stanley本人に聞いてみたところ、これらのインストール対象のライブラリがすでにインストールされている場合には、あらかじめ削除しておいてほしいとのこと。
……それはわかりませんでした（＾ー＾；；
m1mini:~ me$ file /Users/me/Library/Script\ Libraries/BridgePlus.scptd/Contents/Frameworks/BridgePlus.framework/Versions/A/BridgePlus /Users/me/Library/Script Libraries/BridgePlus.scptd/Contents/Frameworks/BridgePlus.framework/Versions/A/BridgePlus: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64:Mach-O 64-bit dynamically linked shared library arm64] /Users/me/Library/Script Libraries/BridgePlus.scptd/Contents/Frameworks/BridgePlus.framework/Versions/A/BridgePlus (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 /Users/me/Library/Script Libraries/BridgePlus.scptd/Contents/Frameworks/BridgePlus.framework/Versions/A/BridgePlus (for architecture arm64): Mach-O 64-bit dynamically linked shared library arm64
あれ？ Dialog Toolkit PlusもFramework同梱ライブラリですが、これに含まれていないような、、、、
→ ああ、バンドル内にFrameworksフォルダが存在しているものの、中身はありませんでした（Thanks Shane!）
ものすごくありふれた「レコードをリストに入れたデータ」を高速でソートするために用いているサブルーチン「sortRecListByLabel」がmacOS 11でクラッシュするという情報を得て、調査してみたところたしかに100％クラッシュすることを確認しました。
具体的にどこでクラッシュするとかいえば、NSSortDescriptorでNSArrayを作る箇所、
set sortDesc to NSSortDescriptor's alloc()'s initWithKey:bLabelStr ascending:ascendF set sortDescArray to NSArray's arrayWithObjects:sortDesc--This line cause crash!!!
ここです。
クラッシュを回避するためには、明示的にNSSortDescriptorでNSArrayを作成せず、Scripting Bridge経由で暗黙のlist→NSArray変換が行われるように書き換えること。こうすればクラッシュは発生しませんでした。
→ 訂正：もともとarrayWithObjectsでNSArrayを作る際には末尾にnull（missing value）が必要になるなど、昨今ではあまり使うことが推奨されない（廃止されつつある）やり方でした。NSArray arrayWithArray:などで作ればとくに問題ないことが発覚。よく見ると、ASOC初期の古いコードでそういうやり方をしていたものがあったようです。これまで「たまたま動いていた」というのが真相のようで、、、、（Thanks Shane!）
| AppleScript名：asoc_レコードのリストをソート v3 |
| — Created 2021-06-24 by Takaaki Naganoya — 2021 Piyomaru Software use AppleScript version "2.4" use scripting additions use framework "Foundation" script orig property aList : {} end script set (aList of orig) to {} using terms from scripting additions repeat 100 times –乱数発生にrandom numberをmacOS 11＋M1 Macで呼び出すと遅いので注意 set the end of aList of orig to {labelA:"a", labelB:(random number from 1 to 100)} end repeat end using terms from set bList to sortRecListByLabel((aList of orig), "labelB", false) of me –昇順ソート return bList –リストに入れたレコードを、指定の属性ラベルの値でソート on sortRecListByLabel(aRecList as list, aLabelStr as string, ascendF as boolean) set aArray to current application’s NSArray’s arrayWithArray:aRecList set sortDesc to current application’s NSSortDescriptor’s alloc()’s initWithKey:aLabelStr ascending:ascendF –set sortDescArray to current application’s NSArray’s arrayWithObjects:sortDesc–macOS 11でクラッシュ set sortedArray to aArray’s sortedArrayUsingDescriptors:{sortDesc} set bList to (sortedArray) as anything return bList end sortRecListByLabel |
We actually came quite late to AppleScript. But now we’ve added it to many functions in MacVector – Mainly for batch processing of multiple sequences, or multiple operations on the same sequence. It’s so easy to write! https://t.co/d77jw0AxaY
— MacVector Inc. (@macvector) June 22, 2021
Twitter上の情報により、遺伝子およびタンパク質シーケンス解析用ソフトウェア「MacVector」がAppleScriptに対応したとのこと。
→ MacVectorについての日本語による解説はこちら
→ MacVectorの日本総代理店はセレスバイオサイエンス株式会社です
MacVectorの現行バージョンはv18、macOS 10.12以降およびIntel/Apple Siliconの両対応とのこと。MacVectorのBlog上の「Free Trial」から21日間の試用版をダウンロード可能です。
以前、バージョン13のときにAppleScript用語辞書がついたという話を聞いてチェックしてみたところ……中身が空っぽ（デフォルト命令以外なかった）ということがありましたが、今度はちゃんと入っているとのこと。
▲MacVectorでHIVの遺伝子マップを表示したところ
▲遺伝子のDNA配列情報を編集し、別売（？）のシーケンサー機能を用いてタンパク質の分析もできるもよう
▲Maker:Fairで見かけた、USB接続のシーケンサー。モバイル遺伝子解析ができるとかで、どえらく驚いた覚えがあります（MacVectorで本シーケンサーを操作できるかどうかは未確認。イメージ写真とでも思ってください）
▲Maker:Fairで展示していた方の話だと、遺伝子の分析（シーケンス）と、オンラインでタンパク質合成＋増殖の依頼が行えるとのこと。シーケンサーがUSB接続で10万円ぐらいの値段で（当時）、腰を抜かした覚えがあります
M1 Mac miniで各種AppleScript系のベンチマークをとってみたところ、信じられないほど遅く、「どうやらAppleScriptを高性能コア（Firestorm）ではなく高効率・省電力コア（Icestorm）」で実行しているのでは？ という疑いを持ちました。
＃ 本件はmacOS 12で修正されました
10倍遅いというとショッキングな数値に見えますが、問題はこれが「まだマシな方」の結果であり、トータルで77倍遅い処理があったりと、目を疑いたくなるような結果のオンパレードです。
そんな中、アクティビティモニタの「ウィンドウ」＞「CPUの履歴」で各CPUコアの履歴とともに種別が表示されることが判明。Icestormには「効率性」、Firestormには「パフォーマンス」とコアごとの種別が表示されます。
冗談抜きで、AppleScriptがIcestormで（効率性コア）実行されているようにしか見えません。
M1 Mac＋macOS 11上で各種ベンチマークをとってみたところ、Intel Mac＋macOS 10.14よりも大幅にパフォーマンスが低下する例が頻発。NSMutableArrayに21万項目の項目を追加するベンチマーク（５回計測して平均値を計算）を走らせてみたところ、
MacBook Pro Retina 2012（Intel Core i7 2.6GHz、macOS 10.14.6）：8.69秒
Mac mini M1 2020（M1 3.2GHz、macOS 11.5beta）：104.25秒
M1 MacがIntel Mac（しかも2012年のマシン）の77倍も処理時間がかかるという結果が出ています。このため、AppleScriptをFirestormではなくIcestormで動かしているのではないか、と疑っていました。
とくに、M1ではAppleScriptのrandom number（乱数計算）コマンドが極端に遅く、これを使ってテスト用に乱数データを作ると腰が抜けるほど時間がかかります。シーケンシャル値の続く配列を作ってGamePlaykit.frameworkを用いてシャッフルするのがよさそうです。ただ、本当にM1でrandom number計算は遅くなります。
700箇所の位置情報をもとに、日本全国の最寄りの鉄道駅を計算する距離計算を行なったところ、M1 Mac miniでは2012年製のMacBook Pro Retina 2012の10倍処理時間がかかりました。MBPで6分かかるところがM1だと1時間かかりました。
GUIアプリケーションにちょこちょこ命令するだけとかいう、「単なるマクロ言語」としての世界観（小乗AppleScript）で使う分にはよいのですが、アプリケーションに依存せず単体でデータ処理を行なったり、Mac App Storeで販売するGUIアプリケーションまで記述して実行しているわけで、Icestormで実行してほしくはありません。
Intel Macで６分あまりの処理にM1 Macでは60分以上かかっており、2012年のマシンに比べて2021年製の最新鋭のマシンがまさに文字通り「桁違いの遅さ」を見せているのが現状です。
実行中のアクティビティモニタの表示を見ると、高性能コア（Firestorm）への負荷はあまりかかっておらず、逆に高効率コア（Icestorm）への負荷が集中していることが見て取れます。
Intel Mac上で実行中には、4コア8スレッドのIntel Core i7の各コア（4コア）に均等に負荷がかかっていることが見て取れました。
M1 Mac miniの基本性能の高さはグラフィック性能やディスクI/O性能を中心に実証されているため、あくまでOS側の「味付け」の問題が原因と見ています。
AppleScriptが単なる「GUIアプリケーションをちょこっと自動化するだけのお可愛らしいマクロ言語」なのであれば、Icestormで実行するという話も悪くはないでしょう。ただ、Mac App Storeで販売しているGUIアプリケーションから各種データ処理を行うシビアな処理を行う処理系でもあり、やはり2012年のIntelマシンの10倍とか77倍遅いという現状は面白くはありません。
M1 Mac miniを使ってみて、「なーんかMacBook Pro Retina 2012とかわんねーなー」と感じていましたが、本当にそんな感じでした。
＃ 後日、詳細に検証したところM1 Mac＋macOS 11.xではAppleScriptからのCocoa呼び出しが大幅に遅くなっていることが判明。処理性能重視のメインCPUコアではなく、省エネのサブCPUコアで実行されていることがわかり、これをAppleにレポートしてmacOS 12からはAppleScript＋Cocoa呼び出しの処理速度が大幅に改善されました
Webブラウザの動作とかディスクI/Oなど、キビキビ動いて快適なのですが、AppleScriptを書いて動かしてみると……GUIアプリの操作は速い（Mac mini 2014比で2〜3倍速い）のですが、Cocoa Scriptingしていると速くなった感じがしません。
Xcode上でCocoa AppleScriptアプリケーションを書いて動かしてみると、冒頭のような感想になります。
机の上にマシンが５台ぐらい並んでおり、これらすべてでベンチマークを実施。体感速度を裏付ける結果が出ました。
# MacBook Air 2011のベンチマーク計測が抜けていました、、、、
上から３番目のマシンは仲間からの借り物の検証用マシンで、前主力環境のMacBook Pro Retina 2012とは別物で、HDDで動作しているマシンです。macOS 10.15の動作確認用マシンで、MacBook Pro Retina 2012よりも少しCPUが速いマシンでもあります。
なので、MacBook Pro Retina 2012をmacOS 10.15にアップデートすると、ほぼこれと同じ結果になるはずです（もったいなくてアップデートしませんが）。
macOS 10.14から10.15に移行したときに「全体的に速度が遅くなった」との証言をShane Stanleyからももらっています。
全体的な傾向として、「macOS 10.15で大幅な速度低下があり、その低下分をM1 Macのハードウェアとしての速さが穴埋めしている」という印象。macOS 10.15はBeta段階で「こんなのはダメ、使い物にならない」と判断し、パスして10.14を使い続けるという判断を行なっていました。
搭載メモリはM1 Mac miniとMac mini 2014が16GB、MacBook Pro 2012とMacBook Pro Retina 2012が8GBです。
| AppleScript名：ASで1D Listをソート（１万件） |
| use AppleScript version "2.7" use framework "Foundation" use scripting additions script spd property aList : {} property aRes : {} property bRes : {} end script set (aRes of spd) to {} set (bRes of spd) to {} –テスト用データリストの作成（1万アイテム） set (aList of spd) to {} repeat with i from 1 to 10000 set the end of (aList of spd) to (random number from 10000 to 99999) end repeat –昇順ソートの時間計測 set a1Dat to current application’s NSDate’s timeIntervalSinceReferenceDate() set (aRes of spd) to sort1DList_ascOrder_((aList of spd), true) set b1Dat to current application’s NSDate’s timeIntervalSinceReferenceDate() set c1Dat to b1Dat – a1Dat –降順ソートの時間計測 set a2Dat to current application’s NSDate’s timeIntervalSinceReferenceDate() set (bRes of spd) to sort1DList_ascOrder_((aList of spd), false) set b2Dat to current application’s NSDate’s timeIntervalSinceReferenceDate() set c2Dat to b2Dat – a2Dat return {c1Dat, c2Dat} –1D Listをsort / ascOrderがtrueだと昇順ソート、falseだと降順ソート on sort1DList:theList ascOrder:aBool set aDdesc to current application’s NSSortDescriptor’s sortDescriptorWithKey:"self" ascending:aBool selector:"compare:" set theArray to current application’s NSArray’s arrayWithArray:theList return (theArray’s sortedArrayUsingDescriptors:{aDdesc}) as list end sort1DList:ascOrder: |
M1 Macで、Mac App StoreからインストールしたiOSアプリから、ジャンル情報を取得するAppleScriptです。
iOSアプリケーションでは、Info.plist内にジャンル情報が記載されておらず、バンドル内の別ファイルに記載されています。これを読み取ることで、ジャンル情報を取得できます。
なかなか素敵な機能なのですが、Xcode上のCocoa-AppleScriptアプリケーション内で実行すると、Sandboxの制限によりデータアクセスができません。
▲macOSのFinder上でiOSアプリのバンドル内部を表示させたところ。メタデータが添付されているのがわかる
ただし、Macのアプリケーションのジャンル情報と項目が異なっていたり、相互に存在しないジャンルなどもあるため、そのままMac上でも同様のジャンルであると判定することは避けたほうがよいでしょう。
| AppleScript名：指定のiOSアプリからジャンル情報を取得.scptd |
| — – Created by: Takaaki Naganoya – Created on: 2021/06/20 — – Copyright © 2021 Piyomaru Software, All Rights Reserved — use AppleScript version "2.7" use scripting additions use framework "Foundation" set aFile to POSIX path of (choose file) set gID to getGenreNumFromiOSApp(aFile) of me on getGenreNumFromiOSApp(aPOSIX) set metaDataPOSIX to aPOSIX & "Wrapper/iTunesMetadata.plist" set aRec to retDictFromPlist(metaDataPOSIX) of me if aRec = missing value then return missing value set aGenreID to genre of aRec return aGenreID end getGenreNumFromiOSApp on retDictFromPlist(aPlistPath) set thePath to current application’s NSString’s stringWithString:aPlistPath set thePath to thePath’s stringByExpandingTildeInPath() set theDict to current application’s NSDictionary’s dictionaryWithContentsOfFile:thePath if theDict = missing value then return missing value return theDict as record end retDictFromPlist |
すべてAppleScriptで組んである、アプリケーションのバイナリアーキテクチャ判定ツール「Uni Detector」。
macOS 11上でCPUアーキテクチャのグラフ表示を行おうとするとクラッシュするという現象を横目に、さすがに開発環境として９年落ちのMacBook Pro Retina 2012が辛くなっていたので、M1 Mac miniに入れ替えてソースコードの改修に着手してみました。
まずは、UniversalバイナリでビルドするようにXcode projectを設定。瞬殺。実機確認ができていないだけで、すでにUniversal Binary化については方法を確認してありました。「Check All」でアプリケーション情報を収集する際のパフォーマンスはIntelバイナリをRosetta 2上で実行したときよりは良好でした。
次に、CPUアーキテクチャのグラフ表示を修正。NSStringのstringWithFormat:メソッドを呼び出すと100％クラッシュするというバグをmacOS 11で仕込まれたことが発覚。同じ働きを行う「回避ルーチン」を作成。さっそく、Uni Detectorに組み込んでみました。
Universal Binary化したら、CPUアーキテクチャの移り変わりを表示したグラフ上の実行中のマシンアーキテクチャ表示インジケータの修正もOK。そして、OSバージョン番号の取得を修正して、現在実行中のOSインジケータも修正。
おおよそ、バージョンアップ前のIntel Mac用バイナリと同等の動作を行うレベルになりました。
ただし、全体的に動作が速くなったりはしません。CPUの速度が速くなっていたとしても、OSの内部機能の呼び出しがmacOS 10.15以降で遅くなっているとのこと。並列処理を行いにくいAppleScriptの処理において、M1 Mac上でアホみたいに速度向上することは（本アプリを試しに動かした感じでは）ありません。
M1 Mac各機種において、SSDへのアクセス速度は大幅に向上しているため（MacBook Pro Retina 2012比）、CPU速度の向上と合わせて大幅な速度向上があるはずでしたが、macOS 10.15以降のOS機能呼び出し（Scripting Bridge経由）が遅くなっており、全体として見るとプラスマイナス・ゼロといった印象。逆にmacOS 11＋M1 MacとmacOS 10.14.6＋Intel Macでは後者の方が高速という笑えない状況も見えてきました。
GUIアプリケーションの動作およびそれをAppleScriptから動かすやり方については、だいたい期待どおりの速度が出ている感じです。
＃ その後、macOS 12でAppleScriptの処理速度が回復＆向上したことで、M1 Mac上で大幅に実行速度が向上しました
M1対応、macOS 11対応などを行い、Appleが新たに作ったメーカー謹製のありがたーーいバグを回避したあとで、実際に１ユーザーとして使ってみるといろいろ感じることがあります。
macOS 11＋M1 MacではiOSのアプリケーションをApp Storeからダウンロードでき、実際にiOSアプリケーションが、macOSアプリケーションと一緒に/Applicationsフォルダに入ります。
iOSアプリも、Zip圧縮されたipa形式ではなく、展開された状態でFinderに表示されます。Finder上に並んでいる様子を見るかぎりではMacアプリケーションと違和感がありません。
ひるがえってUniDetector上に表示されるiOSアプリケーションたち。カテゴリ情報がInfo.plist内に書かれていない（メタデータは別管理）ため、空欄になっています。
また、iOSアプリのカテゴリとMacアプリケーションのカテゴリの整合性も調整する必要があります。サポートする最小限のOSの情報などもiOSのものを表示する必要があることでしょう。
→ iOSアプリのジャンル判定を行う処理を書いて、スクリプトエディタ上では動作しているのですが、Xcode上のCocoa-AppleScriptアプリケーションに組み込むと、Sandboxの制限により機能しませんでした。残念！
