これは、関数の定義時にd2()のコードが生成され、その時点でd()メソッドが解決されるためだと思います。 お気づきのとおり、 d2()は元々定義されていたとおりに再定義して、期待どおりに機能させることができます。 理想的には、このように変更されたときにd()に依存するものを自動的に再定義しますが、それを可能にするメタデータはありません。 この動作についての警告をマニュアルに記載できると思います。 それでも修正する方が良いでしょうが、それを行うのは少し難しいと思います：-/

誰もこれに気付かないことを望んでいましたが、それは私にとって現実的ではなかったと思います:)

それよりも楽しいです。 実行されるまで解決されないため、実際にJITが機能していることを確認できます。

julia> function f2()
       a
       end

julia> function f1()
       f2()
       end

julia> function f2()
       2
       end

julia> f1()
2

ただし、これに対処する最善の方法はわかりませんが、これがREPLで予期しない結果につながる可能性があることを恐れています。 エラーを使用して劇的な方法で違いを示しましたが、内部方程式または定数を変更した場合の影響を確認しようとした場合にも発生する可能性があります。

メソッドが変更されたときに更新する必要がある可能性のある場所には、次の2つのタイプがあります。

• メソッドが関数として明示的に呼び出される場所（call / ret）
• メソッドがインライン化されている場所

前者は、関数本体を変更するだけで更新できます。その場で変更するか、呼び出し元のサイトをアクティブに更新して新しい場所を呼び出すか、古い関数本体を新しいバージョンにジャンプするスタブに置き換えることができます。 、オプションで呼び出し元サイトにパッチを適用します。 インライン化するには、関数をインライン化した呼び出し元を追跡し、それらを再JITする必要があります。

メソッドがインライン化されていなくても、メソッドを呼び出す関数は、メソッドが変更された場合に変更される可能性のある型の動作に依存する可能性があるため、実際にできることはコードを破棄することだけです。 これは主にインタラクティブなケースのためのものであるため、コードの再コンパイルは大したことではありません。
問題＃47と同じ作業が必要です。

バマー。 影響を受けるのは主に担当者であるため、正しいことをゆっくり行うことは問題ありません。 実行時に、これが開始されることはほとんどありません。インタラクティブな場合を除いて、なぜ誰かが何かを定義してから、それを再定義するのでしょうか。 ソリューションが多くのオーバーヘッドを引き起こすことになった場合、おそらくそれを回すのはオプションであり、担当者で自動的に行われるべきですか？

これは現在未定義であることを文書化する必要があります。

技術的には、これはバグではなく、未定義の動作です。 メソッドを再定義すると、結果の動作は未定義になります。 そのため、ジュリアは現在行っていることを含め、好きなことを何でもできます。 メソッドの再定義時に明確に定義された動作を提供することは機能であり、バグ修正ではありません。 また、未定義の動作から明確に定義された動作を提供することは重大な変更ではないため、これがv1.0の問題であるとは確信していません。 これは、有効なv1.0コードを壊すことなくv1.1で実装できます。

AppleのLLVM / LLDBスタッフのGregClaytonは親切にも、埋め込まれたシンボル情報（シンボルインポート）からバイナリの依存関係を決定するために必要な情報を（lldbライブラリ、llvmのサブプロジェクトで）引き出す方法を文書化してくれました。 バイナリによってエクスポートされたシンボルと同様に（完全な依存関係グラフを作成するために必要）。

• ジェイソン

2012年3月31日午後11時2分、ジェイソンE.アテンは次のように書いています。

LLDB愛好家の皆様、

lldbライブラリ/ライブラリを使用して、（dyldinfo -lazy_bind -exportsの出力と同様に）シンボルの2つのリストを返すOSXで実行されている特定のコードを置き換えることができるかどうか疑問に思っています）; つまり、バイナリ共有オブジェクトまたはバンドルによってインポートおよびエクスポートされたシンボルを一覧表示する必要があります。

私の望みは、lldbライブラリを使用することで、OSXでもLinuxと同じクライアントコードを使用できるようになることでした。 （Linuxバージョンのコードは現在libbfdとlibdldを使用して同じことを行っていますが、後者はほとんど愛/メンテナンスを取得していません）。

include / lldb /を調べています。これは、lldbが機能するためにこれと同じ情報（インポートされたシンボルリストとMach-Oファイルのエクスポートされたシンボルリスト）が必要なようですが、使用するAPIが明確ではありません。 lldbのサンプルコードへのすべての提案/ポインタは大歓迎です！

ありがとうございました。
ジェイソン

dyldinfoが何をするのかわからない場合のために、ここに例を示します:(ただし、アドレス、セグメント、セクションではなく、シンボル名のみが必要です）：

$ファイル/ tmp / sample_bundle
/ tmp / sample_bundle：Mach-O64ビットバンドルx86_64

$ dyldinfo -lazy_bind -export / tmp / sample_bundle

遅延バインディング情報（dyld情報のlazy_bind部分から）：
セグメントセクションアドレスインデックスdylibシンボル
__DATA __la_symbol_ptr 0x000010300x0000フラット名前空間__mm_pop_chunk
__DATA __la_symbol_ptr 0x00001038 0x0015 flat-namespace _dh_define
情報のエクスポート（トライから）：
0x000008A0 _C_ipair
0x00000920 _init_ipair
0x00000BC0 _C_iprot
0x00000C40 _C_ipi2
0x00000CC0 _C_ipi1
0x00001040 _K_ipair_R43808f40
0x00001160 _K_ipi1_R5cb4475d
0x00001260 _K_ipi2_R5cb4475d
0x00001360 _K_iprot_Rfc8fe739
0x00001460 _majver_ipair
0x00001464 _minver_ipair

2012年4月2日月曜日午後3時13分、Greg [email protected]は次のように書いています。

Yes you can do this with LLDB. If you load a binary and dump its symbol table, you will see the information you want. For symbols that are lazily bound, you can look for "Trampoline" symbols:

cd lldb/test/lang/objc/foundation
make
lldb a.out
(lldb) target modules dump symtab a.out
Symtab, file = .../lldb/test/lang/objc/foundation/a.out, num_symbols = 54:
              Debug symbol
              |Synthetic symbol
              ||Externally Visible
              |||
Index   UserID DSX Type         File Address/Value Load Address       Size               Flags      Name
------- ------ --- ------------ ------------------ ------------------ ------------------ ---------- ----------------------------------
[    0]      0 D   SourceFile   0x0000000000000000                    Sibling -> [   15] 0x00640000 /Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/main.m
[    1]      2 D   ObjectFile   0x000000004f79f1ca                    0x0000000000000000 0x00660001 /Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/main.o
[    2]      4 D   Code         0x00000001000010f0                    0x00000000000000c0 0x000e0000 -[MyString initWithNSString:]
[    3]      8 D   Code         0x00000001000011b0                    0x0000000000000090 0x000e0000 -[MyString dealloc]
[    4]     12 D   Code         0x0000000100001240                    0x00000000000000a0 0x000e0000 -[MyString description]
[    5]     16 D   Code         0x00000001000012e0                    0x0000000000000020 0x000e0000 -[MyString descriptionPauses]
[    6]     20 D   Code         0x0000000100001300                    0x0000000000000030 0x000e0000 -[MyString setDescriptionPauses:]
[    7]     24 D   Code         0x0000000100001330                    0x0000000000000030 0x000e0000 -[MyString str_property]
[    8]     28 D   Code         0x0000000100001360                    0x0000000000000050 0x000e0000 -[MyString setStr_property:]
[    9]     32 D   Code         0x00000001000013b0                    0x0000000000000040 0x000f0000 Test_Selector
[   10]     36 D   Code         0x00000001000013f0                    0x0000000000000130 0x000f0000 Test_NSString
[   11]     40 D   Code         0x0000000100001520                    0x0000000000000120 0x000f0000 Test_MyString
[   12]     44 D   Code         0x0000000100001640                    0x00000000000001b0 0x000f0000 Test_NSArray
[   13]     48 D   Code         0x00000001000017f0                    0x00000000000000e1 0x000f0000 main
[   14]     56 D X Data         0x0000000100002680                    0x0000000000000000 0x00200000 my_global_str
[   15]     58 D   SourceFile   0x0000000000000000                    Sibling -> [   19] 0x00640000 /Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/my-base.m
[   16]     60 D   ObjectFile   0x000000004f79f1ca                    0x0000000000000000 0x00660001 /Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/my-base.o
[   17]     62 D   Code         0x00000001000018e0                    0x0000000000000020 0x000e0000 -[MyBase propertyMovesThings]
[   18]     66 D   Code         0x0000000100001900                    0x000000000000001f 0x000e0000 -[MyBase setPropertyMovesThings:]
[   19]     82     Data         0x0000000100002000                    0x0000000000000460 0x000e0000 pvars
[   20]     83     ObjCIVar     0x0000000100002518                    0x0000000000000148 0x001e0000 MyBase.propertyMovesThings
[   21]     84   X Data         0x0000000100002660                    0x0000000000000008 0x000f0000 NXArgc
[   22]     85   X Data         0x0000000100002668                    0x0000000000000008 0x000f0000 NXArgv
[   23]     86   X ObjCClass    0x00000001000024d8                    0x0000000000000028 0x000f0000 MyBase
[   24]     87   X ObjCClass    0x0000000100002460                    0x0000000000000028 0x000f0000 MyString
[   25]     88   X ObjCIVar     0x0000000100002510                    0x0000000000000008 0x000f0000 MyString._desc_pauses
[   26]     89   X ObjCIVar     0x0000000100002508                    0x0000000000000008 0x000f0000 MyString.date
[   27]     90   X ObjCIVar     0x0000000100002500                    0x0000000000000008 0x000f0000 MyString.str
[   28]     91   X ObjCMetaClass 0x00000001000024b0                    0x0000000000000028 0x000f0000 MyBase
[   29]     92   X ObjCMetaClass 0x0000000100002488                    0x0000000000000028 0x000f0000 MyString
[   30]     97   X Data         0x0000000100002678                    0x0000000000000008 0x000f0000 __progname
[   31]     98   X Data         0x0000000100000000                    0x00000000000010b0 0x000f0010 _mh_execute_header
[   32]     99   X Data         0x0000000100002670                    0x0000000000000008 0x000f0000 environ
[   33]    101   X Data         0x0000000100002680                    0x0000000000000000 0x000f0000 my_global_str
[   34]    102   X Code         0x00000001000010b0                    0x0000000000000040 0x000f0000 start
[   35]    103     Trampoline   0x0000000100001938                    0x0000000000000006 0x00010200 NSLog
[   36]    104   X Undefined    0x0000000000000000                    0x0000000000000000 0x00010400 OBJC_CLASS_$_NSArray
[   37]    105   X Undefined    0x0000000000000000                    0x0000000000000000 0x00010200 OBJC_CLASS_$_NSAutoreleasePool
[   38]    106   X Undefined    0x0000000000000000                    0x0000000000000000 0x00010400 OBJC_CLASS_$_NSDate
[   39]    107   X Undefined    0x0000000000000000                    0x0000000000000000 0x00010400 OBJC_CLASS_$_NSObject
[   40]    108   X Undefined    0x0000000000000000                    0x0000000000000000 0x00010200 OBJC_CLASS_$_NSString
[   41]    109   X Undefined    0x0000000000000000                    0x0000000000000000 0x00010400 OBJC_METACLASS_$_NSObject
[   42]    110   X Undefined    0x0000000000000000                    0x0000000000000000 0x00010400 __CFConstantStringClassReference
[   43]    111   X Undefined    0x0000000000000000                    0x0000000000000000 0x00010100 _objc_empty_cache
[   44]    112   X Undefined    0x0000000000000000                    0x0000000000000000 0x00010100 _objc_empty_vtable
[   45]    113     Trampoline   0x000000010000193e                    0x0000000000000006 0x00010300 exit
[   46]    114     Trampoline   0x0000000100001920                    0x0000000000000006 0x00010100 objc_getProperty
[   47]    115     Trampoline   0x0000000100001926                    0x0000000000000006 0x00010100 objc_msgSend
[   48]    116     Trampoline   0x000000010000192c                    0x0000000000000006 0x00010100 objc_msgSendSuper2
[   49]    117   X Undefined    0x0000000000000000                    0x0000000000000000 0x00010100 objc_msgSend_fixup
[   50]    118     Trampoline   0x0000000100001932                    0x0000000000000006 0x00010100 objc_setProperty
[   51]    119     Trampoline   0x0000000100001944                    0x0000000000000006 0x00010300 printf
[   52]    120     Trampoline   0x000000010000194a                    0x0000000000000006 0x00010300 usleep
[   53]    121   X Undefined    0x0000000000000000                    0x0000000000000000 0x00010300 dyld_stub_binder
(lldb)


All lazily bound symbols will have type Trampoline:

[   45]    113     Trampoline   0x000000010000193e                    0x0000000000000006 0x00010300 exit
[   46]    114     Trampoline   0x0000000100001920                    0x0000000000000006 0x00010100 objc_getProperty
[   47]    115     Trampoline   0x0000000100001926                    0x0000000000000006 0x00010100 objc_msgSend
[   48]    116     Trampoline   0x000000010000192c                    0x0000000000000006 0x00010100 objc_msgSendSuper2
[   50]    118     Trampoline   0x0000000100001932                    0x0000000000000006 0x00010100 objc_setProperty
[   51]    119     Trampoline   0x0000000100001944                    0x0000000000000006 0x00010300 printf
[   52]    120     Trampoline   0x000000010000194a                    0x0000000000000006 0x00010300 usleep

The other symbols that are exernal are marked with an "X" (which is a boolean flag on each symbol).

The symbols can be accessed via the SBModule:

   size_t
   SBModule::GetNumSymbols ();

   lldb::SBSymbol
   SBModule::GetSymbolAtIndex (size_t idx);

And then you can get the symbol type from each SBSymbol:

   SymbolType
   SBSymbol::GetType ();


I just added the ability to see if a symbol is externally visible:
% svn commit
Sending        include/lldb/API/SBSymbol.h
Sending        scripts/Python/interface/SBSymbol.i
Sending        source/API/SBSymbol.cpp
Transmitting file data ...
Committed revision 153893.


   bool
   SBSymbol::IsExternal();


So your flow should be:

SBDebugger::Initialize();
SBDebugger debugger(SBDebugger::Create());
SBTarget target (debugger.CreateTarget (const char *filename,
                                       const char *target_triple,
                                       const char *platform_name,
                                       bool add_dependent_modules,
                                       lldb::SBError& error));

SBFileSpec exe_file_spec (filename);
SBModule exe_module (target.FindModule(exe_file_spec));
if (exe_module.IsValid()
{
   const size_t num_symbols = exe_module. GetNumSymbols();
   for (size_t i=0; i<num_symbols; ++i)
   {
       SBSymbol symbol (exe_module. GetSymbolAtIndex(i));
       if (symbol.IsExternal())
       {
       }

       if (symbol.GetType() == lldb::eSymbolTypeTrampoline)
       {
       }
   }
}




> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

2012年4月2日月曜日の午後4時5分、Greg [email protected]は次のように書いています。

A quick clarification on the args to CreateTarget:

"filename" is just a full path to the local object file you want to observer. "target_triple" is your <arch>-<vendor>-<os>, or something like "x86_64-apple-darwin" or "i386-pc-linux" and can be NULL if the file is only a single architecture. "platform_name" can be NULL. "add_dependent_modules" should be false, since you are only interested in seeing the one object file itself, an SBError instance  should be created and passed in.

ここでの開発リストのディスカッション： https ：//groups.google.com/forum/ = ＃！topic / julia -dev / snnGKJul4vg。

これは驚くほど古いスレッドを浚渫していますが、codespeedベンチマークコードでこの問題の端をいちゃつく可能性があることに気づきました。 listTests()とrunTests()つの関数を含むCore.include()ファイルを繰り返し実行します。 次に、 listTests()とrunTests()を呼び出すだけで、新しいベンチマークファイルをロードするたびに再定義して呼び出すことができます。 私は第2層の関数を再定義していないので、ここにリストされている問題に遭遇することはないと思いますが、このようなものを再定義することは、同じ「API」で複数のファイルをロードするための悪い方法ですか？

それらをモジュールに繰り返し含める方が良いかもしれませんが、開発リストでも提起されている匿名モジュールの問題にぶつかることに気づきました。 ただし、この場合は、同じモジュールを複数回定義して、発生する警告を無視できるため、問題ない場合があります。

おそらく古いスレッドですが、相変わらず関連性があります。
おそらく別のアプローチは、 evalfileを使用して、ファイルに関数のタプルを「返す」ことです。 匿名モジュールの問題は何ですか？

私はこれを参照していました： https ：

実装戦略について他に考えている人はいますか？ （最適化されていないASTに基づいて）新しいメソッドが作成されるたびに更新される逆コールグラフを維持する単純なスキームをコーディングすることを考えていました。 次に、メソッドが再定義されたときにそのグラフをウォークし、再定義された各関数の子孫のコンパイル済みバージョンを削除します。

これは、他の方法と同じくらい合理的なアプローチです。 あなたがそれをやる気になっていると感じているなら、私は先に進んで、何が起こるか見てみましょう！

呼び出し先の_execution_が呼び出し元の再コンパイルをトリガーするとどうなりますか？

この問題を解決すると、REPLでのユーザーエクスペリエンスを超えた興味深い結果がもたらされる可能性があることに遅れて気付いたので、質問します。メタプログラミングの問題に対する究極の答え、つまり効率的な「段階的」関数の作成が可能になる可能性があります。 知らない人のための背景として：いくつかの関数は現在メタプログラミングによって実装されています、特にアルゴリズムのいくつかの側面が重要な方法で入力のタイプに依存しているもの---標準的な例は関数本体のループの数は、配列の次元に等しくなります。 通常これを処理する方法は、たとえば次元1と2に対して関数を明示的に定義し、次のようなラッパーを作成することです。

_method_cache = Dict()
function myfunction(A::AbstractArray)
    N = ndims(A)
    if !haskey(_method_cache, N)
        func = eval(<an expression that generates the function definition for N dimensions>)
        _method_cache[N] = func
    else
        func = _method_cache[N]
    end
    return func(A)
end

したがって、4次元配列に対して初めてmyfunctionが実行されると、最初に4次元に固有のバージョンが定義され、それが_method_cacheに追加されてから、入力の新しい関数が評価されます。 4次元配列を使用したmyfunction今後の呼び出しでは、ディクショナリから定義を取得して評価するだけです。 _method_cacheは、Julia独自の内部メソッドテーブルと並行した一種の「シャドウメソッドテーブル」であり、この特定の関数のためだけに使用されます。 （非公開にするために、通常はletカプセル化されます。）

この例のアプローチは、実行に時間がかかる関数本体には適していますが、辞書検索に必要な時間よりも短い時間で実行される関数にはあまり適していません。また、必要な関数には特に適していません。インライン化できます。

これを行うためのより良い方法は次のとおりです。

function myfunction(A::AbstractArray)
    bodyexpr = <an expression for the body of the function specific for N dimensions>
    f = <strong i="17">@eval</strong> begin
        function myfunction(A::$(typeof(A)))
            $bodyexpr
        end
    end
    return f(A)
end

ここで、 myfunctionすると、これらの特定の入力タイプに対して_より具体的な_バージョンのmyfunctionれます。 この新しい定義が利用可能になった後にコンパイルされたコードは、該当する場合はこの新しいバージョンを使用します。 上記のバージョンは、より具体的なものをまだ定義していない場合の一般的な「フォールバック」になります。 したがって、これは、Julia独自の内部メソッドテーブルメカニズムを活用する段階的な関数を作成する方法であり、したがって、効率的なコードを生成することができます。

現在、これは1つの重大な理由で機能しません。つまり、 myfunctionと呼ばれるものはすべてすでにコンパイルされているため、新しい定義についてはわかりません。 その結果、この特定の呼び出し元は常にevalを使用してmyfunction新しいバージョンを生成しますが、これは非常に遅くなります。

したがって、トリックは呼び出し元を再コンパイルすることですが、これは_実行の途中で_発生する必要があることに注意してください。 何が起こるだろう？

＃5395も参照してください。

実際にはメソッドの再定義を伴わないが、同様の処理を必要とする抽象型に関連する問題があります。 考えてみましょう：

abstract A
immutable B <: A; end
immutable C <: A; end

g(x::Vector{A}) = f(x[1])

f(::B) = 1
g(A[B()])

f(::C) = 0.5
g(A[C()])

最後の行は4602678819172646912ます。 f(::A)の型推論が無効になったため、 gのコードを破棄する必要があります。

はい、それは非常に明確です。 メソッドの置き換えは1つの特殊なケースにすぎないことを私たちは知っています。 ただし、常に新しいメソッド定義が含まれます。

それ以来、現在の状況はどういうわけか曖昧になる可能性があるようです

f() = x()
x() = 1
println(f())
x() = 2
println(f())

与える

1
1

一方

g() = y()
precompile(g, ())
y() = 1
println(g())
y() = 2
println(g())

与える

1
2

後者のケースは、呼び出し元の再コンパイルをエミュレートするための回避策として使用できるようです（実際には再コンパイルではないことを私は知っています）。

愚かなことを言おうとしているような気がしますが、この問題は単一レベルの間接参照で解消できませんでしたか？ 関数アドレスをハードコーディングする代わりに、固定された場所から検索して呼び出します。 これは、C ++またはJava仮想関数と同様のパフォーマンスを発揮しませんか？ 次に、静的アドレスまたは動的アドレスを持つように関数に注釈を付け、静的アドレスで関数を再定義しようとすると警告/エラーが発生する可能性があります。 デフォルトの機能動作を設定するためのスイッチさえあるかもしれません。 私はこの言語に不慣れで、コードベースにまったく慣れていませんが、これが実現可能であると思われる場合は、ジャブを与えることができると思います。

@ omer4dそのアイデアの1つの問題は、Juliaが多くの小さな関数をインライン化するため、特定の関数のすべての「依存関係」を検索する方法が必要なことです。

C ++のように、静的アドレスを持つものだけをインライン化できます。 これで不便が生じることはありません。
デフォルトの動作ではすべての関数に静的アドレスを使用するため、インタラクティブな開発を気にしない人はまったく影響を受けません。
パフォーマンスは気にしないがインタラクティブな開発が必要な人は、スイッチを使用して、デフォルトで関数アドレスを動的にすることができます。
対話性とパフォーマンスの両方が必要な人は、関連する関数に注釈を付けることができますが、インライン化は頻繁に呼び出される短い低レベルの関数にのみ関連するため、多くの作業は必要ありません。
おそらく、デフォルトの動作はモジュールごとに設定することもできます。

アプローチが実行可能でない理由はいくつかあると思います。 最初、
注釈は、特にハッキングする必要がある場合、本当に厄介です。
このような実装の詳細について。 注釈を使用して2を解決する場合
または3つの問題、それらはかなり積み重なっていきます。 第二に、ありません
関数に適切な注釈を選択するための良い方法。 ありません
何かをインライン化したいかどうかと、
インタラクティブに開発します。 第三に、他の関数での型控除
変更が必要な場合があるため、サイトを呼び出すだけではありません。 実際、私たちは現在
私たちが物事を作ることができる可能性があるよりも少ないタイプ情報を導き出す
この問題に直面しても安全です。

さて、数十の修飾子キーワードと繰り返しの手動再コンパイルを使用して言語でほとんどの作業を行う人として、関数を1つか2つ修飾し、インタラクティブな開発の数サイクル後に再コンパイルする必要があることはそれほど悪くはありませんが、それは私だけです。 しかし、3番目のポイントに対処するのに十分な知識がないので、辞任します。 再コンパイルとは、変更された関数の呼び出しツリーのルートにゲームまたはアニメーションループが含まれている場合、それを終了して再起動する必要があるため、このようなソリューションが実行できないのは残念だと思います。 =（

@JeffBezanson少なくとも最初は、簡単なケースにおそらく最も興味があるでしょう。 eval介してアクセスされるもの（たとえば、REPLプロンプトで入力されるもの）とは対照的に、実行中のコードが更新されることはそれほど気にしません。 最終的には、たとえば、再定義時に呼び出されるdisplayの正しいバージョンを取得することも重要になります。 しかし、これにより、インクリメンタルコンパイルにすぐに近づくことができると思います。

この問題を知って少し驚いたのは、これを処理するのが簡単だと思うからではなく、次のことが期待どおりに機能するからです。

julia> f(a, b) = a + b
f (generic function with 1 method)

julia> g(args...) = f(args...)
g (generic function with 1 method)

julia> g(1, 2)
3

julia> f(a::Int, b::Int) = a - b
f (generic function with 2 methods)

julia> g(1, 2)
-1

編集：実際、これはVararg入力の特殊なケースのように見えます.....これは、vararg関数が呼び出されるたびに再コンパイルされることを意味しますか？ それとも、必要な場合にのみ再コンパイルするのに十分賢いですか？ そして、他の機能を同じように扱うことは可能ですか？

julia> f(a, b) = a + b
f (generic function with 1 method)

julia> g(a, b) = f(a, b)
g (generic function with 1 method)

julia> g(1, 2)
3

julia> f(a::Int, b::Int) = a - b
f (generic function with 2 methods)

julia> g(1, 2)
3

実際には、関数は正しい結果を返しますが、 @code_typedは間違った結果を返します.....

julia> f(a, b) = a + b
f (generic function with 1 method)

julia> g(args...) = f(args...)
g (generic function with 1 method)

julia> g(1, 2)
3

julia> <strong i="7">@code_typed</strong> g(1, 2)
1-element Array{Any,1}:
 :($(Expr(:lambda, Any[:(args::(top(apply_type))(Vararg,Any)::Any::Any)], Any[Any[],Any[Any[:args,(Int64,Int64),0]],Any[]], :(begin  # none, line 1:
        return (top(box))(Int64,(top(add_int))((top(tupleref))(args::(Int64,Int64),1)::Int64,(top(tupleref))(args::(Int64,Int64),2)::Int64))
    end::Int64))))

julia> f(a::Int, b::Int) = a - b
f (generic function with 2 methods)

julia> g(1, 2)
-1

julia> <strong i="8">@code_typed</strong> g(1, 2)
1-element Array{Any,1}:
 :($(Expr(:lambda, Any[:(args::(top(apply_type))(Vararg,Any)::Any::Any)], Any[Any[],Any[Any[:args,(Int64,Int64),0]],Any[]], :(begin  # none, line 1:
        return (top(box))(Int64,(top(add_int))((top(tupleref))(args::(Int64,Int64),1)::Int64,(top(tupleref))(args::(Int64,Int64),2)::Int64))
    end::Int64))))

そして

julia> f(a, b) = a + b
f (generic function with 1 method)

julia> g(args...) = f(args...)
g (generic function with 1 method)

julia> g(1, 2)
3

julia> f(a::Int, b::Int) = a - b
f (generic function with 2 methods)

julia> g(1, 2)
-1

julia> <strong i="12">@code_typed</strong> g(1, 2)
1-element Array{Any,1}:
 :($(Expr(:lambda, Any[:(args::(top(apply_type))(Vararg,Any)::Any::Any)], Any[Any[],Any[Any[:args,(Int64,Int64),0]],Any[]], :(begin  # none, line 1:
        return (top(box))(Int64,(top(sub_int))((top(tupleref))(args::(Int64,Int64),1)::Int64,(top(tupleref))(args::(Int64,Int64),2)::Int64))
    end::Int64))))

関数のメソッド（または関数タイプ/オブジェクト自体のみ）に、何かが割り当てられるたびに変化する番号をインデックス付けして、コンパイルされた（呼び出し元）関数に格納されている番号（つまり、新しい構造を使用しているかどうか）を確認できるようになりますか？関数の数、これらの数値をフィールドとして保存するなど）は、インライン化された（呼び出された）関数で「現在」のものと一致しますか？
（もちろん大きなパフォーマンスペナルティなしで）
また、変更があった場合は、新しいバージョンをコンパイルするか、明示的に呼び出すことを検討してください。

これにより、パフォーマンスへの影響がランタイムに移動します（そして、それはどこにでもあります）。これは望ましくありません。 必要なのは、依存関係のWebを追跡し、メソッドが部分的に再定義されたときに影響を受ける可能性のあるものをすべて再コンパイルすることです。 それはおそらく実行可能です、それはただの_大規模な_痛みです。

この問題の解決策がマクロに簡単に一般化できるかどうかはわかりませんが、そうであれば、それがあればいいのですが。

したがって、逆に、関数をインライン化したすべてのメソッドを格納し、変更時にそれらを再コンパイルする必要があります。 （もちろん、現在の実行などをチェックします）

ここでの難しい問題は次のとおりです。

• あなたが言うようにコードの無効化は、（生成されたコードで）古い関数を使用するすべての場所を見つけます。 これはおそらく、変更されたが呼び出し規約と戻り値の型が変更されていない関数を呼び出すコードを再配置できることを意味します。
• より難しい：新しいメソッドを定義しているときに別のタスクが実行されている場合はどうなりますか？ どのような状態が表示されますか？ 効率的に実装するのは非常に難しいため、スタック上の置換なしでそれを解決したいと考えています。 私たちは、パフォーマンスを損なうことのない解決策があると思います。

問題の解決に取り組んでいる間、私はそれが可能かどうか興味があり、与えられた関数が上位の方法のいずれかで使用された場合にのみ、設定されたすべての関数にフラグを追加することをお勧めします（インライン化など）インライン化されたメソッドが再定義されたという警告を生成するため。 （あいまいな警告が機能する方法と同様）
フラグを保存するより良い方法がない場合は、おそらくjulia0.5のメソッド/関数の新しい構造を使用することによって

replでこれをヒットするのはさらに簡単になり、この動作はマップ用に文書化する必要がありますか？

julia> function f(x)
         1
       end 
f (generic function with 1 method)

julia> map(f, 1:10)
10-element Array{Int64,1}:
 1
 1
 1
 1
 1
 1
 1
 1
 1
 1

julia> function f(x)
         2
       end
WARNING: Method definition f(Any) in module Main at REPL[9]:2 overwritten at REPL[11]:2.
f (generic function with 1 method)

julia> map(f, 1:10)
10-element Array{Int64,1}:
 1
 1
 1
 1
 1
 1
 1
 1
 1
 1

それはまだバニラ＃265です。 これはv0.6-devでまもなく修正されることを理解していただけると思います:)

@vtjnashランタイムパフォーマンスまたはメモリのトレードオフはありますか？

少しのメモリ（140MB-> 170 MB）が必要ですが、パフォーマンス（コンパイルまたはランタイム）に大きな影響を与えることはありません。 そして、私はまだあまり最適化を試みていません。

これまでのデモは楽しいです：

julia> f() = 1
f (generic function with 1 method)

julia> function g(x)
    <strong i="7">@eval</strong> f() = $x # this is the correct way to write `global f() = x` (which should be a syntax error, but isn't currently)
    return @eval(f)() # use `eval` to hide the value from optimization / inlining, but the call is not inside eval
end
g (generic function with 1 method)

julia> g(2)
WARNING: Method definition f() in module Main at REPL[1]:1 overwritten at REPL[2]:2.
1

julia> g(3)
WARNING: Method definition f() in module Main at REPL[2]:2 overwritten at REPL[2]:2.
2

julia> g(4)
WARNING: Method definition f() in module Main at REPL[2]:2 overwritten at REPL[2]:2.
3

2、3、順序による4でコンパイル返さない理由であるg再定義することを実行対f起こるのでは？

おおまかにそうです。 言語セマンティクスはコンパイルを定義しないことに注意してください。したがって、 gが解釈される順序と、 fの再定義がインタープリターに表示される時間との比較の方が正しいと言えます。

了解しました。 +プリミティブを再定義して、使用量をカウントする、もう1つの楽しい小さなデモを次に示します。

julia> add_ctr = UInt(0)
0x0000000000000000

julia> Base.:+(a::Int, b::Int) = (global add_ctr += 1; Core.Intrinsics.add_int(a, b))

julia> add_ctr
0x0000000000000016

julia> last = 0;

julia> println(Int(add_ctr - last)); last = add_ctr;
287

julia> println(Int(add_ctr - last)); last = add_ctr;
17

それはごまかしです。 +がBaseによって使用されることはまったくないと思うので、再コンパイルするものは何もありませんでした。 svdような、REPLが表示される前に少なくとも100回呼び出される必要があることがわかっている実際の関数を再定義します。 それから私たちは感動するでしょう。

プロファイリング/トレース用のコードをライブで再インストルメント化する機会は私を驚かせています。

確かに。 そして、ここで私は新しいキーボードを購入しようとしていました。なぜなら、シーケンスCtrl-D; julia<Enter>はほとんど使い古されているからです。 私はする必要がないように見えます。

リリースノートに入れるのは少し難解かもしれませんが、内包表記がcollect -ing Generator構文になっていることに注意してください（おそらく解析レベルのものとは対照的です） 0.4では？- @whichはそこでは機能しません）？ この例は、上記のvchuravyと同様に、各関数が0.5の型になったことを考慮しても、ちょっとした落とし穴です。

               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.5.0-rc3+0 (2016-08-22 23:43 UTC)
 _/ |\__'_|_|_|\__'_|  |
|__/                   |  x86_64-linux-gnu

julia> f(x) = 1
f (generic function with 1 method)

julia> [f(x) for x in 1:5]
5-element Array{Int64,1}:
 1
 1
 1
 1
 1

julia> f(x) = 2
WARNING: Method definition f(Any) in module Main at REPL[1]:1 overwritten at REPL[3]:1.
f (generic function with 1 method)

julia> [f(x) for x in 1:5]
5-element Array{Int64,1}:
 1
 1
 1
 1
 1

julia> <strong i="9">@which</strong> [f(x) for x in 1:5]
collect(itr::Base.Generator) at array.jl:295

そうじゃないですよね？

修正＃265に役立ちます

これは本当に修正されていますか😲

このソリューションはまだ0.5.xにバックポートされる予定ですか？

番号。

@ rapus95 、これは非常に侵襲的な変更であり、これを間違えると、多くのユーザーの

この問題の進展を見てとてもうれしいです！ これにより、コンパイラがhttps://groups.google.com/forum/#!topic/julia -users / OBs0fmNmjCUで説明されているケースを最適化できるようになれば驚くべきことです。

ワオ。 なんて素晴らしい瞬間でしょう。

こんにちは、みんな！

この修正を0.5シリーズにバックポートする可能性はありますか？ それとも、0.6になるものでのみ機能しますか？

これは重大な変更であり、0.6でのみ利用可能になります

これを修正することがどれほど素晴らしいかを誇張するのは難しいです。 古い習慣は一生懸命に死ぬので、私は時々ジュリアを不必要に再起動したり再構築したりしますが、私が覚えているとき、それは問題を修正するための完全なゲームチェンジャーです。