Gerrit Voss wrote: > Hi, > > On Wed, 2007-09-26 at 07:23 -0500, Patrick Hartling wrote: >> Gerrit Voss wrote: >>> Hi, >>> >>> On Wed, 2007-09-26 at 06:29 -0500, Patrick Hartling wrote: >>>> Are there plans to make more use of Boost.Function in OpenSG 2? I see where >>>> some parts of the code use it now, but there are other parts >>>> (OSG::SceneFileHandler, for example) that use C function pointers. By >>>> replacing those with boost::function<T>() instantiations, existing >>>> user-level code will still compile, but we will be afforded much greater >>>> flexibility in what sort of callback can be passed in. The main reason that >>>> I ask, however, is that using Boost.Function would help PyOpenSG >>>> tremendously. With some proper finessing in the bindings code, it would be >>>> possible to have Python callables be passed in as callbacks. >>> yes, it's somewhere on my 'still to cleanup' list. >> Would you like help, or do you have specific plans that you want to execute >> yourself? > > I'm still collecting and trying to sort things out ;-). If you need the > switch to boost::function you can go ahead.
I don't have an immediate need, but I will keep that in mind as I get back
into PyOpenSG stuff. My main concern, however, is that I would rather make
such changes on the trunk rather than on the old field container pointer
branch. I may just keep track of places where Boost.Function could be used
and then apply changes to OpenSG and to PyOpenSG once PyOpenSG is brought
back in sync with the trunk.
>>> As we are talking of the python bindings I was recently looking at them,
>>> is the cvs head suppose to build (including the gen_bindings.py part).
>>>
>>> I was just trying against the current 2.x head to see where changes are
>>> needed. But I was running into errors which should have nothing to do
>>> with the ptr switch, like wrong scoping (e.g. classes without OSG::)
>> I compiled the head of the trunk yesterday against the OpenSG 2 "stable"
>> field container pointer branch without problems on Fedora Core 6. I am
>> surprised that there would be scoping problems. I don't know for sure, but
>> that sounds like a bug in Py++ or pygccxml.
>
> hmm, it looked more like gen_bindings.py problems, for example the
> following:
>
> for x in ["StatIntElem", "StatTimeElem", "StatRealElem",
> "StatIntOnceElem"]:
>
> temp = tbuilder.Template("OSG::StatElemDesc<%s>"%x, "StatElemDesc_%s"%
> x)
>
> the %s inside <> is missing OSG::. So while compiling there were
> complains that StatIntElem is not found, which is correct because
> it should be OSG::StatIntElem.
This case is fixed now. Thanks for pointing it out.
-Patrick
--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
