約 4,854,155 件
https://w.atwiki.jp/aias-closurecompiler/pages/20.html
トップページ Compilerが求めるコーディングルール Closure Compilerは自身への入力となるJavaScriptがいくつかのコーディングルールに適合していることを想定しています。そしてユーザが高いレベルの最適化を求めるほど、Compilerは入力されるJavaScriptに対しより多くのルールを課すことになります。このページではそれぞれのコンパイルレベルにおけるルールについて説明します。 このページは公式サイトの以下のページを元に作成しました。http //code.google.com/closure/compiler/docs/limitations.html http //code.google.com/closure/compiler/docs/api-tutorial3.html 目次 全てのコンパイルレベルに適用されるルール SIMPLE_OPTIMIZATIONSでのルール ADVANCED_OPTIMIZATIONSでのルール 一貫した方法でプロパティにアクセスする thisはコンストラクタとプロトタイプメソッドだけで使う Compilerが使用箇所を見つけられないコードは削除される アプリケーションは全体を一度にコンパイルする コンパイルされたコードと外部コードの間の参照関係を維持するには 全てのコンパイルレベルに適用されるルール 全てのコンパイルレベルにおいて、Closure Compilerは処理を行うJavaScriptに対し以下の2つのルールを課します。 Compilerは Ecmascript 262 revision 3 だけを正しく認識する Ecmascript revision 3 はJavascript 1.5とJScript 5.5の基礎になっており、"JavaScript"という言葉が使われる場合は通常このバージョンのJavaScriptを意味します。CompilerはJScript独自の言語仕様やJavaScript1.5以降のバージョンのJavaScriptをサポートしません。 ブラウザによる拡張機能は、それがEcmascriptの言語仕様に適合するものであれば、Compilerと共に正常に動作します。例えばActiveXオブジェクトは従来のJavaScriptの構文によって作成されるので、Compilerはそのコードを問題なく扱うことができます。しかし一方、従来のJavaScriptの構文から離れたブラウザ拡張はClosure Compilerのエラーを引き起こします。例えばFirefoxのJavaScriptエンジンは const キーワードをサポートしますが、このキーワードはEcmascriptの言語仕様には含まれていないため、Compilerもそれをサポートしません。この制約により、コードが全ての主要なブラウザで動作するかどうかをチェックするするためにCompilerを利用することもできます。 Compilerはコメントを保存しない 全てのコンパイルレベルにおいてコメントは削除されるため、特殊なフォーマットのコメントに依存しているコードはCompilerのもとでは正常に動作しません。例えば(Compilerがコメントを保存しないために)JScriptの「条件付きコメント」は使用できません。ただしこの制約は条件付きコメントを eval() 式で囲むことで回避できます。Compilerは下のコードをエラーを発生させることなく処理します: x = eval("/*@cc_on 2+@*/ 0"); 注意: @preserve アノテーションを使用して、Compilerの出力結果の先頭にオープンソースライセンスやその他の重要なテキストを含めることができます。詳しくはこちらを参照してください。 SIMPLE_OPTIMIZATIONSでのルール SIMPLE_OPTIMIZATIONS レベルでは、コードサイズを減らすために関数パラメータ、ローカル変数、ローカルで定義された関数の名前を短く変更します。しかしJavaScriptのいくつかの言語構造は、この変更処理を失敗させることがあります。 SIMPLE_OPTIMIZATIONS を適用する場合、以下の言語構造の使用やコードの書き方は避けてください: with with を使用するとCompilerはローカル変数とオブジェクトプロパティを区別できなくなり、プロパティと同名の変数が先に存在した場合はそれに合わせてプロパティ名を変更してしまいます。そもそも with 命令は人間にとってもコードを読みにくいものにします。 with 命令は名前解決のための通常のルールを変更し、名前が参照するものの識別をそのコードを書いたプログラマにすら困難にしてしまうことがあるため、利用すべきではありません。 eval() Compilerは eval() の引数文字列をパースしないので、この引数の中に含まれるいかなる名前も変更されることはありません。このことはリネームされたシンボルとの間で名前の不整合が発生する危険性があることを示しています。 関数やパラメータ名の文字列表現 Compilerは関数と関数パラメータの名前を変更するものの、コードの中でそれらを表す文字列までは変更しません。従って、コード内で関数名やパラメータ名を文字列として表現することは避けるべきです。例えばPrototype.jsライブラリの argumentNames() 関数は関数パラメータの名前を検索するために Function.toString() を使っています。 argumentNames() はコード内で引数名を利用したいと思わせるかもしれませんが、最適化処理の過程でこの種の参照は破壊されてしまいます。 ADVANCED_OPTIMIZATIONSでのルール ADVANCED_OPTIMIZATIONS レベルのコンパイルでは、 SIMPLE_OPTIMIZATIONS と同じ変換処理に加え、プロパティ、変数、関数に対するグローバルスコープでのリネーム、未使用コードの除去、プロパティの平坦化が実行されます。これらの新しい処理は入力されるJavaScriptに対し更に多くの制約を課すことになります。また、 SIMPLE_OPTIMIZATIONS でのルールは ADVANCED_OPTIMIZATIONS にも適用されます。 以下では、 ADVANCED_OPTIMIZATIONS でコンパイルされるコードについて注意すべき点を列挙します。 一貫した方法でプロパティにアクセスする コンパイルレベルに関係なく、Closure Compilerは文字列リテラルを決して変更しません。これは ADVANCED_OPTIMIZATIONS レベルにおいて、プロパティ名を文字列で指定してアクセスしているかどうかによってプロパティの扱い方が違ってくることを意味します。もしプロパティの参照に文字列とドットシンタックスによるものが混在していると、Closure Compilerはそれらの一部だけをリネームします。その結果、おそらくそのコードは正しく動作しなくなるでしょう。 例として以下のコードを取り上げます: function displayNoteTitle(note) { alert(note[ myTitle ]); } var flowerNote = {}; flowerNote.myTitle = Flowers ; alert(flowerNote.myTitle); displayNoteTitle(flowerNote); このソースコードの最後の2つの文は、実際には全く同じことを行っています。 ADVANCED_OPTIMIZATIONS レベルでコードを圧縮するとこうなります: var a={};a.a= Flowers ;alert(a.a);alert(a.myTitle); 圧縮されたコードの最後の文はエラーを引き起こします。 myTitle プロパティへの直接の参照は a にリネームされ、一方 displayNoteTitle() 関数内のクォートされた myTitle による参照はリネームされませんでした。その結果、最後の文では既に存在しない myTitle プロパティが参照されています。 この問題の解決策はとてもシンプルです。可能な限りクォートされた文字列ではなくドットシンタックスによるプロパティ名を使用し、文字列を使うのは Closure Compilerにプロパティ名を変更されたくない場合だけにします。例えばプロパティをエクスポートする際には、文字列が使用される必要があります。しかしそのプロパティがコンパイルされたコードの中だけで使われるなら、ドットシンタックスを使用してください。 もしどうしてもプロパティをクォートされた文字列によって参照する必要があるのであれば、常にその方法を使ってください: function displayNoteTitle(note) { alert(note[ myTitle ]); } var flowerNote = {}; flowerNote[ myTitle ] = Flowers ; alert(flowerNote[ myTitle ]); displayNoteTitle(flowerNote); 変数とグローバルオブジェクトのプロパティの不一致 Compilerはプロパティと変数をそれぞれ独立してリネームするので、それが原因でプロパティ名の不一致が発生する可能性があります。例えばCompilerは下の foo への2つの参照を、それらが実際には同一であっても、別のものとして扱います: var foo = {}; window.foo; // BAD このコードは次のようにコンパイルされます: var a = {}; window.b; もし変数をグローバルオブジェクトのプロパティとして参照したいのであれば、常にその方式で参照してください: window.foo = {}; window.foo; thisはコンストラクタとプロトタイプメソッドだけで使う 名前短縮の前段階として、 ADVANCED_OPTIMIZATIONS レベルのCompilerはオブジェクトプロパティに関するコードを1つにまとめる処理を行います。 var foo = {}; foo.bar = function (a) { alert(a) }; foo.bar("hello"); 例えば上のコードは、次のように変換されます: var foo$bar = function (a) { alert(a) }; foo$bar("hello"); このようなプロパティの平坦化はその後のリネーム処理をより効果的にします。例えば foo$bar はCompilerによって1文字の名前に置き換えられます。 しかしプロパティの平坦化は、関数内の this キーワードの意味を変えてしまうことがあります。 var foo = {}; foo.bar = function (a) { this.bad = a; }; // BAD foo.bar("hello"); 例えば上のコードは、次のように変換されます: var foo$bar = function (a) { this.bad = a; }; foo$bar("hello"); 変換前の foo.bar 内の this は foo を参照していましたが、変換後の this はグローバルの this を参照しています。このようなケースでは、Compilerは下に示す警告を出力します: WARNING - dangerous use of this in static method foo.bar プロパティの平坦化が this の参照を破壊するのを防ぐには、 this をコンストラクタまたはプロトタイプメソッドの中だけで使うようにしてください。コンストラクタを new キーワードを使って呼び出すとき、または this がプロトタイプのプロパティである関数内にあるときには、 this の意味は常に明確であるといえます。 この問題についてはこちらの説明も参照してください。 Compilerが使用箇所を見つけられないコードは削除される もし下の関数だけを ADVANCED_OPTIMIZATIONS でコンパイルした場合、Closure Compilerは空データを出力します: function displayNoteTitle(note) { alert(note[ myTitle ]); } Compilerに渡されたJavaScriptの中で関数が一度も呼び出されていないので、Closure Compilerはこのコードを不要とみなしてしまうのです。この振る舞いは多くのケースで望ましいものです。例えばあなたが自分のコードと大きなライブラリを一緒にコンパイルする場合、Closure Compilerはそのライブラリの中の関数が実際に使用されているかどうかを判断し、使用されていないものを取り除いてくれます。 ある関数(メソッドも)が使用されているとみなされるためには、Compilerが理解できる形式で呼び出しが行われている必要があります。JavaScriptではコンストラクタやそのプロトタイプのプロパティ名を反復処理の中で取得し、メソッドを実行できます。しかしCompilerはこの方法で呼ばれる特定の関数を識別することはできません。例えば次のコードは、意図しないコード削除の原因となります: function Coordinate() {}; Coordinate.prototype.initX = function() { this.x = 0; } Coordinate.prototype.initY = function() { this.y = 0; } var coord = new Coordinate(); for (method in Coordinate.prototype) { Coordinate.prototype[method].call(coord); // BAD } Compilerは for ループの中で initX() や initY() が呼ばれていることが分からず、両方のメソッドを削除します。 関数への参照がパラメータとして渡される場合、Compilerはそのパラメータへの呼び出しを見つけることができます。例えば次のコードが ADVANCED_OPTIMIZATIONS レベルでコンパイルされるとき、Compilerは getHello() 関数を削除しません: function alertF(f) { alert(f()); } function getHello() { return hello ; } // The Compiler figures out that this call to alertF also calls getHello(). alertF(getHello); // This is OK. 残しておきたいコードをClosure Compilerが削除している場合、これを防ぐには2つの方法があります: 関数呼び出しを行っているコードを、Closure Compilerが処理するコードの中へ移動させる 残しておきたいシンボルをエクスポートする 解決策1 関数呼び出しを行っているコードを、Closure Compilerが処理するコードの中へ移動させる もしあなたが自分のコードの一部だけをClosure Compilerでコンパイルした場合、望ましくないコードの削除に遭遇する可能性があります。例えば、関数定義のみを含むライブラリのファイルと、ライブラリをインクルードしその中の関数を呼び出すコードを含むHTMLファイルがあるとします。このとき、もしライブラリファイルだけを ADVANCED_OPTIMIZATIONS でコンパイルすると、Closure Compilerはライブラリ内の関数を全て削除してしまいます。 この問題の最もシンプルな解決策は、関数とそれらを呼び出しているプログラムを一緒にコンパイルすることです。下に示すプログラムをコンパイルしたとき、Closure Compilerは displayNoteTitle() 関数を削除しません: function displayNoteTitle(note) { alert(note[ myTitle ]); } displayNoteTitle({ myTitle Flowers }); このケースでClosure Compilerが displayNoteTitle() 関数を削除しないのは、それがコード内で呼び出されているためです。 言い換えると、Closure Compilerに渡すコード内にそのプログラムの「エントリポイント」を含まれていれば、望ましくないコードの削除を防ぐことができるわけです。プログラムの「エントリポイント」とは、プログラムの実行が開始される場所を指します。例えば前のセクションの"flower note"プログラムであれば最後の3行はJavaScriptがブラウザに読み込まれた直後に実行されるコードですので、ここがこのプログラムのエントリポイントということになります。コードを残すべきかどうかを決定するため、Closure Compilerはエントリポイントを出発点としてプログラムの処理フローのトレースを開始します。 解決策2 残しておきたいシンボルをエクスポートする ではもしあなたが再利用可能なライブラリを作成するため関数定義だけをコンパイルしたいと考えた場合、Closure Compilerによる関数の削除をどうすれば防げるでしょうか? この場合の最善の解決策は、下の例に示すように関数をエクスポートすることです。エクスポートとは、シンボルの参照をグローバルオブジェクトのプロパティにプロパティ名を文字列指定して設定する処理のことです: function displayNoteTitle(note) { alert(note[ myTitle ]); } // Store the function in a global property referenced by a string window[ displayNoteTitle ] = displayNoteTitle; ADVANCED_OPTIMIZATIONS レベルのコンパイルによって圧縮されたコードは、次のようになります: function a(b){alert(b.myTitle)}window.displayNoteTitle=a; 圧縮されたコードが alert 文を実行している部分を関数として残している点に注意してください。この関数はかつての displayNoteTitle() が a() にリネームされたものです。しかし a() を参照するグローバルオブジェクトのプロパティの名称に古い関数名が使われているため、依然としてこの関数を古い名前で呼び出すことも可能になっています。例えばこのコードの外部にあるプログラムから以下のような呼び出しがあったとしても、やはり正しくalertを表示するはずです: displayNoteTitle({ myTitle Flowers }); 上のコードが動作するのは、ちょうど window.alert プロパティの値が alert() 関数であるのと同様、 window.displayNoteTitle プロパティの値が関数であるためです。 さらに、Closure Compilerが関数定義を削除しなかった( a() にリネームして残した)のは、 displayNoteTitle() 関数が実行中の処理の中で使用されていると見なしたからです。以下の代入文が、その使用箇所にあたります: window[ displayNoteTitle ] = displayNoteTitle; コンストラクタやプロトタイプメンバも、上と同様の手法でエクスポートできます。以下に例を示します: MyClass = function(name) { this.myName = name; }; MyClass.prototype.myMethod = function() { alert(this.myName); }; window[ MyClass ] = MyClass; // -- Constructor MyClass.prototype[ myMethod ] = MyClass.prototype.myMethod; もし逐一エクスポートのための文を書くことが面倒に感じられるなら、エクスポート用の関数を使用するのも良いでしょう。そのような関数の例として、Closure Library内の goog.exportSymbol() や goog.exportProperty() を参照してみてください。 アプリケーションは全体を一度にコンパイルする もしあなたが自分のアプリケーションを2つのコードモジュール(JSファイル)に分割したとすると、おそらくそれらのモジュールを別々にコンパイルしたいと考えるでしょう。しかしそれらのモジュールが連携して動作している場合、あなたはコンパイル時に後述するような様々な問題に直面するものと思われます。そして仮にコンパイルに成功したとしても、2つの出力結果は互いに関連性を失っていることでしょう。 例として、データ取得とデータ表示の2つの部分に分割されたアプリケーションを想定します。データを取得するコードは以下のとおりです: function getData() { // In an actual project, this data would be retrieved from the server. return {title Flower Care , text Flowers need water. }; } データを表示するコードは以下のとおりです: var displayElement = document.getElementById( display ); function displayData(parent, data) { var textElement = document.createTextNode(data.text); parent.appendChild(textElement); } displayData(displayElement, getData()); これら2つのコードを別々にコンパイルした場合、いくつかの問題が発生します。第1に、Closure Compilerは getData() を削除します。(その理由についてはCompilerが使用箇所を見つけられないコードは削除されるを参照してください)第2に、データ表示のコードを処理する際、Closure Compilerは以下のエラーを出力します: input 6 ERROR - variable getData is undefined displayData(displayElement, getData()); データ表示のコードのコンパイル時に getData() 関数にアクセスできないため、Closure Compilerは getData を未定義として扱います。 適切なコンパイルを確実に行うには、アプリケーションに含まれる全てのコードを1回の処理で一緒にコンパイルさせるべきです。Closure Compilerには複数のJavaScriptファイルやJavaScriptコード文字列を入力として指定できるため、ライブラリのコードとそれ以外のコードを単一のコンパイル処理リクエストに同時に渡すことが可能です。 注意:コンパイルされたコードとそうでないコードをアプリケーション内に混在させたい場合、この解決策は役に立ちません。このような状況への対応については、次のコンパイルされたコードと外部コードの間の参照関係を維持するにはを参照してください。 コンパイルされたコードと外部コードの間の参照関係を維持するには ADVANCED_OPTIMIZATIONS レベルでのシンボルのリネームによって、Closure Compilerが処理したコードとそうでないコードの間では互いに対話ができなくなります。コンパイル処理がソースコード内に定義された関数をリネームした後に外部のコードがその関数を呼び出したとしても、それらは変更前の関数名を参照しているため全て失敗するでしょう。同様にコンパイルされたコードからの参照に用いられていた外部コードのシンボル名もまた、Closure Compilerによって変更されていると思われます。 注意してほしいのは、コンパイルされたコードから外部コードへの参照を正しく維持することと、外部コードからコンパイルされたコードへの参照を正しく維持することは、実際には別の問題だということです。これらにはそれぞれに異なった解決策があり、Closure Compilerを最大限に活用するには状況に応じ適切な解決策をとることが重要になります。 外部コードからコンパイル済みコードへの呼び出しについての解決策:エクスポート もしあなたがライブラリとして再利用しようと考えているJavaScriptコードを持っているとして、外部のコンパイルされていないコードからライブラリ内の関数を呼び出せなくなるのなら、Closure Compilerによるコードの短縮を使いたいとは思わないでしょう。 この状況に対する解決策は、残しておきたいシンボルをエクスポートするで示した望まないコードを削除への対策と同じです。要素のエクスポートは要素の削除を防ぐだけでなく、それらを外部コードから利用可能な状態にすることにもなります。 コンパイル済みコードから外部コードへの呼び出しについての解決策:extern あなたが"OpenSocial API"や"Google Maps API"のようなサードパーティのJavaScriptライブラリを利用している場合、コード内で使用されている外部ライブラリ定義のシンボル名がClosure Compilerによってリネームされないようにしなければなりません。例えばOpenSocialライブラリの opensocial.newDataRequest() 関数を呼び出しをClosure Compilerが a.b() に変換してしまうのは、まったく望ましいことではありません。あなたのコードは外部ライブラリで使われているとおりの名前を使う必要があるからです。 Closure Compilerは、外部コードが定義する名前を宣言しそれをリネームさせなくする機能を提供します。この機能は「extern」と呼ばれます。Closure Compilerはextern宣言されたシンボルがコンパイルされたJavaScriptが実行される環境内に存在するものとみなして処理を行います。externについてはこちらで詳しく説明します。
https://w.atwiki.jp/aias-closurecompiler/pages/15.html
トップページ Closure Compiler Service API Closure Compiler Service APIはClosure Compilerの機能をWeb-APIとして提供します。この方式ではユーザプログラムは直接APIサーバとHTTP-POST通信を行い、処理結果を受け取れるようになります。 Closure Compiler Service UIは短いコードを使ってCompilerを試してみる分にはとても良いアプリケーションです。しかしあなたがJavaScriptのコンパイルプロセスを自動化したいと考えていたり、あるいはコンパイル処理を(IDEの拡張機能のようなかたちで)ビルドプロセスの一部として組み込みたいと考えているのであれば、Closure Compiler Service APIの利用は検討する価値があります。 以下では簡単なアプリケーションを作成しながら、何段階かに分けてAPIの使い方を説明します。 Closure Compiler Service APIのリファレンスは、こちらを参照してください。 このページは公式サイトの以下のページを元に作成しました。http //code.google.com/closure/compiler/docs/gettingstarted_api.htmlhttp //code.google.com/closure/compiler/docs/api-tutorial1.htmlhttp //code.google.com/closure/compiler/docs/api-tutorial2.html 目次 APIサーバのURL 最も単純なサンプルアプリケーション APIとの通信 JavaScriptファイルをAPIに渡すには データサイズの制限 APIサーバのURL Closure Compiler Service APIへのリクエストは、下記のURLへ送信してください。 http //closure-compiler.appspot.com/compile 最も単純なサンプルアプリケーション 手はじめに、formを使ってAPIサーバへリクエストを送るアプリケーションを作成してみます。Closure Compiler Service APIをformから呼出すのは実際の利用方法としてはやや不自然ですが、HTTP-POSTによる通信の様子を確認するにはこのやり方が最も簡単です。 下のHTMLをコピーペーストして closure_compiler_test.html というファイルを作成してください。 html body form action="http //closure-compiler.appspot.com/compile" method="POST" p Type JavaScript code to optimize here /p textarea name="js_code" cols="50" rows="5" function hello(name) { // Greets the user alert( Hello, + name); } hello( New user ); /textarea input type="hidden" name="compilation_level" value="WHITESPACE_ONLY" input type="hidden" name="output_format" value="text" input type="hidden" name="output_info" value="compiled_code" br br input type="submit" value="Optimize" /form /body /html 上のformでは4つの必須パラメータが設定されています。(各パラメータの詳細はこちらを参照してください)中でも重要なのは次の2つです。 js_code 処理対象となるJavaScriptコードを指定します。このようにコード文字列を直接送信する方法の他に、JSファイルのURLから入力コードを指定することもできます。後者についてはこちらで詳しく説明します。 compilation_level コンパイルレベルを指定します。この例では最も圧縮率の低い WHITESPACE_ONLY が設定されていますが、より強力にコードの短縮を行いたいのであれば、 SIMPLE_OPTIMIZATIONS や ADVANCED_OPTIMIZATIONS を試してみてください。 closure_compiler_test.html をブラウザで開きます。 Optimize ボタンをクリックしコードをClosure Compiler Service APIへ送ると、下のようなコードがAPIサーバから返却されてくるはずです。返却されるコードはオリジナルコードからコメントと空白・改行を削除したもので、機能はオリジナルと同じですがサイズはかなり小さくなっています: function hello(name){alert("Hello, "+name)}hello(){"New user"}; APIとの通信 次に、プログラムが直にHTTP通信を行うサンプルプログラムを示します: 以下のサンプルはPythonで記述されています。ただし構造自体はごく単純ですので、理解するのにPythonの言語的な知識は特に必要ありません。 #!/usr/bin/python2.4 import httplib, urllib, sys # Define the parameters for the POST request and encode them in # a URL-safe format. params = urllib.urlencode([ ( js_code , sys.argv[1]), ( compilation_level , WHITESPACE_ONLY ), ( output_format , text ), ( output_info , compiled_code ), ]) # Always use the following value for the Content-type header. headers = { "Content-type" "application/x-www-form-urlencoded" } conn = httplib.HTTPConnection( closure-compiler.appspot.com ) conn.request( POST , /compile , params, headers) response = conn.getresponse() data = response.read() print data conn.close このスクリプトはコマンドライン引数として渡されたJavaScriptをコンパイルし、処理されたコードを出力します。上のコードをコピーペーストして compile.py というファイル名で保存、ファイルのパーミッションを変更して実行権限を付与した後、以下のコマンドを実行してください。 $ python compile.py alert("hello");// This comment should be stripped 注意: Windows環境でこのプログラムを実行するには、Pythonのインストールが必要です。詳細はこちらを参照してください。 コマンドはAPIから返却されたコンパイル済みコードを出力します。このサンプルでは WHITESPACE_ONLY レベルが設定されているので、Compilerはコメントを取り除く以外は何もしません。 alert("hello"); このスクリプトについて、注意すべき点をいくつか挙げておきます。 HTTPConnection オブジェクトの request メソッドに渡されるパラメータは、 urllib.urlencode によって事前に全てURLエンコードされています。変数 params の値は次のような文字列です: js_code=alert%28%22hello%22%29%3B%2F%2F+This+comment+should+be+stripped output_info=compiled_code out=text compilation_level=WHITESPACE_ONLY リクエストの Content-type ヘッダは常に application/x-www-form-urlencoded でなければなりません。 JavaScriptファイルをAPIに渡すには 上の例ではコマンドライン引数としてJavaScript文字列をプログラムに渡していました。しかし実業務で使われるJavaScriptコード(その長さは2、3行などすぐに超えてしまうでしょう)を扱うには、この方式はやや無理が有るように思われます。このようなケースでは、 code_url パラメータを使って処理したいJavaScriptファイルのURLを指定するのがよいでしょう。 例として、次のJavaScriptプログラムを取り上げます: /** * A simple script for adding a list of notes to a page. The list diplays * the text of each note under its title. */ /** * Creates the DOM structure for a note and adds it to the document. */ function makeNoteDom(noteTitle, noteContent, noteContainer) { // Create DOM structure to represent the note. var headerElement = document.createElement( div ); var headerText = document.createTextNode(noteTitle); headerElement.appendChild(headerText); var contentElement = document.createElement( div ); var contentText = document.createTextNode(noteContent); contentElement.appendChild(contentText); var newNote = document.createElement( div ); newNote.appendChild(headerElement); newNote.appendChild(contentElement); // Add the note s DOM structure to the document. noteContainer.appendChild(newNote); } /** * Iterates over a list of note data objects and creates a DOM */ function makeNotes(data, noteContainer) { for (var i = 0; i data.length; i++) { makeNoteDom(data[i].title, data[i].content, noteContainer); } } function main() { var noteData = [ {title Note 1 , content Content of Note 1 }, {title Note 2 , content Content of Note 2 }]; var noteListElement = document.getElementById( notes ); makeNotes(noteData, noteListElement); } main(); このプログラムをひとかたまりの大きな文字列としてAPIに渡すより、ファイル名を指定するだけの方が便利です。それには以下のようにします: 上のコードをファイルに保存します。 そのファイルをWEBからアクセス可能な場所(あなたのWebサーバなど)に置きます。 APIとの通信で作ったデモを修正し、 js_code を code_url に置き換えます。 params = urllib.urlencode([ ( code_url , sys.argv[1]), # --- This parameter has a new name! ( compilation_level , WHITESPACE_ONLY ), ( output_format , text ), ( output_info , compiled_code ), ]) 以下のコマンドを実行すると、 http //example.com/yourJs.js というURLがClosure Compilerに渡されます。Compilerは指定されたURLからファイルを取得してコンパイルし、その結果を返却します。 $ python compile.py http //example.com/yourJs.js 1つのリクエストの中に複数の code_url パラメータを含めることができます: params = urllib.urlencode([ ( code_url , http //example.com/yourJsPart1.js), ( code_url , http //example.com/yourJsPart2.js), ( compilation_level , WHITESPACE_ONLY ), ( output_format , text ), ( output_info , compiled_code ), ]) ファイルは指定順に結合されてから、1つのコードとしてコンパイルされます。尚、 code_url と js_code も1つのリクエスト内で同時に使用できます。 データサイズの制限 Closure Compiler Service APIに送信できるデータのサイズには、以下の2種類の制限が設けられています。 POSTデータのサイズの合計は200,000バイトまで クライアントがAPIに送信するPOSTデータのサイズは200,000バイト以内でなければなりません。この制限を超過した場合はサーバエラー 8 POST data too large. が返却されます。もし js_code パラメータで送信しているソースコードの量が多い場合は、ファイルに分離した上でそれを code_url パラメータで参照するようにしてください。 コードの総量は1,024,000バイトまで APIが1回のリクエストで処理できるコードの総量は1,024,000バイトとされています。ここでいうコードの総量とは、 code_url 及び externs_url に指定された全てのファイル内のコード、 js_code 及び js_externs に指定された全てのコード文字列の合計を指します。 この制限を超過した場合はサーバエラー 9 File too large. が返却されます。 このエラーが発生する場合は、ローカルマシン上でのClosure Compiler Applicationの使用を検討してください。
https://w.atwiki.jp/aias-closurecompiler/pages/14.html
トップページ Closure Compiler Service UI Closure Compiler Service UIはClosure Compilerの機能をブラウザベースのWebアプリケーションとして提供します。短いコードをClosure Compiler Service UIに投入してその結果を確認してみることは、Compilerの動作を理解するのには最適の方法といえるでしょう。 このページは公式サイトのこちらを元に作成しました。 目次 使い方 JavaScriptファイルをコンパイルする コンパイル結果をファイルとして取得する コード入力欄先頭のコメントについて データサイズの制限 オプションリファレンス Add a URL Optimization Formatting 使い方 ブラウザで下のURLにアクセスします。 http //closure-compiler.appspot.com/ Closure Compiler Service UIの画面が表示されます。左下のコード入力欄には、シンプルな Hello World 関数が予めサンプルとして入力されています。通常はここにユーザのコードが上書きされることになります。 そのまま Compile ボタンをクリックすると、コンパイルされたコードが出力されます。 以上で、オリジナルの関数と同じ機能をもつ、より小さなJavaScriptコードを手に入れることがきました。コメント・空白の削除とローカルシンボルのリネームによって、Closure Compilerは92バイトあったコードを55バイトにまで小さくしました。 JavaScriptファイルをコンパイルする Closure Compiler UIは1つまたは複数のJavaScriptファイルを入力ソースとしてコンパイルを実行することもできます。ただしそのJavaScriptファイルは外部からHTTPでアクセスできる位置に公開されている必要があります。 Add a URL の右のボックスに指定したいJSファイルのURLを入力します。 サンプルとして以下のファイルが用意されています。 http //code.google.com/closure/compiler/samples/tutorial2.js Add ボタンをクリックします。入力欄の先頭コメントに、指定ファイルを値にもつ @code_url パラメータが追加されます。指定したいファイルが複数ある場合は、1.~2.の手順を必要なだけ繰り返します。同じファイルを2度指定した場合はコンパイル時にエラーとなりますので注意してください。 複数指定されたファイルは指定順に結合された後にコンパイルされます。またファイル指定と入力欄へのコード入力を同時に行った場合は、結合されたファイル内コードの後ろに入力コードが結合され、その後コンパイルが実行されます。 コンパイル結果をファイルとして取得する より使いやすいように、Closure Compiler Service UIはコンパイル結果をJSファイルとして1時間の間サーバ上に保持しています。このファイルにアクセスするには、コード出力欄の上にあるリンクのURLをコピーしてください。(The code may also be accessed at {filename}と表示されているところです)デフォルトの出力ファイル名は default.js ですが、入力欄の先頭部分にある @output_file_name パラメータの値を直接編集することで変更可能です。1時間の間に入力コードが変更されて再度コンパイルが行われた場合、Closure Compilerはサーバ上のファイルを新しい結果で上書きします。 アプリケーションのテスト環境からコンパイル結果へ直接リンクすることで、手軽にコードの動作チェックを行えるようになります。しかし決してこの機能を本番環境で使用しないでください。 注意: 過大な負荷を避けるため、あるユーザが一定時間内で連続してClosure Compiler Service UIを利用できる回数には制限が設けられています。もし以下のようなメッセージが表示された場合は、あなたがその制限を一時的にオーバーしてしまったことを示しています: Too many compiles performed recently. Try again later コード入力欄先頭のコメントについて コード入力欄の先頭にある「 // ==ClosureCompiler 」から始まる一連のコメントは、コンパイル時にコードと共にサーバに送信されるパラメータを表しています。この値は画面上のオプション設定変更に伴って即座に変更されていきますが、逆にこのコメントを直接書き換えて設定を変更することもできます。このときコメントと画面の設定が矛盾する可能性がありますが、コメント上の指定の方が優先されるようです。 コードのコピーペーストなどでこのコメントが一時的に消えてしまっても、送信時に自動的に再作成されます。ただし出力ファイル名( @output_file_name )の変更や入力ファイルの指定( @output_file_name )は復活しませんので注意してください。 データサイズの制限 Closure Compiler Service UIからサーバに送信できるデータのサイズは最大200,000バイトに制限されています。ここでいうデータには、入力欄に記述されたコードとアプリケーションが作成する各種のコンパイルパラメータが含まれます。データサイズが制限を超過している場合、コンパイル処理は失敗します。 入力コードのうち、サイズ制限の対象となるのは入力欄に直接記入された分のみです。従ってコードのサイズが大きすぎる場合はJavaScriptファイルをコンパイルするで示されている手順に従ってコードをJSファイルとして指定するようにしてください。(なお、コンパイルパラメータのサイズは全部合わせてもせいぜい100バイト程度です) オプションリファレンス Add a URL 入力ファイルのURLを指定します。詳しくはこちらを参照してください。 Optimization コードのコンパイルレベルを指定します。 Formatting 出力されるコンパイル済みJavaScriptコードの整形方式を指定します。 Pretty print チェックが付いている場合、Closure Compilerは人間が読み易くなるよう出力コードに改行とインデントを付加します。以下にその例を示します: function hello(a) { alert("Hello, " + a) } hello("New user"); Pretty print がチェックされていない場合は次のようになります。 function hello(a){alert("Hello, "+a)}hello("New user"); Print input delimiter チェックが付いている場合、Closure Compilerは各入力ファイルと入力欄に設定されたJavaScriptコードの範囲を示す文字列を出力コード内に付加します。例えば2つのファイルを一緒にコンパイルした場合、出力は次のようになります: // Input 0 alert("hi"); // Input 1 alert("bye"); ファイル間の境界を表す区切り文字としてClosure Compilerは「 // Input X 」を挿入します。これらの区切り文字はコメントであり、JavaScriptの動作を妨げない点に注意してください。 入力ファイルの区切りには、例えば各ファイルのうちコードサイズの圧縮に最も貢献しているものの把握を助けるというような用途が考えられます。
https://w.atwiki.jp/aias-closurecompiler/pages/16.html
トップページ Closure Compiler Application Closure Compiler ApplicationはJavaで実装されたコマンドラインアプリケーションとしてClosure Compilerの機能を提供します。他の提供形式と比べ、Closure Compiler Applicationは以下の点で優れています: 外部サーバとの通信を一切行わず、単独で動作します。このため導入に際して外部との通信経路を考慮しなくてよく、また入力ファイルをWEBに公開する必要もありません。 入力データサイズの制限はありません。 細かいオプションが提供されており、Closure Compilerのもつ機能を最大限に利用することができます。 ある程度以上の規模のシステムでは、Closure Compiler Applicationの導入をお薦めします。 Closure Compiler Service APIのリファレンスは、こちらを参照してください。 このページは公式サイトのこちらを元に作成しました。 目次 インストール 使い方 Antタスクを利用する サンプルビルドファイル リファレンス インストール Closure Compiler Applicationの実行にはJavaの実行環境( JRE6 以上)が必要です。まだインストールされていない場合は、事前にその作業を行ってください。 下記のURLから compiler.jar をダウンロードし、任意のディレクトリに保存、展開します。これでインストールは完了です。 http //closure-compiler.googlecode.com/files/compiler-latest.zip ここから、Closure Compiler Applicationの過去のバージョンをダウンロードできます。 使い方 Closure Compiler Applicationは普通のJavaアプリケーションですので、実行方法自体は至ってシンプルです。以下ではごく短いサンプルコードを使ってコンパイルの手順を説明します。 以下のJavaScriptコードを内容とする hello.js というファイルを作成し、 compiler.jar と同じディレクトリ(ここでは closure-compiler ディレクトリとします)に保存します。 // A simple function. function hello(longName) { alert( Hello, + longName); } hello( New User ); closure-compiler ディレクトリで以下のコマンドを実行します。 java -jar compiler.jar --js hello.js --js_output_file hello-compiled.js このコマンドは hello-compiled.js という名前の新しいファイルを生成します。このファイルの中身は圧縮されたJavaScriptコードです。 function hello(a){alert("Hello, "+a)}hello("New User"); コマンドのオプションでコンパイルレベルを明示的に指定していないため、この例ではデフォルトのコンパイルレベルである SIMPLE_OPTIMIZATIONS が適用されています。 SIMPLE_OPTIMIZATIONS レベルでは、全てのコメント・改行・不要な空白が削除されるほか、ローカル変数が短くリネームされます。上の結果を見ると、実際に元のコードでは longName という名前だった変数が a に変わっているのがわかります。 下のように hello-compiled.js をHTMLに読み込んでみれば、コンパイルされたJavaScriptコードが正常に動作していることが確認できます。このHTMLファイルをブラウザにロードすると挨拶メッセージが表示されるはずです: html head title Hello World /title /head body script src="hello-compiled.js" /script /body /html Antタスクを利用する compiler.jar には組み込みのAntタスクが含まれています。残念ながら使える機能はそれほど多くありませんが、とても簡単に利用できます。 この部分は公式サイトのこちらを元に作成しました。 Antそのものの説明は公式サイトやWeb上の情報を参照してください。 サンプルビルドファイル ?xml version="1.0"? project basedir="." default="compile" taskdef name="jscomp" classname="com.google.javascript.jscomp.ant.CompileTask" classpath="../build/compiler.jar"/ target name="compile" jscomp compilationLevel="simple" warning="verbose" debug="false" output="output/file.js" externs dir="${basedir}/src" file name="extern.js"/ /externs sources dir="${basedir}/src" file name="simple1.js"/ file name="simple2.js"/ /sources sources dir="${basedir}/other" file name="simple3.js"/ /sources /jscomp /target /project リファレンス 属性 名前 説明 compilationlevel --compilation_levelオプションに相当し、コンパイルレベルを whitespace 、 simple 、 advanced のいずれかで指定します。デフォルトは simple です。 customexternsonly --use_only_custom_externsオプションに相当し、 true を指定するとデフォルトのexternファイルを使用しません。デフォルトは false です。 debug --debugオプションに相当し、 true を指定するとデバッグ用の出力を行ないます。デフォルトは false です。 output --js_output_fileオプションに相当し、コンパイル結果の出力ファイル名を指定します。 warning --warning_levelオプションに相当し、エラーと警告の出力量を quiet 、 default 、 verbose のいずれかで指定します。デフォルトは default です。 ネストできる要素このタスクには次の2つの要素をネストさせることができます。これらはFileList型の要素で、Compilerに渡されるファイルのリストを表します。 名前 説明 externs コンパイルに使用するexternファイルを指定します。 sources コンパイル対象となるJavaScriptファイルを指定します。 externs と sources は共に複数指定可能です。
https://w.atwiki.jp/aias-closurecompiler/pages/24.html
トップページ Closure Compiler Service API Closure Compiler Service API リファレンス このページでは、Closure Comiler Service APIのインターフェース仕様について詳細に説明します。APIの使用方法についてはこちらを参照してください。 コンパイルされたコードやAPIからの様々な情報を取得するためには、HTTP POSTリクエストを下記のURLに送る必要があります。 http //closure-compiler.appspot.com/compile リクエストボディは「必須リクエストパラメータ」に列挙されたパラメータを必ず含んでいなければなりません。また「省略可能なリクエストパラメータ」に列挙されたパラメータを含めることもできます。 もしサーバがリクエストの処理に失敗した場合には、サーバエラーメッセージが返却されます。それらのメッセージについては「サーバエラーメッセージ」で説明されています。 このページは公式サイトのこちらを元に作成しました。 目次 必須リクエストパラメータ js_code code_url compilation_level output_format output_info 省略可能なリクエストパラメータ js_externs externs_url exclude_default_externs output_file_name formatting use_closure_library warning_level サーバエラーメッセージ 必須リクエストパラメータ js_code コンパイルするJavaScriptコードをパラメータの値として直接指定します。リクエストにはこのパラメータかcode_urlパラメータを少なくとも1つ以上含んでいなければなりません。両方指定することも可能です。 js_code パラメータを複数指定することもできます。 code_url コンパイルするJavaScriptコードを内容にもつファイルのURLを指定します。リクエストにはこのパラメータかjs_codeパラメータを少なくとも1つ以上含んでいなければなりません。両方指定することも可能です。複数の入力ファイルを指定するため、リクエストには複数の code_url パラメータを含めることができます。 ファイルのURLはWEBからアクセス可能な場所でなければならない点に注意してください。 code_url パラメータの使用方法については、こちらでも詳しく説明しています。 compilation_level JavaScriptに適用する圧縮と最適化の度合い(コンパイルレベル)を指定します。以下の3つのレベルがあります: WHITESPACE_ONLY JavaScriptから空白・改行とコメントだけを削除します。 SIMPLE_OPTIMIZATIONS 圧縮と最適化を実行しますが、ローカル変数のみをリネームし、コンパイルされたコードとそれ以外のコードとの連携を妨げません。 ADVANCED_OPTIMIZATIONS グローバル領域を含むシンボルのリネームを行い、最高レベルの圧縮度を実現します。 ADVANCED_OPTIMIZATIONS レベルを使用する場合、外部のシンボルとの参照関係を維持するために追加の手順が必要となる可能性があります。詳しくはこちらを参照してください。 各コンパイルレベルで入力コードに求められるコーディングルールについては、こちらで詳しく説明されています。 output_format Closure Compilerサービスの出力フォーマットを指定します。指定可能なフォーマットは以下の3つです: xml 処理結果をXML形式で返却します。出力されるXMLは以下のような形式になります: compilationResult compiledCode var a="hello";alert(a); /compiledCode statistics originalSize 98 /originalSize compressedSize 35 /compressedSize compileTime 0 /compileTime /statistics /compilationResult compiledCode 要素の内容はClosure Compilerが生成した圧縮済みのJavaScriptコードです。この要素はoutput_infoパラメータの値に compiled_code が指定されたときのみ出力されます。同様に、 statistics 要素は output_info パラメータの値に statistics が指定されたときのみ出力されます。 output_info パラメータの値に warnings が指定されCompilerが警告を生成した場合、出力結果には warning 要素が含まれます: compilationResult ... warnings warning type="JSC_NO_SIDE_EFFECT" file="default.js" lineno="12" charno="3" line="delete 1;" warning 1 /warning warning type="JSC_UNUSED_VAR" file="default.js" lineno="13" charno="13" line="delete 1;" warning 2 /warning /warnings ... /compilationResult output_info パラメータの値に errors が指定され、入力コードが文法エラーやその他コンパイル処理を妨害するような問題を含んでいた場合、Closure Compilerは errors 要素を出力します。 errors 要素は以下のようなものです: compilationResult ... errors error type="JSC_NO_SIDE_EFFECT" file="default.js" lineno="12" charno="3" line="var x=- hello ;" error 1 /error error type="JSC_UNUSED_VAR" file="default.js" lineno="13" charno="13" line="var x=- hello " error 2 /error /errors ... /compilationResult error 要素と warning 要素の file 、 line 、 col 属性はClosure Compilerがそのエラーに遭遇した位置を示しています。 もしClosure Compilerが処理を停止させるようなエラーに見舞われた場合、以下のような出力結果が返却されます。このタイプのエラーは、JavaScriptコードの内容ではなくリクエストそのものに問題があることを示しています。詳しくはこちらを参照してください: compilationResult serverErrors error code="1" Over quota /error /serverErrors /compilationResult json 処理結果をJSON(JavaScript Object Notation)形式の文字列で返却します。この文字列をJavaScriptとして評価すると、1個のJavaScriptオブジェクトが得られます。出力されるJSONデータは以下のような形式です: { "compiledCode" /* raw code here */, "errors" [ {"charno" 4321, "error" "ERROR You failed.", "lineno" 1234, "file" "default.js", "type" "ERROR_TYPE", "line" "var x=- hello ;"} ], "warnings" [ {"charno" 4321, "lineno" 1234, "file" "default.js", "type" "ERROR_TYPE", "warning" "Warning You did something wrong!", "line" "delete 1;"} ], "serverErrors" [ {"code" 123,"error" "Over quota"} ], "statistics" { "originalSize" 10, "compressedSize" 3000, "compileTime" 10 } } JSON形式とXML形式はよく似ています:XMLの各タグはJSONオブジェクト内の同名のプロパティに相当します。 text text フォーマットを指定すると、タグやJSONブラケットを取り除いたシンプルなテキスト形式の出力結果が返却されます。 output_info Compilerから取得するデータの種類を指定します。指定できるのは以下の4種類です: compiled_code 入力されたJavaScriptコードを圧縮・最適化したものです。 warnings JavaScript内のバグの可能性を警告するメッセージです。 errors JavaScript内の文法エラーやその他のエラーを示すメッセージです。 statistics Closure Compilerが行った圧縮処理の達成度に関する情報です。出力形式がXMLの場合、以下のフォーマットの統計情報が返却されます: compilationResult ... statistics firstStatisticName 24 /firstStatisticName secondStatisticName 15 /secondStatisticName /statistics /compilationResult 省略可能なリクエストパラメータ js_externs js_externs パラメータはコンパイルされるコードが使用している外部プログラム内のシンボル名をリネームから保護するために使用します。このパラメータの値にはリネームされたくない関数やその他のシンボルを宣言するJavaScriptコードを指定します。このパラメータが効果をもつのはcompilation_levelパラメータの値が ADVANCED_OPTIMIZATIONS の場合のみです。詳しくは「extern宣言」を参照してください。 externs_url externs_url パラメータはコンパイルされるコードが使用している外部プログラム内のシンボル名をリネームから保護するために使用します。このパラメータにはリネームされたくない関数やその他のシンボルを宣言するJavaScriptコードが記述されたファイルのURLを指定します。ファイル内に宣言されたシンボルはjs_externsパラメータに直接列挙された場合と全く同じ方法で保護されます。このパラメータが効果をもつのはcompilation_levelパラメータの値が ADVANCED_OPTIMIZATIONS の場合のみです。詳しくは「extern宣言」を参照してください。 リクエスト内に複数の externs_url パラメータを定義できます。 exclude_default_externs Closure Compilerは document オブジェクトやそのメソッドのような標準的なシンボルを宣言した定義情報を持っており、デフォルトではそれを使用してシンボル名の保護を行います。もしこれらの標準的なextern宣言を使いたくない場合は、このパラメータにtrueを設定してリクエストに含めてください。デフォルトのextern宣言に関する詳細はこちらを参照してください。 output_file_name このパラメータを指定すると、Closure Compilerはコンパイルされたコードをサーバ上に1時間キャッシュし、特別なURLを通してそれを利用可能にします。ファイルがキャッシュされている間、このURLにアクセスしコンパイルされたコードをテストすることができます。URLは以下のような形式です: http //closure-compiler.appspot.com/code/bf067f356d510e1c7b81347eb84f65d2/[output_file_nameの値] formatting 出力されるコンパイル済みJavaScriptコードの整形方式を指定します。このパラメータは pretty_print または print_input_delimiter のどちらかの値をとりますが、同一のリクエスト内に2つの formatting パラメータを含めれば、これらを同時に指定することが可能です。 pretty_print と print_input_delimiter は整形方法のそれぞれ異なる側面に関する指示であるため、重複しても互いに影響しあうことがありません。 pretty_print リクエストが pretty_print を値にもつ formatting パラメータを含む場合、Closure Compilerは人間が読み易くなるよう出力コードに改行とインデントを付加します。以下にその例を示します: function hello(a) { alert("Hello, " + a) } hello("New user"); pretty_print がない場合は次のようになります。 function hello(a){alert("Hello, "+a)}hello("New user"); print_input_delimiter リクエストが print_input_delimiter を値にもつ formatting パラメータを含む場合、Closure Compilerは各入力ファイルの範囲を示す文字列を出力コード内に付加します。例えば2つのファイルを一緒にコンパイルした場合、出力は次のようになります。 // Input 0 alert("hi"); // Input 1 alert("bye"); ファイル間の境界を表す区切り文字としてClosure Compilerは「 // Input X 」を挿入します。これらの区切り文字はコメントであり、JavaScriptの動作を妨げない点に注意してください。 code_urlパラメータによって与えられた入力ファイルは、出力コード内で各ファイルに対応するセクションに区切られます。一方js_codeパラメータによって与えられた入力コードは、全ての js_code パラメータの値を結合したものが1つのセクションにまとめられます。入力ファイルの区切りには、例えば各ファイルのうちコードサイズの圧縮に最も貢献しているものの把握を助けるというような用途が考えられます。 use_closure_library use_closure_library パラメータを true に設定すると、compilerはソース内の goog.require() を探し出し、そのステートメントが要求しているClosure Libraryのコードを出力に追加します。また、Closure Libraryのコードのために特に設計された最適化を実行します。Closure Libraryに関する詳細はClosure Library documentationを参照してください。 goog.require() 関数に関する詳細はFinding Your Way around the Closure Libraryを参照してください。 use_closure_library パラメータのデフォルト値は false です。 warning_level コード内の問題になりそうな箇所に関する情報の出力量を指定します。 warning_level パラメータはoutput_infoパラメータの値に warning が一緒に指定されている場合のみ有効です。警告レベルには以下の3種類があります: QUIET 現在のコンパイルでのcompilation_levelに基づく最適化パスで生成された文法エラーと警告のみを出力します。 DEFAULT 最適化パスで生成された文法エラーと警告に加え、最終的に選択されたコードチェックパスで生成された警告を出力します。 warning_level パラメータのデフォルト値です。 VERBOSE 最適化パスで生成された文法エラーと警告に加え、実行された全てのコードチェックパスで生成された警告を出力します。 サーバエラーメッセージ サーバがリクエストの処理に失敗した場合、下表に示すサーバエラーメッセージのうちのいずれかが返却されます。これらのエラーはCompilerが生成するエラーや警告とは異なるものである点に注意してください。Compilerが生成するエラーや警告はJavaScript内で見つかった問題を表しますが、サーバエラーのメッセージはリクエストそのもののエラーによりCompilerがコードを全く処理出来ないことを示しています。 コードの内容が原因で発生するエラーと警告については、こちらを参照してください。 エラーコード メッセージ 意味 2 Unknown output mode. output_formatパラメータの値が xml 、 json 、 text 以外です。 4 Unknown compression level. compilation_levelパラメータの値が WHITESPACE_ONLY 、 SIMPLE_OPTIMIZATIONS 、 ADVANCED_OPTIMIZATIONS 以外です。 8 POST data too large. APIに送信されたデータのサイズが200,000バイトを超えています。Closure Compiler Service UIとAPIではサービスとの通信にHTTP-POSTリクエストを使用しますが、その際リクエストデータの合計が200,000バイトを超えてはなりません。APIでは、この制限はリクエストパラメータに設定された全てのテキストの合計サイズに適用されます。UIでは、この制限はソースコードと @code_url のようなコンパイルオプションを合わせたものに適用されます。もしリクエストが大きすぎた場合はソースコードをファイルに分離した上でそれをcode_urlパラメータで参照するようにするか、ローカルマシン上でClosure Compiler Applicationを使用してください。 9 File too large. コードの総量が1,024,000バイトを超えています。コードの総量とは、全てのcode_urlに指定されたファイル、全てのexterns_urlに指定されたファイル、全てのjs_codeとjs_externsに指定されたコードの合計を指します。 10 Cannot retrieve content from URL. このエラーはAPIがcode_urlパラメータで指定されたJavaScriptファイルまたはexterns_urlパラメータで指定されたexternファイルを取得できなかった場合に発生します。URLが正しいか、またファイルの参照を許可するように権限が設定されているかを確認してください。 12 URL is not formed properly. code_urlパラメータまたはexterns_urlパラメータに指定されたURLが不正な形式であることを表します。 13 No output information to produce, yet compilation was requested. output_infoパラメータが指定されていません。 14 Unknown output_info value output_infoパラメータの値が compiled_code 、 warnings 、 statistics 以外です。 16 Unknown warning level warning_levelパラメータの値が QUIET 、 DEFAULT 、 VERBOSE 以外です。 17 Unknown formatting option. formattingパラメータの値が pretty_print 、 print_input_delimiter 以外です。 18 Unknown parameter in HTTP request 定義されていないパラメータが含まれています。 19 Illegal value for output_file_name 出力ファイル名が1文字の数字、文字、ドット、アンダースコア、ダッシュだけからなっているか、または2つの連続したドット(..)を含んでいます。 22 Too many compiles performed recently. Try again later. このマシンから送信されているコンパイルリクエストが多すぎます。コンパイルの実行が可能になるには1時間必要です。 23 Compiler exception (with backtrace) Compilerがクラッシュしました。エラーテキストにはGoogleのデバッグ作業の助けになる情報が含まれています。 24 Unsupported input resource type リソースタイプが「http 」でなかったため、入力ファイルを取得できませんでした。
https://w.atwiki.jp/anime_wiki/pages/19838.html
1994年3月OVA発売開始。 監督 村山靖、加戸誉夫 原作・ゲストキャラクターデザイン 麻宮騎亜 キャラクターデザイン もりやまゆうじ、大島康弘 ネリマクイーン・キャラクターデザイン 武内直子 美術監督 中座洋次 背景協力 南郷洋一 色彩設計 三笠修、永井留美子 撮影監督 沖野雅英 特殊効果 榊原豊彦 編集 関一彦、船見康恵 音響監督 渡辺淳 録音 丸山光義 音響効果 神保大介 音楽 大森俊之 オープニングアニメーション・エンディングイラスト もりやまゆうじ アニメーション制作 アニメイトフィルム、スタジオ・ファンタジア 制作協力 スタジオ・ファンタジア 脚本 村山靖 加戸誉夫 菊池通隆 絵コンテ 村山靖 加戸誉夫 菊池通隆 演出 村山靖 作画監督 大島康弘 吉田徹 ■関連タイトル DVD Compiler 陰の章 陽の章 Festa Music clips In Trackdown 原作コミック コンパイラ 1 コンパイラ ゴールデンベストデベスト COMPILER 音楽美女大図 イメージアルバム Compiler Kindleまとめ買い コンパイラ
https://w.atwiki.jp/aias-closurecompiler/pages/25.html
トップページ Closure Compiler Application Closure Compiler Application コマンドラインオプション このページでは、Closure Comiler Applicationのコマンドラインオプションについて詳細に説明します。Closure Comiler Applicationの使用方法についてはこちらを参照してください。 このページは--helpオプションで出力されるヘルプの情報を元に作成しました。尚、管理人が使い方を理解できなかったオプションについてはヘルプの原文(英語)をそのまま記載しています。 目次 主なオプション --charset --compilation_level --externs --formatting --help --js --js_output_file --manage_closure_dependencies --use_only_custom_externs --warning_level その他のオプション --compute_phase_ordering --create_name_map_files --create_source_map --debug --define (--D, -D) --jscomp_dev_mode (--dev_mode) --jscomp_error --jscomp_off --jscomp_warning --logging_level --module --module_output_path_prefix --module_wrapper --output_manifest --output_wrapper --output_wrapper_marker --print_ast --print_pass_graph --print_tree --process_closure_primitives --property_map_input_file --property_map_output_file --summary_detail_level --third_party --variable_map_input_file --variable_map_output_file 主なオプション --charset --charset VAL 全ての入力ファイルの文字エンコーディングを指定します。(入力ファイルは全て同じ文字エンコーディングを使用していなくてはなりません。)省略した場合、ファイルの文字エンコーディングは UTF-8 であると解釈されます。 --compilation_level --compilation_level [WHITESPACE_ONLY|SIMPLE_OPTIMIZATIONS|ADVANCED_OPTIMIZATIONS] JavaScriptに適用する圧縮と最適化の度合い(コンパイルレベル)を指定します。以下の3つのレベルがあります: WHITESPACE_ONLY JavaScriptから空白・改行とコメントだけを削除します。 SIMPLE_OPTIMIZATIONS WHITESPACE_ONLY での処理に加えてローカル変数のリネームを行い、コードの圧縮と最適化を行います。このレベルではコンパイルされたコードとそれ以外のコードとの連携が妨げられることはありません。 ADVANCED_OPTIMIZATIONS SIMPLE_OPTIMIZATIONS での処理に加えてグローバル領域を含むシンボルのリネームを行い、最高レベルの圧縮度を実現します。 ADVANCED_OPTIMIZATIONS を使用する場合、外部のシンボルとの参照関係を維持するために追加の手順を実行する必要があります。 ADVANCED_OPTIMIZATIONS レベルのコンパイル処理が求める様々な制約については、こちらを参照してください。 オプション指定を省略した場合は SIMPLE_OPTIMIZATIONS が適用されます。 --externs --externs VAL コンパイル対象となっていないコード上で定義されたシンボル名がリネームされるのを防ぐためのexternファイルを指定します。このオプションが効果をもつのはcompilation_levelオプションの値が ADVANCED_OPTIMIZATIONS の場合のみです。externに関して詳しくはこちらを参照してください。 複数のexternファイルがある場合はこのオプションを複数指定してください。 --formatting --formatting [pretty_print|print_input_delimiter] 出力されるコンパイル済みJavaScriptコードの整形方式を指定します。このオプションは pretty_print または print_input_delimiter のどちらかの値をとりますが、2つの formatting オプションによってこれらを同時に指定することが可能です。 pretty_print と print_input_delimiter は整形方法のそれぞれ異なる側面についての指示であるため、重複しても互いに影響しあうことがありません。 pretty_print 人間が読み易くなるよう出力コードに改行とインデントを付加します。以下にその例を示します: function hello(a) { alert("Hello, " + a) } hello("New user"); pretty_print がない場合は次のようになります。 function hello(a){alert("Hello, "+a)}hello("New user"); print_input_delimiter 各入力ファイルの範囲を示す文字列を出力コード内に付加します。例えば2つのファイルを一緒にコンパイルした場合、出力は次のようになります: // Input 0 alert("hi"); // Input 1 alert("bye"); ファイル間の境界を表す区切り文字としてClosure Compilerは「 // Input X 」を挿入します。これらの区切り文字はコメントであり、JavaScriptの動作を妨げない点に注意してください。入力ファイルの区切りには、例えば各ファイルのサイズ圧縮度の把握を助けるというような用途が考えられます。 --help --help コンソールにオプションのリストを表示し、処理を終了します。 --js --js VAL 入力JavaScriptファイル名を指定します。複数の入力ファイルがある場合はオプションを複数指定してください。このオプションが未指定の場合、出力結果は空文字列となります。 --js_output_file --js_output_file VAL 出力ファイル名を指定します。省略した場合、処理結果は標準出力に出力されます。 --manage_closure_dependencies --manage_closure_dependencies [true|false] true を指定した場合、 goog.provide で定義されたシンボルは必ずそれを要求する goog.require より前に存在する、という関係に基づいて自動的にファイルのソートを実行します。もし定義されたシンボルが一度も要求されなかった場合、そのシンボルはコンパイル結果から除外されます。このオプションの詳細についてはこちらを参照してください。デフォルトは false です。 --use_only_custom_externs --use_only_custom_externs [true|false] Closure Compilerは document オブジェクトやそのメソッドのような標準的なシンボルを宣言したexternファイルを持っており、デフォルトではそれを使用してシンボル名の保護を行います。 --use_only_custom_externs オプションに true を指定するとこれらの標準的なexternを使用しなくなります。デフォルトのextern宣言に関する詳細はこちらを参照してください。デフォルトは false です。 --warning_level --warning_level [QUIET|DEFAULT|VERBOSE] コード内の問題になりそうな箇所に関する情報の量を指定します。警告レベルには以下の3種類があります: QUIET 現在のコンパイルでのcompilation_levelに基づく最適化パスで生成された文法エラーと警告のみを出力します。 DEFAULT 最適化パスで生成された文法エラーと警告に加え、選択されたコードチェックパス上で生成された警告を出力します。 warning_level オプションのデフォルト値です。 VERBOSE 最適化パスで生成された文法エラーと警告に加え、実行された全てのコードチェックパス上で生成された警告を出力します。 エラーと警告は標準エラー出力に出力されます。 その他のオプション --compute_phase_ordering --compute_phase_ordering Runs the compile job many times, then prints out the best phase ordering from this run. --create_name_map_files --create_name_map_files [true|false] If true, variable renaming and property renaming map files will be produced as {binary name}_vars_map.out and {binary name}_props_map.out. Note that this flag cannot be used in conjunction with either variable_map_output_file or property_map_output_file. --create_source_map --create_source_map VAL Closure Inspectorのソースマッピング機能で使用するソースマップファイルの出力ファイルパスを指定します。ソースマップファイルにはコンパイルされたコードとオリジナルのコードとの位置関係がマッピングされています。指定に %output% という文字列を含めると、それはコンパイル結果の出力ファイル名がその位置に展開されるプレースホルダとして機能します。 --debug --debug [true|false] true を指定するとデバッグ用の出力を行ないます。デフォルトは false です。 --define (--D, -D) --define (--D, -D) VAL @define タグが付けられた変数を指定の値で上書きします。このオプションの値の書式は name [= val ] で、 name には @define タグが付与された変数の名前を、 val には置き換えたい値を指定します。 val の値にはブール値、数値、シングルクォートされた文字列(ただしシングルクォートを含まない)を使用できます。 val が省略された場合は true が適用されます。 このオプションについてはこちらも参照してください。 --jscomp_dev_mode (--dev_mode) --jscomp_dev_mode (--dev_mode) [OFF|START|START_AND_END|EVERY_PASS] Turns on extra sanity checks. --jscomp_error --jscomp_error VAL Make the named class of warnings an error. Options accessControls, checkRegExp, checkTypes, checkVars, deprecated, fileoverviewTags, invalidCasts, missingProperties, nonStandardJsDocs, strictModuleDepCheck, undefinedVars, unknownDefines, visibility --jscomp_off --jscomp_off VAL Turn off the named class of warnings. Options accessControls, checkRegExp, checkTypes, checkVars, deprecated, fileoverviewTags, invalidCasts, missingProperties, nonStandardJsDocs, strictModuleDepCheck, undefinedVars, unknownDefines, visibility --jscomp_warning --jscomp_warning VAL Make the named class of warnings a normal warning. Options accessControls, checkRegExp,checkTypes, checkVars, deprecated, fileoverviewTags, invalidCasts, missingProperties, nonStandardJsDocs, strictModuleDepCheck, undefinedVars, unknownDefines, visibility --logging_level --logging_level VAL The logging level (standard java.util.logging.Level values) for Compiler progress. Does not control errors or warnings for the JavaScript code under compilation. --module --module VAL A javascript module specification. The format is name num-js-files [ [ dep ,...][ ]]]. Module names must be unique. Each dep is the name of a module that this module depends on. Modules must be listed in dependency order, and js source files must be listed in the corresponding order. Where --module flags occur in relation to --js flags is unimportant --module_output_path_prefix --module_output_path_prefix VAL Prefix for filenames of compiled js modules. module-name .js will be appended to this prefix. Directories will be created as needed. Use with --module. --module_wrapper --module_wrapper VAL An output wrapper for a javascript module (optional). The format is name wrapper . The module name must correspond with a module specified using --module. The wrapper must contain %s as the code placeholder. --output_manifest --output_manifest VAL 値としてファイル名を指定し、コンパイルされた全てのファイルのリストをそこに出力します。--manage_closure_dependenciesオプションが有効な場合、使用されなかったためにコンパイル対象にならなかったファイルはリストから除外されます。The %outname% placeholder expands to the js output file. If you re using modularization, using %outname% will create a manifest for each module. このオプションについてはこちらも参照してください。 --output_wrapper --output_wrapper VAL このオプションに指定された文字列にコンパイル結果を内包して出力させます。以下に例を示します: --output_wrapper (function(){%output%})() %output% がコンパイルされたコードのプレースホルダとなります。上のような形式で出力するとコンパイルされたコードのスコープは外側の関数内に限定されるため、リネームされたシンボルによるグローバル領域の汚染を防止することができます。デフォルトのプレースホルダ %output% は--output_wrapper_markerによって任意の文字列に変更できます。 --output_wrapper_marker --output_wrapper_marker VAL --output_wrapperオプションにおいてコンパイルされたコードのプレースホルダとして使用されるトークン文字列を指定します。 --print_ast --print_ast Prints a dot file describing the internal abstract syntax tree and exits. --print_pass_graph --print_pass_graph Prints a dot file describing the passes that will get run and exits. --print_tree --print_tree Prints out the parse tree and exits. --process_closure_primitives --process_closure_primitives [true|false] goog.require() 、 goog.provide() 、 goog.exportSymbol() のようなClosure Libraryの関数をコンパイル時にコードに展開します。デフォルトは true です。 ヘルプには上のように書かれていますが、管理人の試した限りでは展開されるのは goog.require() と goog.provide() だけのようでした。 --property_map_input_file --property_map_input_file VAL File containing the serialized version of the property renaming map produced by a previous compilation. --property_map_output_file --property_map_output_file VAL File where the serialized version of the property renaming map produced should be saved. --summary_detail_level --summary_detail_level N Controls how detailed the compilation summary is. Values 0 (never print summary), 1 (print summary only if there are errors or warnings), 2 (print summary if type checking is on, see --check_types), 3 (always print summary). The default level is 1. --third_party --third_party Check source validity but do not enforce Closure style rules and conventions. --variable_map_input_file --variable_map_input_file VAL File containing the serialized version of the variable renaming map produced by a previous compilation. --variable_map_output_file --variable_map_output_file VAL File where the serialized version of the variable renaming map produced should be saved.
https://w.atwiki.jp/g8495625/pages/33.html
コマンド cpp hello.c #define や #include といったマクロを展開する C プリプロセッサ Compiler Libc GCCが行っていることを手作業でやってみる。 基本を再チェック~gcc~ (コンパイル過程の詳細) プリプロセッサ処理 コンパイラの最適化の罪 アセンブラ コマンド GNU C/C++ コンパイラ コマンド アセンブラ コマンド Yacc 優先順位
https://w.atwiki.jp/nino-add-up/pages/38.html
インストール Diskを入れて指示通りすればできる 現在の最新版はR2006b(2006.11.20) 使い方 Matlabを起動 コマンドウィンドウに直接コマンドを入力して一行ずつ実行する [ファイル]- [新規作成]- [Mファイル] editorを開く 一通りプログラムを作成してから実行する(F5でも可能) 知っておくべきこと Mファイルから実行しても一行ずつ実行される エラーの確認は容易(エラーメッセージを読む) コマンドが豊富なのでヘルプをよく確認する コマンドウィンドウで help command と入力すると簡単なヘルプを確認できる なにかやりたい作業がある場合はまずヘルプの検索で確認(検索でひっかからなくてもFileExchangeにある可能性はある) 使いこなせないうちはデモを見て使ってみる 使いこなせるようになってもデモは意外と使える 計算を途中で止めたい場合は[Ctrl + c] % 以降はコメント扱い MATLAB HELP DESKはすべてのコマンドをカバーしていないが機能別コマンド一覧は便利 その他 Matlabの小技 Matlabの本も最近はたくさんある。 参考 サイバネットシステム MathWorks FileExchange MATLAB HELP DESK [PR] メールフォーム
https://w.atwiki.jp/matla/pages/15.html
管理人はMATLABで研究活動をしとりますが、結構ヘビーな処理がしばしば。 そこで、nvidiaの最近のグラボがあれば使えるCUDAを使って高速化したい!というわけで、MATLAB+CUDAのとっかかりを。毎度のことですが、バグとかは責任をおいませんよ。 なお、私はプログラマレベル0.2(当社比)な初心者なので、で間違ってても石を投げないでください(汗 でも、その分初心者でもわかる内容にしたい!とおもいます。 1.CUDAの準備 nvidiaのGeforce8xxx、9xxxとか、280,260とかのCUDA対応ボードを買って、パソコンにいれておく。なくてもできるけど、ソフトウェアエミュレーションは激遅い^^; Visual Studio2005等、CUDAのコンパイルに使える環境のインストール。私はVS2005でやってますが、windowsSDKがあればexpressでもいけるかな??詳しくはCUDAのサイトで確認してくださいな。たぶん2003か2005くらいしか対応していなかった気もしますが・・・ CUDAのSDK、ツールキット、ドライバのインストール。nvidiaのサイト(http //www.nvidia.co.jp/object/cuda_get_jp.html)からダウンロードし、インストール♪これは簡単ですよね?? サンプルがコンパイルできればOK!なお、ボードがない場合にはビルドのターゲットをエミュレーションにして実行すればいちおう実行できますよ。 2.MATLABの準備 MATLABのインストール(当たり前ですねw) 注!- MATLAB2009aでは失敗することが!下のコメントに対処法を記しときます. MEXファイルがコンパイルできるかチェック。私はMATLAB Compilerを持っているので、mbuild -setup、もしなければmex -setupで使用するコンパイラを設定する。MATLAB付属のlccでは、私はCUDAコードをコンパイルするまでうまく設定できませんでした。上級者ならできるかもしれません??とりあえず、VS2005のほうが簡単にできたので、VS2005のコンパイラを選びます。 とりあえずこれだけかな?mexのサンプルを用意してみて、コンパイルできればOK! 3.CUDA入りmexファイルでMATLABを加速! MATLAB+CUDAに必要となるスクリプト等をnvidiaのサイト(http //www.nvidia.co.jp/object/matlab_cuda_jp.html)から落としてきます。 Matlab_CUDA-1.1a.zipを解凍し、中のbinの中にあるnvmex.plを、MATLABのインストールフォルダのbinフォルダに入れる。MATLABの場所がよくわからなければMATLABのショートカットのリンクからたどってください。 nvmex.mと、nvmex-helper.m、nvmexopts.batがCUDAを使ったmexのコンパイルに必要だと思われます。パスの設定とかよくわからなければ、コンパイルしたいファイルと一緒のフォルダにおいてください。 いよいよ本題!CUDA de MEX in MATLABですよ!私は小難しいことはわかりませんので、ここにある(http //www.nvidia.co.jp/object/matlab_cuda_jp.html)ホワイトペーパー内のサンプルをオススメします。なんともわかりやすい!でも、さすがにそれではアレですので(というか、pdf、一部文字がきれてますがな。nvidiaさん)、2乗ではなく配列の各要素の対数を求めるサンプルcuda_test.cuをおいておきます。一行しか変わってないですがw あとは、思う存分CUDAプログラミング!サンプルをみればMATLABとのデータやりとりの方法は推して量れるかと。必要なデータをGPU上に転送して・・・いざ並列コンピューティング! mexファイルのコンパイルには、MATLAB上で,[nvmex -f nvmexopts.bat cuda_test.cu -IC \cuda\include -LC \cuda\lib -lcudart]とします。 思い通りの処理をつんで、”がんばって”高速化してください! 注意!私の環境では,上記nvmex コマンドを実行しても,コンパイルができませんでした.それは,user32.dll,gdi32.dllなど,WindowsSDK?に含まれているらしきライブラリがない旨のエラーが出ました.そこで,nvmexopts.batに含まれるコンパイルオプションの設定部分 set LIB=%VCINSTALLDIR%\ATLMFC\LIB;%VCINSTALLDIR%\LIB;%VCINSTALLDIR%\PlatformSDK\lib;%VSINSTALLDIR%\SDK\v2.0\lib;%MATLAB%\extern\lib\win32;%LIB%; の部分を, set LIB=%VCINSTALLDIR%\ATLMFC\LIB;%VCINSTALLDIR%\LIB;%VCINSTALLDIR%\PlatformSDK\lib;%VSINSTALLDIR%\SDK\v2.0\lib;%MATLAB%\extern\lib\win32;%LIB%;C \Program Files\Microsoft SDKs\Windows\v6.1\Lib; に書き換え,ライブラリパスを追加することでコンパイルができました.本当はどうするんでしょう??windowsSDKのインストールの仕方が悪かったんですね,きっと. ↑VS2005 Expressでやったときのでした。VS2005なら大丈夫だった!記憶違い^^; 高速化にはさまざまなテクニックと知識が必要ですが・・・くわしくはCUDAサンプルを読んでくださいwSIMD的演算ならす~ぐに簡単並列化!大規模データもへっちゃら!(というほど簡単ではないかもですが汗 ちなみに、普通に小さな行列の掛け算やら要素ごとの演算をするくらいならMATLABだけでやったほうがだいぶ高速です。グラボへのデータ転送遅いし、MATLABはdouble、CUDAはfloatなので変換などのオーバーヘッドも無視できない。データ量が比較的すくなくて、計算コストが高く、並列化できる処理。そういうのだけにしたほうがいいっスヨ。ちなみに、float精度でよければ、上のlogとるサンプルはMATLABでやるよりCUDAでやったほうが高速でした。(Geforce8400GSのへなちょこボードですら!) 以下、高速化のコツ??まぁ、できたら。ですが。あまり詳しくないので信じないでください。 スレッドをサボらせない。データ長より長い部分はしゃあないか。 繰り返し使うデータは共有メモリにいれましょう。 メモリアクセスはワープ単位(16ないし32スレッド)でアドレスが連続になるようにしたほうがよさげ。バス幅いっぱいに使いましょう。 メモリのバンクが衝突しないように。これ、意外と難しいきもする。 if文少なく。%とかも遅いらしい。複雑な演算ももちろん減らそう。そもそもアルゴリズムが遅かったら意味ナイね。 同期命令を極力すくなく。これ、だいぶ遅いです。 ほかにもいろいろあったり例外もあったり・・・ 完全な高速化は私にはあまりに難しいのでヘルプを読んでCUDAさい。MATLABより早くなればヨシ、ですよw(MATLABもそもそもベクトル演算そこそこはやいしね^^;) 高速化のためにはいかにグラボにデータを載せっぱなしにするかが大事ですが, MATLABのmexでする例を,快適計算ライフ3にてご紹介しましょう. 本日の来訪者: - 昨日の来訪者: - 来訪者累積: - おなまえ こめんと まーぼうさん 書き込みありがとうございます!私も初心者でわからないことだらけなので随時情報交換しましょう! -- 管理人 (2010-08-19 15 29 20) メーリングリスト投稿ありがとうございます。 さっそくですが、MATLABのやつは現在設定など いろいろ大変なことがあります。 わかんなかったら、MLにて質問します。 では。 -- まーぼう (2010-08-06 18 17 12) 上の2009aでコンパイルできない問題を回避するその場しのぎ的方法をCudaフォーラムで発見. MATLABのbinに入れるnvmex.plの中身,728行目辺りを, $main temp_dir = mexCatdir($ENV{ TEMP },tool_name() . "_" . uuidgen()); から $main temp_dir = mexCatdir($ENV{ TEMP },tool_name() . "_" . "xxx"); に変更し,UUIDを使わず適当な名前にしてやると.なんか問題でるかもしれないけど,とりあえずはコンパイルできそうです. -- 管理人 (2010-03-24 03 01 07) 2009aでコンパイルできない原因は,2007bではmexutils.pmにあったuuidgenが,2009aではmexutils.pmから削除されていることにありそう. ただ,win32 APIを導入する方法がわからず断念.管理人はperlをやったことがなく,ちょっと無理でした. perl詳しい方,直し方おしえてくらさい… -- 管理人 (2010-03-24 02 27 55) その後,MATLAB2009aで試してみたら,"Undefined subroutine main uuidgen called atほげほげ"と出てなぜかコンパイルできない… 2007bでは相変わらずできるので,何か設定ミスらしいのですが…なんでかな?? perlスクリプトのあたりがおかしいらしい… -- 管理人 (2010-03-24 01 49 49)