Open GoogleCodeExporter opened 9 years ago
Is this the same as the patch provided in Issue #388?
Can we merge the two and close it out (after validating the patch performs as
intended and doesn't introduce any other issues)?
Original comment by jlo...@gmail.com
on 3 Jun 2013 at 1:02
Yes this should be a duplicate of issue 388 (although I haven't looked at the
patch yet).
Original comment by g.rodola
on 3 Jun 2013 at 1:05
Issue 388 has been merged into this issue.
Original comment by jlo...@gmail.com
on 3 Jun 2013 at 1:25
Merging this in as revision 55098fbdc601 - thanks Adrien!
Original comment by jlo...@gmail.com
on 3 Jun 2013 at 1:34
Jay, it seems you haven't pushed the change (try hg push).
Original comment by g.rodola
on 3 Jun 2013 at 5:03
Done, should be pushed now - sorry about that :)
Original comment by jlo...@gmail.com
on 3 Jun 2013 at 3:23
Thanks guys !
Do you have an idea of when the change will be released ?
Original comment by adrien.f...@gmail.com
on 3 Jun 2013 at 3:39
Original comment by g.rodola
on 8 Jun 2013 at 12:23
After revision 55098fbdc601 was pushed (discussion started in issue 388) here's
what I get on OSX 10.6:
running develop
running egg_info
writing psutil.egg-info/PKG-INFO
writing top-level names to psutil.egg-info/top_level.txt
writing dependency_links to psutil.egg-info/dependency_links.txt
reading manifest file 'psutil.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'psutil.egg-info/SOURCES.txt'
running build_ext
building '_psutil_osx' extension
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I/usr/local/include/python2.7 -c
psutil/_psutil_osx.c -o
build/temp.macosx-10.4-i386-2.7/psutil/_psutil_osx.o
psutil/_psutil_osx.c: In function 'get_process_memory_maps':
psutil/_psutil_osx.c:337: warning: format '%016lx' expects type 'long
unsigned int', but argument 3 has type 'vm_address_t'
psutil/_psutil_osx.c:337: warning: format '%016lx' expects type 'long
unsigned int', but argument 4 has type 'vm_address_t'
psutil/_psutil_osx.c: In function 'get_process_threads':
psutil/_psutil_osx.c:896: error: 'thread_identifier_info_t' undeclared
(first use in this function)
psutil/_psutil_osx.c:896: error: (Each undeclared identifier is
reported only once
psutil/_psutil_osx.c:896: error: for each function it appears in.)
psutil/_psutil_osx.c:896: error: syntax error before 'id_info_th'
psutil/_psutil_osx.c:952: error: 'THREAD_IDENTIFIER_INFO' undeclared
(first use in this function)
psutil/_psutil_osx.c:959: error: 'id_info_th' undeclared (first use in
this function)
psutil/_psutil_osx.c:959: error: syntax error before 'thinfo_with_id'
error: command 'gcc' failed with exit status 1
I grepped into /usr/include and I couldn't find any reference to
thread_identifier_info_t or THREAD_IDENTIFIER_INFO so this apparently looks
like something which
can be supported on recent OSX versions only.
If that's the case we should revert that change and/or see is we can find a
workaround.
Original comment by g.rodola
on 10 Jul 2013 at 9:42
Change reverted in revision b494fbbc7981 for now.
Original comment by g.rodola
on 10 Jul 2013 at 12:54
I was running 10.6 when I merged this patch in and tested it, so I'm not sure
why it would be a problem for your 10.6 system. It's in mach/thread_info.h on
my 10.8 system, perhaps we need to explicitly include that? I may have access
to another 10.6 system I can test on also, I'll see if I can reproduce it.
Original comment by jlo...@gmail.com
on 10 Jul 2013 at 1:11
I'm on 10.8.4 and I see them in mach/thread_info.h. Do you see them in that
file? If not, can you check which file has the other symbols like
thread_basic_info_t or THREAD_BASIC_INFO or thread_info and look in the same
file if you can find thread_identifier_info_t or THREAD_IDENTIFIER_INFO.
FYI, this compiles fine for me.
Original comment by kunalpar...@gmail.com
on 9 Aug 2013 at 9:30
Original issue reported on code.google.com by
g.rodola
on 22 Oct 2011 at 12:36