Okay... I finally had a closer look at the documentation/code. As you mentionned, the contribution is based on an earlier version of the code (from around Jan/2010) and a number of changes have occured in the code base since (some of them small and subtle, others more substantial).
I think that we should discuss the various facets of your contribution in distinct Bugzillas. Therefore I openend the following bugs (note that the bug descriptions are mostly copied Thomas/Aaron's document): - [TMF] Add event skipping to TmfTrace<https://bugs.eclipse.org/bugs/show_bug.cgi?id=326820> - [TMF] TmfTrace/Experiment indexing improvement<https://bugs.eclipse.org/bugs/show_bug.cgi?id=326821> - [TMF] Event filtering<https://bugs.eclipse.org/bugs/show_bug.cgi?id=326822> - [TMF] TmfTimeRange extension<https://bugs.eclipse.org/bugs/show_bug.cgi?id=326822> - [TMF] TmfDataRequest extension<https://bugs.eclipse.org/bugs/show_bug.cgi?id=326824> As hinted above, the code is not exactly "ready for commit". I suggest that, if possible, you bring it up to the latest version (HEAD) and provide patches for the different bugs. If it's too much trouble I can do it (I really need some of your contributions :-) but I would like you to upload at least something (patches) for the various bugs. This way it is easier for me to give you official contribution credit. Also, I have a few questions/remarks that could eventually justify creating new feature-tracking bugs: - Would it make sense to extend the ITmfTrace API to introduce getPreviousdEvent()? I can see that implementation could be nightmarish in some cases (LTTng for example...) but why not? Maybe adding API like ITmfTrace.getCapabilities(), returning a TmfTraceCapability[], would allow to handle some functions more efficiently in the base class (TmfTrace). Minor stuff. - As discussed in [TMF] Event filtering<https://bugs.eclipse.org/bugs/show_bug.cgi?id=326822>, I wonder if it wouldn't be more interesting to keep ITmfTrace simple and move the filtering stuff to its own API (e.g. ITmfEventFilter). Then the filter could be added to the TmfData/EventRequest constructors instead of extending TmfDataRequest and the filter object could be re-used outside the context of a request (we have an internal use case for this). - I am a little bit confused about the meaning of a filtered experiment. Do you mean to have multiple instances of an experiment using various filters? I am a bit curious as this is not one of my use cases and I wonder how you intend to use this. To be discussed in the bug :-) Thanks, /fc On Wed, Sep 22, 2010 at 1:24 PM, Spear, Aaron <aaron_sp...@mentor.com>wrote: > <<Mentor_Graphics_Changes_to_the_Eclipse_TMF.pdf>> Hi all, > > As described by me here at the CDT summit, attached is a document > written by Thomas Gatterweh of Mentor Graphics in Vienna. The document > describes the changes we made to the TMF API's while in the process of > development of our "EDGE System Analyzer" product, which uses TMF. The > actual code changes will be following as soon as I get some approval > from our legal department (sigh...) > > Best regards, > Aaron > > -- > Aaron Spear | Tools Architect > Mentor Embedded(tm) | 29551 Chestnut Dr, Evergreen, CO. USA > P 303.679.8457 | M 303.946.6516 > Nucleus(r) | Linux(r) | Android(tm) | Services | UI | Multi-OS > > Android is a trademark of Google Inc. Use of this trademark is subject > to Google Permissions. > Linux is the registered trademark of Linus Torvalds in the U.S. and > other countries. > > > > _______________________________________________ > linuxtools-dev mailing list > linuxtools-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev > > -- Francois
_______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
