Shane StanleyのFramework入りAppleScript LibraryがM1対応

Posted on 6月 28, 2021 by Takaaki Naganoya

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!）

(Visited 110 times, 1 visits today)

macOS 11、NSSortDescriptorでNSArrayを作ると100％クラッシュ

Posted on 6月 25, 2021 by Takaaki Naganoya

ものすごくありふれた「レコードをリストに入れたデータ」を高速でソートするために用いているサブルーチン「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

★Click Here to Open This Script　

(Visited 71 times, 1 visits today)

遺伝子およびタンパク質シーケンス解析用ツール「MacVector」がAppleScriptに対応

Posted on 6月 23, 2021 by Takaaki Naganoya

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万円ぐらいの値段で（当時）、腰を抜かした覚えがあります

(Visited 231 times, 1 visits today)

macOS 11, AppleScriptをFirestormではなくIcestormで実行か？！

Posted on 6月 22, 2021 by Takaaki Naganoya

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倍遅いという現状は面白くはありません。

(Visited 414 times, 2 visits today)

M1 Mac miniのベンチマーク 1万要素の1次元配列ソート

Posted on 6月 21, 2021 by Takaaki Naganoya

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:

★Click Here to Open This Script　

(Visited 116 times, 1 visits today)

指定のiOSアプリからジャンル情報を取得

Posted on 6月 20, 2021 by Takaaki Naganoya

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

★Click Here to Open This Script　

(Visited 59 times, 1 visits today)

Uni DetectorをUniversal Binaryビルドして最新OSで動くように改修

Posted on 6月 19, 2021 by Takaaki Naganoya

すべてAppleScriptで組んである、アプリケーションのバイナリアーキテクチャ判定ツール「Uni Detector」。

macOS 11上でCPUアーキテクチャのグラフ表示を行おうとするとクラッシュするという現象を横目に、さすがに開発環境として９年落ちのMacBook Pro Retina 2012が辛くなっていたので、M1 Mac miniに入れ替えてソースコードの改修に着手してみました。

M1 Native動作ほかOSのバグへの対処など

まずは、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対応の「その次」へ

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の制限により機能しませんでした。残念！

(Visited 101 times, 1 visits today)

Uni DetectorをはじめてM1 Mac実機で起動

Posted on 6月 18, 2021 by Takaaki Naganoya

DTKを使うこともなく、M1 Mac登場を横目にずっとIntel Macを使ってきました。ひとつには、買えなかったからという理由ですが、もう１つがWWDCまで待っていた（新ハードが出たら型落ちになってしまう恐怖）からです。

2020年の10月ごろにチーム内でUni Detectorを「作ろう！」という話になって、いろいろ人に見せたりしていましたが、

日本の開発者コミュニティ：バっカじゃねーの？
日本のユーザー：何のために作ってんのかわかんねー

という散々な反応でした。「なんでそこまで言うのか？」という散々な状況。

リリース後は海外を中心に評価していただき、日本国内で石を投げられることもなくなりました。

Uni Detectorはこの移行期に必要なアプリケーションであり、移行が終わった後でもアプリケーション自体を分析/情報収集できるツールとして便利に使えると思っています。

実機がない状況で作ったので（Intel Mac上にmacOS 11Beta環境は用意していましたが）、「仕様から推測するとこんな感じだろう」「もれ伝わっている情報をもとに作るとこんな感じだろう」と予測して作っていたわけです。

Uni DetectorをM1 Macで起動すると……

起動します。これは、Roesetta 2の機能によるものです。起動自体に時間はかかりません。

すべてのアプリケーションをチェックすべく「All」をクリックすると、「最初の違和感」がやってきます。Intel Mac上で動かすのと挙動がぜんぜん違います。最初のSpotlight経由でアプリケーション情報を集めるのにやたらと時間がかかります。「クラッシュしたか？」と思いながら様子を見ると、あっという間にバーが最後まで伸びて、処理が終わっていました。

Spotlight関連で性能が出ないのか、他の方法で情報収集したほうがいいのか……頭が痛いところです。

失敗した！　という点がひとつ。マシンのCPUアーキテクチャの取得です。

これは、Rosetta上で動くIntelバイナリならおそらく「Intel」と判定されてしまうのでしょう。予想し切れるところではありませんが、違和感しかないので修正すべき点でしょう。

→ 予想どおり、Universal（Apple Silicon/Intel 64）ビルドを行ったら、マシンがApple Silicon Macだと認識されました。

事前に予測できなかった点がもうひとつ。OSバージョンの割り振り方です。macOS 10.15の次のmacOS 11シリーズのバージョン番号の振り方が事前にわかりませんでした。最初のバージョンが「11.0」と割り振られたので、その次が「11.1」のパターンと「11.0.1」のパターンの２通りが考えられたわけです。実際には前者でしたが、後者と予想していたので、当てが外れて「現在実行中のOSバージョン」をもとにマークを出す処理に失敗しています。

if aVerStr = "1013" then imgOS13's setHidden:false
if aVerStr = "1014" then imgOS14's setHidden:false
if aVerStr = "1015" then imgOS15's setHidden:false
if (aVerStr = "11") or (aVerStr = "1016") then imgOS16's setHidden:false
if (aVerStr = "12") or (aVerStr = "1017") then imgOS17's setHidden:false
if (aVerStr = "13") or (aVerStr = "1018") then imgOS18's setHidden:false

このあたり、macOS 11以上であればメジャーバージョンのみ返すようにライブラリを書き換え、かつ、Appleがバグを作ってOSバージョンを「10.16」などと返してきても大丈夫なように備えておきました（すごくありがち）。

これで、実行中のマシンのバージョンインジケータについては大丈夫です。

これは「よかった」点ですが、macOS上でiPhone用のアプリが動くことが告知されていたので、どのプラットフォーム向けに作られたアプリかを表示するようにしてあり、これは先見の明がありました（自画自賛）。

とってもやられた、という点もあります。

CPUアーキテクチャ別の円グラフを表示する機能があり、Intel MacでmacOS 10.14/10.15で動かす分には問題なく表示されるのですが、macOS 11のRelease版だとアプリケーションごとクラッシュします。macOS 11の問題（Apple側の問題）だと思いますが、Appleはそういうことをやる会社であり、Appleのせいでこういうトラブルが起こることは日常茶飯事です。たぶん、ソート周りでクラッシュを起こしているんだと思います（ていねいに、グラフ表示する前にソートルーチンで数字の大きい順にデータを並べ替えているので）。

→ クラッシュの原因がわかりました。NSStringのstringWithFormat:メソッドがIntel MacでもApple Silicon MacでもAppleScriptから呼ぶと100%クラッシュします。こんな基礎的なところでバグ作ってどーするんだか、、、（ーー；；

(Visited 55 times, 1 visits today)

macOS 11でメニューバークロックのアナログ/デジタル切り替え

Posted on 6月 17, 2021 by Takaaki Naganoya

macOS 11は、サブマシンで検証用に入れておいたぐらいでメインマシンはずーっとmacOS 10.14.6のままでした。M1 Macを導入したのでメイン環境をmacOS 11に移行。

いままで（macOS 10.14.6で）メニューから手軽に切り替えられていたメニューバークロックのアナログ/デジタル切り替え。ふだんは見やすいデジタル表示で、画面キャプチャする際にはアナログ表示に切り替えていました。

これが、macOS 11ではメニューから直接切り替えられないのがストレスで、すぐに切り替え方を調べてmacOS標準搭載のスクリプトメニューから切り替えられるようにしてみました。現在の設定値を読み取ってトグル動作（アナログ→デジタル、デジタル→アナログ）を行います。

–> Watch Demo movie

AppleScript名：macOS 11_メニューバークロックのアナログ_デジタルトグル切り替え.scpt

—
–　　Created by: Takaaki Naganoya
–　　Created on: 2021/06/17
—
–　　Copyright © 2021 Piyomaru Software, All Rights Reserved
—

use AppleScript version "2.7"
use framework "Foundation"
use scripting additions

set cRes to (do shell script "defaults read com.apple.menuextra.clock.plist IsAnalog") as integer as boolean
set newBool to (not cRes) as string
do shell script "defaults write com.apple.menuextra.clock.plist IsAnalog -bool " & newBool
do shell script "killall ControlCenter"

★Click Here to Open This Script　

(Visited 75 times, 1 visits today)

Hello M1

Posted on 6月 15, 2021 by Takaaki Naganoya

到着してとりあえずのセットアップを行ったM1 Mac mini。とりあえず、ごあいさつの「system info」コマンドの実行。

--> {AppleScript version:"2.7", AppleScript Studio version:"1.5.3", system version:"11.3.1", short user name:"testuser", long user name:"Takaaki Naganoya", user ID:501, user locale:"ja_JP", home directory:alias "Macintosh HD:Users:test1:", boot volume:"Macintosh HD:", computer name:"M1 mini", host name:"m1mini.local", IPv4 address:"192.168.x.xx", primary Ethernet address:"xx:xx:xx:xx:xx:xx", CPU type:"ARM64E", CPU speed:missing value, physical memory:16384}

「ARM64E」と返ってきました。へーー、CPU Typeはそんなかんじなんだ、へー。

CPU Speed、クロックのことですが……missing valueが返ってくるというのは、従来のAPIでは値を取れなくなったのでそのままです、ということなんでしょうか。

(Visited 49 times, 1 visits today)

M1 Mac mini

Posted on 6月 12, 2021 by Takaaki Naganoya

を注文しました。WWDC21でハードウェア系の発表が行われなかったということは、少なくとも2021年中に現行のM1 Mac以上のマシンを投入できないものと判断したためです。

さすがにMacBook Pro Retina 2012では物理的にも性能的にも無理があり、メインマシンとして入れ替えることになります。まだ「上海を出た」ぐらいの距離感です。

RAM 16GB、SSD 1TB構成です。RAM 8GB構成だと割と整備済製品や店頭販売品があるのですが、さすがに8GBはないだろうと。RAM 8GB構成だとSSDのSwapが激しいとのことなので避けてみましたが……実際に動かしてみないとなんとも言えません。

SSD 256GBでは「悪い冗談」、SSD 512GBだと「いまと同じ」、SSD 1TBぐらいが実用上の最低ラインだと判断しました。ポート数が少ないので、ディスプレイ以外で接続しておく周辺機器は最低限のものにとどめておくべきマシンでしょう。

YouTubeをはじめとして各種ベンチマークが掲載されていますが、正直なところムービー書き出しとかゲームやベンチマーク専用ソフトの結果ばかりで、実際に一般的なアプリケーションを動かして、アプリケーションをAppleScriptから操作してゴリゴリにコキ使ったときのパフォーマンスはどこにも載っていません。

Script Debuggerで巨大なScriptを編集すると、文字入力が止まるぐらい遅くなるので、Script Debuggerの操作が軽くなることを期待したいです。

以前に開発用にiMac Proを一時的に預かっていたときにすこしだけ自作ベンチマークをとってみましたが、あれよりも突っ込んだ内容は実験できることでしょう。iMac Proはいいマシンでしたが、（MBPR 2012よりも）３〜４倍ぐらい高価なiMac Proでも1.5倍ぐらいのシングルコア性能で、コストパフォーマンス的にはいまひとつでした。つまり、高い割にたいしたことがない、という印象。

M1 Mac miniにはとても期待しています。

M1 Macでベンチマークをとってみたい処理

・巨大な配列を使う処理
与えられた文字列の1D Listのすべての順列組み合わせパターン文字列を返す v3
→ これは、M1 Mac上でとくに遅い処理で、心底ガッカリしました。この挙動は問題ありすぎなので、Appleに報告して対処してもらえるよう「お願い」をしています

２点間の距離を求める v3
→ 全国のゲームセンターの最寄りの鉄道の駅を求める
→ 2012年のMacBook Proのほうが10倍速いです
・画像処理
画像の空白判定 v4
→ これは、2012年のMacBook Proより高速でした

画面スナップショット超解像バッチ処理 v1
→ M1内蔵のニューラルエンジンを利用しているためか、これはM1 Macが圧倒的に高速です
２つの画像が類似しているかを判定

ghostscriptによるPDFの圧縮・軽量化処理
→ MBP 2012で数分から10分ぐらいかかっていた処理が、１分ぐらいで終わるので速いと思います。ただし、瞬時に終わるとかいうことはありません

・アプリケーションとのやりとりが膨大で重い処理
Mail.appでメールボックスの仕分けを行う（最重量）
→ これは、Intel Macとさほど変わりません。ただ、Mail.appの起動がアホみたいに速い（起動してから操作可能になるまでのタイムラグがほとんどない）ので、その点だけでもM1のトータルなシステムとしての速さを実感できます
CotEditorのウィンドウを楕円運動
→ M1のほうが少し速いか？　ぐらいで、全般的にこの手のScriptはMBP2012の10倍遅いことを覚悟する必要があります
・AppleScriptで組んだGUIアプリケーションの動作
Kamenoko
→ ±ゼロぐらい。しばらく動かしていると動作が止まる瞬間があって、強制終了させたりしています
・重いアプリケーションの動作
巨大なScriptをScript Debuggerでオープンして編集したときの動作
→ Intel Macに比べて速い、ということは感じません。この用途でいえばiMac Proの方が快適かも？

(Visited 63 times, 1 visits today)

STREAM DECKソフトウェアがv5.0にアップデート

Posted on 6月 9, 2021 by Takaaki Naganoya

STREAM DECK制御ソフトウェアがv5.0にアップデートしました。

プラグインのストアが大幅にアップデートしました。

STREAM DECK本の作成のために行なっていた、画面のキャプチャをやり直す必要が出てきてしまいました（泣）。著作権フリーなBGM集とSFX集をStoreからダウンロードできるようになるなど、製品の性格自体が大きく変わるアップデートだと思います。

(Visited 404 times, 1 visits today)

Shortcuts Events

Posted on 6月 9, 2021 by Takaaki Naganoya

macOS 12で搭載される「ショートカット」は、iOS上の自動化ツール「DeskConnect」をAppleが買収して発展させ、Apple純正ソフトウェアとして提供されているものです。簡単な自動化を行うためのツールです。

このショートカットがmacOS 12に搭載されることがKeynoteで発表されました。さらに、ショートカットからAppleScriptが実行できることが明らかにされ、AppleScriptからもショートカットを実行できるとのこと。

タイトルにも挙げている「Shortcuts Events」が、AppleScript専用のGUIなし補助アプリケーションであり、AppleScript側からショートカットのアクションを呼び出すことができるようです。

ただし、最初のmacOS 12β版ではまだAppleScriptからショートカットのアクションを実行できないことが、Release NotesのKnown Issuesに明記されています。

	10.4	10.5	10.6	10.7	10.8	10.9	10.10	10.11	10.12	10.13	10.14	10.15	11.0	12.0
Shortcuts Events														⬛︎
ColorSyncScripting	⬛︎	⬛︎
Database Events	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎
Digital Hub Scripting	⬛︎	⬛︎
FontSync Scripting	⬛︎	⬛︎
Image Events	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	★	★	★
Keychain Scripting	⬛︎	⬛︎	⬛︎
System Events	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎
URL Access Scripting	⬛︎	⬛︎	⬛︎

(Visited 94 times, 1 visits today)

Apple Musicでロスレス配信開始（今度こそ）！

Posted on 6月 8, 2021 by Takaaki Naganoya

macOS 11上のMusic.appの環境設定に突如として、「オーディオの品質」項目が出現。時間が経過するにつれ、kindが「Apple Music AACファイル」だった曲が次第に「HLSメディア」に更新されていきました。

このApple Musicのロスレス配信トラックを再生できるのは、macOS 11.4以降であり、それ以前のmacOSではAAC配信のままです。

段階的に入れ替えられていたり、対応曲と非対応曲があるようで、すべての曲が「HLSメディア」として見えるわけではないようです。自分が試した中でも、「HLSメディア」は１曲だけでした。→ 時間の経過にともない、どんどん増えてきています

これをダウンロードすると、拡張子が「.movpkg」のファイルがローカルにダウンロードされてきました。

バンドルパッケージだったので、Finder上でバンドル内容を表示。

複数のフォーマットのムービーを１つのバンドル（HLSメディア）内に格納できるようです。

覚悟はしていましたが、ハイレゾロスレス（最大24ビット/192kHzのALAC）の１トラックで87.7MBもあり、いちいちダウンロードしているとローカルのディスクの空き容量がヤバいことになります。

(Visited 1,475 times, 1 visits today)

WWDC21でShortcuts for Macが発表に

Posted on 6月 8, 2021 by Takaaki Naganoya

WWDC21にて、macOS 12にShortcuts for Macが搭載されることが発表されました。同ツールはAutomatorを置き換え、iPhoneやiPad上のShortcutsとは異なるクリエイティブ系に寄せたアクションが実行できるとのこと。

Shortcuts内からもAppleScriptやShell Scriptを呼び出せるようになっており、Mac上でSiriからShortcutsの呼び出しが行える＝「Siriから（ShortcutsのAction上に記載した）AppleScriptが実行できるようになった」ことを意味しています。

Automatorの今後については、すでにAppleScript Studioランタイムがdeprecated扱いで、機能の追加は行われません。Xcode上に添付されているAutomator Acrtionのテンプレートも、すでにAppleScript Studioではなく「Cocoa AppleScript」（AppleScriptObjC）です。

(Visited 78 times, 1 visits today)

WWDC21事前予想→答え合わせ

Posted on 6月 8, 2021 by Takaaki Naganoya

今日は真夜中じゅう起きているわけにはいかないので、事前の予想をまとめたものを貼っておきます。あとでゆっくり、答え合わせを。

Apple SiliconのCore数増加、メモリ拡張バージョンが出てくるかもしれませんが、それをどのように実現するのかがキーポイントになると思います。cc:NUMAなどの技術を用いて複数コアをつなぐのか？　そこと、macOS 12.0がもっと安定したバージョンとして位置づけられるのか。そんなあたりが自分の関心事。あと、Mac miniの上位版が本当に出るのかどうか…

答え合わせ

前年（2020）が数年がかりで仕込んだネタを一斉に披露したことと比べると小ぶりな発表内容。
ハードウェア系の発表はありませんでした
Apple Musicのロスレス配信の開始にはまだ時間がかかるようです（秋？）
macOS 12, Montereyを発表。AirPlay to MacやShortcutが搭載される
Xcode 13発表。ちゃんとAppleScriptObjCでの開発をサポート。

機械学習モデルを手軽に作れるCreate MLは、v3.0にアップデートしてHand Post ClassificationとHand Gesture Classificationを追加

(Visited 39 times, 1 visits today)

経過時間文字列を秒数に変換する

Posted on 6月 7, 2021 by Takaaki Naganoya

Safariで表示中のダウンロード残り時間の文字列を数値に変換するために作成したAppleScriptです。

Safariで実行中のダウンロード残り時間の一覧情報を表インタフェースで表示する、ごくごく私的な用途のAppleScriptを書いていたときに必要になったものです。

Safariのダウンロード情報表示は、最近のバージョンではポップオーバーで行われるようになっています。そのポップオーバーの上に表インタフェースが配置されていて、その中の各行の中にあるUI Elementを追いかけるとダウンロード残り時間情報などが取得できます。

▲GUI Scriptingに欠かせない。PFiddlesoftのUI Browser。使わないのと使うのとでは、生産性が１億倍ぐらい違うツール

ただし、得られた「残り時間」の文字列をいったんdateオブジェクトに変換して、経過秒数を計算するのに少々骨が折れました。Safariのダウンロード一覧に表示される文字列はあくまでも「結果表示」で、0分とか0時間とか0秒といった桁は表示が省略されます。

当初、「HH時間mm分ss秒」という固定フォーマットだと勝手に思い込んで処理していました。ところが、各桁が省略されるパターンに遭遇。固定文字列でフォーマット指定をして評価しようとしても、いろいろと無理がありました。自然言語っぽい表記で経過時間の情報を与えられたときに、それを評価してdateオブジェクトに変換するのはけっこうな手間がかかります。

「時」「分」「秒」の各情報が存在するかどうかチェックし、各パターンに合わせた日付フォーマッター文字列を場合分けで書いてみたものの、前述のとおり途中の桁が省略されるパターンに遭遇。３つの桁情報の有無に対応するだけでも、3x2x1＝６パターンに対応するif文が必要。さらに、「年」「月」「日」まで表示される可能性を考慮すると、桁要素が6個になるため、6x5x4x3x2x1＝720パターンに対処するif文が必要に。この、if文で固定フォーマット文字列を場合分けで選択するというアプローチでは処理が破綻することがあきらかです（if文をそんなに書いたら見通しが悪くなって、矛盾した表記が混入してもわからないでしょう。そこはかとなく、頭が悪い感じもします）。

そこで、与えられた経過時間文字列を直接チェックして、「経過時間文字列に合うように」NSDateFormatter用の文字列を「動的に」組み立てるように方針を転換。これで、大幅に簡潔な記述で済むようになりました。

一番の誤算は、AppleScript上でNSDateのtimeIntervalSinceReferenceDate()の結果が正しく取得できなかったこと。このメソッドで2000年1月1日からの相対秒を取得するつもりだったのですが、期待したような結果は得られませんでした。そのため、2000年1月1日のdateオブジェクトを用意して引き算で経過秒数を求めました。このあたり、AFS（Apple File System）導入時にタイムスタンプの分解能が増やされたことに影響を受けているのだろうかと疑っています。

用途が果てしなく下らない割にてこずらされました。

AppleScript名：時分秒の文字列を数値に変換 v5

— Created 2021-06-06 by Takaaki Naganoya
— 2021 Piyomaru Software
use AppleScript version "2.4"
use scripting additions
use framework "Foundation"

set relSecNum to relativeSecondsFromStringWithDateFormat("22時間 21分 15秒") of me
–> 80475

set relSecNum to relativeSecondsFromStringWithDateFormat("22時間 15秒") of me
–> 79215

set relSecNum to relativeSecondsFromStringWithDateFormat("22時間") of me
–> 79200

on relativeSecondsFromStringWithDateFormat(postDateStr as string)
　　set sepList to {"年", "月", "日", "時間", "分", "秒"}
　　set formList to {"yyyy", "MM", "dd", "HH", "mm", "ss"}
　　
　　set formatStr to ""
　　repeat with i from 1 to 6
　　　　set aSepStr to contents of item i of sepList
　　　　set aFormStr to contents of item i of formList
　　　　if postDateStr contains aSepStr then
　　　　　　set formatStr to formatStr & (aFormStr) & (aSepStr)
　　　　end if
　　end repeat
　　
　　set postDate to dateFromStringWithDateFormat(postDateStr, formatStr) of me
　　
　　set origDate to dateFromStringWithDateFormat("0時間 0分 0秒", "HH時間mm分ss秒") of me
　　set aSeconds to postDate – origDate
　　return aSeconds
end relativeSecondsFromStringWithDateFormat

on dateFromStringWithDateFormat(dateString as string, dateFormat as string)
　　set dStr to current application’s NSString’s stringWithString:dateString
　　set dateFormatStr to current application’s NSString’s stringWithString:dateFormat
　　set aDateFormatter to current application’s NSDateFormatter’s alloc()’s init()
　　aDateFormatter’s setDateFormat:dateFormatStr
　　aDateFormatter’s setLocale:(current application’s NSLocale’s alloc()’s initWithLocaleIdentifier:"en_US_POSIX")
　　set aDestDate to (aDateFormatter’s dateFromString:dStr)
　　return aDestDate as date
end dateFromStringWithDateFormat

★Click Here to Open This Script　

(Visited 184 times, 1 visits today)

新旧エミュレータでAppleScript実行速度対決

Posted on 6月 6, 2021 by Takaaki Naganoya

JavaScriptで書かれた68k Macエミュレータの新規軸「macitosh.js」が登場してきたので、SheepShaverと対決させてみました。

macintosh.js–Classic Mac OS 8 on Mac mini 2014 2.6GHz Intel Core i5 macOS 11.5
SheepShaver–Classic Mac OS 9.2 on MacBook Air mid 2011 1.6GHz Intel Core i5 macOS 10.13.6

それぞれ、Mactracker上に記載のあるGeekbenchのベンチマーク値は以下のとおりです。

ベンチマーク対決内容はAppleScriptで1,000万回単純ループを行うものです。

結果：macintosh.js 191秒

結果：sheepshaver 10秒

古いSheepShaverのほうが新しく作られたmacintosh.jsよりも20倍ぐらい高速、という結果が出ました。だからダメということはなく、JavaScriptなどという処理系でここまでネイティブコードに肉薄したということに驚きます。

シングルコア性能でMac mini 2014のほうが倍ぐらい速いのですが、さすがにネイティブコードでエミュレータを動かしているだけあって、MacBook Airのほうが10倍ぐらい高速です。同一マシンでベンチマークしたらsheepshaverのほうが20倍ぐらい高速でしょう。

macintosh.jsにはM1対応版（っていうのか？）もあり、M1 Mac miniで動作させればMac mini 2014の３倍ぐらい高速ですが、それでもMacBook Air上で動かしたsheepshaverのほうが３倍高速ということになります（多分）。

ちなみに、現代のIntel Mac（およびARM Mac）で1,000万回程度の単純ループを普通にAppleScriptで実行させると、速すぎて１秒以下になってしまい計測不能。1億回ぐらい回さないと１秒以下です（10億回ぐらい回さないとダメかも）。PowerPCの時代には1,000万回単純ループが計測の（個人的な）指標になっていました。

▲M1 Mac mini+Macintosh.jsで実行したら68秒。だいたい予想どおり

▲M1 Mac mini+SheepShaver（Universal Binary）で実行したら10秒。MacBook Air 2011＋SheepShaverと同じ結果に

(Visited 159 times, 1 visits today)

2021年6月からApple Musicがロスレス配信！

Posted on 6月 3, 2021 by Takaaki Naganoya

……と言われてはや数日。Twitter上では「おお、これが空間オーディオ対応か？！」「音がよくなった！」といった一部の方々の熱狂がありつつも、実際に、Apple MusicからMacのMusic.appに曲を追加し、AppleScriptでファイルフォーマットやCodecなどを確認すると、それが「錯覚」であることがすぐにわかります。

まだ、AACで配信されており、ロスレスコーデックで配信されてはいません。