genpycode still broken :-/

[hughperkins]

Still cant run genpycode. Obviously this is a critical blocking issue for using Panda in my application

Here is the results of building etc:

This is the output from doing a complete clean, and then a rebuild, redirecting to out.txt.

Here is the terminal output:

Code: Select all

F:\dev\FSPandaWrappers>dir >out.txt

F:\dev\FSPandaWrappers>dir f:\panda3d-1.0.3\pandac >>out.txt

F:\dev\FSPandaWrappers>gnumake >>out.txt
85 python function wrappers exported.

F:\dev\FSPandaWrappers>genpycode -s -e f:\dev\fspandawrappers -r libfractalsplin
epandawrap >>out.txt

F:\dev\FSPandaWrappers>dir f:\panda3d-1.0.3\pandac >>out.txt


Here is the output from the redirection (out.txt):
[code]
驱动器 F 中的å

[Josh Yelon]

Man, you guys don't ask easy questions.

Unfortunately, the guy who knows what he's doing, David Rose, is out for the weekend. If you package up libfractalspline as a set of diffs to panda, I can try to diagnose it myself. But I can't promise much, this isn't much my area of expertise.

[hughperkins]

Ok great!

The build is actually decoupled from the Panda build itself, for a number of reasons, so no issues with diff etc.

It links with Panda 1.0.3

Rather than risking missing files and so on by doing a full sf file release, I've just zipped the three relevant development directories from my machine:

FSPandaWrappers - the key directory here. Contains the new PandaNode derivatives. Uses FractalSpline
FSDev - FractalSpline. A renderer-independent project that creates parametric meshes
fsbuildtools - contains a setpath.bat batch file script to set appropriate environment variables on Windows

Not sure how much of my build environment you need/want to reproduce really.

FractalSpline is already built: its the libfractalspline.dll and libfractalspline.lib files in the FSDev directory. There's also a bunch of include files there that are needed to link with it.

FSPandaWrappers contains the (built) PandaNode derivatives that use FractalSpline to generate the meshes.

fsbuildtools contains a setpath.bat batch file script to set appropriate environment variables on Windows. Basically if you customize this to your environment (path variables at the top), then it will set up your build environment for you, in theory. It also sets MSVC=1, which is necessary for the makefile to work.

You might also need the osmpdevkit:

http://manageddreams.com/osmpwiki/files ... t-msvc.zip

Note that fractalspline and fractalsplinepandawrappers are only built and tested on Windows right now. It should be buildable on Linux, but the makefile will need a little tweaking.

So, the fractalspline + fractalsplinepandawrappers snapshot is at:

http://manageddreams.com/osmpwiki/files ... 5may21.zip

You probably want fsbuildtools, fsdev, fspandawrappers, and osmpdevkit-msvc to be in the same directory somewhere, then a bit of tweaking to the setpath.bat and it should build just fine.

Instruction to build is, from the fspandawrappers directory:

Code: Select all

..\fsbuildtools\setpathfspanda
gnumake


The genpycode runs manually for now.

There's a reasonable chance that its just the genpycode command that is failing, so it might just be enough to go into fspandwrappers and work out the appropriate genpycode command?

Hugh

[Josh Yelon]

Sorry this took all weekend. Ok, so before I just tell you the answer, let me tell you how I figured this out, in case you have any more problems.

The code for 'genpycode' is in direct/src/ffi. I figured that the best place to start would be to add a whole bunch of print statements to show me what wrappers it is generating, and what wrappers it is choosing *not* to generate.

So I found this routine:

def addTypes(self, CModuleName):
for i in range(interrogate_number_of_global_types()):
typeIndex = interrogate_get_global_type(i)
if self.typeInCModule(typeIndex, CModuleName):
self.constructDescriptor(typeIndex)

So I stuck in a print-statement to print out the type names as it goes. Sure enough, it *does* print out FractalSplineNode. Interesting. Yet it is not generating stubs for it. I notice that the if-statement there can fail silently. So I take a look at "self.typeInCModule":

def typeInCModule(self, typeIndex, CModuleName):
if interrogate_type_has_module_name(typeIndex):
moduleName = 'lib' + interrogate_type_module_name(typeIndex)
print "Module name ("+interrogate_type_name(typeIndex)+") = "+moduleName
return (moduleName == CModuleName)

That print-statement is something that I added myself. This is what it prints out:

Module name (FractalSplineNode) = liblibfractalsplinepandawrap

Notice the extra "lib" in the module name. It thinks that this particular function is supposed to be in a DLL called "liblibfractalsplinepandawrap." It says to itself "since I haven't been asked to instrument that DLL, I'm going to ignore that class."

So the answer is that somewhere, we're appending "lib" that we shouldn't be. I'm guessing on the interrogate_module command line, but I haven't looked too carefully. Just look around for an extra "lib" somewhere.

But... wow, was that a poor failure mode. I think we need to make that a little more self-explanatory. Thank you for catching that for us.

[hughperkins]

Awesome Josh! Thanks very much!

Proof that this works now :

Code: Select all

Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from pandac.PandaModules import *
>>> a = FractalSplineBoxNode("a")
>>> print a
[FractalSplineBoxNode at: 32419128]
none a
>>> a.setTwist(30)
>>>


Awesome!

Hugh

[Josh Yelon]

Libfractalspline is an example of a "model-generator" - a library that produces a 3D model from a small number of input parameters. I think that in the long run, there are going to be a lot of model generation libraries. For example, I have a very nice vegetation and palm-tree generator that I used in "A Tale in the Desert." I also want to write a terrain-patch generator for geomipmapped terrain. I wouldn't be surprised if we end up with dozens of these things.

But of course, any given application will only want a small subset of these. We need to come up with a tidy organizational system for integrating these into panda3d, and to allow people to compile in the ones they want. We might as well start thinking about this now. Let's ask David what he thinks, when he gets back.

[hughperkins]

Yes

Actually, just for the record, the actual Panda codebase is already extremely cool in this respect. This particular library above can be linked into Panda without needing to rebuild Panda. Panda automatically finds and is able to use the new type! This is extremely cool; its easy to conceive of systems where this would not have been possible.

Hugh

[hughperkins]

btw, you were doing dev for ATITD? Wow, respect! That was a very cool game I mean, I only saw the beta, but it was revolutionary in very many ways, and was very cool to play.

Hugh

[drwr]

Great job tracking that down! You're right; it's a terrible failure mode.

David

[Josh Yelon]

Is the new interrogate going to make the problem moot?

- josh

[drwr]

I'm not sure yet, but probably not. To solve it properly, we may need a list of all of the expected module names, so we can raise an error if one is encountered off of that list.

In the more general problem of defining a family of geometry-generating nodes, maybe we can avoid the need to run interrogate on each of these link-in dlls, in the same way that we don't need to run interrogate on libpandagl or libpandadx8, or libptloader, to use them. This works because libpandagl and libpandadx8 both have the same public interface, which has already been interrogated and is part of Panda.

The problem, of course, is that we'd like to be able to define arbitrary parameters for these new link-in modules. Hugh, for instance, has defined a new parameter "setTwist", which is not part of any already-existing public interface.

Perhaps we can design a generic interface for extending Panda nodes that allows us to define arbitrary parameters for them. The set of available interfaces and their parameters could get complicated to describe, though, and it's not clear if it would be a long-term win over just using interrogate to define the new interfaces (and presumably making interrogate easier to use and better at supporting third-party add-ons).

David

[hughperkins]

Just for the record, migrating to swig could bear very serious consideration. Its a de facto standard for Python interfaces, easy to use, well documented, and so on.

The issue with using interrogate for Panda is that it forces all components that extend Panda to themselves use interrogate.

interrogate is an issue because it doesnt directly add value to Panda3D, so there is little or no development budget, but on the other hand interrogate is really a thorn in the side of Panda3D development. At least, it was for me. It doesnt fit in with the whole "it just works" experience.

Short-term, obviously changing to swig is not a decision to be taken lightly.

Long-term, the question may not be if you will migrate to swig, but when, since Swig will continue to advance on its own, without a requirement for any investment on the part of Disney/CMT.

What do you think?

Hugh

[drwr]

I agree completely. However, "short term" is relative; it may still be years before it makes sense to migrate completely from interrogate.

In the middle term, it may make sense to continue to use interrogate for core Panda3D development, while providing an out-of-the-box solution to use swig for new third-party development.

David