Menu

Skip to content
AppleScriptの穴
  • Home
  • Products
  • Books
  • Docs
  • Events
  • Forum
  • About This Blog
  • License
  • 仕事依頼

AppleScriptの穴

Useful & Practical AppleScript archive. Click '★Click Here to Open This Script' Link to download each AppleScript

カテゴリー: Bug

Pages v12に謎のバグ。書類上に11枚しか画像を配置できない→解決

Posted on 5月 23 by Takaaki Naganoya

Pages v12に謎のバグを見つけました。Pagesでは書類上に任意の画像を配置できるわけですが、11枚目までは配置できるものの、12枚目を配置できません。実際には120枚ほど画像を用意してテストしていたので、12枚目が配置できればそれでOKかと言われれば、ぜんぜん不十分です。

→ OSの再起動を含む、追試を何回か行ってみたところ、その後このままでは画像の貼り込みができなくなっていました。そして、画像ファイル貼り込み前にパスの文字列をaliasにcastしたところ、問題なく120枚貼り込めました。

–> Watch Movie

以前にも、Keynoteに「特定サイズ以上の表を作るとエラーになる」とかいったバグが発生していましたが、この12個目を配置するとエラーになるというのも、内部で何か不可思議なリミッターを設けているように見えます。

スクリプトエディタ、Script Debuggerの両方で発生しています。おそらく、ランタイム環境が何であるかはこの問題に影響を与えていません。

macOS 10.12以降で、日本語環境限定で発生しているバグで有名なものに、「日本語入力Input Method経由でファイル名を入力している最中に、不必要な不可視文字が入力されてしまい、これがファイル処理を妨げる危険性がある」というものがありますが、これらの画像のファイル名をチェックしたところ、そうした危険な不可視文字は混入していませんでした。

# こうした、複数チームの担当製品の間で発生しているバグは、どこが担当してバグを調査するということはないようです。組織の細分化にともない、こうした組織境界面でバグが発生するととたんに無責任になるのがいまのAppleです(組織の構造上の問題です)

ちなみに、GUI経由で画像をPages書類上に配置してみたところ、12枚以上配置できました。Pagesにそのような上限が存在しているわけではないようです。

Pages書類(バンドル書類)内で何かファイル名の重複のようなものが発生したのかと考え、別の画像を(番号をずらして)指定してみましたが、同様の枚数を配置した時点でエラーになりました。

内部で発生している(していた)別のエラーを発生させないように、謎のリミッターをかけていた可能性もありますが、その必然性がよくわかりません。

AppleScript名:指定の画像をPagesに順次貼り込む(12枚で止まってしまう!).scpt
set baseName to "book24_"
set baseFol to (choose folder) as string

set pMax to 10

(*
tell application "Pages"
  –set newDoc to make new document
  
  tell front document
    set dCount to count every page
    
    repeat with i from (dCount + 1) to pMax
      make new page
    end repeat
    
    set newDCount to count every page
  end tell
end tell
*)

repeat with i from 1 to 120
  set aFN to baseFol & baseName & makeFN(i, 4) of me & ".jpg"
  
tell application "Pages"
    tell front document
      tell page i
        set newItem to make new image with properties {file:aFN}
        
tell newItem
          set position of it to {0, 0}
          
set height of it to 843
          
–set position of it to {-1, 0}
          
set locked to true
        end tell
      end tell
    end tell
  end tell
end repeat

on makeFN(aNum, aDigit)
  set aText to "00000000000" & (aNum as text)
  
set aLen to length of aText
  
set aRes to text (aLen – aDigit + 1) thru -1 of aText
  
return aRes
end makeFN

★Click Here to Open This Script 

(Visited 11 times, 1 visits today)
Posted in Bug news | Tagged 10.15savvy 11.0savvy 12.0savvy Pages | Leave a comment

iWorkアプリケーションv12に共通のバグ? 新規ファイルの保存ができない

Posted on 5月 23 by Takaaki Naganoya

Apple iWorkアプリケーション(Keynote、Pages、Numbers)の最新バージョンv12.0において、共通のバグがあるのではないか? と見ています。もちろん、見ているだけでなくAppleにバグレポートもしています。

症状は、新規作成した書類を「保存できない」というものです。

以前にも、PDFをexportできないという致命的なバグが発生していましたが、今回のも同様のメカニズムで発生しているものと見ています。つまり、「Appleが自社OSに設定したセキュリティ機能によって、自社アプリであるKeynote、Pages、Numbersが自家中毒を起こしている」という状態です。

自分の勘違いだとよいのですが….

あとは、Numbersのsaveコマンドをよく見てみると、書類フォーマットに「as Numbers」というenumがあるのですが、これはAppleScriptの処理系では「number」の複数形として認識されてしまうので、この予約語自体に無理があります。ここは、「as Numbers format」といった予約語に変えるべきです。

AppleScript名:Keynoteで新規書類作成して指定名称で新規保存.scpt
set dtPath to (path to documents folder) as string
set uuidStr to (do shell script "uuidgen") & ".key"
set savePath to dtPath & uuidStr

tell application "Keynote"
  set nDoc to make new document with properties {document theme:theme id "Application/21_BasicWhite/Standard", width:1024, height:768}
  
save nDoc in file savePath as Keynote
end tell

★Click Here to Open This Script 

AppleScript名:Pagesで新規書類を作成して指定名称で新規保存.scpt
set dtPath to (path to documents folder) as string
set uuidStr to (do shell script "uuidgen") & ".pages"
set savePath to dtPath & uuidStr

tell application "Pages"
  set nDoc to make new document with properties {document template:template id "Application/Blank/ISO"}
  
save nDoc in file savePath as Pages Format
end tell

★Click Here to Open This Script 

AppleScript名:Numbersで新規書類作成して指定名称で新規保存.scpt
set dtPath to (path to documents folder) as string
set uuidStr to (do shell script "uuidgen") & ".numbers"
set savePath to dtPath & uuidStr

tell application "Numbers"
  set nDoc to make new document
  
save nDoc in file savePath as numbers –change "Numbers" word into "numbers format" because "numbers" is alredy registered as "list of number" or "every number"
end tell

★Click Here to Open This Script 

(Visited 8 times, 1 visits today)
Posted in Bug news | Tagged 10.15savvy 11.0savvy 12.0savvy Keynote Numbers Pages | Leave a comment

macOS 12.4beta1で「GUIなしツールから起動したAppleScriptでUTIを取得できない」バグ?

Posted on 4月 18 by Takaaki Naganoya

スクリプトメニューやService Stationなど、「メニューやウィンドウを持たないGUIなしツール」がたくさんmacOS環境にありますが、macOS 12.4上ではこれらのAppleScript起動ツールから起動したAppleScriptから、UniformtypeIdentifiers.frameworkを用いたUTIの取得をブロックされているようです。

スクリプトメニューで実行を確認した(途中までで実行がブロックされてしまった)AppleScriptを、スクリプトエディタ上で実行したところ、問題なく実行されます。ちなみに、内容は選択した画像ファイルをPixelmator Proで超解像処理してクリップボードに設定する(コピーする)という「おかわいらしい」内容のものです。

Service Stationは、コンテクストメニューからのAppleScript実行を可能にするAppleScript実行ツールですが、これについてもしかるべきハンドラを書いて同じAppleScriptを実行させるようにしてみたものの、UTIの取得をブロックされるようです。

→ 追試で、Terminal.app上からosascript経由で実行してみたところ、UniformtypeIdentifiers.frameworkの呼び出しに失敗することが判明

明示的にMain threadで実行しないとダメ???>UniformtypeIdentifiers.framework

AppleScript名:🟧選択中の画像を超解像💝処理してコピー.scpt
—
–  Created by: Takaaki Naganoya
–  Created on: 2021/03/25
—
–  Copyright © 2021 Piyomaru Software, All Rights Reserved
—

use AppleScript version "2.8" — Yosemite (10.10) or later
use framework "Foundation"
use framework "UniformtypeIdentifiers"
use scripting additions

property |NSURL| : a reference to current application’s |NSURL|
property NSArray : a reference to current application’s NSArray
property NSPredicate : a reference to current application’s NSPredicate
property NSURLTypeIdentifierKey : a reference to current application’s NSURLTypeIdentifierKey

set acceptUTI to "public.image"

set aFile to choose file
(*
tell application "Finder"
  set aFile to first item of (selection as alias list)
end tell
*)

–set aUTI to getUTIFromFile(aFile) of me –選択ファイルからUTIを
–display dialog aUTI
–if aUTI is equal to missing value then return

–set uRes to filterUTIList({aUTI}, acceptUTI) of me –選択ファイルのUTIが、受付可能UTIに含まれるかどうかチェック
–if uRes is equal to {} then return –選択したファイルが画像ではなかった

–掃除
tell application "Pixelmator Pro" to close every document without saving

–取得した画像を超解像処理してコピー
tell application "Pixelmator Pro"
  try
    open aFile
  on error
    close every document without saving
    
return
  end try
  
  
tell front document
    with timeout of 3000 seconds
      super resolution
    end timeout
  end tell
end tell

tell application "Pixelmator Pro"
  tell front document
    select all
    
copy
    
close without saving
  end tell
end tell

on getUTIFromFile(aFile)
  set aPath to POSIX path of aFile
  
  
set aWS to current application’s NSWorkspace’s sharedWorkspace()
  
set pRes to (aWS’s isFilePackageAtPath:aPath) as boolean
  
if pRes = false then
    set superType to (current application’s UTTypeData)
  else
    set superType to (current application’s UTTypePackage)
  end if
  
  
set pathString to current application’s NSString’s stringWithString:aPath
  
set aExt to (pathString’s pathExtension()) as string
  
  
set aUTType to current application’s UTType’s typeWithFilenameExtension:aExt conformingToType:(superType)
  
  
set aUTIstr to aUTType’s identifier() as string
  
return aUTIstr
end getUTIFromFile

–UTIリストが指定UTIに含まれているかどうか演算を行う
on filterUTIList(aUTIList, aUTIstr)
  set anArray to NSArray’s arrayWithArray:aUTIList
  
set aPred to NSPredicate’s predicateWithFormat_("SELF UTI-CONFORMS-TO %@", aUTIstr)
  
set bRes to (anArray’s filteredArrayUsingPredicate:aPred) as list
  
return bRes
end filterUTIList

★Click Here to Open This Script 

(Visited 23 times, 1 visits today)
Posted in Bug news UTI | Tagged 12.0savvy Pixelmator Pro Service Station | Leave a comment

macOS 12.3上でFinder上で選択中のファイルをそのままオープンできない件

Posted on 3月 28 by Takaaki Naganoya

macOS 12.xはAppleScriptの処理系に対して、主にセキュリティ面でいろいろ修正が加わっています。

この修正は、セキュリテイを「高める」という名目のもとに行われているのですが、セキュリティ面での課題さえ片付けられれば、その他に悪影響を及ぼしていたとしても「知ったことではない」というのがAppleの態度です。そして、その問題に対してユーザー側から文句が出てこなければ、そのままです。

–> View Demo Movie

とくに、深謀遠慮な考えとか、素晴らしい見通しとかはなく、「上から言われたからやっている」というやっつけ仕事感を感じます。

AppleはSteve Jobsが作り上げた秘密警察みたいな組織になっていて、チーム間の権限の切り分けが病的なまでに行われており、チームが違うと会社が違うぐらいの隔たりが発生しています。それは、Steve Jobsという「垣根を無視して横断して歩く異物」がいたから成立する組織であって、官僚化、硬直化が絶賛進行中といったところです。

話を戻しますが….たしかに、そうした機能的なアップを伴わない修正で何も問題(副作用)が起こらなければ「セキュリティが高まったのでよかったね」という美談になるわけですが、たいていの場合にはそうなりません。意図していなかった箇所に副作用が生じます。

あるいは、セキュリティのポリシー同士が実は矛盾を生んでいる、という状況になっていて、Aという問題とBという問題を解決した結果、あらたにCというもっと巨大な問題が発生する、とかいった状況は容易にあり得るわけです。それでも、各担当者は誠意をもってその仕事に取り組んでいるわけで、こうした「人間的に尊敬できて素晴らしい能力を持ったスタッフ」による「熱心かつ誠意あふれる真摯な仕事」が合成された結果、「見たことも聞いたこともない間抜けな理由から生じる猛毒にまみれた悪意」が合成されてしまうことが、現在のTim CookのAppleの下ではあり得るのです。

「Finder上で選択中のファイルをそのままオープンする」

というのは、ここ数年というよりもAppleScriptを覚えたてのころにちょろっと書いて実行したぐらいであり、実際のところ「それがどうした?」というレベルの処理です。

AppleScript名:Finder上で選択中のファイルをオープン.scpt
–macOS 12.3でエラーになる処理
tell application "Finder"
  open selection
end tell

★Click Here to Open This Script 

Finder上で選択したファイルに対する処理は、きょうび何かのアプリケーションに渡さなくてもAppleScriptだけで処理できてしまうことが多いということもありますし(画像とか)、選択されたファイルをそのままオープンするという「1=1」みたいな処理はやりません。

選択したフォルダの中をすべてSpotlight経由で走査して、指定の形式のファイルだけをリストアップして、順次処理するようなものになっています。

ただ、10年たっても20年たっても「1=1」みたいな処理しかしていない人がけっこういて驚かされると同時に、意外なところで(Adobeのアプリケーションでアプリケーション間の連携に)使っていたりして、修正されないと困るケースは多いようです。

Shane StanleyがLateNight Softwareのフォーラムに投稿した、こうした処理への迂回Scriptがありました。さすがです。

Finder経由で書類のオープンと、その書類を作成したアプリケーションの起動を促すという、macOS 12.3で問題が起こっている処理を、Cocoaの機能を用いることで迂回してしまおうというものです。

ただ、そのままではFinder上で指定したファイルを1つオープンするという実証コードのレベルのものだったので、複数のファイルが選択されたものをオープンするように書き足してみました。

AppleScript名:macOS 12.3でFinder上の選択中のファイルをオープン.scpt
—
–  Created by: Shane Stanley
–  Created on: 2022/03/24

–  Modified by: Takaaki Naganoya
–  Modified on: 2022/03/27
—
— macOS 12.3でFinder上のselectionをただopenすると、作成したアプリケーションは起動するが、書類はオープンされないバグ
– に対処したもの。複数ファイルの選択状態を処理する場合がほとんどなので、若干追記
– ただ、漫然と選択したファイルをオープンするという処理はやっていないので(なにがしかの処理を自前でやるので)

use framework "AppKit"
use framework "Foundation"
use scripting additions

tell application "Finder"
  set aSel to selection as alias list
  
if aSel = {} then return
end tell

openFiles(aSel) of me

on openFiles(pathList as list)
  repeat with i in pathList
    set j to contents of i
    
openFile(POSIX path of j) of me
  end repeat
end openFiles

on openFile(thePath as string) — POSIX path
  set ws to current application’s NSWorkspace’s sharedWorkspace()
  
set theURL to current application’s |NSURL|’s fileURLWithPath:thePath
  
ws’s openURL:theURL
end openFile

★Click Here to Open This Script 

(Visited 41 times, 1 visits today)
Posted in Bug file news URL | Tagged 12.0savvy Finder | Leave a comment

macOS 12.x上のAppleScriptのトラブルまとめ

Posted on 3月 20 by Takaaki Naganoya

現在進行形で発生しているAppleScript系のトラブルについてまとめておきます。macOS 12になって、AppleScriptの処理系の根幹部分にいろいろ手が加わっており(だったら機能追加してほしい気がする)、不具合なのかセキュリティポリシーとの不整合なのか(そんなもん、社内で調整してほしい)よくわからない問題がいろいろ生じています。

Apple自身が機能ごとのリリースノートを出さないようになり、こういうときに困ります。

問題1:Scriptを実行すると「表があふれました」と謎のエラーが表示される(解決したか不明)

macOS 12.3で解消されるか? と見ていましたが、完全に対処できている感じではない様子。
→ 関連情報:SkimのAppleScriptサポート機能にバグ

問題2:12.3betaで発生した「AppleScript書類をオープンできない」問題(解決)

これについては、12.3Release版では発生していないもよう。息が止まるかと思うほど焦りました。電子書籍1つ作るにしても、手間のかかる作業の多くをAppleScriptで自動化。そうでなければ、そんなにポンポン書けません。

問題3:インストールされていないアプリケーションを操作するScriptをオープンできない(未解決)

ただし、そのMacにインストールされていないアプリケーションを操作するScriptをオープンしようとすると、これまでは「どのアプリケーションですか?」とユーザーに問い合わせしていましたが、これが一律にエラーになるようです。

問題4:悪意を持って作られたAppleScriptバイナリ(アプレット?)のセキュリティ上の問題(CVE-2022-22626)(解決)

悪意を持って作成したAppleScriptバイナリは予期しない強制終了、ないしはプロセスが確保していたメモリを暴露(他のプロセスから読み書き&実行できてしまう?)する問題があったとのこと。

悪意を持って作ってことはないのと、ランタイムプログラムのメモリ処理の問題のようなので(???)、Scriptを書いている側には「そんなのあったの?」という話です。

個人的には、AppleScriptをアプレット化して動かすことは少なく、Script DebuggerかScript Menuで動かしている場合がほとんどです。

問題5:Finder上のselection itemsをオープンした際に、作成したアプリは起動されるがファイルはオープンされない問題

Finder上で選択したファイルを、指定のアプリケーションや、各ファイルを作成したアプリケーションで開かせようとした場合に、アプリケーションのプロセスは起動するものの、指定の書類はオープンされないという問題。macOS 12.3上で発生した新たな問題の様子。

先に対象のアプリケーションを起動しておくとファイルオープンの処理は通るというケースもあれば、そうではないというケースも。
→ macOS 12.3.1/12.4beta1で解消

問題6:macOS 12のスクリプトエディタで、Context Menu機能にバグ(未解決)


macOS 12のスクリプトエディタで、Script Assistantとして/Library/Scriptsに入れているAppleScriptをコンテクストメニューから呼び出せるようになっていますが、そこにカスタムScriptを入れて呼び出すと(絵文字入りファイル名)コンテクストメニュー上に重複した項目が表示されるというバグです。

(Visited 66 times, 1 visits today)
Posted in Bug news | Tagged 12.0savvy | Leave a comment

ドラッグ&ドロップ機能の未来?

Posted on 3月 17 by Takaaki Naganoya

目下、Tim Cook体制のもと「セキュリティ至上主義」が掲げられ、機能の有用性とセキュリティ(機能を制限、削除する)をてんびんにかけると、後者が重視されるようになっています。

そんな中、ドラッグ&ドロップの機能についてはいろいろ制約を受けたり、一部で使えなくなっていくのではないかという「懸念」を持っています。

実際、macOS 10.12以降、AppleScriptドロップレット(ファイルのドラッグ&ドロップを受信して動作するAppleScriptの実行プログラム)がOS側のセキュリティ機能による動作の影響(xattr)を受け、まっとうな処理方法では期待されるファイル処理ができなくなっています(回避策はあります)。

このため、macOS上でもFinder上でiOS並みのファイル操作、ドラッグ&ドロップでファイル/フォルダを移動させる程度の処理しか許可されず、アプリケーション側にまとめてファイルを渡すような処理ができなくなる「かも」しれません。

このドラッグ&ドロップによるファイルの一括指示の機能を維持するために、「display drop dialog Script Library」というライブラリをedama2氏との協力のもと(自分は要望を出したぐらいで作ったのはedama2氏)、配布しています。

アラートダイアログで指定のファイルタイプの書類のFinderからのドラッグ&ドロップを受け付けます。わざわざDropletを作らなくてもファイルのドラッグ&ドロップを受け付けるためには、こうしたインタフェースがないとまずいんじゃないか? という予測のもとに企画したものです。

目下、macOS 12.3でFinderに対してファイルのAppleScriptからオープン操作を行わせると、「creatorのアプリケーションは起動するもののファイルがオープンされない」という現象が発生しており(エラーダイアログが出る例があったり、出ない例があったり)、Apple社内でも整合性が取れていない状況のようです。

Appleとしては個別のテクノロジーについて発言したり、WWDCでも技術ではなくマーケティング的なセッションが増えて「見るべきものがない」状況になっていますが、こうした状況は好ましいものとは言えません。

(Visited 58 times, 1 visits today)
Posted in Bug news | Tagged 12.0savvy | Leave a comment

macOS 12のスクリプトエディタで、Context Menu機能にバグ

Posted on 3月 4 by Takaaki Naganoya

「AppleScriptによるWebブラウザ自動操縦ガイド」に添付している「Piyomaru Context Menu Assistant」。

スクリプトエディタのコンテクストメニューからAppleScriptを呼び出せるスクリプトエディタの機能を利用して、macOS標準装備の貧相で使い物にならないScriptを全部捨てて、そのかわりに強力なものをインストールするものです。


▲macOS標準でインストールされている、Script Assistant。古い、使えない、役に立たないの3拍子


▲Piyomaru Softwareが書籍のオマケでご提供しているPiyomaru Script Assistant(macOS 10.14.6)


▲macOS 12.3 beta 5上で表示したPiyomaru Script Assistant。メニュー項目(≒ファイル名)が2重に表示されている(macOS 12.3 beta5)

このScript Assistantが、macOS 12.3 beta 5上でメニュー項目が重複して表示されてしまうという現象に遭遇しています。

これは、macOS側のAppleが作ったバグであります。

(Visited 31 times, 1 visits today)
Posted in Bug | Tagged 12.0savvy | 1 Comment

macOS 12.3 beta 5、ASの障害が解消される(?)

Posted on 3月 2 by Takaaki Naganoya

macOS 12.3 beta 3/beta 4で発生していたAppleScriptの処理系全般にわたって発生していた障害が、beta 5で解消されたように見えます。

本Blogへのプログラムリスト掲載時に使っている「AS Publisher v1.8」(AppleScriptでAppleScriptを処理して掲載用のHTMLを生成するプログラム)自体が動作せず、Blogに投稿できない(横にある別Ver.OSのマシンでやればいいんですが)状況が続いていました。

本日配信されていたmacOS 12.3 beta 5で解消されたように見えます。手元にあるScriptが膨大すぎて、全数チェックするわけにもいきませんが、オープンできずにいたAppleScript書類はオープン/実行できています。

昨日リリースした書籍に掲載予定だったリストに動かないものがあって、掲載を見送る処理&使用しているプログラムの作者にお詫びのメールを送っていたのですが、なんのことはない、このbeta 3/4のバグのせいでした(beta 5にアップデートしたら何事もなかったように動いた)。

AppleScript書類をオープンできないとか実行できないといった「最悪レベルの問題」を起こさないことは確認できていますが、やっぱり「内部の表があふれる」的なエラーを出すScriptはまだあるようです。

macOS 11や10.15でそのようなエラーを起こす例を見なかったScriptなので、やはりmacOS 12環境に固有の問題が何かまだ残されているということなんでしょう。

macOS 12.3 beta 5、古めのMac OS X 10.2ぐらいの時期に書かれたAppleScript書類で、現在すでにOSにインストールされていない各種補助アプリケーションを呼び出しているものを、アプリケーション選択ダイアログを出さずに、いきなり「オープンできない」とダイアログを出して切り捨てる動作を行なっています。Script Debugger経由ではオープンできるため、依然として注意が必要です。

(Visited 63 times, 1 visits today)
Posted in Bug news | Tagged 12.0savvy | 8 Comments

macOS 12.3 beta4、まだ直らないASまわりの障害

Posted on 2月 23 by Takaaki Naganoya

macOS 12.3 beta 3で発生した目が覚めるような不具合。本日、beta 4が出てきたものの、AppleScript書類をオープンできない(ものがある)とか、実行できない(ものもある)というなかなかハードな状況です。正直、macOS 12.2に戻したいデス(^ー^;;

ちょっと前にSkimで遭遇した「内部の表があふれました」エラーの問題がどうやら(Skim以外にも)存在していて、その解決を図ろうとして他の問題を引き起こしてしまったのではないかと推測しています。

どこか別のチームが引き起こした修正が影響を及ぼしているのかと思いきや……そうでもない雰囲気が(汗)

macOS 12.3がどの程度までbetaを出すのかわかりませんが、通例ではbeta 5ぐらいでReleaseするんじゃないでしょうか。ラスト1take?

少なくとも、常識的に考えれば3月にリリースするとか噂で言われている新ハードウェアの発売に合わせて(未発表なので詳細は知りませんが)、これらのハードウェア向けにmacOS 12.3をリリースするとかいう話なんじゃないでしょうか。

# macOS 12.2.2とかいった細かいバージョンアップで例外的に対応することも不可能ではないと思われますが、外野からではリリース番号のポリシーなどはよくわかりません

自分なら、当初取り掛かっていた問題解決をいったん引っ込めて、12.2と同等の状況に戻してリリースすることでしょう。一部の問題解決を目指して、より広範囲に問題を引き起こすのは得策ではありません。

正直、AppleScriptの処理系の安定性がここまで「揺らいだ」のは初めての出来事なので(Mac OS X 10.3.xで、自分が多用している「is in」演算子が動かないことに気づいた時には目の前が真っ暗になりました…「Newt Onジャマー」とか呼んで、いいかげんにしてくれよと思ってました)、正直困惑しています。

(Visited 61 times, 1 visits today)
Posted in Bug news | Tagged 12.0savvy | Leave a comment

[超危険]macOS 12.3 beta3、errOSAInternalTableOverflow多発

Posted on 2月 16 by Takaaki Naganoya

今朝方来ていたmacOS 12.3 beta3アップデートをインストールしたら、(Script Debuggerで)AppleScript書類のでかいのをオープンしただけで「errOSAInternalTableOverflow」が表示されるようになりました。

スクリプトエディタでは、AppleScript書類のオープンすら(小さいものでないと)できない状況です。

過去最悪レベルの問題リリースです>macOS 12.3beta 3


▲今日の深夜に問題なく実行できていたScriptがいきなりオープンできなかったり実行できなくなったりする問題が発生


▲昨日までオープンできていたAppleScript書類をスクリプトエディタでオープンできなくなる事態が発生!!!

こういうアップデートは困ります、、、、Betaプログラムに参加されている方は、Beta 3のアップデートをインストールすることはやめておいたほうがいいと思います。

日常的に、Pagesの連続PDF出力+連結など大規模なScriptを動かしていたのが、急に今日になって動かなくなってしまいました。

こういうのは困るんですが?(ーー;;;

大きなScriptを動かすときには、部品ごとに分割して、別ファイルに分割して対処を行なってみていますが、、、過去にこのようなトラブルに遭遇したことはなかったので、純粋に腹が立つバグですわー

# どうしても動かないと困るAppleScriptについては、書き換えてScriptの機能をライブラリに分割して、バンドル内にライブラリを同梱する方向で対処しました

バグレポートはしましたが、「ざけんなコラ!!!!」と日本語で書きそうになりましたわー。

# さすがに直したらしい(謎情報)ですが、macOS 12.3 Beta 4自体がいつ出るのか不明。ものすごくScript周りがバギーで一刻も早く出てほしい。Appleの会議体制から考えると1週間以内に出ることはない

# macOS 12.3 beta 5で直りました(多分)

(Visited 31 times, 1 visits today)
Posted in Bug | Tagged 12.0savvy | 1 Comment

PDFViewでcustom URL protocolのリンクを含むPDFのリンクが途切れるバグが修正される

Posted on 2月 9 by Takaaki Naganoya

PDFView上で、カスタムURLプロトコルのURLリンクを含むPDFのリンクをクリックした場合に、展開されたリンクデータが途中で途切れるバグ(だか仕様だか)がmacOS 12.3beta 1で修正された…ように見えます。

なんの話だか、詳細が説明されなければわからないことでしょう。以下に詳細を示します。

macOS標準装備の「プレビュー.app」では、カスタムURLプロトコル入りのPDFでリンクをクリックしても反応しません。macOS標準装備のPDFビューワでこうしたPDFのリンクを拾わない、というAppleのセキュリティ上のポリシーを通すことについては、それはご勝手にすればいいでしょう。

ただ、だからといってPDFViewというOSの部品レベルでそれを阻害するような機能を実装するというのは、「やりすぎ」であり、「起動しないコンピュータ、動作しないコンピュータを作れば100%セキュリティを守れます!」というどこかの責任者のバカみたいな主張をバカな現場がそのまま実装したというだけの話です。

プレビュー.appなんて「よくわからない人」が使うPDFビューワーであり、文化的な最低限のレベルを満たしている人類は普通にSkimを使います。このバグによってSkimにまで影響が出て、基本的人権ともいえるPDFブラウジングが阻害されたため、「直してくれ」と要求した次第です。

2019/11/29 macOS 10.15でPDFView経由のURLイベントが正しくデコードされないバグ

macOS 10.15でこのバグ(だか仕様変更だか)が発生してAppleにバグレポート。macOS 10.15はそういう勘違いで独善的な仕様変更のオンパレード。macOS 10.15は本当に腹のたつアップデートでした。

そして、待てど暮らせど直る気配もなく、急にレポートがきて「いまごろ、何の話だ?」と、驚いてしまったほどです。

本バグ(と、自分は位置付けている)レポートは、「applescript://」URLリンクを埋め込んだPDFが、macOS上でリンククリックすると、Script Editorにその内容がすべて転送されず、途中で途切れるようになったという現象についての抗議です。

勝手に仕様変更だかバグだかを作ったのはAppleであり、その修正までに2年かかったというバカみたいな話です。

  macOS 10.15:PDFViewのバグ発生を検出、Appleにサンプルコードつきでバグレポートとして報告する
  macOS 11:バグ継続
  macOS 12:Beta 3でバグが修正されたことが通告される

勝手に仕様変更だかバグを作ったのはAppleなのに、利用者がその不利益を被って、多大なる労力を要求されるってなんなんでしょう、、、

PDFViewでPDFを表示する程度のシンプルでおかわいらしい内容のテストプログラムを作ってあったので、Xcodeでビルドして実行してテストしてみました。まだ、すべてのPDFでチェックしたわけではありませんが、いまのところ「いい感じ」に見えます。

この、Apple純正のバグをApple様に直していただいて、そのことをApple様に感謝しなければいけないのでしょうか? なんというマッチポンプ。もしかして、組織のどこかの人たちが善意で直してくれたのかもしれませんが、自分には知る由もありません。

ちなみに、SkimについてはmacOS 12でカスタムURLプロトコルリンクのPDFを問題なく処理できることを確認しています。

この調子で、PDFViewのcurrentPageがAppleScriptにまともにブリッジされていない件についても修正してくださるとありがたいのですが、どんなもんなんでしょうか。

(Visited 25 times, 1 visits today)
Posted in Bug news | Tagged 12.0savvy PDFView | Leave a comment

macOS 12.3 Beta(21E5196i)、電話番号ピックアップできないバグが直る?

Posted on 1月 28 by Takaaki Naganoya

macOS 12.3 Beta(21E5196i)が配信され、M1 Mac mini上で実験してみたところ、macOS 12でバグが出ていた「自然言語テキストからNSDataDetectorで電話番号を抽出しようとすると何も出てこない」件(日本語環境限定)が修正されているように見えます。

Thanks Shane!

AppleScript名:与えられたテキストから電話番号を抽出 v2
— Created 2015-08-21 by Shane Stanley
— Modified 2015-08-21 by Takaaki Naganoya
— Modified 2015-08-22 by Shane Stanley
use AppleScript version "2.4"
use scripting additions
use framework "Foundation"

set theString to "長野谷隆昌
(Takaaki Naganoya)
maro@piyocast.com
http://piyocast.com/as
2015年8月21日〜23日
080-1111-2222
030-1234-5678
東京都練馬区中村橋1-2-3
"

set theDates to (extractPhoneNumberFromNaturalText(theString))
–>  {​​​​​"080-1111-2222"​​​}–macOS 10.12 or other version
–> {"080-1111-2222", "030-1234-5678"}–macOS 13.6 with Intel MacBook Air
–> {"080-1111-2222", "030-1234-5678"}–macOS 14.6 with Intel MacBook Pro
–> {"080-1111-2222", "030-1234-5678"}–macOS 15.7 with Intel MacBook Pro
–> {} –macOS 12 beta 6 with M1 Mac mini
–> {"080-1111-2222", "030-1234-5678"}–macOS 12.3beta1 with M1 Mac mini

on extractPhoneNumberFromNaturalText(aString)
  set anNSString to current application’s NSString’s stringWithString:aString
  
  
set {theDetector, theError} to current application’s NSDataDetector’s dataDetectorWithTypes:(current application’s NSTextCheckingTypePhoneNumber) |error|:(reference)
  
set theMatches to theDetector’s matchesInString:anNSString options:0 range:{0, anNSString’s |length|()}
  
set theResults to theMatches’s valueForKey:"phoneNumber"
  
  
return theResults as list
end extractPhoneNumberFromNaturalText

★Click Here to Open This Script 

(Visited 18 times, 1 visits today)
Posted in Bug | Tagged 12.0savvy NSDataDetector NSString | Leave a comment

Skim v1.6.8でScripting機能のバグを修正

Posted on 1月 18 by Takaaki Naganoya

フリーのPDFビューワー「Skim」の最新版v1.6.8で、前バージョンで発生していたAppleScriptのサポート機能のバグが修正されました。どちらかといえば、OS側の不具合のような雰囲気も漂っています。

(Visited 22 times, 1 visits today)
Posted in Bug | Tagged macOS 12 Skim | Leave a comment

SkimのAppleScriptサポート機能にバグ

Posted on 12月 28, 2021 by Takaaki Naganoya

フリーのPDFビューワー「Skim」の最新版v1.6.7で、AppleScriptのサポート機能にバグが発生していることが明らかになりました。

スクリプトエディタでtell app “Skim”….end tellと入力して構文確認しただけで「内部の表があふれました」というワーニングが出てしまいます。

Script Debuggerでも同様です。

Script MenuからAppleScriptを呼び出して実行する分にはエラーが出ないので、今日もSkim経由でオープン中のJPEG画像を書き出したりしていたのですが、、、、

12/15の時点で、SkimのForum上でこの問題について話題になり、対策ビルドなども出ているようなので、年明けほどなくして解決されることを期待しています。

AppleのKeynote/Pages/Numbersだとあからさまな不具合であっても修正に半年ぐらいかかるので、このあたりはオープンソースのソフトウェアのほうが安心感があります。

(Visited 48 times, 1 visits today)
Posted in Bug | Tagged 11.0savvy 12.0savvy Skim | 3 Comments

Xcode 13.2 〜 13.3は有害(正式版でもまだ有害)

Posted on 12月 17, 2021 by Takaaki Naganoya

Xcode 13.2がリリースされ、賛否両論いろいろ意見が出されていますが、自分にとっては有害であり、Betaの段階でバグレポートを出していましたが、修正されずにリリースされました。

Interface Builder上でApp Delegateを選択してもScriptコード内のイベントハンドラが認識されないため、インタフェースのアクションとコードのひもづけが行えません。


▲左:Xcode 9.xで作ったAppleScriptのプロジェクトをXcode 13.2でオープンしたもの、右:Xcode 13.2上でゼロから作ったAppleScriptのプロジェクト XIB上でAppDelegateのイベントハンドラを追加できず、GUI部品の操作に対応するハンドラのひもづけができない

もはや「またか?」というぐらい何度も発生しているバグであり、責任者に知性が欠如しているのではという疑いを持たずにはいられません。

# Xcode 13.3が正式リリースされましたが、相変わらず使えません

(Visited 185 times, 1 visits today)
Posted in Bug | Tagged 12.0savvy Xcode | Leave a comment

macOS 12 beta9が登場

Posted on 10月 7, 2021 by Takaaki Naganoya

macOS 12 beta9が出てきています。もう、リリース間近というより大した問題がなければbeta 8でリリースしていたのでしょう。

AppleScript系では、Cocoa Scriptingの処理速度の低下は観測されていません。Beta 5以降はほぼ誤差の範囲内の変化しかありません。これはいいことです。

あいかわらず、日本語環境でNSDataDetectorで自然言語テキストからの電話番号の抽出に失敗します。これは、少し不幸なことですが、修正されることを期待したいところです。

(Visited 32 times, 1 visits today)
Posted in Bug news | Tagged 12.0savvy | Leave a comment

macOS 12 beta7が登場

Posted on 9月 22, 2021 by Takaaki Naganoya

ここ最近のmacOSのβ版の出来・不出来

macOS 12 beta 7が出てきました。macOSのリリースはiOS/iPadOSの後にリリースされるのが通例(というか、技術的にそうしないと無理)で、β番号から見て割とβ版の末期にあるものと推測されます。

例年だと、8月の終わりのmacOSの出来でRelease時の品質が推し図れています(農作物みたいだ)。

macOS 10.13:Beta中はとても好感触 → Release版で大事故(前代未聞の大惨事。macOS Vistaと呼ばれる)
macOS 10.14:Beta中、バグが多くて使う気になれず → 最終版(macOS 10.14.6)まで様子見
macOS 10.15:Beta中、8月末に大事故。開発者がそろって「こいつは新たなmacOS 10.13だ」として見放す。8月中にmacOS Vista 2のあだ名が確定
macOS 11:Beta中の印象は好感触(Intel Mac)。だが、Release後にM1 Macハードウェアがらみの未知の問題点が多数報告される

というのが、ここ最近のmacOSのリリースの流れです。

macOS 10.13、10.15と「奇数番号は地雷」という状態で、この命名法則でいえば「10.17」にあたるmacOS 12は、不吉な予感を抱かせるものでした。

Cocoa ScriptingなどAppleScript系の処理速度の回復と向上

自分はmacOS 10.15を全力で見送り、macOS 10.14.6をメイン環境にすえました。通例、新たなmacOSがリリースされるとScript環境まわりの評価記事を書きますが、10.15ははじめて評価記事をボイコットしたほどひどいものでした。

「10.15がひどい」という中には、「①本当にバグや不具合のもの」「②勝手に仕様変更して周知しなかったもの」「③OS全体のセキュリティ強化にともない、結果として機能不全になったもの」など多々あります。

その後、M1 Mac mini導入にともないmacOS 11に環境を移しました。M1 Mac mini+macOS 11は、世間の評判もよく、安住の地となるはずでした。

ところが! M1 Mac miniを開封して1時間もたたずに血の気がひきます。Cocoa Scriptingを多用している現代のAppleScriptを走らせると、2012年のMacBook Pro Retina 2012よりも10倍ぐらい遅かったからです。

調べてみると、macOS 10.15の時代からCocoa呼び出しで大幅なスピード低下が発生しており、その延長線にあるmacOS 11も同様の現象が発生。

さらに、M1に搭載されたCPUコアのうち、高性能コアではなく省エネコア(Ice Storm)を使用してAppleScriptが実行されているようで、2011年のMacBook Airよりも数倍M1 Mac miniが遅い処理が出てくる状況でした。

そこで、Shane Stanleyと相談してAppleに詳細なレポートを提出し、「おまえんとこの最新鋭機種は10年前のへっぽこマシンよりはるかに遅いぞ、どうしてくれる?」という報告をしたわけです。もちろん、M1 Mac mini購入後のアンケートでは「10年前のIntel Macの10倍も遅い。不満」と答えています。

運よく、レポートが功を奏してM1がらみの速度低下問題はmacOS 12beta 5で解決。同時にmacOS 10.15から発生していたCocoa呼び出しの速度低下問題も解決(たぶん)。このことで、Intel Macでも、速度低下発生前のmacOS 10.14より高速な処理が行えるようになったほどでした(もちろん、macOS 10.15や11よりも高速です)。

この問題の検証のため、手元のアップデート可能なMacは2台ともmacOS 12に上げてしまい、先日リリースされたmacOS 11.6においてパフォーマンス低下問題がフィードバックされたのかどうかは検証できません。

高速だが小バグが直っていないmacOS 12beta7

さて、macOS 12beta7ですが、ベンチマークを実施したところBeta 5、6と同様にCocoa Scriptingの速度は維持されています。Beta5よりも速くなった処理がある一方で、若干速度低下した項目も見られますが、誤差の範囲内でしょう。


▲同一ハードウェアでOSのアップデートにともない、速度低下が解消され、高速化


▲約700箇所の位置情報と8,000箇所の駅の位置情報との間での最短距離計算。macOS 11+M1 Macでは1時間かかって気を失いかけたが、いまではiMac Proより2.5倍高速の異次元の速さを実現。これなら、ScripterにもApple Silicon Macをおすすめできます

一方で、日本語環境でのみ発生しているNSStringからのData Detectorによる電話番号ピックアップができないバグは直っていません。GUI部品のお守りよりもデータ処理を行うことが多いAppleScript界隈としては「無視できない問題」です。

Release版では直ってほしいですよね>誰となく

また、macOS 11で確認された特定ハードウェア(Mac Pro 2019)で関数計算を間違えるバグについては、当該機種を所有していないため、自分には追跡調査は行えていません。

(Visited 42 times, 2 visits today)
Posted in Bug news | Tagged 12.0savvy | Leave a comment

macOS 12 beta6、Cocoa Scriptingの速度低下なし

Posted on 8月 31, 2021 by Takaaki Naganoya

macOS 12 beta6が出てきました。beta 5でM1 Mac上でのAppleScript実行速度低下が大幅に改善され、そのアップデート版であるbeta 6で「先祖返り」していないかを確認。beta 5と同程度か、少し高速になっている処理もあるようです(気持ち速いぐらい)。

でも油断はできません。macOS史上最悪最低のmacOS 10.13のときには、Release前には何も問題がなく順調にバグがつぶされてきたのに、Release版はBeta以下という出来でした。

あのmacOS 10.13の開発プロジェクトを思えば、Release版を見るまで結論は出せません。

追記1:
Beta 6に、NSDataDetector経由で電話番号を取得できないというバグを見つけました(レポート済み)。プログラミング言語ではなく、ユーザー環境の設定言語に依存して発生するようです。いまのところ、日本語環境で問題が発生し、英語環境では発生していません。

(Visited 36 times, 1 visits today)
Posted in Bug news | Tagged 12.0savvy | Leave a comment

macOS 12 beta5でAppleScript処理系の大幅なスピードアップ。M1もIntelも

Posted on 8月 18, 2021 by Takaaki Naganoya

以前から本Blogでは、M1 Mac+macOS 11上でAppleScriptの実行、とくにCocoaの機能呼び出しが10〜77倍遅くなるという件についてレポートしてきました。

–> macOS 11, AppleScriptをFirestormではなくIcestormで実行か?!

CPUの乗り換え直後ということもあり、淡々とAppleにバグレポートしつつ、周囲には「まだM1に手を出すべきではない」と話していたものが、最新のmacOS 12 beta 5においてどの程度変わったのでしょうか?

2つのスピード低下問題

AppleScriptのコミュニティ的には「macOS 10.15をインストールするとCocoa Scriptingが遅くなる問題」(Intel Mac)があり、そのうえに「M1でAppleScriptの実行+Cocoa Scriptingが遅くなる問題」の2つの問題を抱えていました。

macOS 10.15以降の速度低下問題は、自分がmacOS 10.15を「ダメ環境」としてパスし、M1 Macの導入にともないOSバージョンを1つ飛ばしてmacOS 11に移行したときにはじめて認識しました。

Mac App Storeに出している、AppleScriptで組んだアプリケーションの数々が、さぞやM1 Mac上で処理速度が向上して、より快適に使えるに違いない……と、ルンルンで箱を開けてテストをしだして、「遅い!! MacBook Pro Retina 2012より遅いとはどういうこと?!」と、落胆の表情に変わるまで1日も必要ありませんでした。

とくに期待していた時間のかかる大規模データ処理が、MacBook Pro Retina 2012の10倍以上遅いという結果に言葉を失い、Appleにこれを「バグレポート」としてレポートすることになったのです。

メール.appの起動やSafariの操作など、日常的な操作の範囲では噂どおりの処理性能を発揮していたのに、AppleScriptの処理だけ遅いというのは、これはもう明らかに「異常事態」です。

ベンチマーク比較対象

身の回りにあるMacをかき集めて調べてみました。現用機でこのベンチマークに参加していないのは奥方様のMacBook Air 2015ぐらいです。

今回、青い色で指し示しているmacOS 12 beta 5環境が注目点です。M1 Mac miniおよびIntel Mac mini 2014にmacOS 12 beta 5をインストールし、速度の変化を検証しました。

結論から言うと、macOS 12 beta 5ではM1 MacでmacOS 11.xの30倍、Intel Macで10倍ぐらいCocoa Scriptingの実行が高速になっています。

これは、冒頭で説明した(1)macOS 10.15で発生した何らかの内部的なミス (2)M1 Mac上でAppleScriptの処理系が明らかにIcestorm(電力効率のよいローパワーCPUコア)で処理されてしまっていたこと の2つの問題が解消されたため、と推測しています。

これらの組み合わせによって、Intel MacでもM1 Macでも処理速度が大幅に向上した、という「現象」のみが確認できているだけです。

ベンチマーク1:Permutation

DNAの塩基配列「T」「C」「G」「A」のすべての順列組み合わせパターンを計算する計算(Permutation)です。桁数が多くなるとデータ量と計算量が膨大に増えるのと、Cocoa Scripting導入の有用性を示す演算内容(Vanilla AppleScriptより桁違いに高速)でもあるため、4〜8桁のPermutationを採用しました。以下、グラフ内の横軸の単位はすべて「秒」です。

Machine 4が前の開発環境(MacBook Pro Retina 2012)で、これを基準に「速い」「遅い」という比較を行っています。

アップデート前のM1 Mac mini+macOS 11の環境はMachine 4よりもはるかに遅くて「使っていられない」状態でしたが、アップデート後の環境(Machine 1’)ではMachine 4の2倍強、アップデート前からは平均で27倍の速度向上を実現。

Intel MacでもmacOS 11から12への移行で11〜21倍程度、高速化しています。

ベンチマーク2:乱数配列の生成とソーティング

M1+macOS 11の環境では「要素数の多い配列の操作」と「乱数の生成」(AppleScriptのrandom number)がとくに遅いという傾向が出ていたので、10万要素、20万要素、30万要素の配列でベンチマークを行いました。ただし、本ベンチマークでは乱数の生成を最速の方法で計算しているため、M1 Macで1.3倍速、Intel Macでも同程度の速度向上になっています。とくに、要素数が少ないほど速度向上の割合が増えており、これは歓迎できる傾向です。

ベンチマーク3:AppleScriptのrandom number関数を用いた乱数配列の生成とソーティング

AppleScriptのrandom number関数を用いて1〜99999999の範囲の乱数を1万回生成して配列に追加するベンチマークです。初回実施時にはこれでM1 Mac mini+macOS 11の環境が、MacBook Air 2011+macOS 10.13の5倍の処理時間がかかるという衝撃の数値が出た内容です。

macOS 11から12 beta 5へのアップデートに伴い、M1 Macで30倍、Intel Macでも12倍速度が向上していることを確認しています。

macOS 11の正式版がmacOS 12?

どこまでも「次世代Apple Silicon Mac用OSのβ版」という印象が強かったmacOS 11から、AppleScript+Cocoa呼び出しについては機能の改善が行われ、macOS 10.15で失った処理速度をIntel Macでも回復できているように見えます。

自分が大規模データ処理+演算速度の目安に用いている、「約700箇所の日本全国のゲームセンターについて、全国の鉄道駅(約8,000箇所)との距離を求め最短のものを最寄駅とし、それぞれ最寄駅までの距離が短い順にソートする」計算の結果を見てみると、

MacBook Pro Retina 2012:7分13秒
iMac Pro:4分17秒
M1 Mac mini:1分42秒

と、iMac Proを大きく上回る結果を叩き出しています。あまりに速いので、計算内容が間違っているのではないか? とか、計算結果が出力されないのではないか?? などと疑問に思って何度も調べてみましたが、きちんと計算されています。間違いなく、これまでに遭遇したMacの中で最も高速にAppleScriptを実行する環境といえます。この速さは、異次元のレベルです(力説)。

正直なところ、Cocoa Scripting Course本掲載のサンプルAppleScriptをM1 Mac mini+macOS 11で動かしたときには「イヤな汗」が出まくりました。高速なCocoa Scriptingだぜキャッホー(奇声)! などとノリノリで書いていたものが、

「残念なお知らせです。いま、Vanilla ScriptingのソートルーチンにCocoa Scriptingのソートルーチンが抜かされました」

などと書けるでしょうか? いや、書けるわけがない(反語)。本件は、Cocoa Scripting本の続刊を書く手が止まってしまうぐらいの(よくない方向への)インパクトがありました。

かくして、そこから詳細な調査や問題傾向の炙り出しなど、表沙汰にできない調査と資料作成がはじまったわけで、一応こういう形で(いい方向に)問題が解決されて本当によかったデス。これで解決されなかったら、海外のYouTuberにチクリまくってセンセーショナルな方向で炎上させるしかない、と割と本気で思っていたほどでした。だいたい、自分にしかレポートできないのに、時間と何かを失って何も得られない膨大な作業。Appleが自分でチェックする能力がない一方で、この無償奉仕労働を強いられるのが納得できません。

macOS 12については期待が持てる内容ですが、これがいまだ現用環境であるmacOS 10.15やmacOS 11へのフィードバックが可能な内容なのか、あるいはmacOS 12の登場を待たなくてはならないのかは現時点ではわかりません。

ただ、ここ数年というもの(2020年は珍しい例外)、このぐらいの時期(8月後半)になると「またAppleの現場が無茶な仕様追加を行って開発プロジェクトが崩壊した」「Release版のひどさがいまから感じられるので、アップデート禁止」といった話題しか出ていませんでした。それが、「macOS 12には期待できる」という話ができるのは、喜ばしいことでしょう。

# Beta版では素晴らしかったのに、Release版で別物が壊滅的な出来でリリースされた「macOS 10.13」という悪しき前例があるので、Betaがよくても安心できない今日このごろです。「どうして10.13がああなったのか」という説明は一切ないままなので、いまひとつ信頼できません

Mac App Storeに出している各種アプリケーション(すべてAppleScriptで記述)の動作が、macOS 12 beta5上であればひじょうに高速です。

UNI detector+macOS 12 beta5 DEMO

Watch kamenoko_M1+macOS 11 DEMO

Watch Kamenoko_M1_macOS 12 beta5 DEMO

FileMaker Proに組み込んで大規模なCocoaの機能を呼び出しているAppleScriptの動作も快適になっています。

Watch M1+macOS11 MkMapView Demo

Watch M1+macOS12 beta5 MkMapView Demo

CotEditorと組み合わせて動かしている「CotEditor PowerPack v3」のAppleScriptも、macOS 12beta 5上できわめて高速に動く様子がわかります。

Watch CotEditor_M1+macOS11 DEMO

Watch CotEditor_M1+macOS12 beta5 DEMO

Numbers.appで選択中の範囲のセルをシャッフルするAppleScriptをmacOS 12beta5で動かしたもので、左がIntel Mac mini 2014、右がM1 Mac mini 2020です。
numbers_selection_shuffle_intel_M1_12beta5

これはAppleScriptに関する処理だけにとどまるものではないようです。Terminal.app上で動作させる各種CLI系のプログラムの動作時のCPU Coreの割り当ても変化しており、よりパフォーマンスを発揮する方向に「味付け」が変化しているように見えます。

ただ、CLIベースのプログラムについてまとまったベンチマークを行なっているわけではないため、実際に動作させている数少ない膨大な処理時間のかかるプログラム(PDF内の画像サイズ圧縮のために併用しているGhostScript)を見ている範囲で、アクティビティモニタ上のCPU各コアの動きが変わっているように見える、ということです。

(Visited 237 times, 1 visits today)
Posted in Bug news | Tagged 11.0savvy 12.0savvy | Leave a comment

Stream DeckのKeynote操作プラグインがKeynoteの操作を妨害するメカニズム

Posted on 8月 7, 2021 by Takaaki Naganoya

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

★Click Here to Open This Script 

(Visited 54 times, 1 visits today)
Posted in Bug | Tagged Stream Deck | Leave a comment

Post navigation

  • Older posts

電子書籍(PDF)をオンラインストアで販売中!

Google Search

Popular posts

  • ebook:アーケードゲーム「戦場の絆」僕らの15年戦争
  • macOS 12が正式リリースされる
  • macOS 12 beta5でAppleScript処理系の大幅なスピードアップ。M1もIntelも
  • AppleScriptからショートカット実行&ショートカット内でAppleScriptを実行
  • Xcode 13.2 〜 13.3は有害(正式版でもまだ有害)
  • M1 Macの各種温度センサーから値を取得する
  • Intel MacとApple Silicon Macの速度差〜画像処理
  • AS Publisher v18
  • 2021年に書いた価値あるAppleScript
  • 新刊 elgato STREAM DECK 徹底活用Mac+STREAM DECKで時短+作業効率化!! 刊行
  • macOS 11.5+Keynote 11.1でGUI Scriptingに障害?
  • CotEditorで選択範囲の行頭にある数字をリナンバーする v1
  • Stream Deck Softwareがバージョン5.1.2にバージョンアップ
  • 「AppleScript最新リファレンス」に追加ダウンロードコンテンツ
  • Shortcuts Eventsでショートカットのインストール+実行
  • AppleScriptによるWebブラウザ自動操縦ガイド
  • マウスの右クリックメニューをカスタマイズするService Station
  • Amazon EC2 M1 Macインスタンスが利用可能に
  • macOS 12.x上のAppleScriptのトラブルまとめ
  • macOS 12.3 beta 5、ASの障害が解消される(?)

Tags

10.11savvy (1102) 10.12savvy (1243) 10.13savvy (1389) 10.14savvy (565) 10.15savvy (400) 11.0savvy (235) 12.0savvy (106) CotEditor (54) Finder (46) iTunes (19) Keynote (83) NSAlert (60) NSArray (51) NSBezierPath (18) NSBitmapImageRep (21) NSBundle (20) NSButton (34) NSColor (51) NSDictionary (27) NSFileManager (23) NSFont (18) NSImage (42) NSJSONSerialization (21) NSMutableArray (61) NSMutableDictionary (21) NSPredicate (36) NSRunningApplication (56) NSScreen (30) NSScrollView (22) NSString (117) NSURL (97) NSURLRequest (23) NSUTF8StringEncoding (30) NSUUID (18) NSView (33) NSWindow (17) NSWorkspace (20) Numbers (51) Pages (32) Safari (38) WKUserContentController (21) WKUserScript (20) WKUserScriptInjectionTimeAtDocumentEnd (18) WKWebView (22) WKWebViewConfiguration (22)

カテゴリー

  • 2D Bin Packing
  • AirDrop
  • AirPlay
  • Animation
  • AppleScript Application on Xcode
  • Bluetooth
  • Books
  • boolean
  • bounds
  • Bug
  • Calendar
  • call by reference
  • Clipboard
  • Code Sign
  • Color
  • Custom Class
  • dialog
  • drive
  • exif
  • file
  • File path
  • filter
  • folder
  • Font
  • Font
  • GAME
  • geolocation
  • GUI
  • GUI Scripting
  • History
  • How To
  • Icon
  • Image
  • Input Method
  • Internet
  • iOS App
  • JavaScript
  • JSON
  • JXA
  • Keychain
  • Language
  • list
  • Locale
  • Machine Learning
  • Markdown
  • Menu
  • Metadata
  • MIDI
  • MIME
  • Natural Language Processing
  • Network
  • news
  • Noification
  • Notarization
  • Number
  • Object control
  • OCR
  • OSA
  • PDF
  • Peripheral
  • PRODUCTS
  • QR Code
  • Raw AppleEvent Code
  • Record
  • recursive call
  • regexp
  • Release
  • Remote Control
  • Require Control-Command-R to run
  • REST API
  • Review
  • RTF
  • Sandbox
  • Screen Saver
  • Script Libraries
  • sdef
  • search
  • Security
  • selection
  • shell script
  • Shortcuts Workflow
  • Sort
  • Sound
  • Spellchecker
  • Spotlight
  • SVG
  • System
  • Tag
  • Telephony
  • Text
  • Text to Speech
  • timezone
  • Tools
  • Update
  • URL
  • UTI
  • Web Contents Control
  • WiFi
  • XML
  • XML-RPC
  • イベント(Event)
  • 未分類

アーカイブ

  • 2022年5月
  • 2022年4月
  • 2022年3月
  • 2022年2月
  • 2022年1月
  • 2021年12月
  • 2021年11月
  • 2021年10月
  • 2021年9月
  • 2021年8月
  • 2021年7月
  • 2021年6月
  • 2021年5月
  • 2021年4月
  • 2021年3月
  • 2021年2月
  • 2021年1月
  • 2020年12月
  • 2020年11月
  • 2020年10月
  • 2020年9月
  • 2020年8月
  • 2020年7月
  • 2020年6月
  • 2020年5月
  • 2020年4月
  • 2020年3月
  • 2020年2月
  • 2020年1月
  • 2019年12月
  • 2019年11月
  • 2019年10月
  • 2019年9月
  • 2019年8月
  • 2019年7月
  • 2019年6月
  • 2019年5月
  • 2019年4月
  • 2019年3月
  • 2019年2月
  • 2019年1月
  • 2018年12月
  • 2018年11月
  • 2018年10月
  • 2018年9月
  • 2018年8月
  • 2018年7月
  • 2018年6月
  • 2018年5月
  • 2018年4月
  • 2018年3月
  • 2018年2月

https://piyomarusoft.booth.pm/items/301502

メタ情報

  • 登録
  • ログイン
  • 投稿フィード
  • コメントフィード
  • WordPress.org

Forum Posts

  • 人気のトピック
  • 返信がないトピック

メタ情報

  • 登録
  • ログイン
  • 投稿フィード
  • コメントフィード
  • WordPress.org
Proudly powered by WordPress
Theme: Flint by Star Verte LLC