As noted here, PStats isn’t included when installing Panda3D via Pip. Is there a way to get it in that case? (Aside, I suppose, from building it from source.)
And if I may ask, why is PStats not included in Pip-based installations? It’s such a useful tool that its lack can really be felt when performance issues crop up, I fear…
I would very much like to get pstats working with pip-based installs. There are currently issues around GTK (the GUI library used by pstats) and the manylinux1 Docker image to build the wheels. I believe the issues are solvable, but I need to get back to having a stable build environment (I have been running into issues with the Docker image) to continue experimenting.
The PIP package only contains parts of Direct and what’s needed for Python. PStats is written in C++ I believe. Is using a package install (e.g. .deb) at all possible?
EDIT: It appears I made a mistake about what could be packaged. Changes have been corrected.
We can ship binaries with wheels. For example, we ship egg2bam and pview.
I will add, lest a casual peruser of this forum post be misled, that we do ship PStats in the pip installation on Windows, just not on Linux.
As Moguri pointed out, there is no issue with shipping C++ binaries in pip packages in general, but the issue is the difficulty to pack the GTK+ library with all its dependencies in a self-contained, relocatable wheel. (On Windows, the PStats implementation uses the native Win32 API instead of GTK.)
I am grateful for efforts to try and address those issues. In the meantime, it is of course possible to use a .deb installation of Panda to get the PStats server GUI.
@Moguri and rdb: Fair enough, on all counts, and thank you for the explanation. I hope that a solution is found in the end!
One thought that occurs to me is to suggest using TK, as DirectTools does–it seems to work well enough there. That said, I forget whether it calls for a separate installation of TK on the part of the developer, which may be a downside if so.
Otherwise, could PStats be rewritten to use a Panda3D window, thus allowing it to employ DirectGUI?
That would mean rewriting PStats on top of the Tk library, which would be as big an effort as rewriting it for any other toolkit, such as FLTK or wxWidgets. (Note that the DIRECT tools are written in Python, whereas PStats is written in C++.)
I would be in favour of an implementation of PStats that either serves its results to a browser web page or displays it as an overlay on top of the Panda3D scene. However, using DirectGUI would limit its utility to Python users only, so perhaps it would be better to use PGui or LUI or even IMGUI.
Ah, I see–that makes sense.
I’ll confess that I’m not as familiar with the C++ side as the Python, and so not familiar with the constraints there.
I’m not convinced that overlaying it on the scene being monitored is the best option available: that could quite easily end up significantly obscuring the developer’s view of the program being monitored, and programs that hide the mouse cursor might interfere with use of PStats.
If a Panda3D GUI is to be used, I think that I’d prefer that it remain in a window (or set of windows) of its own. (I don’t know LUI or IMGUI offhand; am I correct in recognising PGui as the C++ implementation that underlies DirectGUI?)
Having the results appear in a web page might work, indeed. (Again, I’m not sufficiently familiar with the technologies involved to make any real suggestions for this approach, I’m afraid.)
I’d like to revisit this, if I may:
It’s generally been recommended to me, I believe, that going forward I use the “wheel” builds of Panda–and indeed, the BuildBot doesn’t seem to be generating “deb” builds at all, at least on the “deploy-ng” branch. But I also don’t want to swap back and forth every time that I want to use PStats.
So, is there some way of getting PStats separately? Could I perhaps build PStats alone from source, or is there a downloadable version somewhere, either way that I might simply run from a directory? (And would rebuilding or re-downloading be called for when I download a new version of the engine?)
If you use pip in combination with virtualenvs (or even tools that combine the two, like pipenv), it’s perfectly fine to have many versions of Panda3D installed at the same time. This would allow you to use the pstats from a .deb build while using a particular pip version of Panda3D in a particular project.
That said, the ideal is for us to be able to ship PStats build with the wheels on Linux as well, but I don’t know how achievable that is.
I’m not aware of standalone builds of PStats, but theoretically they could be produced by building Panda3D with the --static --no-python flags.
It does now. It just needs a bit of prodding from time to time. Just let @Moguri or me know if you’re ever missing a build.
I don’t, I’m afraid. ^^;
I suppose that I could figure it out–but that seems like a fair bit of additional complication just to get access to a single (albeit very useful) tool.
Hmm… It might be worth a shot.
Ah, thank you, both for poking the BuildBot and for the being willing to do so. 
It’s tempting to go back to the “deb” builds.
Hmm… I do have a thought. It wouldn’t be a complete solution by any means, and it may well be that I’m missing something, I do confess.
That said, when Panda is installed from a “deb” installer, it includes an executable version of PStats, if I’m not much mistaken. Could that alone be copied from such an installation, and provided for separate download, with the stated caveat that the user would (presumably) require GTK to be installed on their system for it to run?
If not, might it provide a solution in my case? I’m imagining that I download the new “deb” build that you prompted the BuildBot to make, uninstall my “wheel” version, install the “deb” version, copy PStats to a folder somewhere, then uninstall the “deb” version and go back to using “wheel” versions.
You would also need to copy over the Panda3D libraries that PStats depends on, such as libpanda.so.1.10, etc. These could theoretically conflict with other Panda3D builds. That’s why I suggested the --static flag earlier to producing a standalone PStats build, since that will cause the resulting binary to have no dependencies on other libraries (but be bigger as a result). That means building Panda3D from source, though that is less difficult than it sounds.
It is a fair point that we could probably get away with shipping a PStats binary in the pip wheels even without including GTK, with the added caveat that the user already needs a compatible version of GTK installed. It would be better than not having any version of PStats at all.
I could also see the advantages in packaging a static build of PStats separately.
I saw this thread awhile back and I would be potentially interested in trying to rewrite pstats as a browser/js based interface. Would that still be a useful/viable route, or is it not worth rewriting the entire tool?
That sounds like a great idea, to have a web-stats version of the PStats server that serves up the graphs on a web page. It would also address the issue that we don’t currently have a working macOS version of PStats.
I think @Yonnji has done some work in this direction too, seeing the screenshots in this thread:
A browser-based version sounds like a very good idea, to me: as rdb indicates, such an implementation would (presumably) work across multiple platforms, which I imagine might result in it being a little easier to maintain.
As to building my own copy of PStats, I’m attempting it. I’ve created what appears to be a successful build, but it doesn’t seem to have produced an executable copy of PStats amongst its output. Searching the directory, I do see some “.o” and “.a” files that seem related to PStats.
This is the build command that I’m using:
python makepanda/makepanda.py --nothing --use-pandatool --verbose --static --no-python
Is there anything that I should change there?
I can share the source code, if someone wants to integrate it with panda3d. It’s ugly and depends on cython, so some parts have to be rewritten, but it just works for me.
@Thaumaturge Yes, to build the graphical GTK server you need to also add the --use-gtk2 flag (and ensure you have libgtk2.0-dev package installed first). Note that --no-python is redundant since you already specified --nothing.
@Yonnji I think that might be quite useful at the very least as a reference or starting point for @Brisingr’s implementation (or whoever else wants to work on this project). Thanks!
Ok, here is the webstats module:
webstats.zip (8.4 KB)
Cython and YAML is required: pip install Cython PyYAML
To build it: cmake .
It also has the example: python example.py
Ah, thank you! I’ve rebuilt with “–use-gtk2”, and I now seem to have a PStats server! For the sake of convenience I’ve simply copied it over to my game-dev directory, from where it seems to work perfectly well.
As to “–no-python” being redundant, fair enough–that didn’t occur to me at the time. That said, if it had, I imagine that there would have been enough uncertainty on my part as to what’s covered by “–nothing” that I would likely have included “–no-python” just in case anyway. Ah well, it’s a small redundancy.
The buildbot now builds pstats for manylinux1 wheels. The wheels have been tested on a couple of Arch Linux machines, and appear to work. gtk2 and its dependencies are not shipped as part of the wheel, so you will need to handle that dependency yourself. Lots of Linux apps use gtk2, so you probably have this dependency satisfied already.