Provide actions for text-based streamers #578
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In most cases it should be same actions like for binary I/O, but several special cases will be implemented. Also in such list original (not-compressed) list of data members will be used. This will solve problem of unfolding such compressed members later
Main difference - it is not-optimized list, therefore there is no need to unfold compressed data members
When such classes stored, class streamer called directly. Such approach does not work with text storage, therefore special actions required.
When TObject instance was stored as is, wrong output was produced. Now UniqueID, fBits and process ID stored normally
Required for special handling of kStreamerLoop members. Special case when empty arrays should be stored - binary I/O completely ignores such containers, but text representaion need normal array structure arround nulls
isText boolean parameter let provide customization for text-based streaming. Potentially same action can be used for binary I/O
It should be handled as normal array.
Just reuse postprocessing code for TObject. Makes output more readable, but TRef need much more work to be supported with JSON and JSROOT
In original code direct class streamer is called, which is impossible to handle with TBufferJSON. Keep binary code as well in the action to have possibility use same code-base for binary use-case
|
Starting build on |
pcanal
reviewed
May 16, 2017
| // TODO: subinfo used for WriteBufferSTL call, which is private for the moment | ||
| //TStreamerInfo *subinfo = (TStreamerInfo*)vClass->GetStreamerInfo(); | ||
|
|
||
| //for (int k = 0; k < narr; ++k) { |
Member
There was a problem hiding this comment.
This line is comment-out, I assume it is not in the original. Is that the correct change (and if so, it should be explained) or is that inadvertently removing support for C-style array of STL vectors?
Member
There was a problem hiding this comment.
potentially can be used later for non-text streaming
To verify that the code is indeed correct (at least as far as roottest can tell), I recommend to go ahead and also use those for the binary case.
Member
Author
There was a problem hiding this comment.
For the moment this part is not used - it is only for binary I/O.
To enable this, one should made subinfo->WriteBufferSTL() public
Member
There was a problem hiding this comment.
Why would it need to become public? In the contrary, isn't the action making WriteBufferSTL obsolete?
Member
Author
There was a problem hiding this comment.
WriteBufferSTL still used in normal I/O.
Once we implement correspondent actions (including writing branches data), WriteBufferSTL can be removed.
Member
There was a problem hiding this comment.
Once we implement correspondent actions
I was pushing you in that direction as it will increase the test coverage and benefit all users ;)
Member
Author
There was a problem hiding this comment.
I was pushing you in that direction as it will increase the test coverage and benefit all users ;)
I prefer do it in small steps.
We have functional code and can incrementally improve it.
My main motivation now - clearly separate binary and text streaming from each other.
Once it is done, we could remove many workarounds from both.
Member
|
Please merge this into master only after the branch of v6-10-00-patches (which is imminent). |
pcanal
reviewed
May 16, 2017
io/io/src/TStreamerInfoActions.cxx
Outdated
|
|
||
| /** Direct copy of code from TStreamerInfo::WriteBufferAux, | ||
| * potentially can be used later for non-text streaming */ | ||
| template<bool isText> |
Member
There was a problem hiding this comment.
this should read kIsTestT (k for constant, trailing T for template parameter).
Member
Author
There was a problem hiding this comment.
You mean: template<bool kIsTextT> ?
Member
|
And be careful about "Merge branch 'master' into json"... |
|
Build failed on mac1012/native. Warnings:
|
Member
Author
I can remove this merge commit |
|
Starting build on |
Member
Author
|
Should I create new PR without merge commit? |
Member
|
yes, we can not include the PR with a merge commit. |
Member
Author
|
I closing PR and prepare new |
Member
|
I think so... You should rebase (it's what Vassil told me...) |
Member
Author
|
There are not that many commits, I can cherry-pick them |
Member
|
As you prefer |
Member
Author
This PR solves most of known problems with TBufferJSON and does not touch basic I/O. |
This was referenced Dec 14, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Idea to create separate actions list, which will be used only for text-based streaming.
Most actions functions can be reused from normal I/O,
only several cases should be implemented slightly different.
On the long run one could create complimentary actions list for reading data with TBufferXML or TBufferSQL2 and fully isolate text-based and binary I/O
That is in PR:
PR solves several existing problem with JSON:
With provided code all my test classes working. I can provide patch for roottest.
P.S. Most probably, Travis-CI check will be unhappy about source-code formatting.