Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dependent blocks #249

Closed
timholy opened this issue Mar 8, 2019 · 0 comments · Fixed by #497
Closed

Dependent blocks #249

timholy opened this issue Mar 8, 2019 · 0 comments · Fixed by #497
Labels

Comments

@timholy
Copy link
Owner

timholy commented Mar 8, 2019

Revise's "top-level block" design does not allow it to do the right thing when flag is changed below:

flag = false
if flag
    f() = 1
else
    f() = 2
end

Revise will happily update flag but the consequences will not propagate to f, as f is defined in a different :block expression.

In case anyone thinks this is easy, consider

flag = false
if flag
    f() = 1
else
    f() = 2
end

flag = true
ccall(:initialize_a_c_library_that_will_crash_julia_if_initialized_twice, Any, (CInt,), Cint(0))
push!(container, "I really didn't want two copies of this string in `container`")
if flag
    g() = 1
else
    g() = 2
end

Now just update the second time flag is set and imagine trying to come up with the right definition of both f and g without crashing Julia. And make it work if the definitions of g are in a different file from this one, etc.

The whole backedges.jl infrastructure lays the groundwork for this, but there is still a lot to do. And it's also possible that this shouldn't be fixed at all; imagine moving the push! command inside the flag block; should it be run again or not?

timholy added a commit that referenced this issue Mar 25, 2019
The goal here is to figure out which statements need to be executed
and which can be ignored. Also takes a step twoards resolving issue #249.
timholy added a commit that referenced this issue Mar 25, 2019
The goal here is to figure out which statements need to be executed
and which can be ignored. Also takes a step twoards resolving issue #249.
timholy added a commit that referenced this issue Nov 2, 2019
Backedges allow us to figure out which statements need to be executed
and which can be ignored. Also takes a step towards resolving issue 
#249.
@timholy timholy mentioned this issue May 23, 2020
@timholy timholy added the bug label May 25, 2020
timholy added a commit that referenced this issue May 28, 2020
This is a major rewrite of the backedge component.
Moving it to LoweredCodeUtils and giving it
a "real" API led to many improvements
in selectivity of code-evaluation.

This rewrite aims to make Revise do just one thing,
which is to update methods. "Data" is not touched.
In this world, #249 is not a bug.
The benefit is that `includet` should work much more
reliably to distinguish "code" from "method definitions";
by and large, the days of needing to separate code
from method definitions in order to avoid confusing
Revise should be over.

Importantly, this introduces multiple "modes" of
operation. `:sigs` is for signature extraction,
`:eval` is for full evaluation (as you might do
during the initial `includet` on a file), and
`:evalmeth` is used during revision. This is essentially
a generalization of `define::Bool` to allow more
nuanced behavior.

Fixes #479
Closes #249
timholy added a commit that referenced this issue May 29, 2020
This is a major rewrite of the backedge component.
Moving it to LoweredCodeUtils and giving it
a "real" API led to many improvements
in selectivity of code-evaluation.

This rewrite aims to make Revise do just one thing,
which is to update methods. "Data" is not touched.
In this world, #249 is not a bug.
The benefit is that `includet` should work much more
reliably to distinguish "code" from "method definitions";
by and large, the days of needing to separate code
from method definitions in order to avoid confusing
Revise should be over.

Importantly, this introduces multiple "modes" of
operation. `:sigs` is for signature extraction,
`:eval` is for full evaluation (as you might do
during the initial `includet` on a file), and
`:evalmeth` is used during revision. This is essentially
a generalization of `define::Bool` to allow more
nuanced behavior.

Fixes #479
Closes #249
timholy added a commit that referenced this issue May 29, 2020
This is a major rewrite of the backedge component.
Moving it to LoweredCodeUtils and giving it
a "real" API led to many improvements
in selectivity of code-evaluation.

This rewrite aims to make Revise do just one thing,
which is to update methods. "Data" is not touched.
In this world, #249 is not a bug.
The benefit is that `includet` should work much more
reliably to distinguish "code" from "method definitions";
by and large, the days of needing to separate code
from method definitions in order to avoid confusing
Revise should be over.

Importantly, this introduces multiple "modes" of
operation. `:sigs` is for signature extraction,
`:eval` is for full evaluation (as you might do
during the initial `includet` on a file), and
`:evalmeth` is used during revision. This is essentially
a generalization of `define::Bool` to allow more
nuanced behavior.

Fixes #479
Closes #249
timholy added a commit that referenced this issue Jun 6, 2020
This is a major rewrite of the backedge component.
Moving it to LoweredCodeUtils and giving it
a "real" API led to many improvements
in selectivity of code-evaluation.

This rewrite aims to make Revise do just one thing,
which is to update methods. "Data" is not touched.
In this world, #249 is not a bug.
The benefit is that `includet` should work much more
reliably to distinguish "code" from "method definitions";
by and large, the days of needing to separate code
from method definitions in order to avoid confusing
Revise should be over.

Importantly, this introduces multiple "modes" of
operation. `:sigs` is for signature extraction,
`:eval` is for full evaluation (as you might do
during the initial `includet` on a file), and
`:evalmeth` is used during revision. This is essentially
a generalization of `define::Bool` to allow more
nuanced behavior.

Fixes #479
Closes #249
timholy added a commit that referenced this issue Sep 7, 2020
This is a major rewrite of the backedge component.
Moving it to LoweredCodeUtils and giving it
a "real" API led to many improvements
in selectivity of code-evaluation.

This rewrite aims to make Revise do just one thing,
which is to update methods. "Data" is not touched.
In this world, #249 is not a bug.
The benefit is that `includet` should work much more
reliably to distinguish "code" from "method definitions";
by and large, the days of needing to separate code
from method definitions in order to avoid confusing
Revise should be over.

Importantly, this introduces multiple "modes" of
operation. `:sigs` is for signature extraction,
`:eval` is for full evaluation (as you might do
during the initial `includet` on a file), and
`:evalmeth` is used during revision. This is essentially
a generalization of `define::Bool` to allow more
nuanced behavior.

Fixes #479
Closes #249
timholy added a commit that referenced this issue Sep 16, 2020
This is a major rewrite of the backedge component.
Moving it to LoweredCodeUtils and giving it
a "real" API led to many improvements
in selectivity of code-evaluation.

This rewrite aims to make Revise do just one thing,
which is to update methods. "Data" is not touched.
In this world, #249 is not a bug.
The benefit is that `includet` should work much more
reliably to distinguish "code" from "method definitions";
by and large, the days of needing to separate code
from method definitions in order to avoid confusing
Revise should be over.

Importantly, this introduces multiple "modes" of
operation. `:sigs` is for signature extraction,
`:eval` is for full evaluation (as you might do
during the initial `includet` on a file), and
`:evalmeth` is used during revision. This is essentially
a generalization of `define::Bool` to allow more
nuanced behavior.

Fixes #479
Closes #249
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant