Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi JS, On Thu, Feb 5, 2009 at 7:38 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Oh come on. Aren't you pushing this a bit too far? We're not playing anyone's game, just using a tool that allows us to compile code on a given platform. This platform choice (which is only one option, we support Linux too, but cannot go away from Windows completely) is dictated by our clients and past history. That's what's locking us into using that tool, not the tool itself. I'm not suggesting dropping windows support, I'm just saying that you keep all the platform specific hacks as far away from general code as possible. You keep is as localised as possible, this is the key to cross platform development - it's why the OSG is so portable. Adding obscure platform specific hacks to all header files is totally wrong for this project, and make it less maintainable. It would be a backwards step that I won't merge. Even if I were working on personal projects only, I would still advocate for OSG to support VS in the best way possible. It's too big a market and a user base to push to the wayside and have half-baked support for. Not supporting the MS pet way of doing things isn't providing poor windows support. The OSG supports VS just fine. Using CMake you can disable the Export pragma's, you have complete control. If you want to then isolate the warnings from OSG headers yourself then again you have complete control to do so. Rather than stuff macro's or extra includes why not in your own application just have your own macro such as: #define INCLUDE(header) / #pragma (warning(push)) / #pragma (warning(disable : a b c d)) / #includeheader / #pragma (warning(pop)) Then in your own code you just have: INCLUDE(osg/Node) Like the ScopedLock trick we use for Mutex management - it's an design pattern that ensures robust resource management and far more maintainable than need to enclose everything carefully with lines that are only relevant to a single platform. But then even OSG's headers will generate warnings. A library should not generate warnings, but should not obscure the warnings in your own code. Period. Do you at least agree with that? I really stove for the ideal of the OSG header not generating any warnings so not requiring the pragma's, I wrote just this as my goal, but we've falling short, and through lack of effort. The reality is that modern compilers at high warning levels produce lots of false positives on perfectly correct code. As Matthew said, this could be replaced by macros in a single header, or something else. As I said, I was trying to suggest something, anything, in the hope we could go forward in some way. Just arguing back and forth doesn't help anything, so I think I'll stop replying about this subject if we don't go forward at least a bit. Mathew's suggest is marginally better, but still a horrible hack. What happens if I forget to add #endif to the end of a header to close the include guards? That's not standard C++ either, just common practice, and no one really fights that. The #ifdef #endif around headers is a back that we all have to employ across all platforms. If someone missing it out we have a good chance of catching it on the any platform. It's a pain but it is at least maintainable without too much effort or likely-hood of introducing mistakes. Contracts this we push/pop macro/include errors - the code would still compile even under VisualStudio, no one would know about a problem until someone starting looking for errors that were being accidentally suppressed. If you code typically doesn't generate warnings, and continues not to generate warnings you'll happily assume everything is dandy... but it's not, it's broken, but... where o lots of headers to go through. Well, since you don't even see the VS warnings, and don't see errors related to OSG_EXPORT, and don't see... I don't understand how that's worse. Someone (probably me, lucky as I am) will compile on Windows, see the error, track it to the missing end marker (whatever that may be) and submit the fix, the same as a missing OSG_EXPORT. For the number of times a new header is added to OSG, I think it's really minor. The OSG_EXPORT issues is a pain, but at least if they are missing someone eventually picks up the error and the error report you get pinpoints the problem precisely. The push/pop is a very different beast - its an untraceable and largely un-noticable error. The OSG_EXPORT also provides a function to the binaries, doesn't add any extra lines of code to the headers and is well understood by most developers. So it's more functional, and less intrusive and more maintainable than the proposed push/pop macro/headers. This certainly won't make help code portability and maintainability. Let's just suppress all warnings in osg/Export then, and see if users like that. (I'm only partly joking) Anyways, the basic premise I'm maintaining is
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, Sigh. I have worked my bollocks off trying to reduce the number of suppressed warnings in include/osg/Export. We have got as far as we are going to get without holding back the release for many more weeks, and without modifying many hundreds of files, needless changes too, then won't actually fix any bugs, it just compilers over zealous warnings we are suppressing via code changes to code that is typically perfectly correct in the first place. One thing I never suggested (even remotely) is holding back the 2.8 release because of warnings. Worst case, we could go back to the situation as it was before, OSG_USE_AGGRESSIVE_WARNINGS to off by default on Windows and no one notices. There's no reason to spend the major part of your work hours on OSG trying to fix Windows warnings, when it can be done gradually over a couple weeks after the release, so as to not get fed up with it as you seem to be now. Out of curiosity, I just diffed osg/Export between revision 9235 (Nov. 24, 2008, before the warnings blitz) and the trunk to see what had been removed. There were 8 disables before, now there are 4. So I guess it's progress, at least. If nothing else comes up, it's a good middle ground. I was just trying to see if we could satisfy the users who have come by the list in the past, saying why does OSG disable warnings in my own code?. It's happened a few times IIRC. So my hope was to be able to get 0 warning disables in osg/Export, not 50% of what we had... But it doesn't seem possible. Me, I don't care, other than having an ideological stance that doesn't help anyone. What is far far more important is testing and fixing real bugs. Fixing real bugs benefits everybody. Well said. I'll get back to work now. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
I am not sure if it's related or not but i tried to compile the trunk this morning and here the warning i get. [ 8%] Building CXX object src/osg/CMakeFiles/osg.dir/OcclusionQueryNode.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/i686-pc-linux-gnu/bits/c++locale.h: In function ‘int std::__convert_from_v(char*, int, const char*, _Tv, __locale_struct* const, int) [with _Tv = double]’: /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/locale_facets.tcc:1074: instantiated from ‘_OutIter std::num_put_CharT, _OutIter::_M_insert_float(_OutIter, std::ios_base, _CharT, char, _ValueT) const [with _ValueT = double, _CharT = char, _OutIter = std::ostreambuf_iteratorchar, std::char_traitschar ]’ /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/locale_facets.tcc:1234: instantiated from ‘_OutIter std::num_put_CharT, _OutIter::do_put(_OutIter, std::ios_base, _CharT, double) const [with _CharT = char, _OutIter = std::ostreambuf_iteratorchar, std::char_traitschar ]’ /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/locale_facets.h:2350: instantiated from ‘_OutIter std::num_put_CharT, _OutIter::put(_OutIter, std::ios_base, _CharT, double) const [with _CharT = char, _OutIter = std::ostreambuf_iteratorchar, std::char_traitschar ]’ /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/ostream.tcc:370: instantiated from ‘std::basic_ostream_CharT, _Traits std::basic_ostream_CharT, _Traits::operator(double) [with _CharT = char, _Traits = std::char_traitschar]’ /home/mornifle/dev/osg-trunk/src/osg/OcclusionQueryNode.cpp:269: instantiated from here /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/i686-pc-linux-gnu/bits/c++locale.h:86: warning: format not a string literal, argument types not checked /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/i686-pc-linux-gnu/bits/c++locale.h:86: warning: format not a string literal, argument types not checked Cheers, Cedric Robert Osfield wrote: Hi JS, Thanks for the warning fixes, I've merged about 2/3rds of them, but will record some of the other ones. The server isn't accessible right now so I'm not able to check in right now. I'll have bash tomorrow morning. These last warning fixes won't affect runtime at all so the 2.8.0-rc1 as it stands right now should be good enough for testing. Robert. On Wed, Feb 4, 2009 at 5:44 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Robert, As I said on my other post, I don't seem to get any warnings (other than can't open build log for writing, which is weird but benign - the warnings if any would still go to stdout and thus get reported in the CDash warnings page for the build). I'll try another full rebuild and see for sure. Then if I get any I'll see what needs to be done. OK, I've had a go at fixing the warnings. I've attached a zip containing the build output before the fixes for you to see, as well as the changed files. The PDB warnings (which come from the fact that a given 3rd party library was compiled with debug information split into a separate file instead of embedded into the library) we can just ignore. They only happen at link time for the given plugin. Same thing for the default library MSVCRT conflicts... warning, though that might indicate a bigger problem. The next time someone makes a 3rd party package, those things should be taken care of. Other than that, here are the warnings I fixed: ___ osgUtil.lib and osglauncher example 4C:\Tools\msvs8\VC\include\list(42) : warning C4510: 'std::_List_nod_Ty,_Alloc::_Node' : default constructor could not be generated (and other similar and related warnings) Simply adding an empty default constructor to the arc class in TriStrip_graph_array.h and the Xample class in osglauncher.cpp fixed this You could see that std::list was not the problem, but the class used as a template argument, because lower in the warning message there was mention of 4 c:\dev\openscenegraph-svn\openscenegraph-2.8-branch\src\osgutil\TriStrip_graph_array.h(109) : see reference to class template instantiation 'std::list_Ty' being compiled 4with 4[ 4 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 4] which pointed to the type to which a default constructor needed to be added. It comes down to deciphering VS's messages... :-) ___ osga plugin 198..\..\..\..\src\osgPlugins\osga\OSGA_Archive.cpp(727) : warning C4512: 'OSGA_Archive::WriteObjectFunctor' : assignment operator could not be generated 198..\..\..\..\src\osgPlugins\osga\OSGA_Archive.cpp(719) : see declaration of 'OSGA_Archive::WriteObjectFunctor' (and so on for the other Write*Functors) I didn't find any way to fix this other than locally suppressing it, since creating a default constructor would imply constructing a default osg::Object, which is abstract so I can't do that. So I suppressed it around
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, I use the gcc 4.1.2 i guess it's bogus on this version, i will try to update. Thank you Cheers, Cedric Robert Osfield wrote: HI Cendric, The line that is trigger this warning is essentially of the form: float myValue ostream this is very silly, can't even write out a float these days myValuestd::endl; This is of course perfectly valid C++, this screams out a bug in the standard library, or the compiler, and not in the OSG. The only thing we can do is disable this particular warning as it's clearly bogus. Note, not all versions of gcc has this bug, for instance I'm using 4.3.2 and don't get these errors. I'm just testing the removal of the --format==2 entry from the aggressive warnings. I'll check this in once I've got a complete build of the 2.8 branch. Robert. On Thu, Feb 5, 2009 at 9:41 AM, Cedric Pinson morni...@plopbyte.net wrote: I am not sure if it's related or not but i tried to compile the trunk this morning and here the warning i get. [ 8%] Building CXX object src/osg/CMakeFiles/osg.dir/OcclusionQueryNode.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/i686-pc-linux-gnu/bits/c++locale.h: In function 'int std::__convert_from_v(char*, int, const char*, _Tv, __locale_struct* const, int) [with _Tv = double]': /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/locale_facets.tcc:1074: instantiated from '_OutIter std::num_put_CharT, _OutIter::_M_insert_float(_OutIter, std::ios_base, _CharT, char, _ValueT) const [with _ValueT = double, _CharT = char, _OutIter = std::ostreambuf_iteratorchar, std::char_traitschar ]' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/locale_facets.tcc:1234: instantiated from '_OutIter std::num_put_CharT, _OutIter::do_put(_OutIter, std::ios_base, _CharT, double) const [with _CharT = char, _OutIter = std::ostreambuf_iteratorchar, std::char_traitschar ]' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/locale_facets.h:2350: instantiated from '_OutIter std::num_put_CharT, _OutIter::put(_OutIter, std::ios_base, _CharT, double) const [with _CharT = char, _OutIter = std::ostreambuf_iteratorchar, std::char_traitschar ]' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/ostream.tcc:370: instantiated from 'std::basic_ostream_CharT, _Traits std::basic_ostream_CharT, _Traits::operator(double) [with _CharT = char, _Traits = std::char_traitschar]' /home/mornifle/dev/osg-trunk/src/osg/OcclusionQueryNode.cpp:269: instantiated from here /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/i686-pc-linux-gnu/bits/c++locale.h:86: warning: format not a string literal, argument types not checked /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/i686-pc-linux-gnu/bits/c++locale.h:86: warning: format not a string literal, argument types not checked Cheers, Cedric Robert Osfield wrote: Hi JS, Thanks for the warning fixes, I've merged about 2/3rds of them, but will record some of the other ones. The server isn't accessible right now so I'm not able to check in right now. I'll have bash tomorrow morning. These last warning fixes won't affect runtime at all so the 2.8.0-rc1 as it stands right now should be good enough for testing. Robert. On Wed, Feb 4, 2009 at 5:44 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Robert, As I said on my other post, I don't seem to get any warnings (other than can't open build log for writing, which is weird but benign - the warnings if any would still go to stdout and thus get reported in the CDash warnings page for the build). I'll try another full rebuild and see for sure. Then if I get any I'll see what needs to be done. OK, I've had a go at fixing the warnings. I've attached a zip containing the build output before the fixes for you to see, as well as the changed files. The PDB warnings (which come from the fact that a given 3rd party library was compiled with debug information split into a separate file instead of embedded into the library) we can just ignore. They only happen at link time for the given plugin. Same thing for the default library MSVCRT conflicts... warning, though that might indicate a bigger problem. The next time someone makes a 3rd party package, those things should be taken care of. Other than that, here are the warnings I fixed: ___ osgUtil.lib and osglauncher example 4C:\Tools\msvs8\VC\include\list(42) : warning C4510: 'std::_List_nod_Ty,_Alloc::_Node' : default constructor could not be generated (and other similar and related warnings) Simply adding an empty default constructor to the arc class in TriStrip_graph_array.h and the Xample class in osglauncher.cpp fixed this You could see that std::list was not the problem, but the class used as a template argument, because lower in the warning message there was mention of 4 c:\dev\openscenegraph-svn\openscenegraph-2.8-branch\src\osgutil\TriStrip_graph_array.h(109) : see reference to class template instantiation
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
HI Cendric, The line that is trigger this warning is essentially of the form: float myValue ostream this is very silly, can't even write out a float these days myValuestd::endl; This is of course perfectly valid C++, this screams out a bug in the standard library, or the compiler, and not in the OSG. The only thing we can do is disable this particular warning as it's clearly bogus. Note, not all versions of gcc has this bug, for instance I'm using 4.3.2 and don't get these errors. I'm just testing the removal of the --format==2 entry from the aggressive warnings. I'll check this in once I've got a complete build of the 2.8 branch. Robert. On Thu, Feb 5, 2009 at 9:41 AM, Cedric Pinson morni...@plopbyte.net wrote: I am not sure if it's related or not but i tried to compile the trunk this morning and here the warning i get. [ 8%] Building CXX object src/osg/CMakeFiles/osg.dir/OcclusionQueryNode.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/i686-pc-linux-gnu/bits/c++locale.h: In function 'int std::__convert_from_v(char*, int, const char*, _Tv, __locale_struct* const, int) [with _Tv = double]': /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/locale_facets.tcc:1074: instantiated from '_OutIter std::num_put_CharT, _OutIter::_M_insert_float(_OutIter, std::ios_base, _CharT, char, _ValueT) const [with _ValueT = double, _CharT = char, _OutIter = std::ostreambuf_iteratorchar, std::char_traitschar ]' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/locale_facets.tcc:1234: instantiated from '_OutIter std::num_put_CharT, _OutIter::do_put(_OutIter, std::ios_base, _CharT, double) const [with _CharT = char, _OutIter = std::ostreambuf_iteratorchar, std::char_traitschar ]' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/locale_facets.h:2350: instantiated from '_OutIter std::num_put_CharT, _OutIter::put(_OutIter, std::ios_base, _CharT, double) const [with _CharT = char, _OutIter = std::ostreambuf_iteratorchar, std::char_traitschar ]' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/ostream.tcc:370: instantiated from 'std::basic_ostream_CharT, _Traits std::basic_ostream_CharT, _Traits::operator(double) [with _CharT = char, _Traits = std::char_traitschar]' /home/mornifle/dev/osg-trunk/src/osg/OcclusionQueryNode.cpp:269: instantiated from here /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/i686-pc-linux-gnu/bits/c++locale.h:86: warning: format not a string literal, argument types not checked /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/i686-pc-linux-gnu/bits/c++locale.h:86: warning: format not a string literal, argument types not checked Cheers, Cedric Robert Osfield wrote: Hi JS, Thanks for the warning fixes, I've merged about 2/3rds of them, but will record some of the other ones. The server isn't accessible right now so I'm not able to check in right now. I'll have bash tomorrow morning. These last warning fixes won't affect runtime at all so the 2.8.0-rc1 as it stands right now should be good enough for testing. Robert. On Wed, Feb 4, 2009 at 5:44 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Robert, As I said on my other post, I don't seem to get any warnings (other than can't open build log for writing, which is weird but benign - the warnings if any would still go to stdout and thus get reported in the CDash warnings page for the build). I'll try another full rebuild and see for sure. Then if I get any I'll see what needs to be done. OK, I've had a go at fixing the warnings. I've attached a zip containing the build output before the fixes for you to see, as well as the changed files. The PDB warnings (which come from the fact that a given 3rd party library was compiled with debug information split into a separate file instead of embedded into the library) we can just ignore. They only happen at link time for the given plugin. Same thing for the default library MSVCRT conflicts... warning, though that might indicate a bigger problem. The next time someone makes a 3rd party package, those things should be taken care of. Other than that, here are the warnings I fixed: ___ osgUtil.lib and osglauncher example 4C:\Tools\msvs8\VC\include\list(42) : warning C4510: 'std::_List_nod_Ty,_Alloc::_Node' : default constructor could not be generated (and other similar and related warnings) Simply adding an empty default constructor to the arc class in TriStrip_graph_array.h and the Xample class in osglauncher.cpp fixed this You could see that std::list was not the problem, but the class used as a template argument, because lower in the warning message there was mention of 4 c:\dev\openscenegraph-svn\openscenegraph-2.8-branch\src\osgutil\TriStrip_graph_array.h(109) : see reference to class template instantiation 'std::list_Ty' being compiled 4with 4[ 4
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, Thanks for the warning fixes, I've merged about 2/3rds of them, but will record some of the other ones. The server isn't accessible right now so I'm not able to check in right now. I'll have bash tomorrow morning. The server is back up and I've been able to do an update. All warnings fixes I sent are in except the one in src/osgPlugins/osga/OSGA_Archive.cpp. Is there a reason or it just got forgotten in the batch? Also, I would have preferred if you had kept my push/pop in QOSGWidget.cpp, since users might want the given warning to be enabled in their own code and this shows how to suppress it for Qt's headers but not for their code. And the same pattern should be used for osgviewerGLUT.cpp too. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi JS, On Thu, Feb 5, 2009 at 4:23 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: The server is back up and I've been able to do an update. All warnings fixes I sent are in except the one in src/osgPlugins/osga/OSGA_Archive.cpp. Is there a reason or it just got forgotten in the batch? I moved the suppression of OSGA_Archive.cpp warning into include/osg/Export as others were reporting lots of warnings of this type elsewhere in the OSG. Also, I would have preferred if you had kept my push/pop in QOSGWidget.cpp, since users might want the given warning to be enabled in their own code and this shows how to suppress it for Qt's headers but not for their code. And the same pattern should be used for osgviewerGLUT.cpp too. For specific headers I think push/pop is barely tolerable, but for a .cpp I think it's a real waste of lines of code. Were are talking about suppressing a warning in an example, and warning that is pretty bogus w.r.t helping us detect and fix bugs. Our examples shouldn't be about how to work around idiosyncracies of VS, there should be about how to write applications with the OSG, so the less extra crude the better. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, For specific headers I think push/pop is barely tolerable, but for a .cpp I think it's a real waste of lines of code. Were are talking about suppressing a warning in an example, and warning that is pretty bogus w.r.t helping us detect and fix bugs. That's your opinion but you shouldn't be making judgement calls like that for other people's projects, which is why I think putting suppression in include/osg/Export is a bad practice. But I know I won't make you change your opinion on this. I just think if OSG wants to be a truly cross-platform library it needs to do things the right way on all platforms. On VS, using push/pop is the way to go so you don't cause warnings to be suppressed in user code (which is the other project's call to make). Our examples shouldn't be about how to work around idiosyncracies of VS, there should be about how to write applications with the OSG, so the less extra crude the better. On that I agree. But doing things the right way (whatever the platform/compiler may be) doesn't count as crud IMHO. Anyways, as you said it's an example, so someone who wants to base their code on that example can do it however they want. Anyways, we've been around these opinions before, so we can just change the subject. I just saw the changes being merged differently and was curious. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi JS, On Thu, Feb 5, 2009 at 4:41 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: That's your opinion but you shouldn't be making judgement calls like that for other people's projects, which is why I think putting suppression in include/osg/Export is a bad practice. But I know I won't make you change your opinion on this. I have *really* *really* hard to get the pragma's out of the include/osg/Export. I've have poured several weeks of my life trying to do so. I have only added suppression back into the Export because the remaining warnings were just detracting form the real job in hand - fixing the code rather adding workarounds. I just think if OSG wants to be a truly cross-platform library it needs to do things the right way on all platforms. On VS, using push/pop is the way to go so you don't cause warnings to be suppressed in user code (which is the other project's call to make). push/pop adds a lot of extra syntax to headers for just one single platform, it's not cross platform in any whatso ever. Polluting our headers and .cpp's with lots of pragma's for just one platform because it's warnings are misleading and impractical/impossible to fix is not good practice. One should only do hacks like this when you absolutely have to. Don't forgot fixing warnings are double edge sword. Right now I've investigating a new bug that has occurred because of the warnings work. I hate taking step backs on code quality and this one is exactly because of an attempt at fixing bugs. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, push/pop adds a lot of extra syntax to headers for just one single platform, it's not cross platform in any whatso ever. I see things from the opposite perspective: if OSG wants to be used multi-platform, it has to work well on each platform, the way that platform works. Otherwise, just make VS unsupported and make everyone build through cygwin if they want to build on Windows... That way gcc is always used and you don't have to worry about how VS does things. If you want a native Windows build, people need to use VS. If OSG has to be compiled through VS, it needs to conform to how VS does things (and any other compiler, I'm not putting VS in a special bunch here just putting it on the same footing as gcc). Polluting our headers and .cpp's with lots of pragma's for just one platform because it's warnings are misleading and impractical/impossible to fix is not good practice. One should only do hacks like this when you absolutely have to. The problem is that *in OSG* and *in your opinion*, these warnings add nothing. But if they exist at all, it must be because they add something sometimes. Hence my assertion that OSG should not make decisions as to what warnings to suppress for user code. OK, back to trying to find solutions as opposed to opinionated discussions that don't lead anywhere (I'm talking about me, not you :-) ) What we could do is kind of like what (I think) SDL does. Instead of having each header start with #include osg/Export // rest of header it could be something like this: #include osg/HeaderStart // rest of header #include osg/HeaderEnd Where: HeaderStart: #if defined(_MSC_VER) %% defined(OSG_DISABLE_MSVC_WARNINGS) #pragma warning(push) #pragma warning(disable: a b c d e f g) #endif HeaderEnd: #if defined(_MSC_VER) %% defined(OSG_DISABLE_MSVC_WARNINGS) #pragma warning(pop) #endif That way, the code would not be littered with push/pop/disable pragmas, but the warnings would be disabled only for the OSG headers, and it would not seep into user code. We could do the same for any cpp file that has warnings we want to disable (so instead of HeaderStart/HeaderEnd maybe it could be called FileStart/FileEnd)... Sure, if we implement that solution it will imply changing a lot of files. But no less than the recent warnings purge(s) have... Anyways, I just thought I'd try to suggest a constructive solution just so you know I'm not just complaining. :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Skylark wrote: Where: HeaderStart: #if defined(_MSC_VER) %% defined(OSG_DISABLE_MSVC_WARNINGS) #pragma warning(push) #pragma warning(disable: a b c d e f g) #endif HeaderEnd: #if defined(_MSC_VER) %% defined(OSG_DISABLE_MSVC_WARNINGS) #pragma warning(pop) #endif You can actually roll the pragamas all up into two macros - one to begin (push+disable) and one to end. e.g., in a common header, (osg/Export or whatever), include the following block: #ifdef _MSC_VER #define SUPPRESS_WARNINGS __pragma (warning(push)) __pragma (warning(disable : a b c d)) #define POP_WARNINGS __pragma (warning(pop)) #else #define SUPPRESS_WARNINGS #define POP_WARNINGS #endif Now, obviously, you could also define these macros to selectively suppress warnings in other compilers by including proper conditional switches for each in the above block. I myself do this often, and have a common macros header, which gets included pretty much everywhere, for this purpose (it also defines macros for declaration specifiers and other compiler- or OS-specific code features). Matthew W Fuesz Software Engineer Asc Lockheed Martin STS -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=6004#6004 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Thu, Feb 5, 2009 at 5:28 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: I see things from the opposite perspective: if OSG wants to be used multi-platform, it has to work well on each platform, the way that platform works. Otherwise, just make VS unsupported and make everyone build through cygwin if they want to build on Windows... That way gcc is always used and you don't have to worry about how VS does things. I strongly disagree with adding lots of platform specific hacks into headers and cpp's. Standard C++ and OpenGL, CMake all exist for a reason - to make code more portable with the need for lots of platform specific hacks and expertise. Once you start adding lots of platform specific code you are on slippery slope on poor maintainability and portability. If you want a native Windows build, people need to use VS. If OSG has to be compiled through VS, it needs to conform to how VS does things (and any other compiler, I'm not putting VS in a special bunch here just putting it on the same footing as gcc). Just because we use VS doesn't mean that we have to do everything the MS way. The MS way is to code everything for Windows and Windows only, cares for portability are very much against MS's strategic goals of vendor lock-in. Play their game and you end up tied to just a single platform and benefiting that vendor rather than your customers. The problem is that *in OSG* and *in your opinion*, these warnings add nothing. But if they exist at all, it must be because they add something sometimes. The add something sometimes, so you have to review them all carefully and them make a judgement call, once you've made that judgement call and it's clear the code is correct, and the warning misleading then you have to then look at quashing it, but only then. Don't forget that even the include/osg/Export pragam's can be switched off via CMake so you can easily do a periodic double check to see if any of the warnings point to some genuine problem. Hence my assertion that OSG should not make decisions as to what warnings to suppress for user code. We'll we did try very hard to avoid the need for pragma's but even MS's own code produces warnings OK, back to trying to find solutions as opposed to opinionated discussions that don't lead anywhere (I'm talking about me, not you :-) ) What we could do is kind of like what (I think) SDL does. Instead of having each header start with #include osg/Export // rest of header it could be something like this: #include osg/HeaderStart // rest of header #include osg/HeaderEnd Goodness, this is pretty long departure from having clean Standard C++ headers... Adding two header includes to our headers just to quieten down warnings on one specific compiler set, or one specific platform so everyone pays for the convenience of one platform. What happens if you forgot to add the closing HeaderEnd?? What happens if you miss the beginning one? Yep the push/pop won't balance. If I make such a mistake ut wont' effect me working under unix, I won't even spot it, but port my problem code to windows and bang lots of odd problems. This certainly won't make help code portability and maintainability. I won't be seeing this suggestion merged into the core OSG. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, Just because we use VS doesn't mean that we have to do everything the MS way. The MS way is to code everything for Windows and Windows only, cares for portability are very much against MS's strategic goals of vendor lock-in. Play their game and you end up tied to just a single platform and benefiting that vendor rather than your customers. Oh come on. Aren't you pushing this a bit too far? We're not playing anyone's game, just using a tool that allows us to compile code on a given platform. This platform choice (which is only one option, we support Linux too, but cannot go away from Windows completely) is dictated by our clients and past history. That's what's locking us into using that tool, not the tool itself. Even if I were working on personal projects only, I would still advocate for OSG to support VS in the best way possible. It's too big a market and a user base to push to the wayside and have half-baked support for. The add something sometimes, so you have to review them all carefully and them make a judgement call, once you've made that judgement call and it's clear the code is correct, and the warning misleading then you have to then look at quashing it, but only then. Again, the judgement call only applies to one situation (OSG). Others should be free to make another judgement call depending on their situation. Don't forget that even the include/osg/Export pragam's can be switched off via CMake so you can easily do a periodic double check to see if any of the warnings point to some genuine problem. But then even OSG's headers will generate warnings. A library should not generate warnings, but should not obscure the warnings in your own code. Period. Do you at least agree with that? Goodness, this is pretty long departure from having clean Standard C++ headers... Adding two header includes to our headers just to quieten down warnings on one specific compiler set, or one specific platform so everyone pays for the convenience of one platform. As Matthew said, this could be replaced by macros in a single header, or something else. As I said, I was trying to suggest something, anything, in the hope we could go forward in some way. Just arguing back and forth doesn't help anything, so I think I'll stop replying about this subject if we don't go forward at least a bit. What happens if you forgot to add the closing HeaderEnd?? What happens if I forget to add #endif to the end of a header to close the include guards? That's not standard C++ either, just common practice, and no one really fights that. What happens if you miss the beginning one? Yep the push/pop won't balance. If I make such a mistake ut wont' effect me working under unix, I won't even spot it, but port my problem code to windows and bang lots of odd problems. Well, since you don't even see the VS warnings, and don't see errors related to OSG_EXPORT, and don't see... I don't understand how that's worse. Someone (probably me, lucky as I am) will compile on Windows, see the error, track it to the missing end marker (whatever that may be) and submit the fix, the same as a missing OSG_EXPORT. For the number of times a new header is added to OSG, I think it's really minor. This certainly won't make help code portability and maintainability. Let's just suppress all warnings in osg/Export then, and see if users like that. (I'm only partly joking) Anyways, the basic premise I'm maintaining is that a) a library should not cause any warnings when including its headers in user code b) a library should not suppress warnings caused by user code If you don't agree with that, then I'll let go, because suppressing *some* warnings in osg/Export is probably the best middle ground I'm likely to get. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert and JS, I won't take part of this inflamed discussion, but I just want to add a little technical note: Whenever the #include osg/HeaderStart is worth trying or not, I guess there is a way to avoid most missing headers by the way of defines, such as: // Opening #ifndef HEADER_OPENED #define HEADER_OPENED #else #error You added twice the start header #endif ... // Closing #ifdef HEADER_OPENED #undef HEADER_OPENED #else #error You added twice the end header, or forgot the start header #endif Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 20:38:53 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Robert, Just because we use VS doesn't mean that we have to do everything the MS way. The MS way is to code everything for Windows and Windows only, cares for portability are very much against MS's strategic goals of vendor lock-in. Play their game and you end up tied to just a single platform and benefiting that vendor rather than your customers. Oh come on. Aren't you pushing this a bit too far? We're not playing anyone's game, just using a tool that allows us to compile code on a given platform. This platform choice (which is only one option, we support Linux too, but cannot go away from Windows completely) is dictated by our clients and past history. That's what's locking us into using that tool, not the tool itself. Even if I were working on personal projects only, I would still advocate for OSG to support VS in the best way possible. It's too big a market and a user base to push to the wayside and have half-baked support for. The add something sometimes, so you have to review them all carefully and them make a judgement call, once you've made that judgement call and it's clear the code is correct, and the warning misleading then you have to then look at quashing it, but only then. Again, the judgement call only applies to one situation (OSG). Others should be free to make another judgement call depending on their situation. Don't forget that even the include/osg/Export pragam's can be switched off via CMake so you can easily do a periodic double check to see if any of the warnings point to some genuine problem. But then even OSG's headers will generate warnings. A library should not generate warnings, but should not obscure the warnings in your own code. Period. Do you at least agree with that? Goodness, this is pretty long departure from having clean Standard C++ headers... Adding two header includes to our headers just to quieten down warnings on one specific compiler set, or one specific platform so everyone pays for the convenience of one platform. As Matthew said, this could be replaced by macros in a single header, or something else. As I said, I was trying to suggest something, anything, in the hope we could go forward in some way. Just arguing back and forth doesn't help anything, so I think I'll stop replying about this subject if we don't go forward at least a bit. What happens if you forgot to add the closing HeaderEnd?? What happens if I forget to add #endif to the end of a header to close the include guards? That's not standard C++ either, just common practice, and no one really fights that. What happens if you miss the beginning one? Yep the push/pop won't balance. If I make such a mistake ut wont' effect me working under unix, I won't even spot it, but port my problem code to windows and bang lots of odd problems. Well, since you don't even see the VS warnings, and don't see errors related to OSG_EXPORT, and don't see... I don't understand how that's worse. Someone (probably me, lucky as I am) will compile on Windows, see the error, track it to the missing end marker (whatever that may be) and submit the fix, the same as a missing OSG_EXPORT. For the number of times a new header is added to OSG, I think it's really minor. This certainly won't make help code portability and maintainability. Let's just suppress all warnings in osg/Export then, and see if users like that. (I'm only partly joking) Anyways, the basic premise I'm maintaining is that a) a library should not cause any warnings when including its headers in user code b) a library should not suppress warnings caused by user code If you don't agree with that, then I'll let go, because suppressing *some* warnings in osg/Export is probably the best middle ground I'm likely to get. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Humm can we remove the Export header ? just joking ;) Sukender wrote: Hi Robert and JS, I won't take part of this inflamed discussion, but I just want to add a little technical note: Whenever the #include osg/HeaderStart is worth trying or not, I guess there is a way to avoid most missing headers by the way of defines, such as: // Opening #ifndef HEADER_OPENED #define HEADER_OPENED #else #error You added twice the start header #endif ... // Closing #ifdef HEADER_OPENED #undef HEADER_OPENED #else #error You added twice the end header, or forgot the start header #endif Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 20:38:53 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Robert, Just because we use VS doesn't mean that we have to do everything the MS way. The MS way is to code everything for Windows and Windows only, cares for portability are very much against MS's strategic goals of vendor lock-in. Play their game and you end up tied to just a single platform and benefiting that vendor rather than your customers. Oh come on. Aren't you pushing this a bit too far? We're not playing anyone's game, just using a tool that allows us to compile code on a given platform. This platform choice (which is only one option, we support Linux too, but cannot go away from Windows completely) is dictated by our clients and past history. That's what's locking us into using that tool, not the tool itself. Even if I were working on personal projects only, I would still advocate for OSG to support VS in the best way possible. It's too big a market and a user base to push to the wayside and have half-baked support for. The add something sometimes, so you have to review them all carefully and them make a judgement call, once you've made that judgement call and it's clear the code is correct, and the warning misleading then you have to then look at quashing it, but only then. Again, the judgement call only applies to one situation (OSG). Others should be free to make another judgement call depending on their situation. Don't forget that even the include/osg/Export pragam's can be switched off via CMake so you can easily do a periodic double check to see if any of the warnings point to some genuine problem. But then even OSG's headers will generate warnings. A library should not generate warnings, but should not obscure the warnings in your own code. Period. Do you at least agree with that? Goodness, this is pretty long departure from having clean Standard C++ headers... Adding two header includes to our headers just to quieten down warnings on one specific compiler set, or one specific platform so everyone pays for the convenience of one platform. As Matthew said, this could be replaced by macros in a single header, or something else. As I said, I was trying to suggest something, anything, in the hope we could go forward in some way. Just arguing back and forth doesn't help anything, so I think I'll stop replying about this subject if we don't go forward at least a bit. What happens if you forgot to add the closing HeaderEnd?? What happens if I forget to add #endif to the end of a header to close the include guards? That's not standard C++ either, just common practice, and no one really fights that. What happens if you miss the beginning one? Yep the push/pop won't balance. If I make such a mistake ut wont' effect me working under unix, I won't even spot it, but port my problem code to windows and bang lots of odd problems. Well, since you don't even see the VS warnings, and don't see errors related to OSG_EXPORT, and don't see... I don't understand how that's worse. Someone (probably me, lucky as I am) will compile on Windows, see the error, track it to the missing end marker (whatever that may be) and submit the fix, the same as a missing OSG_EXPORT. For the number of times a new header is added to OSG, I think it's really minor. This certainly won't make help code portability and maintainability. Let's just suppress all warnings in osg/Export then, and see if users like that. (I'm only partly joking) Anyways, the basic premise I'm maintaining is that a) a library should not cause any warnings when including its headers in user code b) a library should not suppress warnings caused by user code If you don't agree with that, then I'll let go, because suppressing *some* warnings in osg/Export is probably the best middle ground I'm likely to get. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:morni...@plopbyte.net http://www.plopbyte.net ___ osg-users mailing list
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All, On Tue, Feb 3, 2009 at 9:32 PM, Sukender suky0...@free.fr wrote: My mistake, I meant that the volatile and should be removed (not the whole static_cast). May static_castunsigned int do it? (since I'm not certain volatile here is useful, because we simply return a copy). I've just got confirmation from Mathias that removing the cast should be OK, so I've gone ahead and committed this change. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All, I have now made the OpenSceneGraph-2.8 branch, the svn entry for it is: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8/ If those don't CDash builds (as well as everyone else) move across to using this branch as the base for testing the OSG-2.8 release series. I'll also soon be making an OSG-2.8.0-rc1, but first I'll do a fresh build on the 2.8 branch and see how I get on. It'd be useful to have feedback from others as well on how the OSG-2.8 is fairing. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, I checked out a fresh 2.8 source tree (rev 9648) and it built fine on vs 2005 xp! But I still see a few warnings and they are attached. cheers Mattias On 2/4/09, Robert Osfield robert.osfi...@gmail.com wrote: Hi All, I have now made the OpenSceneGraph-2.8 branch, the svn entry for it is: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8/ If those don't CDash builds (as well as everyone else) move across to using this branch as the base for testing the OSG-2.8 release series. I'll also soon be making an OSG-2.8.0-rc1, but first I'll do a fresh build on the 2.8 branch and see how I get on. It'd be useful to have feedback from others as well on how the OSG-2.8 is fairing. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _nod_Ty,_Alloc::_Node' : default constructor could not be generated 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 15C:\Program Files\Microsoft Visual Studio 8\VC\include\list(38) : see declaration of 'std::_List_nod_Ty,_Alloc::_Node' 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 15C:\Program Files\Microsoft Visual Studio 8\VC\include\list(111) : see reference to class template instantiation 'std::_List_nod_Ty,_Alloc::_Node' being compiled 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 15C:\Program Files\Microsoft Visual Studio 8\VC\include\list(110) : while compiling class template member function 'std::_List_nod_Ty,_Alloc::_Node *std::list_Ty::_Nextnode(std::_List_nod_Ty,_Alloc::_Node *)' 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 15c:\public\openscenegraph-2.8\src\osgutil\TriStrip_graph_array.h(109) : see reference to class template instantiation 'std::list_Ty' being compiled 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 15 c:\public\openscenegraph-2.8\src\osgutil\TriStrip_tri_stripper.h(257) : see reference to class template instantiation 'triangle_stripper::common_structures::graph_arraynodetype,arctype' being compiled 15with 15[ 15nodetype=triangle_stripper::triangle, 15arctype=char 15] 15C:\Program Files\Microsoft Visual Studio 8\VC\include\list(42) : warning C4610: struct 'std::_List_nod_Ty,_Alloc::_Node' can never be instantiated - user defined constructor required 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 16Registry.cpp 15TriStrip_tri_stripper.cpp 15C:\Program Files\Microsoft Visual Studio 8\VC\include\list(42) : warning C4510: 'std::_List_nod_Ty,_Alloc::_Node' : default constructor could not be generated 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 15C:\Program Files\Microsoft Visual Studio 8\VC\include\list(38) : see declaration of 'std::_List_nod_Ty,_Alloc::_Node' 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 15C:\Program Files\Microsoft Visual Studio 8\VC\include\list(111) : see reference to class template instantiation 'std::_List_nod_Ty,_Alloc::_Node' being compiled 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, If those don't CDash builds (as well as everyone else) move across to using this branch as the base for testing the OSG-2.8 release series. Quick question about this: Since the Nightly build is still called Nightly in the 2.8 branch, it will replace any result of a nightly build of the trunk right? So I don't have to schedule a nightly build of both, just the 2.8 branch, until 2.8 is out. Am I right? BTW, I've got a build from last night on the CDash dashboard (WHITESTAR) and it looks like it built fine, though with 13 warnings from compiling the 29 changed files. I've started a build of the 2.8 branch, since it's the first it will be a complete build and the results should be there in about 20 minutes. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, Just built a clean checkout of the 2.8 branch on Windows Vista, Visual Studio 8 SP1. Apart from the std::list warning that we can't do much about, there were 4 left in OSGA_Archive.cpp (below). I tested the build in our app and everything worked as expected. Cheers, Morne warning C4512: 'OSGA_Archive::WriteObjectFunctor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp 727 warning C4512: 'OSGA_Archive::WriteImageFunctor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp 737 warning C4512: 'OSGA_Archive::WriteHeightFieldFunctor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp 747 warning C4512: 'OSGA_Archive::WriteNodeFunctor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp 757 On Wed, Feb 4, 2009 at 1:02 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi All, I have now made the OpenSceneGraph-2.8 branch, the svn entry for it is: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8/ If those don't CDash builds (as well as everyone else) move across to using this branch as the base for testing the OSG-2.8 release series. I'll also soon be making an OSG-2.8.0-rc1, but first I'll do a fresh build on the 2.8 branch and see how I get on. It'd be useful to have feedback from others as well on how the OSG-2.8 is fairing. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi JS, On Wed, Feb 4, 2009 at 2:32 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Quick question about this: Since the Nightly build is still called Nightly in the 2.8 branch, it will replace any result of a nightly build of the trunk right? So I don't have to schedule a nightly build of both, just the 2.8 branch, until 2.8 is out. Am I right? Yes, move across to making the builds from the 2.8 banch till 2.8.0 is out. Even after 2.8.0 is out, there is some value in having periodic builds of the 2.8 branch as there may well be a 2.8.1+ later released, although we could probably just make a request for new tests of the 2.8 if we actually need to make a 2.8.1+ I've started a build of the 2.8 branch, since it's the first it will be a complete build and the results should be there in about 20 minutes. Thanks. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, I'm terribly sorry, but I don't have the time right now. I just hope someone else will do it. PS: I launched an experimental build. I'll tell you about the results. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 04 Feb 2009 15:57:45 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Window's users, I've tried really hard to fix all these Windows warnings, while most seem now fixed/workaround/suppressed some have resisted my attempts to remotely fix them, we me doing several unsuccessful attempts at this last persistent warnings. A fundamental problem is that I can't make a change and see whether the problem is fixed or not, this makes it really inefficient... So could a windows hack take over the attempt at fixing these warnings. Suppressing these warnings is fair game at this stage, especially if simple code changes aren't possible, suppressing a warning for a single .cpp is also note such a bad thing, especially if you use the convention set up in the include/osg/Export that allows you to switch off the disabling of the MSVC warnings. The src/osgPlugins/cfg/ConfigLexer.cpp has one such example (that doesn't seem to work... if the latest build results are correct). #if defined(_MSC_VER) defined(OSG_DISABLE_MSVC_WARNINGS) // disable '=' : conversion from 'int' to 'char', possible loss of data style warnings #pragma warning( disable : 4244) #endif Just send me the code changes that resolve these final warnings. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, Yes, move across to making the builds from the 2.8 banch till 2.8.0 is out. OK, I've disabled the nightly build of the branch for now. Even after 2.8.0 is out, there is some value in having periodic builds of the 2.8 branch as there may well be a 2.8.1+ later released, although we could probably just make a request for new tests of the 2.8 if we actually need to make a 2.8.1+ We could perhaps have the same thing as for 2.6 - a Nightly-2.8 target, so that the build would end up in a different category and not overwrite the build of the trunk on the dashboard page? I've started a build of the 2.8 branch, since it's the first it will be a complete build and the results should be there in about 20 minutes. Which is now done (20.2 minutes), and it seems that the only warnings were could not open build log for writing... Good job on the warnings fixes. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, I've tried really hard to fix all these Windows warnings, while most seem now fixed/workaround/suppressed some have resisted my attempts to remotely fix them, we me doing several unsuccessful attempts at this last persistent warnings. As I said on my other post, I don't seem to get any warnings (other than can't open build log for writing, which is weird but benign - the warnings if any would still go to stdout and thus get reported in the CDash warnings page for the build). I'll try another full rebuild and see for sure. Then if I get any I'll see what needs to be done. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Window's users, I've tried really hard to fix all these Windows warnings, while most seem now fixed/workaround/suppressed some have resisted my attempts to remotely fix them, we me doing several unsuccessful attempts at this last persistent warnings. A fundamental problem is that I can't make a change and see whether the problem is fixed or not, this makes it really inefficient... So could a windows hack take over the attempt at fixing these warnings. Suppressing these warnings is fair game at this stage, especially if simple code changes aren't possible, suppressing a warning for a single .cpp is also note such a bad thing, especially if you use the convention set up in the include/osg/Export that allows you to switch off the disabling of the MSVC warnings. The src/osgPlugins/cfg/ConfigLexer.cpp has one such example (that doesn't seem to work... if the latest build results are correct). #if defined(_MSC_VER) defined(OSG_DISABLE_MSVC_WARNINGS) // disable '=' : conversion from 'int' to 'char', possible loss of data style warnings #pragma warning( disable : 4244) #endif Just send me the code changes that resolve these final warnings. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi JS, Thanks for the warning fixes, I've merged about 2/3rds of them, but will record some of the other ones. The server isn't accessible right now so I'm not able to check in right now. I'll have bash tomorrow morning. These last warning fixes won't affect runtime at all so the 2.8.0-rc1 as it stands right now should be good enough for testing. Robert. On Wed, Feb 4, 2009 at 5:44 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Robert, As I said on my other post, I don't seem to get any warnings (other than can't open build log for writing, which is weird but benign - the warnings if any would still go to stdout and thus get reported in the CDash warnings page for the build). I'll try another full rebuild and see for sure. Then if I get any I'll see what needs to be done. OK, I've had a go at fixing the warnings. I've attached a zip containing the build output before the fixes for you to see, as well as the changed files. The PDB warnings (which come from the fact that a given 3rd party library was compiled with debug information split into a separate file instead of embedded into the library) we can just ignore. They only happen at link time for the given plugin. Same thing for the default library MSVCRT conflicts... warning, though that might indicate a bigger problem. The next time someone makes a 3rd party package, those things should be taken care of. Other than that, here are the warnings I fixed: ___ osgUtil.lib and osglauncher example 4C:\Tools\msvs8\VC\include\list(42) : warning C4510: 'std::_List_nod_Ty,_Alloc::_Node' : default constructor could not be generated (and other similar and related warnings) Simply adding an empty default constructor to the arc class in TriStrip_graph_array.h and the Xample class in osglauncher.cpp fixed this You could see that std::list was not the problem, but the class used as a template argument, because lower in the warning message there was mention of 4 c:\dev\openscenegraph-svn\openscenegraph-2.8-branch\src\osgutil\TriStrip_graph_array.h(109) : see reference to class template instantiation 'std::list_Ty' being compiled 4with 4[ 4 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 4] which pointed to the type to which a default constructor needed to be added. It comes down to deciphering VS's messages... :-) ___ osga plugin 198..\..\..\..\src\osgPlugins\osga\OSGA_Archive.cpp(727) : warning C4512: 'OSGA_Archive::WriteObjectFunctor' : assignment operator could not be generated 198..\..\..\..\src\osgPlugins\osga\OSGA_Archive.cpp(719) : see declaration of 'OSGA_Archive::WriteObjectFunctor' (and so on for the other Write*Functors) I didn't find any way to fix this other than locally suppressing it, since creating a default constructor would imply constructing a default osg::Object, which is abstract so I can't do that. So I suppressed it around those 4 classes. ___ cfg plugin and osgviewerGLUT example You had tried suppressing warnings in these two cases, protected by #if defined(_MSC_VER) defined(OSG_DISABLE_MSVC_WARNINGS) but you needed to include osg/Config before that, so that OSG_DISABLE_MSVC_WARNINGS was defined... ___ osgviewerQT example 26c:\tools\qt\4.4.3\include\qtcore\../../src/corelib/concurrent/qtconcurrentiteratekernel.h(97) : warning C4512: 'QtConcurrent::BlockSizeManager' : assignment operator could not be generated 26 c:\tools\qt\4.4.3\include\qtcore\../../src/corelib/concurrent/qtconcurrentiteratekernel.h(79) : see declaration of 'QtConcurrent::BlockSizeManager' Since this is in Qt's headers, I just suppressed this locally (for both Qt 4 and Qt 3 - I'm using Qt 4 and I have no way of knowing if this appears for Qt 3). ___ I'm doing a full rebuild now (and as you all know now thanks to the dashboard reports, this takes 20 minutes on my machine if nothing else is happening) so I'll tell you when this is done if any fixable warnings remain, but I think it should look good. Of course as we can see from osgviewerQT, there are perhaps warnings lurking in other examples/plugins which I don't compile... Others will have to pitch in for fixing those. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi JS et. al, On Mon, Feb 2, 2009 at 8:51 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Sooo... What are you planning as an upload area for packages? :-) You said we'd put them into SVN, but do you plan to give all of us commit access to a given area of the SVN? Perhaps an FTP would be easier, we could just upload and people would download and then once we've confirmed the packages are good you can commit the packages to SVN... After the last discussion on this topic I end up leaning towards not using svn for binaries. The server supports webdav as well as ftp. I'll go an experiment with these routes and report back. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi, svn rev 9631 builds correctly on CentOS 4.7: - Kernel: 2.6.9-78.0.8.ELsmp - gcc: 3.4.6-10 I have also setup a continuous build for trunk which will keep on building until 2.8 is out! Appreciate everybody's effort in getting 2.8 out asap;) Best regards, John Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Best regards, John WeatherOne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Melchoir, On Tue, Feb 3, 2009 at 7:33 AM, Melchior FRANZ melchior.fr...@gmail.com wrote: Just for the record: I've had several segfaults in OSG's particle code (threading related) since I updated a few days ago. I'll post a backtrace when I run into it again. The particle code has changed very little in the last year, and only a tiny tweak recently that won't effect threading stability. It could be an old problem that has only just now surfaced, or perhaps just a build consistency issue. Do any of the standard particle examples reproduce the crash? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Umit, On Tue, Feb 3, 2009 at 3:58 AM, Ümit Uzun umituzu...@gmail.com wrote: Sorry for late but I have already tried 2.8 :) There are some problem, while using osgviewer sometimes there was a Error: [Screen #0] GraphicsWindowWin32::swapBuffersImplementation() - Unable to swap display buffers problem. And almost all examples working on my system but osgprecipictation example make my computer lock and after I run this example I get push emergency shutdown button :) Maybe because of my system's configuration. But I have no luck to figure it out what was the problem because of there was no message in deadlock mode :( My System : XP Pro SP3, Core2 2.2GHz, ATI Mobility Radeon HD 2300, 2 GB Ram I suspect the problems are caused by dodgy ATI drivers - both the swap buffers and the preciptation rendering. I have seen first hand ATIcards really struggling with osgpreciptiation, it looks like drivers are errors in particle sizing that in turn causes huge fill requirements that in turn leads to very low framerate, which makes the particles even larger due to the motion blurr that osgparticle implememts, which makes things worse... With decent drivers osgparticle works well even on relatively low hardwre, but it has to support GLSL properly. Thanks for Ver-2.8 to OSG-Family and especially Robert by 9 passion hardworking years :) Thanks. This morning it occurred to me that it's now 2009, which means it's actually a decade now since I started putting significant amounts of time into the OSG. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
About the stats display problem, it's resolved here, thanks ! On Tue, Feb 3, 2009 at 10:15 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Umit, On Tue, Feb 3, 2009 at 3:58 AM, Ümit Uzun umituzu...@gmail.com wrote: Sorry for late but I have already tried 2.8 :) There are some problem, while using osgviewer sometimes there was a Error: [Screen #0] GraphicsWindowWin32::swapBuffersImplementation() - Unable to swap display buffers problem. And almost all examples working on my system but osgprecipictation example make my computer lock and after I run this example I get push emergency shutdown button :) Maybe because of my system's configuration. But I have no luck to figure it out what was the problem because of there was no message in deadlock mode :( My System : XP Pro SP3, Core2 2.2GHz, ATI Mobility Radeon HD 2300, 2 GB Ram I suspect the problems are caused by dodgy ATI drivers - both the swap buffers and the preciptation rendering. I have seen first hand ATIcards really struggling with osgpreciptiation, it looks like drivers are errors in particle sizing that in turn causes huge fill requirements that in turn leads to very low framerate, which makes the particles even larger due to the motion blurr that osgparticle implememts, which makes things worse... With decent drivers osgparticle works well even on relatively low hardwre, but it has to support GLSL properly. Thanks for Ver-2.8 to OSG-Family and especially Robert by 9 passion hardworking years :) Thanks. This morning it occurred to me that it's now 2009, which means it's actually a decade now since I started putting significant amounts of time into the OSG. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All, So are we ready for the OSG-2.8 branch?? It looks like we are a good position to tag. Please raise your hand now if there is something amiss that I need to address. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Sukender, On Tue, Feb 3, 2009 at 11:26 AM, Sukender suky0...@free.fr wrote: Uh??? I sent you a 7z file... it's okay if it's binary, isn't it? There wasn't an extension on the end of the file, I didn't get to find out that it was a 7z file... Here is a zip with only the CSV inside (the txt is about 360 ko). Please tell me if it's okay. This came through fine. CSV doesn't add anything, straight compiler output is actually the most convenient for me, as I don't need remove an non essential stuff like the warning number in the list. From looking at the file was is very clear is that include\osgIntrospection\TypedMethodInfo generates almost all the warnings. So I'd suggest we using a #pragma to disable the specific C4121 warning for this header. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Sukender, On Tue, Feb 3, 2009 at 11:41 AM, Robert Osfield robert.osfi...@gmail.com wrote: From looking at the file was is very clear is that include\osgIntrospection\TypedMethodInfo generates almost all the warnings. So I'd suggest we using a #pragma to disable the specific C4121 warning for this header. To the include/osg/TypedefMethodInfo header I've added: #if defined(_MSC_VER) // disable for this header the VS warning C4121 : alignment of a member was sensitive to packing #pragma warning( push ) #pragma warning( disable : 4121) #endif ... #if defined(_MSC_VER) #pragma warning( pop ) #endif In attempt to disable this specific warning for just this file, in the hope that it'll quieten things done. This change is now checked in. File also attached. Could you try a rebuild to see if this warning is now gone? If this doesn't work we'll need to remove the push/pop. I'll now look at the other warnings. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Building on Windows XP, Visual Studio 2008 sp1. All builds fine, but
getting same warnings as Sukender (haven't tried your latest updates
Robert...about to rebuild with latest revision).
Examples run good except getting crash in osgTexture2D with a map/set
iterator not incrementable error. This error goes away if I add
viewer.setThreadingModel( osgViewer::Viewer::SingleThreaded ); to the
example...maybe thread safety issue with incrementing _currPos??
Stack Trace:
msvcp90d.dll!std::_Debug_message(const wchar_t * message=0x017ab278, const
wchar_t * file=0x0178, unsigned int line=304) Line 24C++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator==(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 304 + 0x17 bytesC++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator!=(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 316 + 0xc bytesC++
osg55-osgTextd.dll!osgText::Text::renderOnlyForegroundText(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1746 + 0x33
bytesC++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1368C++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::RenderInfo
renderInfo={...}) Line 1252C++
osg55-osgd.dll!osg::Drawable::draw(osg::RenderInfo renderInfo={...})
Line 898 + 0x13 bytesC++
osg55-osgUtild.dll!osgUtil::RenderLeaf::render(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 60 + 0x19
bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 419 +
0x19 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384 +
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 469 +
0x35 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line
1253C++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384 +
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8, bool
doCopyTexture=false) Line 848C++
osg55-osgUtild.dll!osgUtil::RenderStage::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 1108 +
0x1b bytesC++
osg55-osgUtild.dll!osgUtil::SceneView::draw() Line 1540 + 0x37
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::draw() Line 451 + 0xf
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext *
context=0x0277fb30) Line 693 + 0xf bytesC++
osg55-osgd.dll!osg::GraphicsContext::runOperations() Line 688 + 0x33
bytesC++
osg55-osgd.dll!osg::RunOperations::operator()(osg::GraphicsContext *
context=0x0277fb30) Line 135C++
osg55-osgd.dll!osg::GraphicsOperation::operator()(osg::Object *
object=0x0277fb30) Line 50 + 0x19 bytesC++
osg55-osgd.dll!osg::OperationThread::run() Line 413 + 0x26 bytes
C++
osg55-osgd.dll!osg::GraphicsThread::run() Line 40C++
ot11-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void *
data=0x026f82ac) Line 116 + 0xf bytesC++
msvcr90d.dll!_callthreadstartex() Line 348 + 0xf bytesC
msvcr90d.dll!_threadstartex(void * ptd=0x026f9830) Line 331C
kernel32.dll!7c80b713()
- Donny
On Mon, Feb 2, 2009 at 9:01 AM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi All,
I've now finished all the merges/bug/features fixes that is required
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Donald,
This looks to be a threading issue with the text label being updated
while being rendered.
There was no text-setDataVariance(DYNAMIC) so I've added this, and
checked this change into svn/trunk. Could you please test. Modified
osgtexture2D.cpp also attached.
Robert.
On Tue, Feb 3, 2009 at 12:35 PM, Donald Cipperly osgc...@gmail.com wrote:
Building on Windows XP, Visual Studio 2008 sp1. All builds fine, but
getting same warnings as Sukender (haven't tried your latest updates
Robert...about to rebuild with latest revision).
Examples run good except getting crash in osgTexture2D with a map/set
iterator not incrementable error. This error goes away if I add
viewer.setThreadingModel( osgViewer::Viewer::SingleThreaded ); to the
example...maybe thread safety issue with incrementing _currPos??
Stack Trace:
msvcp90d.dll!std::_Debug_message(const wchar_t * message=0x017ab278, const
wchar_t * file=0x0178, unsigned int line=304) Line 24C++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator==(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 304 + 0x17 bytesC++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator!=(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 316 + 0xc bytesC++
osg55-osgTextd.dll!osgText::Text::renderOnlyForegroundText(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1746 + 0x33
bytesC++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1368C++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::RenderInfo
renderInfo={...}) Line 1252C++
osg55-osgd.dll!osg::Drawable::draw(osg::RenderInfo renderInfo={...})
Line 898 + 0x13 bytesC++
osg55-osgUtild.dll!osgUtil::RenderLeaf::render(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 60 + 0x19
bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 419 +
0x19 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384 +
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 469 +
0x35 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line
1253C++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384 +
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8, bool
doCopyTexture=false) Line 848C++
osg55-osgUtild.dll!osgUtil::RenderStage::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 1108 +
0x1b bytesC++
osg55-osgUtild.dll!osgUtil::SceneView::draw() Line 1540 + 0x37
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::draw() Line 451 + 0xf
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext *
context=0x0277fb30) Line 693 + 0xf bytesC++
osg55-osgd.dll!osg::GraphicsContext::runOperations() Line 688 + 0x33
bytesC++
osg55-osgd.dll!osg::RunOperations::operator()(osg::GraphicsContext *
context=0x0277fb30) Line 135C++
osg55-osgd.dll!osg::GraphicsOperation::operator()(osg::Object *
object=0x0277fb30) Line 50 + 0x19 bytesC++
osg55-osgd.dll!osg::OperationThread::run() Line 413 + 0x26 bytes
C++
osg55-osgd.dll!osg::GraphicsThread::run() Line 40C++
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Sukender,
If we can't work out what it's on a bout and the warning looks benign,
should we just suppress it?
Robert.
On Tue, Feb 3, 2009 at 1:56 PM, Sukender suky0...@free.fr wrote:
Hi Robert,
Not many ideas, but:
- This may be related to the IC class used at this moment. Unfortunately,
there is no clue in the log about which IC causes it, except it's in osgDB
wrapper. So this may be the DatabasePager. Perhaps is it linked to:
I_StaticMethod0(osgDB::DatabasePager *, create,
__DatabasePager_P1__create_S,
create a DatabasePager by cloning
DatabasePager::prototype(). ,
);
in DatabasePager.cpp?
- Could this be related to the fact that ConstructorInfo is private
inheritance? I guess no, but...
- Just for info, the help says VC generates 4702 when a catch() block cannot
be reached (when functions called in try() are all C, because extern C
functions are assumed to not throw).
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Tue, 03 Feb 2009 14:32:59 +0100, Robert Osfield robert.osfi...@gmail.com
a écrit:
Hi All,
I'm look at the follow warning under Windows. I can't figure out why
there is a warning of this type:
152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36)
: warning C4702: unreachable code
The code is:
templatetypename C, typename IC
struct TypedConstructorInfo0: ConstructorInfo
{
TypedConstructorInfo0(const ParameterInfoList plist,
std::string briefHelp = std::string(), std::string detailedHelp =
std::string())
:ConstructorInfo(typeof(C), plist, briefHelp, detailedHelp)
{
}
Value createInstance(ValueList /*args*/) const
{
return IC::create();
} This is line 36 for which the warning is being emited.
};
The offending line is overriding a virtual createInstance(ValueList)
const method from the ConstructorInfo base class. This usage pattern
is also used in the many other template classes in
include/osgIntrospection/TypedConstructorInfo but none generate
warnings...
Strange, any chance that someone can shine some light on this warning?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, hi all,
const T *v: When T is a function, I guess the compiler reads pointer to a
const function instead of const pointer to a function. Thus the const
applied on a function has no meaning. I don't know, however, how to avoid this,
since const (T *) v will result in a parse error.
Any idea?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Tue, 03 Feb 2009 14:41:21 +0100, Robert Osfield robert.osfi...@gmail.com a
écrit:
Hi All,
I can't quite fathom the following warning either...
164..\..\include\osgIntrospection/Value(373) : warning C4180:
qualifier applied to function type has no meaning; ignored
164..\..\include\osgIntrospection/TypedMethodInfo(84) : see
reference to function template instantiation
'osgIntrospection::Value::Valuebool(osg::Object ,osgDB::Input )(T
(__cdecl *))' being compiled
164with
164[
164T=bool (osg::Object ,osgDB::Input )
164]
164..\..\include\osgIntrospection/TypedMethodInfo(77) : while
compiling class template member function 'osgIntrospection::Value
osgIntrospection::TypedMethodInfo0C,R::invoke(const
osgIntrospection::Value ,osgIntrospection::ValueList ) const'
164with
164[
164C=osgDB::DotOsgWrapper,
164R=osgDB::DotOsgWrapper::ReadFunc
164]
164.\osgDB\DotOsgWrapper.cpp(58) : see reference to class
template instantiation 'osgIntrospection::TypedMethodInfo0C,R' being
compiled
164with
164[
164C=osgDB::DotOsgWrapper,
164R=osgDB::DotOsgWrapper::ReadFunc
164]
templatetypename T Value::Value(const T *v)
{
_inbox = new Ptr_instance_boxconst T *(v);This is
line 373, which generates the warning
_type = _inbox-type();
_ptype = _inbox-ptype();
}
I have other stuff to chase up so I'll leave this is the hands of
those more community to see if they figure it out and suggest a way to
resolve the problem.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Windows experts,
Here's another Windows warning that I'll like a hand resolving:
2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension
used : 'static_cast' : conversion from 'volatile const long' to
'volatile const unsigned int '
The code is:
Atomic::operator unsigned() const
{
#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)
__sync_synchronize();
return _value;
#elif defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED)
MemoryBarrier();
return static_castunsigned const volatile (_value);
Here is line 133, problem line.
#elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC)
OSMemoryBarrier();
return static_castunsigned const volatile(_value);
#else
# error This implementation should happen inline in the include file
#endif
}
To me a fix would be to remove the from the static_castunsigned
const volatile as it seems a tad superfluous in this method as it's
returning an unsigned int on the stack anyway.
Thoughts?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Morne, On Tue, Feb 3, 2009 at 2:54 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hi Robert, I think in VS, specifiying something as just unsigned causes the compiler to read unsigned int. If you change the line to return static_castunsigned long const volatile (_value); I think the warning will disappear. This will just then invoke an implicit case from unsigned long to unsigned int, it's better to keep the cast explict. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Sukender wrote: Hi Robert, hi all, const T *v: When T is a function, I guess the compiler reads pointer to a const function instead of const pointer to a function. Thus the const applied on a function has no meaning. I don't know, however, how to avoid this, since const (T *) v will result in a parse error. I don't think you can avoid it, as it seems that the Value constructor in question (Value::Value(const T* v)) is used when T is a function type. The different variations of it (const T* v, T* v, const T v) make sense in general, just not all for a function type. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, After the last discussion on this topic I end up leaning towards not using svn for binaries. The server supports webdav as well as ftp. I'll go an experiment with these routes and report back. OK, let me know. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
HI Window dev's, I've now checked in fixes for the majority of the warnings that Sukender reported, there are a few left: 2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension used : 'static_cast' : conversion from 'volatile const long' to 'volatile const unsigned int ' 24D:\Prog\Libs\3rdParty\include\GL/glut.h(549) : warning C4505: 'glutCreateMenu_ATEXIT_HACK' : unreferenced local function has been removed 164..\..\include\osgIntrospection/Value(373) : warning C4180: qualifier applied to function type has no meaning; ignored 152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36) : warning C4702: unreachable code For the first of these it looks like the should be removed. For the GLUT one, this is a header issue, nothing to do with our code so the only avenue is to ignore or suppress it. The last two errors generated in osgIntrospection look to me like pretty unhelpful warnings, and neither look to be ones that point to a problem that needs to be solved code wise, so I'm inclined to suppress it. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Robert,
That did indeed fix the issue.
Thanks,
Donny
On Tue, Feb 3, 2009 at 6:43 AM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi Donald,
This looks to be a threading issue with the text label being updated
while being rendered.
There was no text-setDataVariance(DYNAMIC) so I've added this, and
checked this change into svn/trunk. Could you please test. Modified
osgtexture2D.cpp also attached.
Robert.
On Tue, Feb 3, 2009 at 12:35 PM, Donald Cipperly osgc...@gmail.com
wrote:
Building on Windows XP, Visual Studio 2008 sp1. All builds fine, but
getting same warnings as Sukender (haven't tried your latest updates
Robert...about to rebuild with latest revision).
Examples run good except getting crash in osgTexture2D with a map/set
iterator not incrementable error. This error goes away if I add
viewer.setThreadingModel( osgViewer::Viewer::SingleThreaded ); to the
example...maybe thread safety issue with incrementing _currPos??
Stack Trace:
msvcp90d.dll!std::_Debug_message(const wchar_t * message=0x017ab278,
const
wchar_t * file=0x0178, unsigned int line=304) Line 24C++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator==(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 304 + 0x17 bytesC++
osg55-osgTextd.dll!std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator::operator!=(const
std::_Treestd::_Tmap_traitsosg::ref_ptrosgText::Font::GlyphTexture,osgText::Text::GlyphQuads,std::lessosg::ref_ptrosgText::Font::GlyphTexture
,std::allocatorstd::pairosg::ref_ptrosgText::Font::GlyphTexture const
,osgText::Text::GlyphQuads ,0 ::const_iterator
_Right=({_ptr=0xcdcdcdcd },{_glyphs=[0]() _coords=[0]()
_transformedCoords={...} ...})) Line 316 + 0xc bytesC++
osg55-osgTextd.dll!osgText::Text::renderOnlyForegroundText(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1746 + 0x33
bytesC++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1368C++
osg55-osgTextd.dll!osgText::Text::drawImplementation(osg::RenderInfo
renderInfo={...}) Line 1252C++
osg55-osgd.dll!osg::Drawable::draw(osg::RenderInfo
renderInfo={...})
Line 898 + 0x13 bytesC++
osg55-osgUtild.dll!osgUtil::RenderLeaf::render(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 60 +
0x19
bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 419
+
0x19 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384
+
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 469
+
0x35 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line
1253C++
osg55-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 384
+
0x17 bytesC++
osg55-osgUtild.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8, bool
doCopyTexture=false) Line 848C++
osg55-osgUtild.dll!osgUtil::RenderStage::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x02a5f4d8) Line 1108
+
0x1b bytesC++
osg55-osgUtild.dll!osgUtil::SceneView::draw() Line 1540 + 0x37
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::draw() Line 451 + 0xf
bytesC++
osg55-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext
*
context=0x0277fb30) Line 693 + 0xf bytesC++
osg55-osgd.dll!osg::GraphicsContext::runOperations() Line 688 +
0x33
bytesC++
osg55-osgd.dll!osg::RunOperations::operator()(osg::GraphicsContext *
context=0x0277fb30) Line 135C++
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Tue, Feb 3, 2009 at 10:41 AM, Tony Horrobin a.j.horro...@its.leeds.ac.uk wrote: I believe it is due to virtual inheritence of Object as in CullCallback - NodeCallback - Object. Ahh... good clue... I've added an explicit initialization of the osg::Object and checked it in, fingers crossed it'll fix the warning. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Guys, Since I've had no feedback on the remaining WIndows warnings I've gone ahead and added pragma's to suppress the following warnings that seemed to be appropriate for supression given that fixes aren't possible/don't look easily resolvable, and the warnings don't point to a real problem in the code either. 24D:\Prog\Libs\3rdParty\include\GL/glut.h(549) : warning C4505: 'glutCreateMenu_ATEXIT_HACK' : unreferenced local function has been removed 164..\..\include\osgIntrospection/Value(373) : warning C4180: qualifier applied to function type has no meaning; ignored 152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36) warning C4702: unreachable code An svn update should fix these warnings. In case of osgIntrospection I've added the warning disable pragma's to the include/osgIntrospection/Export rather each header as doing so ended up many lines of coding for just a single warning disable, not good news when each code change comes with a potential from introducing typo's + associated build/runtime problems. This leaves one warning left: 2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension used : 'static_cast' : conversion from 'volatile const long' to 'volatile const unsigned int ' For this I think the proper solution is to remove the . Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Robert, Removing the generates another warning: warning C4197: 'volatile const unsigned int' : top-level volatile in cast is ignoredc:\OpenSceneGraphSVN\src\OpenThreads\common\Atomic.cpp133 OpenThreads However, changing line 133 to just return _value; generates no warnings on Visual Studio 2008 sp1. I also see these warnings: warning C4701: potentially uninitialized local variable 'qu' used c:\openscenegraphsvn\src\osg\matrixdecomposition.cpp281osg warning C4512: 'CopyPointsToVertexArrayVisitor' : assignment operator could not be generatedc:\OpenSceneGraphSVN\src\osgUtil\Simplifier.cpp 1654osgUtil - Donny On Tue, Feb 3, 2009 at 10:44 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Guys, Since I've had no feedback on the remaining WIndows warnings I've gone ahead and added pragma's to suppress the following warnings that seemed to be appropriate for supression given that fixes aren't possible/don't look easily resolvable, and the warnings don't point to a real problem in the code either. 24D:\Prog\Libs\3rdParty\include\GL/glut.h(549) : warning C4505: 'glutCreateMenu_ATEXIT_HACK' : unreferenced local function has been removed 164..\..\include\osgIntrospection/Value(373) : warning C4180: qualifier applied to function type has no meaning; ignored 152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36) warning C4702: unreachable code An svn update should fix these warnings. In case of osgIntrospection I've added the warning disable pragma's to the include/osgIntrospection/Export rather each header as doing so ended up many lines of coding for just a single warning disable, not good news when each code change comes with a potential from introducing typo's + associated build/runtime problems. This leaves one warning left: 2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension used : 'static_cast' : conversion from 'volatile const long' to 'volatile const unsigned int ' For this I think the proper solution is to remove the . Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Donald, On Tue, Feb 3, 2009 at 5:03 PM, Donald Cipperly osgc...@gmail.com wrote: Removing the generates another warning: warning C4197: 'volatile const unsigned int' : top-level volatile in cast is ignoredc:\OpenSceneGraphSVN\src\OpenThreads\common\Atomic.cpp133 OpenThreads However, changing line 133 to just return _value; Tempting to go with this, but there must have been a motivation for the use of volatile here. I'll track down the original author. generates no warnings on Visual Studio 2008 sp1. I also see these warnings: warning C4701: potentially uninitialized local variable 'qu' used c:\openscenegraphsvn\src\osg\matrixdecomposition.cpp281osg warning C4512: 'CopyPointsToVertexArrayVisitor' : assignment operator could not be generatedc:\OpenSceneGraphSVN\src\osgUtil\Simplifier.cpp 1654osgUtil I've just checked in fixes for these, could you do an svn update and let me know how things build. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All,
I can't quite fathom the following warning either...
164..\..\include\osgIntrospection/Value(373) : warning C4180:
qualifier applied to function type has no meaning; ignored
164..\..\include\osgIntrospection/TypedMethodInfo(84) : see
reference to function template instantiation
'osgIntrospection::Value::Valuebool(osg::Object ,osgDB::Input )(T
(__cdecl *))' being compiled
164with
164[
164T=bool (osg::Object ,osgDB::Input )
164]
164..\..\include\osgIntrospection/TypedMethodInfo(77) : while
compiling class template member function 'osgIntrospection::Value
osgIntrospection::TypedMethodInfo0C,R::invoke(const
osgIntrospection::Value ,osgIntrospection::ValueList ) const'
164with
164[
164C=osgDB::DotOsgWrapper,
164R=osgDB::DotOsgWrapper::ReadFunc
164]
164.\osgDB\DotOsgWrapper.cpp(58) : see reference to class
template instantiation 'osgIntrospection::TypedMethodInfo0C,R' being
compiled
164with
164[
164C=osgDB::DotOsgWrapper,
164R=osgDB::DotOsgWrapper::ReadFunc
164]
templatetypename T Value::Value(const T *v)
{
_inbox = new Ptr_instance_boxconst T *(v);This is
line 373, which generates the warning
_type = _inbox-type();
_ptype = _inbox-ptype();
}
I have other stuff to chase up so I'll leave this is the hands of
those more community to see if they figure it out and suggest a way to
resolve the problem.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi, I believe it is due to virtual inheritence of Object as in CullCallback - NodeCallback - Object. Cheers, -Tony [quote=Jeremy Moles]On Mon, 2009-02-02 at 17:32 +, Robert Osfield wrote: [quote]HI Jeremy, On Mon, Feb 2, 2009 at 5:19 PM, Jeremy Moles wrote: The only MAJOR one I'm getting anymore is this: In copy constructor 'osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)': /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osg::Object' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osgGA::GUIEventHandler' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'struct osg::Drawable::CullCallback' should be explicitly initialized in the copy constructor The warning remains with the latest revision; osg::Object must also be initialized for this warning to go away. Why this is the case, I do not know. -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5734#5734 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Ümit, There are some problem, while using osgviewer sometimes there was a Error: [Screen #0] GraphicsWindowWin32::swapBuffersImplementation() - Unable to swap display buffers problem. And almost all examples working on my system but osgprecipictation example make my computer lock and after I run this example I get push emergency shutdown button :) Maybe because of my system's configuration. I cannot reproduce either of these two problems. Perhaps it's a driver issue on your side? I'm on Vista 32bit, nVidia 9800GTX+, driver 180.48 J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Sukender wrote: Hi Robert, hi all, const T *v: When T is a function, I guess the compiler reads pointer to a const function instead of const pointer to a function. That's not specific to functions, as const C *c where C is a class means the same: c is a pointer to a const instance of C. If you want a const pointer you would have to write C *const c. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert,
Not many ideas, but:
- This may be related to the IC class used at this moment. Unfortunately,
there is no clue in the log about which IC causes it, except it's in osgDB
wrapper. So this may be the DatabasePager. Perhaps is it linked to:
I_StaticMethod0(osgDB::DatabasePager *, create,
__DatabasePager_P1__create_S,
create a DatabasePager by cloning
DatabasePager::prototype(). ,
);
in DatabasePager.cpp?
- Could this be related to the fact that ConstructorInfo is private
inheritance? I guess no, but...
- Just for info, the help says VC generates 4702 when a catch() block cannot be
reached (when functions called in try() are all C, because extern C functions
are assumed to not throw).
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Tue, 03 Feb 2009 14:32:59 +0100, Robert Osfield robert.osfi...@gmail.com a
écrit:
Hi All,
I'm look at the follow warning under Windows. I can't figure out why
there is a warning of this type:
152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36)
: warning C4702: unreachable code
The code is:
templatetypename C, typename IC
struct TypedConstructorInfo0: ConstructorInfo
{
TypedConstructorInfo0(const ParameterInfoList plist,
std::string briefHelp = std::string(), std::string detailedHelp =
std::string())
:ConstructorInfo(typeof(C), plist, briefHelp, detailedHelp)
{
}
Value createInstance(ValueList /*args*/) const
{
return IC::create();
} This is line 36 for which the warning is being emited.
};
The offending line is overriding a virtual createInstance(ValueList)
const method from the ConstructorInfo base class. This usage pattern
is also used in the many other template classes in
include/osgIntrospection/TypedConstructorInfo but none generate
warnings...
Strange, any chance that someone can shine some light on this warning?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All,
I'm look at the follow warning under Windows. I can't figure out why
there is a warning of this type:
152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36)
: warning C4702: unreachable code
The code is:
templatetypename C, typename IC
struct TypedConstructorInfo0: ConstructorInfo
{
TypedConstructorInfo0(const ParameterInfoList plist,
std::string briefHelp = std::string(), std::string detailedHelp =
std::string())
:ConstructorInfo(typeof(C), plist, briefHelp, detailedHelp)
{
}
Value createInstance(ValueList /*args*/) const
{
return IC::create();
} This is line 36 for which the warning is being emited.
};
The offending line is overriding a virtual createInstance(ValueList)
const method from the ConstructorInfo base class. This usage pattern
is also used in the many other template classes in
include/osgIntrospection/TypedConstructorInfo but none generate
warnings...
Strange, any chance that someone can shine some light on this warning?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert,
I think in VS, specifiying something as just unsigned causes the
compiler to read unsigned int.
If you change the line to
return static_castunsigned long const volatile (_value);
I think the warning will disappear.
Cheers,
Morne
On Tue, Feb 3, 2009 at 2:48 PM, Robert Osfield robert.osfi...@gmail.com wrote:
Hi Windows experts,
Here's another Windows warning that I'll like a hand resolving:
2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension
used : 'static_cast' : conversion from 'volatile const long' to
'volatile const unsigned int '
The code is:
Atomic::operator unsigned() const
{
#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)
__sync_synchronize();
return _value;
#elif defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED)
MemoryBarrier();
return static_castunsigned const volatile (_value);
Here is line 133, problem line.
#elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC)
OSMemoryBarrier();
return static_castunsigned const volatile(_value);
#else
# error This implementation should happen inline in the include file
#endif
}
To me a fix would be to remove the from the static_castunsigned
const volatile as it seems a tad superfluous in this method as it's
returning an unsigned int on the stack anyway.
Thoughts?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Sukender, Could you send the file as an ascii file, just came through as binary here. W.r.t warnings, if we can't fix them easily and non-intrusively then we'll have to suppress them. Robert. On Tue, Feb 3, 2009 at 10:12 AM, Sukender suky0...@free.fr wrote: Hi Robert, As the dashboard limits the warnings to 50, I did a full rebuild of rev. 9631 (VC8sp1) for you. So attached is an archive containing: - The full log (maybe useless, but who knows?) - The warnings as a CSV file (Tab separated, '' as text separator). Enjoy these 1841 warnings... ;) Well of course, most of them can be ignored since 1738 of them are alignment of a member was sensitive to packing for introspection, and there are some assignment operator could not be generated too. Just sort by description :) Hope it helps. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 21:54:34 +0100, Sukender suky0...@free.fr a écrit: Hi Robert, Second experimental build launched. (SUKENDER1 2009-02-02 on the dashboard, rev 9631, VC8sp1, all inclusive). Maybe you'll have the result before going to sleep (= To all: this is a joke... Robert NEVER sleeps! :D Even kill_and_go_to_bed -9 can't get rid of him!!!) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 21:36:03 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender (et. al) On Mon, Feb 2, 2009 at 4:20 PM, Sukender suky0...@free.fr wrote: Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... I've now gone through all the 50 warnings reported on Dashbord from your VS build, I have applied fixes for them all. Whether they are fixed or not... we I can't say till you or others do another build. I have checked my changes into svn/trunk. Since the at the end of Dashboard log there the line: The maximum number of reported warnings or errors has been reached!!! I suspect there are more warnings lurking, and even if I fix these 50, more will pop up in their place. How many we'll have to wait an see. Could everyone do another svn update on svn/trunk and build to see how things are now hanging. Posting your results on Dashboard helps me keep track of things. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All, I'm still waiting on feedback from a few emails regarding failed builds reported on CDash, and email from Mathias Froehlich on the Atomic.cpp volatile related warning, but as it's into the evening here at the westerly end of Europe I'd guess we won't get a reply tonight. I could press ahead and make the branch, but right now I'd rather wait till the morning. This gives you all a chance to do some more testing of svn/trunk :-) As long as there are no show stoppers reported overnight I'll press ahead with the OpenSceneGraph-2.8 branch + 2.8.0-rc1 tomorrow morning. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Sukender wrote:
Hi Robert, hi all,
const T *v: When T is a function, I guess the compiler reads pointer to a
const function instead of const pointer to a function.
That's not specific to functions, as const C *c where C is a class
means the same: c is a pointer to a const instance of C. If you want a
const pointer you would have to write C *const c.
Paul
Hi Robert and Paul,
Yes, that sounds logical when T is a class to give the const object
pointer/reference method. However, it's useless for functions. Actually, the
code would look like:
#if T is a not a function
Value::Value(const T *v) { ... }
#endif
Of course, we can't do *that* simple. If the whole Value class was templated,
we could partially specialize the templated class (= removing the
Value::Value(const T *v) definition in the specialization when T is a
function). But this is not the case.
May we use something similar to boost::add_const type traits then? Something
that adds a const only if possible:
templatetypename T Value(add_constT::type *v);
But I don't understand one point with functions: why don't the compiler
complain about having twice the same constructor then, since we have
Value::Value(const T *v) and Value::Value(T *v), and that the const is
ignored?
If the last point is not a problem, then I suggest we use an add_const-like
solution.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
My mistake, I meant that the volatile and should be removed (not the
whole static_cast).
May static_castunsigned int do it? (since I'm not certain volatile here is
useful, because we simply return a copy).
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Tue, 03 Feb 2009 22:28:26 +0100, Sukender suky0...@free.fr a écrit:
I don't even understand the reason of the static_cast... why it is there?
IMHO, it should be removed, but I'm no Atomic/Threads/etc expert.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Tue, 03 Feb 2009 15:48:03 +0100, Robert Osfield robert.osfi...@gmail.com
a écrit:
Hi Windows experts,
Here's another Windows warning that I'll like a hand resolving:
2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension
used : 'static_cast' : conversion from 'volatile const long' to
'volatile const unsigned int '
The code is:
Atomic::operator unsigned() const
{
#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)
__sync_synchronize();
return _value;
#elif defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED)
MemoryBarrier();
return static_castunsigned const volatile (_value);
Here is line 133, problem line.
#elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC)
OSMemoryBarrier();
return static_castunsigned const volatile(_value);
#else
# error This implementation should happen inline in the include file
#endif
}
To me a fix would be to remove the from the static_castunsigned
const volatile as it seems a tad superfluous in this method as it's
returning an unsigned int on the stack anyway.
Thoughts?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, Sorry about not anwsering sooner, but I was very busy this late afternoon. I sum up: About the #1 and #3 warnings (C4239 nonstandard extension, and C4180), I suggested in previous posts static_castunsigned int and an add_const-like solution... does it make sense for you? About C4702 unreachable code, well, I'm really stuck. I told this may be from DatabasePager, but I don't have more clues. ... And sorry about not having much time to test these solutions... maybe later... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Tue, 03 Feb 2009 16:28:04 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: HI Window dev's, I've now checked in fixes for the majority of the warnings that Sukender reported, there are a few left: 2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension used : 'static_cast' : conversion from 'volatile const long' to 'volatile const unsigned int ' 24D:\Prog\Libs\3rdParty\include\GL/glut.h(549) : warning C4505: 'glutCreateMenu_ATEXIT_HACK' : unreferenced local function has been removed 164..\..\include\osgIntrospection/Value(373) : warning C4180: qualifier applied to function type has no meaning; ignored 152d:\prog\libs\openscenegraph\include\osgintrospection\typedconstructorinfo(36) : warning C4702: unreachable code For the first of these it looks like the should be removed. For the GLUT one, this is a header issue, nothing to do with our code so the only avenue is to ignore or suppress it. The last two errors generated in osgIntrospection look to me like pretty unhelpful warnings, and neither look to be ones that point to a problem that needs to be solved code wise, so I'm inclined to suppress it. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
I don't even understand the reason of the static_cast... why it is there?
IMHO, it should be removed, but I'm no Atomic/Threads/etc expert.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Tue, 03 Feb 2009 15:48:03 +0100, Robert Osfield robert.osfi...@gmail.com a
écrit:
Hi Windows experts,
Here's another Windows warning that I'll like a hand resolving:
2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension
used : 'static_cast' : conversion from 'volatile const long' to
'volatile const unsigned int '
The code is:
Atomic::operator unsigned() const
{
#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)
__sync_synchronize();
return _value;
#elif defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED)
MemoryBarrier();
return static_castunsigned const volatile (_value);
Here is line 133, problem line.
#elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC)
OSMemoryBarrier();
return static_castunsigned const volatile(_value);
#else
# error This implementation should happen inline in the include file
#endif
}
To me a fix would be to remove the from the static_castunsigned
const volatile as it seems a tad superfluous in this method as it's
returning an unsigned int on the stack anyway.
Thoughts?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, STOP Experimental build launched on rev. 9622 (trunk) STOP Using VC8sp1 STOP See results on dashboard when available (Machine's name is SUKENDER1) STOP Should be finished in... err... when it's done! :) STOP Sukender STOP PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ STOP Le Mon, 02 Feb 2009 16:01:55 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, Feb 2, 2009 at 3:01 PM, Robert Osfield robert.osfi...@gmail.com wrote: I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. OSX CMake/Make Intel builds. Kubuntu 8.10, 64 bit builds. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Morne, On Mon, Feb 2, 2009 at 3:39 PM, Morné Pistorius mpistorius@googlemail.com wrote: I successfully built the current trunk on Windows, VS8. Attached are more warnings if you are interested (about 71), they look to be mostly benign. Thanks, I'll do a review of the warnings and look to get the fixed (or suppressed if we have to) before OSG-2.8.0 goes out. In tests with my app I found some curious behaviour with the QOSGWidget (non-GraphicsWindowEmbedded) implementation. Since moving from the GLWidget approach to this, the throwing functionality of the TrackballManipulator disappeared. This is also visible in the osgViewerQt example - spinning a model works for the GLAdapterWidget, but not for the QOSGWidget. (Oh, and the example hangs when pressing ESC.) Could you specify the command line you are using to reproduce these problems? Also, I have problems manually adding/removing views from a composite viewer. Adding/removing works fine until I remove the last view and try to add a view to an empty composite viewer. The viewer just shows garbage from the last view visible before it was removed and wont update with any new views added. I will try and reproduce this in the composite viewer example. If the window doesn't have any camera's active on it then there is nothing to clear the window, if one enable the clear on the window this issue may well disappear. As for adding views back after they've all been removed should work, but I haven't tested this combination personally. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi all, Here everything build fines under WinXP, VS8 SP1. But I have a little question, when I call : osviewer.exe --window 100 100 800 600 cow.osg Then I try to display the stats, nothing appears before several hits on the s button, and I just see some parts of the stats, is it normal ? On Mon, Feb 2, 2009 at 5:03 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hi Robert, In tests with my app I found some curious behaviour with the QOSGWidget (non-GraphicsWindowEmbedded) implementation. Since moving from the GLWidget approach to this, the throwing functionality of the TrackballManipulator disappeared. This is also visible in the osgViewerQt example - spinning a model works for the GLAdapterWidget, but not for the QOSGWidget. (Oh, and the example hangs when pressing ESC.) Could you specify the command line you are using to reproduce these problems? osgviewerQT --QOSGWidget cow.osg Also, I have problems manually adding/removing views from a composite viewer. Adding/removing works fine until I remove the last view and try to add a view to an empty composite viewer. The viewer just shows garbage from the last view visible before it was removed and wont update with any new views added. I will try and reproduce this in the composite viewer example. If the window doesn't have any camera's active on it then there is nothing to clear the window, if one enable the clear on the window this issue may well disappear. As for adding views back after they've all been removed should work, but I haven't tested this combination personally. Yup, I have the clearmask enabled for the viewer and it works fine as long as at least one view is still present. But as soon as the last camera is removed, the entire viewer stops working, even if adding new views afterwards. I am trying to reproduce that now in a small example, will send it in a bit. Cheers, Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 17:20 +0100, Sukender wrote: Hi Jeremy, hi Robert, Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... I have two machines: a laptop (Dell M90 with Core2Duo 1.6Ghz) and a desktop (QuadCore 2.6Ghz). It takes about 20 minutes to build from scratch on my laptop (no including the introspection stuff) and about 5 minutes on my desktop. The laptop runs Fedora 10 and the desktop Vista 64. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 16:56:06 +0100, Jeremy Moles jer...@emperorlinux.com a écrit: On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Jeremy, Could you please capture the warnings you are getting now. They are almost certainly be the same set as the original warnings you sent as I have fixed hundreds and hundreds and hundreds of warnings, having spent well over a week of my life dedicated to just aggressive warnings level. Please also could specify the compiler options as well - are they different from the standard options used by the OSG? (I only see warnings with 3rd party libs that we can do no thing about on my builds). Robert. On Mon, Feb 2, 2009 at 3:56 PM, Jeremy Moles jer...@emperorlinux.com wrote: On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Sukender, Alright... Strange thing it took 40 minutes on my machine (which is faster than your laptop, and I had a few *.cpp already compiled). Or maybe you disable compiling wrappers, examples, applications, plugins or such (I do compile them all)? If you don't use the wrappers, disable those. That will likely cut your compile time in half if not more. The wrappers really take a long time to compile. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi J-S, Hem... I *do* use osgGA wrapper... And yes, I saw they cost much in compile time. :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 17:36:49 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Sukender, Alright... Strange thing it took 40 minutes on my machine (which is faster than your laptop, and I had a few *.cpp already compiled). Or maybe you disable compiling wrappers, examples, applications, plugins or such (I do compile them all)? If you don't use the wrappers, disable those. That will likely cut your compile time in half if not more. The wrappers really take a long time to compile. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 17:44 +0100, Sukender wrote: Hi J-S, Hem... I *do* use osgGA wrapper... And yes, I saw they cost much in compile time. :) Yeah, I don't compile the introspection stuff because it makes it take about 40 minutes here, too. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 17:36:49 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Sukender, Alright... Strange thing it took 40 minutes on my machine (which is faster than your laptop, and I had a few *.cpp already compiled). Or maybe you disable compiling wrappers, examples, applications, plugins or such (I do compile them all)? If you don't use the wrappers, disable those. That will likely cut your compile time in half if not more. The wrappers really take a long time to compile. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Serge, On Mon, Feb 2, 2009 at 4:32 PM, Robert Osfield robert.osfi...@gmail.com wrote: Ack... two steps forward, one step back... Looks like a bug fix for another stats rendering problem broke this particular combination. I see the problem under Linux as well so can chase it up personally. I've now improved the handling of the scaling the stats projection matrix, this ensures that the osgviewer cow.osg --window 100 100 800 500 works fine, as well as the usage case that was previously broken. This change is now checked into svn/trunk. Could you please test svn/trunk to see if this problem is solved at your end as well. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Thanks Robert, I'll only be able to test tomorrow morning but i'll let you know. On Mon, Feb 2, 2009 at 6:13 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Serge, On Mon, Feb 2, 2009 at 4:32 PM, Robert Osfield robert.osfi...@gmail.com wrote: Ack... two steps forward, one step back... Looks like a bug fix for another stats rendering problem broke this particular combination. I see the problem under Linux as well so can chase it up personally. I've now improved the handling of the scaling the stats projection matrix, this ensures that the osgviewer cow.osg --window 100 100 800 500 works fine, as well as the usage case that was previously broken. This change is now checked into svn/trunk. Could you please test svn/trunk to see if this problem is solved at your end as well. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 16:23 +, Robert Osfield wrote: Hi Jeremy, Could you please capture the warnings you are getting now. They are almost certainly be the same set as the original warnings you sent as I have fixed hundreds and hundreds and hundreds of warnings, having spent well over a week of my life dedicated to just aggressive warnings level. Please also could specify the compiler options as well - are they different from the standard options used by the OSG? (I only see warnings with 3rd party libs that we can do no thing about on my builds). The only MAJOR one I'm getting anymore is this: In copy constructor ‘osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)’: /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class ‘class osg::Object’ should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class ‘class osgGA::GUIEventHandler’ should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class ‘struct osg::Drawable::CullCallback’ should be explicitly initialized in the copy constructor I'm using GCC 4.3 building both my software (osgPango/osgCairo/osgWidget) and OSG itself using: -W -Wall -Wno-unused Speaking of Cairo, what did you ever decide to do about that? :) Robert. On Mon, Feb 2, 2009 at 3:56 PM, Jeremy Moles jer...@emperorlinux.com wrote: On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
HI Jeremy, On Mon, Feb 2, 2009 at 5:19 PM, Jeremy Moles jer...@emperorlinux.com wrote: The only MAJOR one I'm getting anymore is this: In copy constructor 'osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)': /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osg::Object' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osgGA::GUIEventHandler' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'struct osg::Drawable::CullCallback' should be explicitly initialized in the copy constructor I've just checked in a fix for this. Could you do an svn update and let me know what warnings remain. I'm using GCC 4.3 building both my software (osgPango/osgCairo/osgWidget) and OSG itself using: -W -Wall -Wno-unused Speaking of Cairo, what did you ever decide to do about that? :) For Cairo I've kept the implementations local in the svg and gecko plugins. Rather than go for an CarioImage subclass class, I opted to have a custom user data object that implements the Cario integration. This allows one to add and then remove the Cario support to any image - it needn't be one subclassed from a Cario base class. For 2.8 I've not rolled this Cario helper class out into osgWidget as it was a another little feature that could cause complication and necessitate wider platform testing/debugging. Once 2.8 is out we can look at the issue of exposing an Cario helper class out into osgWidget or other NodeKit. I still think it's probably be best to keep such a class entirely in the header. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 17:32 +, Robert Osfield wrote: HI Jeremy, On Mon, Feb 2, 2009 at 5:19 PM, Jeremy Moles jer...@emperorlinux.com wrote: The only MAJOR one I'm getting anymore is this: In copy constructor 'osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)': /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osg::Object' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osgGA::GUIEventHandler' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'struct osg::Drawable::CullCallback' should be explicitly initialized in the copy constructor I've just checked in a fix for this. Could you do an svn update and let me know what warnings remain. I'm using GCC 4.3 building both my software (osgPango/osgCairo/osgWidget) and OSG itself using: -W -Wall -Wno-unused Speaking of Cairo, what did you ever decide to do about that? :) For Cairo I've kept the implementations local in the svg and gecko plugins. Rather than go for an CarioImage subclass class, I opted to have a custom user data object that implements the Cario integration. This allows one to add and then remove the Cario support to any image - it needn't be one subclassed from a Cario base class. For 2.8 I've not rolled this Cario helper class out into osgWidget as it was a another little feature that could cause complication and necessitate wider platform testing/debugging. Once 2.8 is out we can look at the issue of exposing an Cario helper class out into osgWidget or other NodeKit. I still think it's probably be best to keep such a class entirely in the header. I agree entirely, and it would be nice to strike osgCairo off my list of software dependencies (especially for osgPango, which I'm making incredible progress on and which now works pleasantly well in Windows). Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: On Mon, Feb 2, 2009 at 3:01 PM, Robert Osfield robert.osfi...@gmail.com wrote: I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. OSX CMake/Make Intel builds. Kubuntu 8.10, 64 bit builds. Also Mandriva 2009, 32 bit builds OK and seems to work. BTW, OSG package in Mandriva is being updated right now, the packager is waiting for 2.8 to be out. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJhzG8n11XseNj94gRAlO1AKCK6zLxI6dhHb0/r9CyMOAiSHzZkQCeMxzJ BQ7h9Lag3KX0uFhmxT6wPOo= =UUVf -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Jeremy, On Mon, Feb 2, 2009 at 7:11 PM, Jeremy Moles jer...@emperorlinux.com wrote: The warning remains with the latest revision; osg::Object must also be initialized for this warning to go away. Why this is the case, I do not know. This class doesn't directly inherit from osg::Object, I added all the initializers that should be required. Could it be one of the parent classes need the explicit initializer? Could you look into this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Sukender (et. al) On Mon, Feb 2, 2009 at 4:20 PM, Sukender suky0...@free.fr wrote: Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... I've now gone through all the 50 warnings reported on Dashbord from your VS build, I have applied fixes for them all. Whether they are fixed or not... we I can't say till you or others do another build. I have checked my changes into svn/trunk. Since the at the end of Dashboard log there the line: The maximum number of reported warnings or errors has been reached!!! I suspect there are more warnings lurking, and even if I fix these 50, more will pop up in their place. How many we'll have to wait an see. Could everyone do another svn update on svn/trunk and build to see how things are now hanging. Posting your results on Dashboard helps me keep track of things. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All, Thanks for the all the testing, a few more bugs and warnings have been fleshed and should be now resolved, alas this has taken me pretty well all the day, so it's now too late for me to go create the OpenSceneGraph-2.8 today. What I'll do is leave svn/trunk to be tested over night and in morning if things look sane I'll go ahead and make the 2.8 branch and the 2.8.0-rc1 from this. Once 2.8.0-rc1 is done, it'll be time to even more build and runtime testing, and for those planning to help out with packaging to start creating packaging for the rc1. In the past we've required a couple rc's so we should expect the same, but your never know perhaps all the i's have been doted and we'll be able to make rc1 gold and then I can take the rest of week off :-) With the rc1 done I'll be starting to nag people for feedback on how their own projects are running against the rc1, testing against real apps is what will start shaking down the build and runtime fully. My aim is to the final get 2.8.0 tagged this week, and if possible packages up for the main platforms. Thanks for you assistance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, Once 2.8.0-rc1 is done, it'll be time to even more build and runtime testing, and for those planning to help out with packaging to start creating packaging for the rc1. Sooo... What are you planning as an upload area for packages? :-) You said we'd put them into SVN, but do you plan to give all of us commit access to a given area of the SVN? Perhaps an FTP would be easier, we could just upload and people would download and then once we've confirmed the packages are good you can commit the packages to SVN... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, Second experimental build launched. (SUKENDER1 2009-02-02 on the dashboard, rev 9631, VC8sp1, all inclusive). Maybe you'll have the result before going to sleep (= To all: this is a joke... Robert NEVER sleeps! :D Even kill_and_go_to_bed -9 can't get rid of him!!!) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 21:36:03 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender (et. al) On Mon, Feb 2, 2009 at 4:20 PM, Sukender suky0...@free.fr wrote: Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... I've now gone through all the 50 warnings reported on Dashbord from your VS build, I have applied fixes for them all. Whether they are fixed or not... we I can't say till you or others do another build. I have checked my changes into svn/trunk. Since the at the end of Dashboard log there the line: The maximum number of reported warnings or errors has been reached!!! I suspect there are more warnings lurking, and even if I fix these 50, more will pop up in their place. How many we'll have to wait an see. Could everyone do another svn update on svn/trunk and build to see how things are now hanging. Posting your results on Dashboard helps me keep track of things. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
+1 :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 21:51:05 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Robert, Once 2.8.0-rc1 is done, it'll be time to even more build and runtime testing, and for those planning to help out with packaging to start creating packaging for the rc1. Sooo... What are you planning as an upload area for packages? :-) You said we'd put them into SVN, but do you plan to give all of us commit access to a given area of the SVN? Perhaps an FTP would be easier, we could just upload and people would download and then once we've confirmed the packages are good you can commit the packages to SVN... J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Robert Osfield wrote: I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. On Linux the new TF1D seems to work fine indeed (and the setColor() and friends API seems to make more sense). Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Quick note: build is done, but most warnings are wrappers-related (and seem harmless). Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 21:54:34 +0100, Sukender suky0...@free.fr a écrit: Hi Robert, Second experimental build launched. (SUKENDER1 2009-02-02 on the dashboard, rev 9631, VC8sp1, all inclusive). Maybe you'll have the result before going to sleep (= To all: this is a joke... Robert NEVER sleeps! :D Even kill_and_go_to_bed -9 can't get rid of him!!!) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 21:36:03 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender (et. al) On Mon, Feb 2, 2009 at 4:20 PM, Sukender suky0...@free.fr wrote: Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... I've now gone through all the 50 warnings reported on Dashbord from your VS build, I have applied fixes for them all. Whether they are fixed or not... we I can't say till you or others do another build. I have checked my changes into svn/trunk. Since the at the end of Dashboard log there the line: The maximum number of reported warnings or errors has been reached!!! I suspect there are more warnings lurking, and even if I fix these 50, more will pop up in their place. How many we'll have to wait an see. Could everyone do another svn update on svn/trunk and build to see how things are now hanging. Posting your results on Dashboard helps me keep track of things. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Serge, On Mon, Feb 2, 2009 at 4:21 PM, Serge Lages serge.la...@gmail.com wrote: Here is a screenshot fo my bug. Ack... two steps forward, one step back... Looks like a bug fix for another stats rendering problem broke this particular combination. I see the problem under Linux as well so can chase it up personally. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Alright... Strange thing it took 40 minutes on my machine (which is faster than your laptop, and I had a few *.cpp already compiled). Or maybe you disable compiling wrappers, examples, applications, plugins or such (I do compile them all)? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 17:25:22 +0100, Jeremy Moles jer...@emperorlinux.com a écrit: On Mon, 2009-02-02 at 17:20 +0100, Sukender wrote: Hi Jeremy, hi Robert, Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... I have two machines: a laptop (Dell M90 with Core2Duo 1.6Ghz) and a desktop (QuadCore 2.6Ghz). It takes about 20 minutes to build from scratch on my laptop (no including the introspection stuff) and about 5 minutes on my desktop. The laptop runs Fedora 10 and the desktop Vista 64. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 16:56:06 +0100, Jeremy Moles jer...@emperorlinux.com a écrit: On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 17:32 +, Robert Osfield wrote: HI Jeremy, On Mon, Feb 2, 2009 at 5:19 PM, Jeremy Moles jer...@emperorlinux.com wrote: The only MAJOR one I'm getting anymore is this: In copy constructor 'osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)': /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osg::Object' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osgGA::GUIEventHandler' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'struct osg::Drawable::CullCallback' should be explicitly initialized in the copy constructor I've just checked in a fix for this. Could you do an svn update and let me know what warnings remain. The warning remains with the latest revision; osg::Object must also be initialized for this warning to go away. Why this is the case, I do not know. I'm using GCC 4.3 building both my software (osgPango/osgCairo/osgWidget) and OSG itself using: -W -Wall -Wno-unused Speaking of Cairo, what did you ever decide to do about that? :) For Cairo I've kept the implementations local in the svg and gecko plugins. Rather than go for an CarioImage subclass class, I opted to have a custom user data object that implements the Cario integration. This allows one to add and then remove the Cario support to any image - it needn't be one subclassed from a Cario base class. For 2.8 I've not rolled this Cario helper class out into osgWidget as it was a another little feature that could cause complication and necessitate wider platform testing/debugging. Once 2.8 is out we can look at the issue of exposing an Cario helper class out into osgWidget or other NodeKit. I still think it's probably be best to keep such a class entirely in the header. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, In tests with my app I found some curious behaviour with the QOSGWidget (non-GraphicsWindowEmbedded) implementation. Since moving from the GLWidget approach to this, the throwing functionality of the TrackballManipulator disappeared. This is also visible in the osgViewerQt example - spinning a model works for the GLAdapterWidget, but not for the QOSGWidget. (Oh, and the example hangs when pressing ESC.) Could you specify the command line you are using to reproduce these problems? osgviewerQT --QOSGWidget cow.osg Also, I have problems manually adding/removing views from a composite viewer. Adding/removing works fine until I remove the last view and try to add a view to an empty composite viewer. The viewer just shows garbage from the last view visible before it was removed and wont update with any new views added. I will try and reproduce this in the composite viewer example. If the window doesn't have any camera's active on it then there is nothing to clear the window, if one enable the clear on the window this issue may well disappear. As for adding views back after they've all been removed should work, but I haven't tested this combination personally. Yup, I have the clearmask enabled for the viewer and it works fine as long as at least one view is still present. But as soon as the last camera is removed, the entire viewer stops working, even if adding new views afterwards. I am trying to reproduce that now in a small example, will send it in a bit. Cheers, Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, I successfully built the current trunk on Windows, VS8. Attached are more warnings if you are interested (about 71), they look to be mostly benign. In tests with my app I found some curious behaviour with the QOSGWidget (non-GraphicsWindowEmbedded) implementation. Since moving from the GLWidget approach to this, the throwing functionality of the TrackballManipulator disappeared. This is also visible in the osgViewerQt example - spinning a model works for the GLAdapterWidget, but not for the QOSGWidget. (Oh, and the example hangs when pressing ESC.) Also, I have problems manually adding/removing views from a composite viewer. Adding/removing works fine until I remove the last view and try to add a view to an empty composite viewer. The viewer just shows garbage from the last view visible before it was removed and wont update with any new views added. I will try and reproduce this in the composite viewer example. Cheers, Morne On Mon, Feb 2, 2009 at 3:01 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Warning 1 warning C4239: nonstandard extension used : 'static_cast' : conversion from 'volatile const long' to 'volatile const unsigned int ' c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\OpenThreads\common\Atomic.cpp 133 Warning 2 warning C4189: 'pd' : local variable is initialized but not referenced c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\OpenThreads\win32\Win32Thread.cpp 139 Warning 3 warning C4512: 'TransformVisitor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osg\Transform.cpp 89 Warning 4 warning C4512: 'DrawShapeVisitor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osg\ShapeDrawable.cpp 67 Warning 5 warning C4512: 'ComputeBoundShapeVisitor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osg\ShapeDrawable.cpp 1058 Warning 6 warning C4512: 'PrimitiveShapeVisitor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osg\ShapeDrawable.cpp 1328 Warning 7 warning C4701: potentially uninitialized local variable 'p' used c:\p\testlibs\osg\openscenegraph-svn\src\osg\matrixdecomposition.cpp506 Warning 8 warning C4245: '=' : conversion from 'int' to 'unsigned int', signed/unsigned mismatch c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgAnimation\Timeline.cpp 30 Warning 9 warning C4245: '=' : conversion from 'int' to 'unsigned int', signed/unsigned mismatch c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgAnimation\Timeline.cpp 45 Warning 10 warning C4512: 'WriteValue' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgUtil\TriStripVisitor.cpp49 Warning 11 warning C4512: 'RemapArray' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgUtil\TriStripVisitor.cpp166 Warning 12 warning C4510: 'std::_List_nod_Ty,_Alloc::_Node' : default constructor could not be generated C:\Program Files\Microsoft Visual Studio 8\VC\include\list 42 Warning 13 warning C4610: struct 'std::_List_nod_Ty,_Alloc::_Node' can never be instantiated - user defined constructor required C:\Program Files\Microsoft Visual Studio 8\VC\include\list 42 Warning 14 warning C4510: 'std::_List_nod_Ty,_Alloc::_Node' : default constructor could not be generated C:\Program Files\Microsoft Visual Studio 8\VC\include\list 42 Warning 15 warning C4610: struct 'std::_List_nod_Ty,_Alloc::_Node' can never be instantiated - user defined constructor required C:\Program
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Jeremy, hi Robert, Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 16:56:06 +0100, Jeremy Moles jer...@emperorlinux.com a écrit: On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Just for the record: I've had several segfaults in OSG's particle code (threading related) since I updated a few days ago. I'll post a backtrace when I run into it again. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
