Community
Participate
Working Groups
Implement new binary format to replace existing XML format. - Standalone mode: Allow the possibility to switch between XML and binary format by entering new command line parameter: format=binary|xml (default binary) - enabled/controlled mode (via AC) Introduce negotiation protocol allowing client to determine the possibility to use binary format (compatibility with older clients/profilers)
Created attachment 88134 [details] Initial implementation of the Binary Format This patch incorporates all changes required for producing binary trace file in standalone mode. To do that use new option 'format=binary'. The implementation is not complete though it covers basic design and structure of the new format.
Wouldn't be better to have the XML format default (to ensure that old clients will work) and if you connect with a new client it will set the binary format (this will be default on the client side) or whatever format the user had chosen.
Thanks Marius! Making XML format default for standalone mode does make sense. I shall think on it and provide explanations within the next patch. Format negotiation protocol is not implemented yet, but it would work similar to your suggestion.
(In reply to comment #3) > Thanks Marius! > Making XML format default for standalone mode does make sense. I shall think on > it and provide explanations within the next patch. > Format negotiation protocol is not implemented yet, but it would work similar > to your suggestion. I think the suggestion is to make the default XML in all cases, and the client (workbench) or command line user can specifically ask for binary. I am assuming that we will have a new file extension like trcbin or something, and we will add support for streaming to file on the workbench side as well as a new import hook.
IMO, It's better to configure for XML format when working with old clients. Default mode should better provide best available format by default. Users who we want to attract by new better profiler in TPTP 4.5 should get good first experience with default options.
(In reply to comment #5) > IMO, It's better to configure for XML format when working with old clients. > Default mode should better provide best available format by default. > Users who we want to attract by new better profiler in TPTP 4.5 should get good > first experience with default options. Agreed, so when a 4.5 workbench launches or attaches to the TI agent it can request binary data and the user gets the benifits. What we have to deal with is if a pre 4.5 workbench connects with a 4.5 TI agent then the agent needs to produce XML without being asked to. The same holds true for standalone mode. Mixed environments are normal for TPTP.
This is a more general question than one related to binary xfer... I understand that we support 4.5 workbench connecting to pre-4.5 agents. I was not aware that we were supposed to support pre 4.5 workbenches connecting to 4.5 agents. That seems a strange combination to support. Thx, Chris
(In reply to comment #7) > This is a more general question than one related to binary xfer... > > I understand that we support 4.5 workbench connecting to pre-4.5 agents. > > I was not aware that we were supposed to support pre 4.5 workbenches connecting > to 4.5 agents. That seems a strange combination to support. > > Thx, > Chris > The old workbench naturally doesn't have to support the new agent but the newer agent has to maintain backward compatability. We see these configurations in the real world all the time. Particularly when customers are doing staged release updates. You can often have 100 users spread across 3 release levels of the workbench sharing 10 dept. servers that are in transition over a few weeks. Either way, it doesn't seem to difficult to maintain this backward compatible behavior.
(In reply to comment #7) > This is a more general question than one related to binary xfer... > > I understand that we support 4.5 workbench connecting to pre-4.5 agents. > > I was not aware that we were supposed to support pre 4.5 workbenches connecting > to 4.5 agents. That seems a strange combination to support. > > Thx, > Chris > The backward compatibility, newer workbench should work on previous workspaces and with previous agents, should be ensured at all levels (model, transport protocol, persistence format, preferences etc). The way I understand binary profiling support it shouldn't be any problem in leaving the old behavior in place. The new profiling format/behavior should be build as a vertical component beside the old one, and just set the old one by default when working with old AC (pre TPTP 4.5) and new one default for AC 4.5 (including IAC 4.5). AC 4.5 profiling agent should be able to handle requests from a pre TPTP 4.5 workbench. To ensure these rules there should be a negotiation protocol between workbench and agent(s), which will identify the best workbench/agent behavior path for each profiling session.
Created attachment 90073 [details] BF emitter with new format header support Changes: - introduce new format header (stabilized) - remove system message #1 (ex-format header)
Stanislav, you have this enhancement listed in the weekly schedules and yet this feature is not in plan for 4.5. Are you planning to resolve this in 4.5? If so, please create a FDD and request arch board review
Actually, this is a part of bug 196713. W/o this emitting part BF format loader is meaningless. So, yes, I am going to resolve this in 4.5i6
Joanna, parent bug 196713 has description document - is it enough or I should add more details? Alexander has scheduled AG review on next week.
(In reply to comment #13) > Alexander has scheduled AG review on next week. Alexander has not yet requested an AG review.
> Alexander has not yet requested an AG review. > Well, I do it right now. :) Paul, could you arrange AG review for this enhancement on Thursday or Friday next week. Thanks.
(In reply to comment #15) > > Alexander has not yet requested an AG review. > > > Well, I do it right now. :) > Paul, could you arrange AG review for this enhancement on Thursday or Friday > next week. > Thanks. > Done. Fri Feb 29 @ 10 AM ET.
This should be a child defect of the root-level enhancement.
(In reply to comment #17) > This should be a child defect of the root-level enhancement. > Yes, it depends on bug 196713 which is root-level enhancement.
Created attachment 90763 [details] Minor optimizations and two new system messages Changes: - new system message defining character encoding - new system message defining max qualified CPU frequency - CPrintBinary code dealing with output buffer is optimized
(In reply to comment #18) > (In reply to comment #17) > > This should be a child defect of the root-level enhancement. > > > > Yes, it depends on bug 196713 which is root-level enhancement. > Usually child defects block parent enhancements (e.g. work item required for the enhancement).
Thanks Paul. I changed dependencies.
Created attachment 93127 [details] Handshaking protocol introduced Changes: - handshaking protocol (binary/xml format enabling) is introduced
Igor, could you, please, verify this patch and check it into repository.
Created attachment 93278 [details] Profiler-side support for BF Final patch for commitment.
Resolving defect as fixed. Please reopen if problem found during test pass.
patch is committed to the HEAD
Created attachment 93439 [details] Fix broken build for Windows Fix broken build for Windows EM64T and IPF
Comment on attachment 93439 [details] Fix broken build for Windows patch was moved to appropriate bug 223830
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since the originator of this enhancement/defect has an inactive Bugzilla account and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
