Maybe I was wrong with what I wrote above. I thought Revise tracks only changes in functions, but this is obviously not correct (in retrospect I know that it also works with new struct definitions and so on).
Still I’m not sure exactly when and which parts of the code will be re-run when you make changes in the script above.
I guess what I am confused about your workflow is- what parts of the code do you wish that Revise will automatically re-evaluate as you are making changes?
Yep, tried that, logs returns a 0-element Array{Revise.LogRecord,1}.
I thought about X-posting this to the Issues section on github, but I know @tim.holy replies to the posts here very often, so I thought that it would be unnecessary flooding.
I don’t have time to dig into this in detail right now, but the short answer is that whenever you have problems with includet you should consider separating your “code” (function definitions) and “script” (tasks you want to run) into separate files. You should includet the functions and include the script. (Or better, make the functions a package, so you get the benefits of precompilation.)
This comes down to the fact that includet needs to be able to figure out what’s code-definition and what’s “work,” and run the code-definition in the interpreter and the work in the compiler (for reasons of performance, because the interpreter is really slow). Moreover, it needs to be extremely careful not to run certain kinds of things twice. Revise is already quite good at figuring these things out, but surely there are still some bugs and it’s fundamentally a hard (perhaps undecidable) problem. You can make its job easier by separating your code from your script-work and make sure it only tracks the former.
5 Likes
Alright, It makes sense. I will practice this separation (as @orialb and @ericphanson have suggested) of “global variables file” and “functions file”, looks like it’s the Julian way to go.
3 Likes