strange behaviour

[questor]

I've integrated your lib into my own toy-project and have a really strange behavior:
I compile and start my program in the original state and it runs.
Now I modify a small parameter (call if mod1)
jet runs and recognizes my filechange and recompiles the file
I reload the application and get 2 messages "[E]: WTF" coming from the elf loader
the program gets reloaded and some functions are relocated
now the program runs, but still in the original state (without mod1!)
now I again change something (mod2)
it gets recompiled
I reload and get again 2 times the WTF message
now the program runs in the mod1 state and not with my latest modifications, so it seems it is always one step behind?!

I understand if it works (of course) or if it does not work (not so nice), but beeing one step behind is strange. Anything I can dig into to find out what is going on?

my environment is linux 64bit, clang 7.1.0 x86_64-pc-linux-gnu

[ddovod]

Hey, thanks for the report!
Usually [E]: WTF is not very dangerous (at least it wasn't the case on the projects I'm working on), but it fully depends on your project. Anyway the problem you're experiencing is really weird, it either should work or not at all. Right now I have a very tight schedule, so I'll have time to investigate this in a week or so.
Until that:

1. It would be great if you can share a minimal reproducible example so I can debug it on my side
2. Are tests pass on your setup? You can find the test runner command in the .travis.yml

[questor]

Hm. thanks for your hints. Giving you a simple reprocase is not that easy as it's my toy engine were I test new (and creative) ideas with an esoteric buildsystem, shadercompilation and so on. Maybe I can strip it down. But I got some other ideas to experiment.

Interestingly: in the project are more than one executable and with a very simple one (and my own integration of jetlive into that buildsystem) it works, so it seems it's not a general issue on the platform.

will play a bit and try to strip it down if nothing helps. Also will try to include debugging-printfs to find out what is going on.

[questor]

that was fast and easy to reproduce. I found that I have a class with a const int variable and changing this variable produces this strange behaviour. when I modify not the value itself but the usage the change gets reloaded fine. the basic structure is this:

class Test {
	const int blub = 20;
public:
	void print() {
		static int last = 0;
		if(last != blub) {
			printf("blub: %d\n", blub);
			last = blub;
		}
	}
};
Test test;
void mainFunc() {
	test.print();
}

If you setup an small example with the code above and you change the variable "blub" it will not be printed instantely because no change is detected. but when I remove the "blub" in the if, in the printf and in the assignment and replace it by a value it will get reloaded fine. In the above example it will never be changed by using jet-live, why in my toy-engine it get reloaded with a delay of one reload-cycle I'm still unsure (but I can live with it when I know where it does come from).

Honestly speaking I would have assumed, because it's a const int, the variable gets integrated directly into the code, but when I look with godbolt the variable will be put into a memory location and used from there: https://godbolt.org/z/b_B6Ch