Community
Participate
Working Groups
In bug 387299 in requested to make RAT also take into consideration when we do a CIF#invoke which Oleg closed because this would change the behior of invoke which is not desired. To fix our timerExec problem I'd like to propose 3 new invoke-methods who explicitly turn on tracking so the API user decides whether he wants to track accesses or now. patch with implementation and test case to follow
Created attachment 224738 [details] patch
Tom, could we just include the last public method, and allow passing in null for the static context and null for the default return value? Is that not what the other 2 methods resolve to? PW
Yes but I thought it would not harm to provide all 3 variations like we have on simple invoke but if this is the only problem I've no problem removing them.
Unfortunately this patch is completely wrong :-( we are only going through the RAT on leaf change but the other reinjections are done through method-requestor reinjection
Created attachment 224960 [details] another try This patch follows another route - it disables the pausing so the RAT recording the changes and on change we rerun the RAT. The test checks that and it recreates the RAT on the activeChild so we have no effectivly 2 RATs
Created attachment 224961 [details] New JUnit-Test
Comment on attachment 224961 [details] New JUnit-Test have to correct myself - the RAT-RAT is needed, else we'll get update requests when changes are made e.g. to an inactive child!
Created attachment 224962 [details] New Test Improved test with some error output - there still seems to be a problem which happens when we activate/deactivate branches where we get 2 requests instead of only 1
I think the reason why this is arbitary is which modification in the map is executed earlier.
Created attachment 224967 [details] Improved diagnose Fixed test implementation which only invoked once
The last problem is that RAT is not able to track ExtendedObjectSuppliers need to take a look into them need to see how I can make get them into RAT
Created attachment 224975 [details] Approach to RaT ExtendedObjectSupplier Unfortunately ExtendedObjectSuppliers do not take part in change computations like values in the PrimaryObjectSupplier do. I've experimented with the approach to pass on the RaT to invokeAndTrack and make the ExtendedObjectSupplier directly calling back to it when a value changes. As an example I implemented the PreferenceObjectSupplier to make use of the new API. I really have no better idea for ExtendedObjectSupplier and RaT. We could decide that we are not providing reinjection support for @Preference and @EventTopic but I don't really think this is an option, right?
Tom, I've turned your last patch into a Gerrit patch set, https://git.eclipse.org/r/#/c/10943/ I'd like to review this for M6 (Tomorrow and Monday) to see if we can get this in and remove the timer in Kepler. PW
(In reply to comment #5) > Created attachment 224960 [details] > another try Tom, was this in good shape except for the fact it didn't deal with ExtendedObjectSuppliers? PW
(In reply to comment #14) > (In reply to comment #5) > > Created attachment 224960 [details] > > another try > > Tom, was this in good shape except for the fact it didn't deal with > ExtendedObjectSuppliers? > > PW Yes
I'm going to work from patch set 7, see how far I get. PW
Working with attachment 224960 [details] it can track arguments in invokeAndTrack calls. But because of how most of the client code is structured it doesn't appear to keep most tool items up to date. PW
Please reopen if that is still relevant.
