Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [incquery-dev] Viewers refactoring, help needed
I have clarified that the "bug" was equally present on 3.8 and 4.3, so no inconsistency there (my bad).

With Abel's help we managed to make the fixed computedset work correctly - for the time being, I have opted for option 1) (including a verbatim copy with the patched code blocks in our source tree).

We should discuss all related open questions on the next meeting.

cheers
Istvan

--
Istvan RATH, PhD
Research fellow
Budapest University of Technology and Economics
Fault Tolerant Systems Research Group

On Friday, September 20, 2013 at 2:22 PM, Ujhelyi Zoltán wrote:

We are using Kepler (4.3) for testing; it is possible that some changes were added to platform/JFace that helps something, but as you said, it is still not correct.

Some clarification: data binding was not suggested as the "primary" event tracking API, just something that can fill the gap until we stabilize EVM for common use; we knew from the first moment that this approach has its shortcoming, but it was easy to implement for end-users.

On the other hand, Viewers was modeled after the JFace Data binding API, as it is already used for this reason. It helped a lot to kickstart the implementation and test out what are the critical elements. Additionally, the EVM API matured a lot meanwhile, and now it is more ready to form the basis of Viewers directly than half a year ago.

Zoli
-- Zoltán Ujhelyi

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

On 2013.09.20., at 14:14, Istvan Rath <rath@xxxxxxxxxx> wrote:

THanks, I'll do some testing with this. Btw, which version of the Eclipse platform are you testing/running this on? Because I have noticed that with my naive implementation, the behavior is almost correct on 4.3, but extremely buggy on 3.8.

On a related note, I'm beginning to think that our choice of data binding as the "primary" event tracking API for IncQuery may not have been the best idea. Additionally, building things such as Viewers on databinding now also seems more and more questionable...

--
Istvan RATH, PhD
Research fellow
Budapest University of Technology and Economics
Fault Tolerant Systems Research Group



On Friday, September 20, 2013 at 2:06 PM, Ábel Hegedüs wrote:

I have done a bit more digging in the ComputedSet implementation and came up with a possible fix, but it involves a minor change in the ComputedSet implementation itself (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=414297)

While the patched ComputedSet passes all test cases as defined by the JFace data binding test suite and the small test case that we originally wrote for the issue. It would be nice to test whether the patch fixes the problems in the Viewer framework as well.

If it does, we have several options:
- we can choose to include the patched ComputedSet implementation as an internal class in Viewers. We keep all copyright information and include a disclaimer that the code is copied verbatim from the original class. This is quite ugly.
- we can implement our own observable set (possibly closer to EVM) that is specifically designed with the assumptions that we can make for the viewer framework
- we can decide to use only lists for now, with the expectation that the viewer framework will have to be reimplemented without relying on data binding.

As Zoltán said, we can choose to cut out several levels of observable collections by using the EVM API in the viewer framework and implementing specific observables for items, edges and containment, where the Match->Item/Edge conversion is done by the EVM jobs, instead of data binding converters.

Cheers,
Ábel Hegedüs

Fault Tolerant Systems Research Group
Department of Measurement and Information Systems
Budapest University of Technology and Economics


On 2013.09.19. 22:34:25, Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx (mailto:ujhelyiz@xxxxxxxxxx)> wrote:

Sadly, I am not completely surprised that it is not possible to put a ComputedSet inside another; as they try to monitor changes inside the Data binding Realm, and then manually compare the results. We have already observed some cases with forgotten notifications earlier.

What I was originally thinking is to forget about creating a two-level observable collection building and provide a single ComputedSet - it looks really bad, and it could perform quite bad, as it cannot only recalculate a single small ComputedSet but always the other. This approach is even more naive then your implemented solution, however, I have no better idea while relying on the data binding framework.

The only other think I can think about is to extend the data binding layer to create an Observable set directly on the EVM level - however, I am not entirely sure whether that is a useful thing to have outside Viewers (but possibly it is). Some recent functionality created for the transformation API could also help in this regard.

Ábel, what do you think about this approach?

Cheers,
Zoli
-- Zoltán Ujhelyi

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

On 2013.09.19., at 16:26, Istvan Rath wrote:

OK I gave this another try today, with a very naive approach: the ComputedSet of ComputedSets.


At first, I thought it to be working correctly, but then it turned out that it doesn't :-(
(Extremely weird behavior, e.g. returns semi-correct results in a debugging session, but completely bogus (empty) results when run normally…)

Any ideas?


--
Istvan RATH, PhD
Research fellow
Budapest University of Technology and Economics
Fault Tolerant Systems Research Group



On Monday, August 12, 2013 at 7:01 PM, Ujhelyi Zoltán wrote:

Hi,
HI all,

for now, I have sent a message to the Platform forum, as maybe we have missed something (although I am more likely to think it is a bug).

Are there any news regarding this?
Neither in the forum nor in Bugzilla.

I am not entirely sure about it, but maybe a more complex computedset implementation could also solve the issue, as we did not experience the same issues with only a single ComputedSet, but maybe I have missed some corner case. (The current implementation is logically cleaner, but maybe this is required).


So, if I understand correctly, we should do a workaround by implementing a custom computedset that would emulate the unionset correctly?
Yes, I was thinking among this angle.

Zoli
_______________________________________________
incquery-dev mailing list
incquery-dev@xxxxxxxxxxx (mailto:incquery-dev@xxxxxxxxxxx)


_______________________________________________
incquery-dev mailing list
incquery-dev@xxxxxxxxxxx (mailto:incquery-dev@xxxxxxxxxxx)

_______________________________________________
incquery-dev mailing list
incquery-dev@xxxxxxxxxxx (mailto:incquery-dev@xxxxxxxxxxx)
_______________________________________________
incquery-dev mailing list
incquery-dev@xxxxxxxxxxx (mailto:incquery-dev@xxxxxxxxxxx)


_______________________________________________
incquery-dev mailing list

_______________________________________________
incquery-dev mailing list

Back to the top