Yeah i cant reproduce it myself on a small sample. But it did cost me about 30 min trying to find the infinite loop and now i cant repro it. I want my 30 min back!
Sorry for not being clear, it’s TaskOrig, not TaskNew.
Oh. Well, TaskOrig is being phased out and will be deleted eventually anyway. Do you really need to use TaskOrig instead of TaskNew?
David
The correct question should be “Does everyone ready to switch to TaskNew ?”
Yes. Isn’t everyone? That’s the default with 1.6.0 anyway; you have to go out of your way if you really want TaskOrig. I wasn’t aware of any outstanding issues with TaskNew, or any reason to keep TaskOrig around at all for that matter.
Another way of saying it is, if you’re not ready for TaskNew, you’re not ready for 1.6.0.
David
Nobody said that before, not even in your PM. So in official 1.6.0, “want-new-tasks” would be gone ?
So, there is completely nothing to worry about ?
Umm, any brief overview of the new stuff in TaskNew ?
Thanks.
Right, that was my intention; sorry for the confusion. Whether I actually get around to removing want-new-tasks or not, TaskOrig.py is already deprecated and no longer intended for use. Whether that’s anything to worry about or not is a question for philosophers, however. 
I haven’t yet written up a decent manual page for the new task features, but in a nutshell, you have:
(a) The old task “priority” is renamed to task “sort”, to be consistent with usage and with other similar features in Panda.
(b) There’s a new task “priority” which is more similar to conventional ideas of priority.
© You can have any number of independent task chains, each of which corresponds to a list of tasks to be executed round-robin fashion. taskMgr.setupTaskChain() sets up the properties for a given task chain. One of the main reasons to use other than the default task chain is to run your tasks in a sub-thread; each task chain can be run in its own thread.
(d) Python generators are supported implicitly. A task may yield task.cont instead of returning task.cont, and it will continue the next frame from the same point.
(e) The task manager can be used from C++ now, and the PandaFramework code has been modified to do so.
David
Ok. Thanks again.
I got 1 funny CVS issue here. I can’t login with no password for anonymous.
Sounds like a SourceForge issue. Maybe their anonymous CVS servers are down at the moment.
David
Login with ‘pserver’ instead of ‘ext’.
It’s always been pserver. It’s already accessible this midnite.
I confirm that all 2 (not 3) problems are history. GRRRREAT ! 
I’ve never had any problem with vertex color.
But, I noticed something else :
[1] David, when you added PyErr_Warn in pystub.cxx, did you intentionally leave PyErr_WarnEx ?
Its absence caused this :
[2] some renamed types in libpanda.dict :
‘RGBColorf’: <type ‘libpanda.VBase3’>
‘RGBColord’: <type ‘libpanda.VBase3D’>
‘Colord’: <type ‘libpanda.VBase4D’>
‘Colorf’: <type ‘libpanda.VBase4’>
‘Normald’: <type ‘libpanda.Vec3D’>
‘Normalf’: <type ‘libpanda.Vec3’>
‘TexCoordf’: <type ‘libpanda.Point2’>
‘TexCoordd’: <type ‘libpanda.Point2D’>
‘Vertexd’: <type ‘libpanda.Point3D’>
‘Vertexf’: <type ‘libpanda.Point3’>
The original one like VBase4 is no longer exist in libpanda, and renamed to Vertexf.
That sounds like intentional transition, but without preserving what used to be there ?
Meanwhile, I added these to PandaModules.py, or showbase wouldn’t start :
VBase4 = Colorf
VBase4D = Colord
Vec3 = Normalf
Vec3D = Normald
VBase3 = RGBColorf
VBase3D = RGBColord
Point2 = TexCoordf
Point2D = TexCoordd
Point3 = Vertexf
Point3D = Vertexd[1] No, this was an accidental omission, caused by a difference in Python versions (we still do our work in Python 2.4 here, which doesn’t have PyErr_WarnEx). I guess in Python 2.5, they implemented PyErr_Warn as a macro to call PyErr_WarnEx. I just added the new symbol which should solve the Python 2.5 issue.
[2] Huh? Not sure exactly what you’re describing, but there was no intentional change here in the renaming of these classes. Sounds like something went foobar in there for you. It still seems to be working for me, though, so I’m a little mystified. I’m picking up the latest now and rebuilding just to be sure.
David
I found 1 more thing :
from pandac.PandaModules import *
n=NodePath('')
c=CardMaker('')
a=n.attachNewNode(c.generate())
a.setPos(5,0,5)
b=n.attachNewNode(c.generate())
b.setPos(1,0,1)
# <type 'libpanda.Point3'>
print type(a.getBounds().getCenter())
# Vec3(-1, 0, -1)
print a.getBounds().getCenter() - b.getBounds().getCenter()
# Vec3(0, 0, 0)
print a.getBounds().getCenter() - b.getBounds().getCenter()
# Vec3(4, 0, 4) <-- correct
print Point3(a.getBounds().getCenter()) - b.getBounds().getCenter()Is there any good reason why doesn’t get_center() return new LPoint3f, as get_min() and get_max() ?
Hmm, get_center() is returning an LPoint3f a.k.a. Point3, but I think the minus operator is getting it wrong because it is a const LPoint3f. I’ll investigate.
David
OMG, finally I think I know what went wrong.
Somehow, during CVS update, some .N files extension got changed to lower case !!
Same thing happened for .I and .T files, but I just missed renaming .N files, since no error is thrown if it’s not found.
I realized this when I got Camera.getDisplayRegion is not published, even in the _igate file.
Ah, curse those darn .N files. That explains the renaming problem. The minus operator is something different, though, since I see the same problem.
David
OK, the subtraction problem was a good one. I’ve checked in a fix.
David
I can’t seem to run the Shadows sample. It gives me a segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f006055c6e0 (LWP 9722)]
GLShaderContext::update_shader_texture_bindings (this=0x7f0045380be8,
prev=<value optimized out>, gsg=0x300b8c8) at ../pgraph/textureAttrib.I:249
249 if (_sort_seq != TextureStage::get_sort_seq()) {
Current language: auto; currently c++
(gdb) bt
#0 GLShaderContext::update_shader_texture_bindings (this=0x7f0045380be8,
prev=<value optimized out>, gsg=0x300b8c8) at ../pgraph/textureAttrib.I:249
#1 0x00007f004a5c185e in GLGraphicsStateGuardian::do_issue_texture (
this=0x300b8c8) at ../glstuff/glGraphicsStateGuardian_src.cxx:6425
#2 0x00007f004a5c7e73 in GLGraphicsStateGuardian::set_state_and_transform (
this=0x300b8c8, target=<value optimized out>,
transform=<value optimized out>)
at ../glstuff/glGraphicsStateGuardian_src.cxx:6253
#3 0x00007f005b24adda in CullBinStateSorted::draw (this=0x39242f8,
force=<value optimized out>, current_thread=0x287c4c8)
at ../pgraph/cullHandler.I:29
#4 0x00007f005c78e806 in CullResult::draw (this=0x365e818,
current_thread=0x287c4c8) at cullResult.cxx:277
#5 0x00007f005aae3721 in GraphicsEngine::do_draw (this=<value optimized out>,
cull_result=0x365e818, scene_setup=0x365e718, win=0x300a6e8, dr=0x3251338,
current_thread=0x287c4c8) at graphicsEngine.cxx:1827
...Any ideas what could be wrong?
It looks like check_sorted() gets called on a NULL pointer to TextureAttrib or so.
Oops, my bad, just checked in a fix.
David