Just learned recently that uproot us upgrading soon
https://github.com/scikit-hep/uproot4#uproot-3-vs-uproot-4
FYI: https://www.youtube.com/watch?v=ea-zYLQBS4U&feature=youtu.be

Will the UpROOT.jl be affected?

also asked on discourse
https://discourse.julialang.org/t/tables-jl-uproot-jl-and-the-speed/44737/4

Hey, I tried to open a TTree with uproot.jl and got the following error
Error showing value of type TTree:
ERROR: KeyError: key "name" not found
Stacktrace:
[1] getproperty(::PyObject, ::String) at .../packages/PyCall/ttONZ/src/PyCall.jl:308
[2] getproperty(::PyObject, ::Symbol) at .../packages/PyCall/ttONZ/src/PyCall.jl:313
[3] awkwardobjectarray2jl(::PyObject) at .../packages/UpROOT/nF6Gy/src/pyjlconv.jl:25

It seems that the PyCall Code has changed.

When julia is killed while the TTree reading is being processed Atom crashes.

Julia 1.3.0
Windows 10

Can someone reproduce?

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

My ROOT tree contains covariance matrices,
the tree[1] breaks when Table is created

https://github.com/JuliaHEP/UpROOT.jl/blob/master/src/ttree.jl#L40

It happens because _ndims(nt) of TypedTables.jl is confused.

_ndims(::Type{<:Tuple{Vararg{AbstractArray{<:Any, n}}}}) where {n} = n

It wants that all object in the tuple are n-dims. arryas.

For some reason for matrices in branches pyobj(tree).arrays returns not an array of matrices, but 3d matrices.

https://github.com/JuliaHEP/UpROOT.jl/blob/master/src/ttree.jl#L39

...needs uproot4. See also scikit-hep/uproot3-methods#99

Add support for Base.close to close files, etc.

I cannot read histograms from this ROOT file. I think it's a floating point arithmetic issue.

julia> using UpROOT
julia> UpROOT.TFile("histos.root")["h_comp_roi"]
ERROR: Histogram edge vectors must be 1 longer than corresponding weight dimensions
Stacktrace:
 [1] error(s::String)
   @ Base ./error.jl:33
 [2] Histogram
   @ ~/.julia/packages/StatsBase/DU1bT/src/hist.jl:193 [inlined]
 [3] Histogram (repeats 2 times)
   @ ~/.julia/packages/StatsBase/DU1bT/src/hist.jl:199 [inlined]
 [4] roothist2jl(x::PyCall.PyObject)
   @ UpROOT ~/.julia/packages/UpROOT/YRyC3/src/pyjlconv.jl:58
 [5] py2jl(x::PyCall.PyObject)
   @ UpROOT ~/.julia/packages/UpROOT/YRyC3/src/pyjlconv.jl:78
 [6] getindex(tdir::TDirectory, objname::String)
   @ UpROOT ~/.julia/packages/UpROOT/YRyC3/src/tdirectory.jl:33
 [7] top-level scope
   @ REPL[8]:1

The right edges in the original histograms are 0:0.2:100, but the reconstructed range is 0.0:0.20000000000000004:99.80000000000003, which explains the error.

If I remove this if ... else here:

https://github.com/JuliaHEP/UpROOT.jl/blob/master/src/pyjlconv.jl#L45-L47

and just return edge, everything works as expected. Why trying to convert the histogram edges to a range object? Is there a performance gain?

We should think about implementing a custom HEPHistogram object with under/overflow bins à la ROOT.

The following minimum example code

using PythonPlot
using UpROOT

fails with:

free(): invalid pointer
signal (6): Aborted

Julia 1.7.3
UpROOT v0.3.3
PythonPlot v1.0.0

I guess it should be related to both packages calling Python.

Here is how I plot TGraphError extracted from TFile,

f = TFile("test.root")
c = f["myTGE"]  # typo of object PyObject <b'TGraphErrors' b'myTGE' 0x00003a8740f0>
plot(
    vcat(c.xvalues...),
    vcat(c.yvalues...),
    xerr = vcat(c.xerrors...), yerr = vcat(c.yerrors...),
    lab="",
    xlab = latexstring(replace(c.xlabel,"text" => "mathrm")),
    ylab = latexstring(replace(c.ylabel,"text" => "mathrm")),
    title = c.title
)

I think it would make a lot of sense to write a few recipes. I am just not sure how to check subtypes of these PyObject without writing the parser