Not possible to "share" top-level variables during precompilation?

General Usage
1

I noticed the following behavior I’m trying to understand if its intentional, a bug, or could be changed. It seems obscure but has kind of come up as I’m trying to make Memoization.jl more precompile-friendly. On 1.9-beta2, imagine you have 2 packages:

module Foo
const caches = IdDict()
set_cache(x) = (@show(objectid(caches)); caches[x] = x)
set_cache("foo")
end

module Bar
using Foo
Foo.set_cache("bar")
end

Then you do

julia> using Bar
[ Info: Precompiling Bar [b60c06c0-7e54-11e8-3788-4bd722d65317]
objectid(caches) = 0x52bb3bf00c4b7e9d
objectid(caches) = 0x4de8dd67f96a789a

julia> Bar.Foo.caches
IdDict{Any, Any} with 1 entry:
  "foo" => "foo"

So as you can see, during precompilation, apparently, there’s are two different copies of caches created. And only the one created inside Foo I suppose persists to the actual session (and contains “foo”).

My question is whether this is intentional? Followup question, would there be a way to have a shared global object that is populated during precompilation from any module? Thanks.

2

One module owns the binding and the object being pointed to. The idiomatic way is to apply the changes that you want to make during __init__ in th second module.

2 Likes
3

That is one way, but __init__ functions are not particularly idiomatic. The common way to handle this (like Base.Docs) is to embed a variable within the new Module (Base.Docs.meta()) that contains the content relevant to that module.