Hey all,
Since a few weeks I’m using buildbot internally for my builds, and I figured I’d let it build nightly snapshots so that everyone can benefit from it. So, I moved it over to panda3d.org:
It’s scheduled to build every 24 hours from CVS. Not only does this save you guys from the effort of building it from CVS, it also allows us to catch bugs early.
Right now it only provides Windows and OSX builds, but that will change soon.
For the record, the latest development build also contains PandAI and enn0x’ PhysX support.
You can import those modules by importing from “panda3d.ai” and “panda3d.physx”.
Ooh, nice. I was thinking recently how handy it would be if Panda3d had some nightly build repository.
Thanks for this!
Update: I’ve updated the buildbot to also generate snapshots of the manual, both zip and chm:
panda3d.org/buildbot/
The manual doesn’t change as often as the source, so I’ve set it to build weekly. I can force builds on request though.
This rocks!
David
This is indeed GREAT.
I would dare ask for something though: would it be too much to set the builds for the files with the manuals to start with “Panda3d-” as well?
Er, I could do that, but is there any particular reason to do so?
I did it like this because of conventions, we have always shipped the manual as manual-x.x.x.zip.
Furthermore, if I call it panda3d-x.x.x.zip/chm, if I add the API reference later, they would have the same name.
Great work!
Report from OS X 10.6.2:
Installation was fine (i checked /Developer/… and all seemed good)
Samples are not included with the installer (not sure if you’ve planned to include the Samples into the daily snapshots)
Unfortunately basic usage fails
$ ppython
Python 2.5.4 (r254:67916, Jul 7 2009, 23:51:24)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import direct.directbase.DirectStart
DirectStart: Starting the game.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Developer/Panda3D/lib/direct/directbase/DirectStart.py", line 3, in <module>
from direct.showbase import ShowBase
File "/Developer/Panda3D/lib/direct/showbase/ShowBase.py", line 10, in <module>
from pandac.PandaModules import *
File "/Developer/Panda3D/lib/pandac/PandaModules.py", line 2, in <module>
from libpandaexpressModules import *
File "/Developer/Panda3D/lib/pandac/libpandaexpressModules.py", line 1, in <module>
from extension_native_helpers import *
File "/Developer/Panda3D/lib/pandac/extension_native_helpers.py", line 81, in <module>
Dtool_PreloadDLL("libpandaexpress")
File "/Developer/Panda3D/lib/pandac/extension_native_helpers.py", line 79, in Dtool_PreloadDLL
imp.load_dynamic(module, pathname)
ImportError: dlopen(/Developer/Panda3D/lib/libpandaexpress.dylib, 2): Library not loaded: libp3dtool.1.7.0.dylib
Referenced from: /Developer/Panda3D/lib/libpandaexpress.dylib
Reason: image not found
>>> Hm. Can you do a few tests for me?
from panda3d.core import FilenameDoes it work? If not, what error message does it print?
I indeed didn’t include the samples yet. I’ll do so soon, when I finish fixing the sample programs for 1.7.0.
Shouldn’t it be Python 2.6 instead of Python 2.5? Is ppython still part of the build process?
David
Sure, here we go:
$ ppython
Python 2.5.4 (r254:67916, Jul 7 2009, 23:51:24)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from panda3d.core import Filename
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Developer/Panda3D/lib/panda3d.py", line 190, in __getattr__
mod = self.__manager__.libimport(lib)
File "/Developer/Panda3D/lib/panda3d.py", line 126, in libimport
return cls.imp.load_dynamic(name, target)
ImportError: dlopen(/Developer/Panda3D/lib/libpandaexpress.dylib, 2): Library not loaded: libp3dtool.1.7.0.dylib
Referenced from: /Developer/Panda3D/lib/libpandaexpress.dylib
Reason: image not found
>>> $ ls -al /Developer/Panda3D/lib/libp3dtool.1.7.0.dylib
-rwxrwxr-x 1 root admin 499456 5 Jan 11:16 /Developer/Panda3D/lib/libp3dtool.1.7.0.dylibYes.
Yes.
Hm… DYLD_LIBRARY_PATH was indeed empty. I added /Developer/Panda3D/lib to DYLD_LIBRARY_PATH in my ~/.bash_profile manually and now it works:
$ ppython
Python 2.5.4 (r254:67916, Jul 7 2009, 23:51:24)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import direct.directbase.DirectStart
DirectStart: Starting the game.
Known pipe types:
osxGraphicsPipe
(all display modules loaded.)
Tue Jan 5 19:51:01 franz.local ppython[1882] <Error>: kCGErrorIllegalArgument: CGSCopyRegion : Null pointer
Tue Jan 5 19:51:01 franz.local ppython[1882] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
>>> run()
Tue Jan 5 19:51:13 franz.local ppython[1882] <Error>: kCGErrorIllegalArgument: _CGSFindSharedWindow: WID 277
Tue Jan 5 19:51:13 franz.local ppython[1882] <Error>: kCGErrorIllegalArgument: CGSRemoveSurface: Invalid window 0x115Despite the errors the window opens and can be closed. It seems that DYLD_LIBRARY_PATH is not picked up from ~/.MacOSX/environment.plist - I assume that’s the intention behind the environment.plist
Hope that helps, let me know if I can be of any more help. Thanks for the help, I’ll dig deeper in the next few days and see how the current pre-release versions behave.
Snow Leopard Python 2.6 is 64-bit and doesn’t work together with the these versions:
$ python
Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import direct.directbase.DirectStart
DirectStart: Starting the game.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Developer/Panda3D/lib/direct/directbase/DirectStart.py", line 3, in <module>
from direct.showbase import ShowBase
File "/Developer/Panda3D/lib/direct/showbase/ShowBase.py", line 10, in <module>
from pandac.PandaModules import *
File "/Developer/Panda3D/lib/pandac/PandaModules.py", line 2, in <module>
from libpandaexpressModules import *
File "/Developer/Panda3D/lib/pandac/libpandaexpressModules.py", line 1, in <module>
from extension_native_helpers import *
File "/Developer/Panda3D/lib/pandac/extension_native_helpers.py", line 81, in <module>
Dtool_PreloadDLL("libpandaexpress")
File "/Developer/Panda3D/lib/pandac/extension_native_helpers.py", line 79, in Dtool_PreloadDLL
imp.load_dynamic(module, pathname)
ImportError: /Developer/Panda3D/lib/libpandaexpress.dylib: no appropriate 64-bit architecture (see "man python" for running in 32-bit mode)
>>> PS: It’s possible to set python to 32-bit but that’s not default - from “man python”:
Versions 2.6 and 3.0 support 64-bit execution (which is on by default).
Version 2.5 only supports 32-bit execution.
Like the version of Python, the python command can select between 32 and
64-bit execution (when both are available). Use:
% defaults write com.apple.versioner.python Prefer-32-Bit -bool yes
to make 32-bit execution the user default (using
`/Library/Preferences/com.apple.versioner.python' will set the system-
wide default). The environment variable VERSIONER_PYTHON_PREFER_32_BIT
can also be used (has precedence over the preference file):
% export VERSIONER_PYTHON_PREFER_32_BIT=yes # Bourne-like shells
or
% setenv VERSIONER_PYTHON_PREFER_32_BIT yes # C-like shells
Again, the preference setting and environmental variable applies to both
python and pythonw.Ah, right. In Snow Leopard, you have to run python 2.6 in 32-bit mode, because Panda is (at the moment) compiled only in 32-bit mode.
You can do this on a one-time basis with “arch -i386 python”, or you can tell the system to launch Python that way by default with “defaults write com.apple.versioner.python Prefer-32-Bit -bool yes”.
David
Nope, the Mac build is still compiled against Leopard’s default copy of Python, 2.5. We might ship our own version of Python later, but this will become easier when we switch to using a Panda3D framework (when we can ditch the whole path mess).
“ppython” still exists, it is a symlink to /usr/bin/python2.5, a handy shortcut to get the right version of Python right away.
kaweh: can you post the contents of environment.plist? There’s something that really confuses me here. It apparently does locate the Python modules, these are in PYTHONPATH, also set by environment.plist. But it ignores DYLD_LIBRARY_PATH?
Is there perhaps anything (in your .bash_profile or so) that overrides the DYLD_LIBRARY_PATH setting from the environment.plist? When you open a terminal and echo $PYTHONPATH, does that work correctly?
In this case, I can probably workaround the issue by using install_name_tool to write absolute library links. We can fix it for real when we use a Panda3D framework.
Note that Snow Leopard provides python 2.6 by default.
David
Yeah, but it also provides Python 2.5, which is why I still compiled it against Python 2.5. I’m fine with upgrading to 2.6, if you want, but that would mean we would need to ship our own copy of Python for the Leopard users.
Perhaps we should make ppython into a script that sets the ARCHPREFERENCE environment variable before launching python2.5, so that it will prefer 32-bit.
Edit: actually, it looks like python2.5 doesn’t include 64-bit binaries anyway, so that shouldn’t be an issue. Hmm.
David
This is awesome and much appreciated. Thanks for your efforts.
Alex
Ah! I tried googling for the issue and lots of stuff came up. It appears that some security update in OSX made it impossible to set DYLD_LIBRARY_PATH in environment.plist.
I’m going to use install_name_tool and ditch the DYLD_LIBRARY_PATH setting.
kaweh, could you check if this problem is also for the PATH variable? e.g. can you run “pview” correctly?
After that, can you then try the new daily build?