Re: Re: Recovering the underlying TObject from a PyObject

On 10 August 2010 16:57, <wlavrijsen_at_lbl.gov> wrote:
> Tim,
>
>> Trying this on different machines it works as expected on one but not
>> on the other. So I suspect something strange going on on my OsX laptop
>> (where it does not work).
>
> so ... works on my Mac. I don't have a 10.4 (I've a 10.3.9 which I could
> revive and a 10.5).

Actually I am confused (showing off what a apple n00b I am) if I look at "about this mac" it makes me believe I have Mac OSX 10.6.4, uname -a makes me think I have 10.4.0

>
> The debugging will have to happen on your machine for a bit ...

I was wondering if it is possible that I screwed something up with 32/64bit compilation. I built root and python myself. I think both are correctly built as 64bit executables, at least if I do file `which python` I get told it is a "Mach-O universal binary with 3 architectures", one of which is x86_64. I need to read up on universal executables a bit to understand more though.

My first investigation down this path was to look at ROOT.gSystem.GetMakeSharedLib() which gives:

'cd $BuildDir ; g++ -c $Opt -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -D_REENTRANT -pthread $IncludePath $SourceFiles ; MACOSX_DEPLOYMENT_TARGET=10.6 g++ $ObjectFiles -dynamiclib -single_module -undefined dynamic_lookup -O2 -m64 $DepLibs -o $SharedLib'

which to me looks sensible.

>
>>> However with this tree will always be 0, pytree also seems to fail
>>> ObjectProxy_Check().
>
> Could you print it to see what pytree actually is?
>

I print the tree on the python side before calling getobj(), again inside the function and then the result of TTree* t = (TTree*)TPython::ObjectProxy_AsVoidPtr(pytree):

tree in python: <ROOT.TTree object at 0x104c42ef0> pytree: <ROOT.TTree object at 0x104c42ef0> ttree again: 0

Thanks,
Tim

-- 
http://tim.jottit.com/