Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

PyROOT std.tuple_element not working on macOS #14232

Closed
1 task done
tmadlener opened this issue Dec 14, 2023 · 11 comments
Closed
1 task done

PyROOT std.tuple_element not working on macOS #14232

tmadlener opened this issue Dec 14, 2023 · 11 comments

Comments

@tmadlener
Copy link
Contributor

tmadlener commented Dec 14, 2023

Check duplicate issues.

  • Checked for duplicates

Description

This was originally reported in key4hep/EDM4hep#246 and I think it is a ROOT bug rather than one in podio / EDM4hep. At least the error message suggests that there is an issue somehwere in the underlying c++ infrastructure:

AttributeError: <class cppyy.gbl.tuple_element<1,tuple<int,float,string,double> > at 0x126829b00> has no attribute 'type'. Full details:
 type object 'tuple_element<1,tuple<int,float,string,double> >' has no attribute 'type'
 'tuple_element<1,tuple<int,float,string,double> >::type' is not a known C++ class
 'type' is not a known C++ template
 'type' is not a known C++ enum

Reproducer

The basic issue is that the following minimal reproducer does not work with
/cvmfs/sft.cern.ch/lcg/views/dev3/arm64-mac13-clang150-opt/setup.sh

import ROOT

ROOT.gInterpreter.LoadText("""
#include <tuple>
#include <string>
using ATuple = std::tuple<int, float, std::string, double>;
""")
from ROOT import ATuple

import cppyy
cppyy.gbl.std.tuple_element[1, ATuple].type

ROOT version

HEAD

Installation method

LCG stack (dev3)

Operating system

MacOS

Additional context

@peremato FYI.

@tmadlener tmadlener added the bug label Dec 14, 2023
@guitargeek
Copy link
Contributor

Hi! You are having two different C++ interpreters running there. The one of ROOT and the one of cppyy. I don't really understand why you do that. Maybe it's an artifact of how you constructed the reproducer? What about using PyROOT all the way?

import ROOT

ROOT.gInterpreter.LoadText("""
#include <tuple>
#include <string>
using ATuple = std::tuple<int, float, std::string, double>;
""")
from ROOT import ATuple

ROOT.std.tuple_element[1, ATuple].type

If you mix the independent interpreters in such a crazy way that you use the types from PyROOT as template parameters for cppyy types, it's not surprising that it fails.

@tmadlener
Copy link
Contributor Author

I think in this case the cppyy that we pick up is the one that comes bundled with ROOT1, and this seems to be working in all other OS'es (or at least we have not yet heard any complaints) except for macOS. I simply assumed that ROOT will just forward to its cppyy internally which is why I went for cppyy directly.

Let me try via PyROOT to see if that indeed already solves this.

Footnotes

  1. At least python -c 'import cppyy; print(cppyy.__file__)' yields <root-prefix>/lib/root/cppyy/__init__.py.

@tmadlener
Copy link
Contributor Author

Just tested this and we get the same error message:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: <class cppyy.gbl.tuple_element<1,tuple<int,float,string,double> > at 0x146607890> has no attribute 'type'. Full details:
  type object 'tuple_element<1,tuple<int,float,string,double> >' has no attribute 'type'
  'tuple_element<1,tuple<int,float,string,double> >::type' is not a known C++ class
  'type' is not a known C++ template
  'type' is not a known C++ enum
>>> 

This looks a bit like some mismatch between clang or libc++ versions(?), but I don't know where the specifics would enter in this case.

@guitargeek
Copy link
Contributor

Ah okay, interesting I didn't know you would pick up the cppyy from ROOT like this! Will investigate further next week when I can reproduce it. Interestingly, on my computer it works, even your original reproducer! So I think you're right, there must be some mismatch that happens with ROOT in your environment.

@gaede
Copy link

gaede commented Feb 2, 2024

Has there been any resolution to this issue ?
I observe the same error on a rather virgin macbook pro (coreI5, 14.3) after installing ROOT w/ homebrew (no LCG or Ke4hep stack involved).

@guitargeek
Copy link
Contributor

guitargeek commented Feb 5, 2024

@gaede, I still fail to reproduce the issue, but I'm intending to make the reproducer a unit test, hoping to see the failure on some of the platforms.

guitargeek added a commit to guitargeek/roottest that referenced this issue Feb 5, 2024
@gaede
Copy link

gaede commented Feb 5, 2024

@guitargeek, excellent thanks. Then we hope that it can be reproduced - and fixed ;-)

@guitargeek
Copy link
Contributor

It doesn't look like it can be reproduced so far :( Maybe after merging the roottest PR, we will see the failure at some point somewhere in the nightlies.

@gaede
Copy link

gaede commented Feb 23, 2024

Strange that you cannot reproduce this on any macos. I see this error even with using cppyy standalone:

import cppyy
cppyy.cppdef("""
#include <tuple>
#include <string>
using ATuple = std::tuple<int, float, std::string, double>;
""")

from cppyy.gbl import ATuple

cppyy.gbl.std.tuple_element[1, ATuple].type

print( cppyy )

Gives with cppyy and no root in the path:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: <class cppyy.gbl.std.tuple_element<1,std::tuple<int,float,std::string,double>> at 0x7f9365f9b1d0> has no attribute 'type'. Full details:
  type object 'tuple_element<1,std::tuple<int,float,std::string,d' has no attribute 'type'
  'std::tuple_element<1,std::tuple<int,float,std::string,double>>::type' is not a known C++ class
  'type' is not a known C++ template
  'type' is not a known C++ enum
>>> print (cppyy)
<module 'cppyy' from '/usr/local/lib/python3.9/site-packages/cppyy/__init__.py'>

And of course the same error using the cppyy shipped with root 6.26.06 and 6.28.04.

So to me it seems cppyy cannot deal with std::tuple on macos.

guitargeek added a commit to root-project/roottest that referenced this issue Mar 6, 2024
@guitargeek
Copy link
Contributor

The unit test with the reproducer from this PR is now running every night on all available macOS nodes, and passing just fine.

Could it be a problem when installing ROOT via homebrew? This was of installing ROOT is not supported by the ROOT team itself, so there might be some library mismatch there

@guitargeek
Copy link
Contributor

Strange that you cannot reproduce this on any macos. I see this error even with using cppyy standalone

If you see this even on cppyy standalone and you can clearly reproduce it, then please open an issue for cppyy. If it works upsteam but still not with ROOT, then this is a ROOT problem and we can reopen this issue if you want.

Until then, I suggest to close this issue, also because we can't reproduce in on any CI platform (we are testing multiple versions of macOS, both on Arm an x64).

Thanks for your understanding!

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
Development

No branches or pull requests

3 participants