Revise and const values changed during a session?

General Usage
1

Until now, I was used to having a file containing a module with some parameters, usually set with const keyword. This is very similar to a singleton - the design pattern, not the Julian singleton - and guarantees that anywhere in the code the configuration variables that I am using are the same.

During an interactive session, I just did include("src/myincludes.jl"); MyModule.main() to run the code while testing various parameters.

Today, I have some issues with JLD and type identity, for which I need to reload some file. For this reason, I am now using Revise. However, Revise I cannot reproduce the same workflow.

For instance, suppose having the following 4 files:

# A.jl
module A

const a = 6
b = 6

end

# B.jl
module B
using Main.A: a, b
function test()
    println(a, b)
end
end

# C.jl
module C
using Main.B: test
function main()
    test()
end
end

# D.jl
using Revise
__revise_mode__ = :eval

includet("A.jl")
includet("B.jl")
includet("C.jl")

During an interactive session, I run:

julia> include("D.jl");

julia> B.test()
66

julia> C.main()
66

Then, I change the values in A.jl and retry, but the output is still the same

julia> include("D.jl");

julia> B.test()
66

julia> C.main()
66

What is the most similar workflow to the one I am used while using Revise? I really need to have a module with many const values in it and to change those values in a running session.

2

I don’t know a way to do what you want without any syntax changes, but if you don’t mind changing how you acess the variables a little, you can do

module A
a() = 6
end

and access it via a() (i.e. define a function and call it)
or

module A
const a = Ref(6)
end

and access it by a[].

These of course are different things; by defining a function, you can rely on Julia to invalidate old code when the value changes and recompile (and Revise works well with this). When you mutate a ref, a[] = 1, then of course any code accessing the ref gets the current value. Revise does not work well with this approach if you modify the source code to e.g. const a = Ref(1) but you can modify it from code like a[] = 1.

3

Thank you so much! Today I have prepared a little test comparing your solution and another idea I had involving mutable structs. Your solution is by far the best (even better the not-working one).

Here the code and tests:

# A.jl
module A

# METHOD 1
# the following works but are not re-evaluated by Revise
const a = 5
b = 5

# METHOD 2
# functions are re-evaluated by Revise when they are changed
const c() = 5
d() = 5

# METHOD 3
mutable struct S
    vars::NamedTuple
    function S()
        # the following ensures that S cannot be reinstantiated without explicit
        # usage of `eval`
        isdefined(S, :s) && error("Cannot instantiate S twice")
        return new()
    end
end

# `const` ensures that the reference to the object will always be the same
const s = S()

# an easier way to get the settings
function getS()
    return s.vars
end

# defining fields in a function allows Revise to re-evaluate it when settings
# are changed
function init()
    s.vars = (a = 5, b = 5)
end

end


# B.jl
module B
using Main.A: a, b, c, d, getS
function test1()
    r = 0
    for i in 1:1000
        r += a + b
    end
    return r
end
function test2()
    r = 0
    for i in 1:1000
        r += c() + d()
    end
    return r
end
function test3()
    s = getS()
    r = 0
    for i in 1:1000
        r += s.a + s.b
    end
    return r
end
end

# C.jl
module C
using BenchmarkTools
using Main.B: test1, test2, test3
using Main.A: init


function main()
    init()
    println(@btime test1())
    println(@btime test2())
    println(@btime test3())
end
end

# D.jl
using Revise

includet("A.jl")
includet("B.jl")
includet("C.jl")

And here the tests:

julia> include("D.jl");

julia> C.main()
k  30.400 μs (958 allocations: 14.97 KiB)
12000
  1.492 ns (0 allocations: 0 bytes)
12000
  62.388 μs (958 allocations: 14.97 KiB)
12000

julia> C.main() # re-run after having  changed the settings
  30.289 μs (958 allocations: 14.97 KiB)
12000
  1.492 ns (0 allocations: 0 bytes)
10000
  62.629 μs (949 allocations: 14.83 KiB)
10000

As you see, method 1 doesn’t work on re-evaluation, method 3 works but is 2x slower, while method 2 works and is 20.000x faster

1 Like