-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to read a LorentzVector from a Tree #880
Comments
thanks for the report. I'll have a look. |
Looking into this a bit more on my own, I've noticed a few things:
|
yep, I have a temporary fix: diff --git a/groot/rdict/decoder.go b/groot/rdict/decoder.go
index 4502e539..7f5474e1 100644
--- a/groot/rdict/decoder.go
+++ b/groot/rdict/decoder.go
@@ -84,6 +84,16 @@ func (rr *rstreamerInfo) Bind(recv interface{}) error {
return fmt.Errorf("rdict: invalid kind (got=%T, want=pointer)", recv)
}
rr.recv = recv
+ if recv, ok := recv.(rbytes.Unmarshaler); ok {
+ // FIXME(sbinet): handle mbr-/obj-wise
+ rr.rops = []rstreamer{{
+ op: func(r *rbytes.RBuffer, _ interface{}, _ *streamerConfig) error {
+ return recv.UnmarshalROOT(r)
+ },
+ cfg: nil,
+ }}
+ return nil
+ }
if len(rr.rops) == 1 {
se := rr.rops[0].cfg.descr.elem
if se.Name() == "This" || that leads to:
|
This CL adds a temporary mitigation of go-hep#880. It tries to detect whether a given receiver for binding implements rbytes.Unmarshaler and use it instead of generating rstreamers. rstreamers may not properly work in the case where fields of a struct aren't exported. Updates go-hep#880.
see: #881 |
This CL adds a temporary mitigation of go-hep#880. It tries to detect whether a given receiver for binding implements rbytes.Unmarshaler and use it instead of generating rstreamers. rstreamers may not properly work in the case where fields of a struct aren't exported. Updates go-hep#880.
This CL adds a temporary mitigation of go-hep#880. It tries to detect whether a given receiver for binding implements rbytes.Unmarshaler and use it instead of generating rstreamers. rstreamers may not properly work in the case where fields of a struct aren't exported. Updates go-hep#880.
This CL adds a temporary mitigation of go-hep#880. It tries to detect whether a given receiver for binding implements rbytes.Unmarshaler and use it instead of generating rstreamers. rstreamers may not properly work in the case where fields of a struct aren't exported. Updates go-hep#880.
This CL adds a temporary mitigation of go-hep#880. It tries to detect whether a given receiver for binding implements rbytes.Unmarshaler and use it instead of generating rstreamers. rstreamers may not properly work in the case where fields of a struct aren't exported. Updates go-hep#880.
This CL adds a temporary mitigation of go-hep#880. It tries to detect whether a given receiver for binding implements rbytes.Unmarshaler and use it instead of generating rstreamers. rstreamers may not properly work in the case where fields of a struct aren't exported. Updates go-hep#880.
This CL adds a temporary mitigation of go-hep#880. It tries to detect whether a given receiver for binding implements rbytes.Unmarshaler and use it instead of generating rstreamers. rstreamers may not properly work in the case where fields of a struct aren't exported. Updates go-hep#880.
cool :) |
I've created #882 to track the more general issue of reading/writing types with private fields (and leveraging the |
I'm having difficulty reading from a branch of a tree that contains a
TLorentzVector
. I first noticed this when writing a short test script for some analysis ntuples, where I was usingrtree.Reader
to read into an instance ofrphys.LorentzVector
, but the same error occurs when runninggroot/cmd/root-dump
over a simpler test file.The test file was created with:
And the error is:
In particular,
rstreamer.go:766
seems to be trying to access therbase.Object
inside of therphys.LorentzVector
, so it can directly callUnmarshalROOT
on theObject
, rather than lettingLorentzVector.UnmarshalROOT
handle that. Since the object field of theLorentzVector
is not exported,reflect
panics during theInterface()
call ondescr.go:52
, if I'm following things correctly.It appears that
TLorentzVector
is registered inrtypes.Factory
out-of-the-box (and callingGoType()
on the branch of the tree returns"rphys.LorentzVector"
), so it seems like things should be in place. I would naively guess thatrstreamSI
should be following the case where it finds the root class in the factory, but I think it may actually be following the lastreturn
statement, where it ultimately loops overrdict.StreamerInfo.roops
and tries to decode the fields one at a time. I haven't tried to test that yet, I thought it better to report the problem in case I'm doing something stupid.The text was updated successfully, but these errors were encountered: