opensg-core — List for people with CVS/SVN write access

Re: [Opensg-core] [Opensg-users] CVS tree (1.8)

[David K. <djk...@gm...>]

On Tue, Feb 22, 2011 at 1:44 PM, Michael Raab <mic...@gm...> wrote:

>  Hi all,
>
> we have up to now only worked with CVS and SVN. Does anyone of you work
> with GIT in a windows enviroment.
> Which tools do you use to manage GIT?
>

Hi Michael,

Welcome to using git. There is a learning curve; but, for me at least, it is
well worth it.  On windows I use the Git bash shell that comes with
the git<http://git-scm.com/>installer for windows.  This will install
a new menu to the right-click menu
that opens up a cygwin bash shell.  I would recommend this if you want a
consistent interface between using git on windows/linux/os x.  There is
also, TortoiseGIT <http://code.google.com/p/tortoisegit/>, which is becoming
more stable than a year ago.  It provides a completely GUI driven interface
to all git commands.

Cheer,
David K.

>
> Thanks,
> Michael
>
>
> Am 22.02.2011 19:10, schrieb Dirk Reiners:
>
>
>     Hi All,
>
> On 02/22/2011 08:55 AM, Michael Raab wrote:
>
> Hi,
>
> two questions on that issue:
>
> 1.) What is planned to be final solution for the 1.8 repository? SVN?
> 2.) Is there an estimate when this solution could be ready?
>
>
> Given that SF supports a lot more VCSs and in general seems to be much more
> active now there is very little reason to run our own server for this. Now
> the question is what to use. A bunch of people on the project use (and
> apparently like) git, mostly using github for their work, so git is probably
> the preferred system. SF would serve as the master/stable repository, work
> repos would be on github.
>
> So here's my proposal:
>
> - Migrate SF CVS to SF GIT as a OpenSG_1 repository. I have a
> cvs2git.options file attached that I tried and the results seem ok to me. I
> would need input from anybody that has committed to OpenSG 1 if they're ok
> with putting their name/email (and which one) into this. I extracted the
> following list from CVS:
>
>     'aegis' : 'Chad Austin <no...@em...> <no...@em...>',
>     'allenb' : 'Allen Bierbaum <no...@em...> <no...@em...>',
>     'a-m-z' : 'Andreas Zieringer <no...@em...> <no...@em...>',
>     'dirk' : 'Dirk Reiners <di...@us...><di...@us...>',
>
>     'dkabala' : 'David Kabala <no...@em...> <no...@em...>',
>     'edhellon' : 'Akos Balazs <no...@em...> <no...@em...>',
>     'eschler' : 'Peter Eschler <no...@em...> <no...@em...>',
>     'eysquared' : 'Unknown <no...@em...> <no...@em...>',
>     'istoynov' : 'Ivan Stoynov <no...@em...> <no...@em...>',
>     'jbehr' : 'Johannes Behr <no...@em...> <no...@em...>',
>     'macnihilist' : 'Karsten Schwenk <no...@em...> <no...@em...>',
>     'malexa' : 'Marc Alexa <no...@em...> <no...@em...>',
>     'mroth' : 'Marcus Roth <no...@em...> <no...@em...>',
>     'neumannc' : 'Carsten Neumann <no...@em...> <no...@em...>',
>     'oliverabert' : 'Oliver Abert <no...@em...> <no...@em...>',
>     'pdaehne' : 'Patrick Daehne <no...@em...> <no...@em...>',
>     'priessigd' : 'Patrick Riess <no...@em...> <no...@em...>',
>     'sawebel' : 'Sabine Webel <no...@em...> <no...@em...>',
>     'tbeer' : 'Thomas Beer <no...@em...> <no...@em...>',
>     'trembilski' : 'Andrzej Trembilski <no...@em...> <no...@em...>',
>     'vossg' : 'Gerrit Voss <no...@em...> <no...@em...>',
>     'yjung' : 'Yvonne Jung <no...@em...> <no...@em...>',
>
> If you are on this list and want to have an email in the conversion, please
> let me know privately. If you don't want your name in here please let me
> know, too, and I will use the CVS Unix name.
>
> - Migrate the OpenSG.org SVN to SF GIT as OpenSG_2 repository. I know
> Gerrit has a live link between his git and svn, so that should be easy to
> do.
>
> - Turn off SVN and CVS on SF, and the SVN on opensg.org, make SF GIT the
> official repo.
>
>
> Comments?
>
>     Dirk
>
>
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
>
>
> _______________________________________________
> Opensg-core mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/opensg-core
>
>
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Opensg-core mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-core
>
>

Re: [Opensg-core] [Opensg-users] CVS tree (1.8)

[Michael R. <mic...@gm...>]

Hi all,

we have up to now only worked with CVS and SVN. Does anyone of you work 
with GIT in a windows enviroment.
Which tools do you use to manage GIT?

Thanks,
Michael


Am 22.02.2011 19:10, schrieb Dirk Reiners:
>
>     Hi All,
>
> On 02/22/2011 08:55 AM, Michael Raab wrote:
>> Hi,
>>
>> two questions on that issue:
>>
>> 1.) What is planned to be final solution for the 1.8 repository? SVN?
>> 2.) Is there an estimate when this solution could be ready?
>
> Given that SF supports a lot more VCSs and in general seems to be much 
> more active now there is very little reason to run our own server for 
> this. Now the question is what to use. A bunch of people on the 
> project use (and apparently like) git, mostly using github for their 
> work, so git is probably the preferred system. SF would serve as the 
> master/stable repository, work repos would be on github.
>
> So here's my proposal:
>
> - Migrate SF CVS to SF GIT as a OpenSG_1 repository. I have a 
> cvs2git.options file attached that I tried and the results seem ok to 
> me. I would need input from anybody that has committed to OpenSG 1 if 
> they're ok with putting their name/email (and which one) into this. I 
> extracted the following list from CVS:
>
>     'aegis' : 'Chad Austin <no...@em...>',
>     'allenb' : 'Allen Bierbaum <no...@em...>',
>     'a-m-z' : 'Andreas Zieringer <no...@em...>',
>     'dirk' : 'Dirk Reiners <di...@us...>',
>     'dkabala' : 'David Kabala <no...@em...>',
>     'edhellon' : 'Akos Balazs <no...@em...>',
>     'eschler' : 'Peter Eschler <no...@em...>',
>     'eysquared' : 'Unknown <no...@em...>',
>     'istoynov' : 'Ivan Stoynov <no...@em...>',
>     'jbehr' : 'Johannes Behr <no...@em...>',
>     'macnihilist' : 'Karsten Schwenk <no...@em...>',
>     'malexa' : 'Marc Alexa <no...@em...>',
>     'mroth' : 'Marcus Roth <no...@em...>',
>     'neumannc' : 'Carsten Neumann <no...@em...>',
>     'oliverabert' : 'Oliver Abert <no...@em...>',
>     'pdaehne' : 'Patrick Daehne <no...@em...>',
>     'priessigd' : 'Patrick Riess <no...@em...>',
>     'sawebel' : 'Sabine Webel <no...@em...>',
>     'tbeer' : 'Thomas Beer <no...@em...>',
>     'trembilski' : 'Andrzej Trembilski <no...@em...>',
>     'vossg' : 'Gerrit Voss <no...@em...>',
>     'yjung' : 'Yvonne Jung <no...@em...>',
>
> If you are on this list and want to have an email in the conversion, 
> please let me know privately. If you don't want your name in here 
> please let me know, too, and I will use the CVS Unix name.
>
> - Migrate the OpenSG.org SVN to SF GIT as OpenSG_2 repository. I know 
> Gerrit has a live link between his git and svn, so that should be easy 
> to do.
>
> - Turn off SVN and CVS on SF, and the SVN on opensg.org, make SF GIT 
> the official repo.
>
>
> Comments?
>
>     Dirk
>
>
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
>
>
> _______________________________________________
> Opensg-core mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-core

Re: [Opensg-core] [Opensg-users] CVS tree (1.8)

[Dirk R. <dir...@gm...>]

	Hi All,

On 02/22/2011 08:55 AM, Michael Raab wrote:
> Hi,
>
> two questions on that issue:
>
> 1.) What is planned to be final solution for the 1.8 repository? SVN?
> 2.) Is there an estimate when this solution could be ready?

Given that SF supports a lot more VCSs and in general seems to be much more 
active now there is very little reason to run our own server for this. Now the 
question is what to use. A bunch of people on the project use (and apparently 
like) git, mostly using github for their work, so git is probably the preferred 
system. SF would serve as the master/stable repository, work repos would be on 
github.

So here's my proposal:

- Migrate SF CVS to SF GIT as a OpenSG_1 repository. I have a cvs2git.options 
file attached that I tried and the results seem ok to me. I would need input 
from anybody that has committed to OpenSG 1 if they're ok with putting their 
name/email (and which one) into this. I extracted the following list from CVS:

     'aegis' : 'Chad Austin <no...@em...>',
     'allenb' : 'Allen Bierbaum <no...@em...>',
     'a-m-z' : 'Andreas Zieringer <no...@em...>',
     'dirk' : 'Dirk Reiners <di...@us...>',
     'dkabala' : 'David Kabala <no...@em...>',
     'edhellon' : 'Akos Balazs <no...@em...>',
     'eschler' : 'Peter Eschler <no...@em...>',
     'eysquared' : 'Unknown <no...@em...>',
     'istoynov' : 'Ivan Stoynov <no...@em...>',
     'jbehr' : 'Johannes Behr <no...@em...>',
     'macnihilist' : 'Karsten Schwenk <no...@em...>',
     'malexa' : 'Marc Alexa <no...@em...>',
     'mroth' : 'Marcus Roth <no...@em...>',
     'neumannc' : 'Carsten Neumann <no...@em...>',
     'oliverabert' : 'Oliver Abert <no...@em...>',
     'pdaehne' : 'Patrick Daehne <no...@em...>',
     'priessigd' : 'Patrick Riess <no...@em...>',
     'sawebel' : 'Sabine Webel <no...@em...>',
     'tbeer' : 'Thomas Beer <no...@em...>',
     'trembilski' : 'Andrzej Trembilski <no...@em...>',
     'vossg' : 'Gerrit Voss <no...@em...>',
     'yjung' : 'Yvonne Jung <no...@em...>',

If you are on this list and want to have an email in the conversion, please let 
me know privately. If you don't want your name in here please let me know, too, 
and I will use the CVS Unix name.

- Migrate the OpenSG.org SVN to SF GIT as OpenSG_2 repository. I know Gerrit has 
a live link between his git and svn, so that should be easy to do.

- Turn off SVN and CVS on SF, and the SVN on opensg.org, make SF GIT the 
official repo.


Comments?

	Dirk

Re: [Opensg-core] CVS tree (1.8)

[Johannes B. <joh...@ig...>]

Hi,

what is the long-term solution?
Where can we commit fixes to 1.8?

regards
johannes

> 
> Hi,
> 
> I temporarily provide the 1.8 cvs tree under
> 
> https://vo...@gi.../vossg/OpenSGCVSTree.git
> git://github.com/vossg/OpenSGCVSTree.git
> 
> 
> until we can sort out the migration.
> 
> The last commit I have is following:
> 
> From: 	Patrick D?hne <pd...@us...>
> To: 	ope...@li...
> Subject: 	[Opensg-commits] OpenSG/Source/Base/Base OSGGL.h,1.12,1.13
> Date: 	25/01/11 21:38:15
> 
> Modified Files:
>        OSGGL.h 
> Log Message:
> Fixed compile problem on Windows
> 
> 
> Please send me your git commits if you need to apply changes.
> Carsten can write to.
> 
> kind regards
>  gerrit
> 
> 

--
Dr. Johannes Behr
Abteilungsleiter Visual Computing System Technologies
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-510  |  Fax +49 6151 155-196
joh...@ig...  |  www.igd.fraunhofer.de

Re: [Opensg-core] [Opensg-users] CVS tree (1.8)

[Michael R. <Rok...@gm...>]

Hi,

two questions on that issue:

1.) What is planned to be final solution for the 1.8 repository? SVN?
2.) Is there an estimate when this solution could be ready?

Best regards,
Michael

-------- Original-Nachricht --------
> Datum: Sat, 12 Feb 2011 08:41:01 +0800
> Von: "Gerrit Voß" <vo...@vo...>
> An: ope...@li...
> CC: ope...@li...
> Betreff: Re: [Opensg-core] [Opensg-users]   CVS tree (1.8)

> 
> Hi,
> 
> 
> On Fri, 2011-02-11 at 16:41 +0100, Timm Drevensek wrote:
> > Hi,
> > 
> > will this be the final destination or will you move the official 1.8
> repository around?
> 
> no, as said, the github one is a temporary solution, but it should be
> the second last.
> 
> kind regards
>   gerrit
> 
> 
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Opensg-core mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-core

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: [Opensg-core] OpenSG 2 python bindings

[Gerrit V. <vo...@vo...>]

Hi,

some updates :)

On Wed, 2011-02-09 at 18:26 +0800, Gerrit Voß wrote:
> Hi,
> 
> > > 
> > > There is some manual post-processing that has to be done after running gen_bindings.py. I think there are three cases where Py++ generates code contrary to what it is supposed to do. The other case has to do with 
> > > Py++ not currently understanding that OSG::GLUTWindowBase and OSG::PassiveWindowBase 
> > > have OSG::Window as a base class. I haven't figured out the cause for that problem.

> > ok, I'm not that far yet, 

ok, that comes from the fact that these derive from NativeWindow
(typedef to the platform dependent os window) and not from Window
directly any more. 

Looking at pyplusplus I don't see good/easy way to convince pyplusplus
to write out that typedef instead of the os window, but I haven't looked
to hard. I changed the gen code so that it patches the corresponding
files after generating the code and included the os windows (at least
win32 and x) into the generation process.

Something like:

for nativeWinDep in ["GLUTWindow", "PassiveWindow"]:

  nativeWinDepIn      = pj(output_dir, "generated", nativeWinDep +
"Base.pypp.cpp")

  _inFileContent      = open(nativeWinDepIn, "r").read();

  _inFileContent      = _inFileContent.replace("XWindow","NativeWindow")

  open(nativeWinDepIn, "w").write(_inFileContent)




I found that one can get rid of the 

ContainerMixinHeadStageDrawableDesc.pypp.cpp (should not expose
createAspectCopy())

problem modifying the pure virtual members of FieldContainer immediately
after the ModuleBuilder is created and before anything else:

  # take the pure virtual functions out immediately otherwise they show
  # up in random places.
  cls = osg["FieldContainer"]

  for pvf in ["createAspectCopy", "shallowCopy", 
              "shallowCopyDependent", "shallowCopyLocal",
              "execSyncV"]:
    cls[pvf].ignore = True
    cls[pvf].set_virtuality(pd.VIRTUALITY_TYPES.NOT_VIRTUAL)

   # ------------ Helper methods and data -------------------- #
   
   # Map from template alias name to real decl wrapper type
   print "Building template alias map..."
   template_alias_db = {}
   osg_typedef_db    = {}


The Color3f.pypp.cpp problem I haven't seen yet.


In general I managed to integrate things into the cmake build process.
The biggest change was to build an individual wrapping lib for each
OpenSG lib. For that I had to split gen_bindings.py into the structural
part and the lib dependent parts.

So far it seems to work (except that container.dump() throws an
exception on Windows).

Currently only the generation part is within the main repository, the
created bindings live in the AddOns tree.

kind regards
  gerrit

Re: [Opensg-core] [Opensg-users] CVS tree (1.8)

[Gerrit V. <vo...@vo...>]

Hi,


On Fri, 2011-02-11 at 16:41 +0100, Timm Drevensek wrote:
> Hi,
> 
> will this be the final destination or will you move the official 1.8 repository around?

no, as said, the github one is a temporary solution, but it should be
the second last.

kind regards
  gerrit

Re: [Opensg-core] CVS tree (1.8)

[Carsten N. <car...@gm...>]

	Hi Gerrit,

On 02/10/2011 11:06 PM, Gerrit Voß wrote:
> Please send me your git commits if you need to apply changes.
> Carsten can write to.

please see attached. Just a few small things and the 
PolygonForeground/MultiPassMaterial fix (haven't found the problem with 
the MaterialChunk wireframe pass Michael reported yet).

	Cheers,
		Carsten

Re: [Opensg-core] [Opensg-users] CVS tree (1.8)

[Timm D. <Tim...@ig...>]

Hi,

will this be the final destination or will you move the official 1.8 repository around?
Background is, that I don't want to touch our build scripts over and over again :)

Greetings
Timm

> -----Original Message-----
> From: Gerrit Voß [mailto:vo...@vo...]
> Sent: Freitag, 11. Februar 2011 07:21
> To: ope...@li...
> Cc: OpenSG Core
> Subject: Re: [Opensg-core] [Opensg-users] CVS tree (1.8)
> 
> 
> Hi,
> 
> On Fri, 2011-02-11 at 13:06 +0800, Gerrit Voß wrote:
> > Hi,
> >
> > I temporarily provide the 1.8 cvs tree under
> >
> > https://vo...@gi.../vossg/OpenSGCVSTree.git
> 
> arrg, that should have been
> 
> https://github.com/vossg/OpenSGCVSTree.git
> 
> of course, without the login.
> 
> kind regards
>   gerrit
> 
> 
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Opensg-core mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-core

Re: [Opensg-core] [Opensg-users] CVS tree (1.8)

[Gerrit V. <vo...@vo...>]

Hi,

On Fri, 2011-02-11 at 13:06 +0800, Gerrit Voß wrote:
> Hi,
> 
> I temporarily provide the 1.8 cvs tree under
> 
> https://vo...@gi.../vossg/OpenSGCVSTree.git

arrg, that should have been

https://github.com/vossg/OpenSGCVSTree.git

of course, without the login.

kind regards
  gerrit

[Opensg-core] CVS tree (1.8)

[Gerrit V. <vo...@vo...>]

Hi,

I temporarily provide the 1.8 cvs tree under

https://vo...@gi.../vossg/OpenSGCVSTree.git
git://github.com/vossg/OpenSGCVSTree.git


until we can sort out the migration.

The last commit I have is following:

From: 	Patrick D?hne <pd...@us...>
To: 	ope...@li...
Subject: 	[Opensg-commits] OpenSG/Source/Base/Base OSGGL.h,1.12,1.13
Date: 	25/01/11 21:38:15

Modified Files:
        OSGGL.h 
Log Message:
Fixed compile problem on Windows


Please send me your git commits if you need to apply changes.
Carsten can write to.

kind regards
  gerrit

Re: [Opensg-core] OpenSG 2 python bindings

[Gerrit V. <vo...@vo...>]

Hi,

On Wed, 2011-02-09 at 17:50 +0800, Gerrit Voß wrote:
> Hi,
> 
> On Tue, 2011-02-01 at 09:50 -0600, Patrick Hartling wrote:
> > On Feb 1, 2011, at 1:09 AM, Gerrit Voß wrote:
> > 
> > > 
> > > Something else I would like to integrate the python bindings back into
> > > the cmake system. 
> > > 
> > > Currently I plan to have them live of a pyopensg checkout and pull
> > > things during the cmake run as needed (as we do with the support stuff).
> > > I don't want to have a diverging duplicate of the original pyopensg
> > > project.
> > > 
> > > The only part where this seems to break (from early tests) seem to be
> > > the gen_bindings.py script. So there I would have to have some kind of
> > > duplication of which I have figure out how to keep it in sync with the
> > > main pyopensg developments.
> > 
> > There is some manual post-processing that has to be done after running gen_bindings.py. I think there are three cases where Py++ generates code contrary to what it is supposed to do. The other case has to do with 
> > Py++ not currently understanding that OSG::GLUTWindowBase and OSG::PassiveWindowBase 
> > have OSG::Window as a base class. I haven't figured out the cause for that problem.
> 
> ok, I'm not that far yet, my biggest issue so far are the pure virtual
> function from FieldContainer, for example createAspectCopy or the
> shallowCopy variants. They seem to get thrown into a wrapper rather
> randomly. Right now I find them in ShaderProcVariableBase
> 
> struct ShaderProcVariableBase_wrapper : OSG::ShaderProcVariableBase,
> bp::wrapper< OSG::ShaderProcVariableBase > {
> 
>     ::OSG::FieldContainer * createAspectCopy( ::OSG::FieldContainer
> const * arg0 ) const {
>         return
> OSG::FieldContainer::createAspectCopy( boost::python::ptr(arg0) );
>     }
> 
> };
> 
> Looking at ShaderValueVariableBase, which has the same structure
> (abstract intermediate class, derived from ShaderVariable) I don't
> find these included. 
> 
> Something is strange, I can't really point to a difference in these
> classes. Any hint what might cause this is really welcome.

arrg, few more minutes thinking, it seems to be an order problem. If
I take them out (ignore = true, 
set_virtuality(pd.VIRTUALITY_TYPES.NOT_VIRTUAL) immediately after 
creating the module_builder the problem is gone ;). 

kind regards
  gerrit

Re: [Opensg-core] OpenSG 2 python bindings

[Gerrit V. <vo...@vo...>]

Hi,

On Tue, 2011-02-01 at 09:50 -0600, Patrick Hartling wrote:
> On Feb 1, 2011, at 1:09 AM, Gerrit Voß wrote:
> 
> > 
> > Something else I would like to integrate the python bindings back into
> > the cmake system. 
> > 
> > Currently I plan to have them live of a pyopensg checkout and pull
> > things during the cmake run as needed (as we do with the support stuff).
> > I don't want to have a diverging duplicate of the original pyopensg
> > project.
> > 
> > The only part where this seems to break (from early tests) seem to be
> > the gen_bindings.py script. So there I would have to have some kind of
> > duplication of which I have figure out how to keep it in sync with the
> > main pyopensg developments.
> 
> There is some manual post-processing that has to be done after running gen_bindings.py. I think there are three cases where Py++ generates code contrary to what it is supposed to do. The other case has to do with 
> Py++ not currently understanding that OSG::GLUTWindowBase and OSG::PassiveWindowBase 
> have OSG::Window as a base class. I haven't figured out the cause for that problem.

ok, I'm not that far yet, my biggest issue so far are the pure virtual
function from FieldContainer, for example createAspectCopy or the
shallowCopy variants. They seem to get thrown into a wrapper rather
randomly. Right now I find them in ShaderProcVariableBase

struct ShaderProcVariableBase_wrapper : OSG::ShaderProcVariableBase,
bp::wrapper< OSG::ShaderProcVariableBase > {

    ::OSG::FieldContainer * createAspectCopy( ::OSG::FieldContainer
const * arg0 ) const {
        return
OSG::FieldContainer::createAspectCopy( boost::python::ptr(arg0) );
    }

};

Looking at ShaderValueVariableBase, which has the same structure
(abstract intermediate class, derived from ShaderVariable) I don't
find these included. 

Something is strange, I can't really point to a difference in these
classes. Any hint what might cause this is really welcome.

kind regards
  gerrit

Re: [Opensg-core] OpenSG 2 python bindings

[Patrick H. <pa...@pr...>]

On Feb 1, 2011, at 1:09 AM, Gerrit Voß wrote:

> 
> Hi,
> 
> On Tue, 2011-01-11 at 08:37 -0600, Patrick Hartling wrote:
> 
>> 
>> 
>> As promised, here are the patches:
>> 
>> 
>>      * add-FogChunk-methods.patch: Adds missing method definitions to
>>        OSG::FogChunk to fix linker errors.
>>      * add-TreeBuilderBase-getNodePool.patch: Adds a missing method
>>        definition to OSG::TreeBuilderBase to fix a linker error.
>>      * fix-64bit.patch: Fixes a compiler error when targeting 64-bit
>>        architectures. I am not sure why this one bit only us. In
>>        retrospect, this change may have been to silence a compiler
>>        warning rather than to fix an error.
>>      * fix-Image-clearData.patch: Fixes the implementation of
>>        OSG::Image::clearData() to behave the way it was intended.
>>      * fix-build-errors.patch: For various instantiations of
>>        OSG::Point<V,S> and OSG::Vector<V,S>, compiler errors occurred
>>        without these changes. The second block is the critical part.
>>        As I recall, Visual C++ reported overload ambiguity errors
>>        because it could not deduce the type of multiplying a float by
>>        the result of OSG::Vector<V,S>::dot() for some V (OSG::Uint8
>>        maybe?). I have a standalone test program somewhere that
>>        demonstrates the issues if this one needs further
>>        clarification.
>>      * fix-build.patch: Fixes the build to ensure that the correct
>>        FreeType ft2build.h is used. (We have our own FreeType build
>>        that we use for OpenSG and other packages, so it is important
>>        that the OpenSG build pick up the correct headers.)
> 
> I have applied all of those patches.
> 
>>      * fix-gdal-include.patch: I haven't seen a GDAL installation
>>        where the GDAL headers are under a gdal subdirectory. The
>>        build should allow the path to the directories containing the
>>        GDAL headers to be specified, right?
> 
> hmm, for me it was the other way round coming from (redhat/fedora)
> background I haven't seen it without the gdal subdirectory. IIRC
> ubuntu also did not give me a problem. I'll check it again.

I was guessing that that was the case. When built from its source rather than installed via package management, the GDAL headers don't go into a gdal subdirectory. We could probably change our build process to use the --includedir configure argument on Linux and tweak the Windows Nmake build to put headers in %GDAL_HOME%\include\gdal instead. I don't really know the best answer to this.

> Something else I would like to integrate the python bindings back into
> the cmake system. 
> 
> Currently I plan to have them live of a pyopensg checkout and pull
> things during the cmake run as needed (as we do with the support stuff).
> I don't want to have a diverging duplicate of the original pyopensg
> project.
> 
> The only part where this seems to break (from early tests) seem to be
> the gen_bindings.py script. So there I would have to have some kind of
> duplication of which I have figure out how to keep it in sync with the
> main pyopensg developments.

There is some manual post-processing that has to be done after running gen_bindings.py. I think there are three cases where Py++ generates code contrary to what it is supposed to do. The other case has to do with Py++ not currently understanding that OSG::GLUTWindowBase and OSG::PassiveWindowBase have OSG::Window as a base class. I haven't figured out the cause for that problem.

> Before I push this out I just want to make sure this way is ok with the
> pyopensg crowd ;)

If that plan helps you, then that sounds fine to me. Is there anything that I can do to support that? I'm willing to switch the repository to Mercurial if that could help you make better use of PyOpenSG.

 -Patrick


--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

The information transmitted in this communication is intended only for
the person or entity to which it is addressed and contains proprietary
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please destroy any copies, contact the sender
and delete the material from any computer.

Re: [Opensg-core] OpenSG 2 python bindings

[Gerrit V. <vo...@vo...>]

Hi,

On Tue, 2011-01-11 at 08:37 -0600, Patrick Hartling wrote:

> 
> 
> As promised, here are the patches:
> 
> 
>       * add-FogChunk-methods.patch: Adds missing method definitions to
>         OSG::FogChunk to fix linker errors.
>       * add-TreeBuilderBase-getNodePool.patch: Adds a missing method
>         definition to OSG::TreeBuilderBase to fix a linker error.
>       * fix-64bit.patch: Fixes a compiler error when targeting 64-bit
>         architectures. I am not sure why this one bit only us. In
>         retrospect, this change may have been to silence a compiler
>         warning rather than to fix an error.
>       * fix-Image-clearData.patch: Fixes the implementation of
>         OSG::Image::clearData() to behave the way it was intended.
>       * fix-build-errors.patch: For various instantiations of
>         OSG::Point<V,S> and OSG::Vector<V,S>, compiler errors occurred
>         without these changes. The second block is the critical part.
>         As I recall, Visual C++ reported overload ambiguity errors
>         because it could not deduce the type of multiplying a float by
>         the result of OSG::Vector<V,S>::dot() for some V (OSG::Uint8
>         maybe?). I have a standalone test program somewhere that
>         demonstrates the issues if this one needs further
>         clarification.
>       * fix-build.patch: Fixes the build to ensure that the correct
>         FreeType ft2build.h is used. (We have our own FreeType build
>         that we use for OpenSG and other packages, so it is important
>         that the OpenSG build pick up the correct headers.)

I have applied all of those patches.

>       * fix-gdal-include.patch: I haven't seen a GDAL installation
>         where the GDAL headers are under a gdal subdirectory. The
>         build should allow the path to the directories containing the
>         GDAL headers to be specified, right?

hmm, for me it was the other way round coming from (redhat/fedora)
background I haven't seen it without the gdal subdirectory. IIRC
ubuntu also did not give me a problem. I'll check it again.

Something else I would like to integrate the python bindings back into
the cmake system. 

Currently I plan to have them live of a pyopensg checkout and pull
things during the cmake run as needed (as we do with the support stuff).
I don't want to have a diverging duplicate of the original pyopensg
project.

The only part where this seems to break (from early tests) seem to be
the gen_bindings.py script. So there I would have to have some kind of
duplication of which I have figure out how to keep it in sync with the
main pyopensg developments.

Before I push this out I just want to make sure this way is ok with the
pyopensg crowd ;)

thanks & kind regards
  gerrit

Re: [Opensg-core] AttachmentContainer ref counting

[Carsten N. <car...@gm...>]

	Hello Gerrit,

On 08/22/2010 03:16 AM, Gerrit Voß wrote:
> On Thu, 2010-08-19 at 11:10 -0500, Carsten Neumann wrote:
>>> the server is in fact a VRJuggler program, that runs a separate thread
>>> to receive the CL and merges it to the juggler render thread in postFrame().
>>> Let me back out r2472 and the AttCon change locally and give you more
>>> details on what happens.

old thread, but his has come back to haunt me ;)
I've just reverted r2472, as with the other fixes I made to ref counting 
in AttachmentContainer, ChangeList and RemoteAspect it actually did 
hurt. Thinking about it, since the usual case for an AttachmentContainer 
is isMTLocal() == false that case should act like all other pointer 
fields and therefore use unrecorded ref counting - why wasn't that 
obvious to me 6 month ago? ;)

	Cheers,
		Carsten

Re: [Opensg-core] [Opensg-commits] r2533 - trunk/Source/Base/FieldContainer/Base

[Carsten N. <car...@gm...>]

	Hello Gerrit,

On 01/25/2011 08:24 PM, ope...@ex... wrote:
> Author: vossg
> Date: Tue Jan 25 20:24:09 2011
> New Revision: 2533
> Trac changeset: http://www.opensg.org/changeset/2533
>
> Modified:
>     trunk/Source/Base/FieldContainer/Base/OSGAttachment.h
> Log:
> fixed: readded removed documentation hierarchy info (please keep those)

sorry about that, I had fcd2code regenerate the non-base files too. How 
about the attached patch for the template file to prevent that in the 
future?

	Cheers,
		Carsten

Re: [Opensg-core] Separate library doxygen documentation

[Gerrit V. <vo...@vo...>]

Hi,

On Sun, 2011-01-23 at 09:23 +0800, Gerrit Voß wrote:
> Hi,
> 
> On Thu, 2011-01-20 at 19:47 -0600, David Kabala wrote:
> > It looks like there are some recent changes to the doc structure that
> > I haven't merged yet.  So this patch may not work.
> 
> no worries, it does. I'm just cleaning it a little and later today
> I will commit it.

ok, I committed the patch plus some changes. The main changes where
that the separate variant uses the same openg-doxy.in as the full
doc build so that we don't have to keep track of two different config
files. That means I've currently taken out the lib based additional
doxygen entries for the global settings. I have to see how to handle and
integrate external libs though, so this might come back. The other small
change was to add a OSG*DocOnly target which only builds the respective
lib docs.

I yet have to time things but doxygen seems to spend a lot of time
somewhere once it starts using tags. Building the doc for some of the
OSGWindow* libs took quite more time than expected (for the few files
per window lib, excluding the docs these depend on). Looking at the log
file timestamps it looks something like 40 minutes for OSGWindowX docs
and nearly and hour for OSGWindowGLUT. 

Anybody an idea what might be wrong ? Oh for doxygen 1.7.2 as I do not
really like the new 1.7.3 style, nav tree, and layout.


kind regards
  gerrit

Re: [Opensg-core] Separate library doxygen documentation

[Gerrit V. <vo...@vo...>]

Hi,

On Thu, 2011-01-20 at 19:47 -0600, David Kabala wrote:
> It looks like there are some recent changes to the doc structure that
> I haven't merged yet.  So this patch may not work.

no worries, it does. I'm just cleaning it a little and later today
I will commit it.

kind regards
  gerrit

Re: [Opensg-core] Separate library doxygen documentation

[David K. <djk...@gm...>]

It looks like there are some recent changes to the doc structure that I
haven't merged yet.  So this patch may not work.

On Thu, Jan 20, 2011 at 6:05 PM, David Kabala <djk...@gm...> wrote:

> I would like to submit a patch that adds support for separate doxygen
> documentation for each OpenSG library similar to the discussion here<http://www.opensg.org/wiki/Dev/Documentation>
> .
>
>  I added support for building separate doxygen documentation for each
> OpenSG library.  The separate documentation trees reference the
> documentation of dependent libraries.  New build targets are made for
> building the documentation of a library, e.g. to make the OSGDrawable
> library documentation use: make OSGDrawableDoc.  This will build the
> dependent library docs first.
>
> The new cmake option OSG_GENERATE_SEPARATE_LIB_DOC can be used to turn  the
> building of separate doxygen documentation on or off.  By default it is off.
>
> I also added cmake configuration for installing doxygen documentation. If
> the new cmake option OSG_INSTALL_DOXYDOC is on then the doxygen
> documentation will be installed to
> <INSTALL_PREFIX>/share/OpenSG/documentation. By default OSG_INSTALL_DOXYDOC
> is off.
>
> The following is a link to an example build of the documentation.  Note,
> this is a doc build from a fork of the OpenSG 2 repository with some of my
> own additions to the core OpenSG source.
> http://www.vrac.iastate.edu/~dkabala/OpenSGDocExample<http://www.vrac.iastate.edu/%7Edkabala/OpenSGDocExample>
>
> Findings: Preliminary testing indicates that separating the libraries does
> not decrease the time needed to build ALL of the library's documentation.
> However, building is faster on a per-library basis than when the build is
> not separated.  The real benefit is realized when only part of the
> documentation needs to be rebuilt, in that case only the documentation of
> the changed library needs to be built.  Also, given the size of some contrib
> libraries to OpenSG, mine in particular :), a single monolithic build takes
> a very long time, and can consume a large amount of memory.
>
> Future work: Currently there is no main html page that can be used to
> navigate between the separate documentation trees.  I would like to create a
> template html file that would have a tree gui component that linked to each
> of the libraries documentation trees.  This template html file would be
> filled with the correct structure and linking information during cmake
> configuration if the OSG_GENERATE_SEPARATE_LIB_DOC is on.  Suggestions on
> other strategies?
>
> I am willing to help with any bugs, deficiencies, changes that this
> contribution may have/need if you choose to add it.
>
> Thanks,
> David Kabala
>

Re: [Opensg-core] Some File I/O WIP - RFC

[Carsten N. <car...@gm...>]

	Hello Gerrit,

attached is the current state of things.

On 01/11/2011 01:33 AM, Gerrit Voß wrote:
> On Mon, 2011-01-10 at 10:52 -0600, Carsten Neumann wrote:
>> On 01/10/2011 10:25 AM, Gerrit Voß wrote:
>>> Similar can't we keep the return one container variant in the
>>> SFH/SFT for convenience. For both reading and writing, it is a nuisance
>>> to deal with the vector wrapper in case one is only interested in one
>>> container.
>>
>> ok, I'll add a single container version. Again the SFT base class can
>> implement it in terms of the multi container version, that way it is
>> enough to implement the multi container read/write functions for a
>> loader and get the others for free.
>
> in both cases it is more about the inconvenience of spreading these
> things all over the place. It seems easier to collect them at a central
> place.

I've tried to limit e.g. stream creation to as few places as seemed 
possible, it is effectively contained in SFH and SFT, not user code or 
the loader implementations.

>>> A general question, as you currently pass the SFH down as 'this',
>>> later on this has to involve some form of locking so the cloning does
>>> not happen while something else modifies the global SFH from which you
>>> clone ?

yes, but my current thinking is that it should be possible to only hold 
the lock when creating the FooFileType instances.

>>> Another one, as IIRC it was mentioned/half discussed some time ago that
>>> the general search path handling is kind of scattered, would it be a
>>> good time (read do we have the time) to revised (or at least remember)
>>> it in this context ?
>>
>> not sure what you mean with scattered? It seems to be mostly contained
>> in SFH::initPathHandler(). Can you refresh my memory what the problem was?
>
> I guess I somehow remembered pieces of the following two discussions /
> pages:
>
> http://www.opensg.org/wiki/Dev/FileIO
> http://www.opensg.org/wiki/Dev/PluginsPathes

hmm, this is a larger chunk than I can handle at the moment ;-(

>>>> - Do we want to keep the read/write callback in SFH? What are they good
>>>> for anyway, it looks as if they hijack the loading process?
>>>
>>> A better way would maybe be to provide a generic callback SFT which
>>> can easily be registered for the corresponding suffixes instead of
>>> pushing this to the SFH ?
>>
>> well, the funny thing is that the callbacks get passed the SFT as an
>> argument... - Is anybody using this? What's is/was the purpose?
>
> IIRC that came from Andreas, not sure about the usage might be some
> custom compression/encryption hooks.
>
>>>> - Do we want to keep the progress callbacks?
>>>
>>> hmm, are they actually working with useful numbers for all loaders ?
>>
>> sort of, I guess. It does check the stream position and compares with
>> the end position to determine progress, so it does not necessarily need
>> much support from the loader implementations IIUC.
>
> ah, ok, have to check this. Anyway I would assume the outside to take
> care that the usage of the progress callbacks is thread safe.

yes, in fact my original idea was that it is only possible to parallel 
load using different instances of the SFH (I'm allowing multiple 
instances of it, but keep a global one for convenience). Relaxing that 
may be possible, but I'm not sure I can achieve that right now.

	Cheers,
		Carsten

Re: [Opensg-core] OpenSG 2 python bindings

[Patrick H. <pa...@pr...>]

On Jan 11, 2011, at 9:27 PM, Gerrit Voß wrote:

> 
> Hi,
> 
> On Tue, 2011-01-11 at 08:37 -0600, Patrick Hartling wrote:
>> On Jan 11, 2011, at 7:34 AM, Patrick Hartling wrote:
>> 
>>> On Jan 11, 2011, at 1:49 AM, Gerrit Voß wrote:
>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> as this came up internally, can somebody give me a hint as to
>>>> the status and where I can get started to look at it. It seems
>>>> more sooner than later that I will need some form of (at least
>>>> basic)
>>>> script support. So I would like to have another structured go at
>>>> it ;)
>>> 
>>> PyOpenSG is up to date with r2500 of the SVN trunk and is working
>>> well on Linux and Windows. I've only tested 32-bit builds on
>>> Windows, but I would like to try a 64-bit build soon. The project is
>>> hosted here:
>>> 
>>> http://code.google.com/p/pyopensg/
>>> 
>>> I did have to make some patches to OpenSG get PyOpenSG to compile
>>> and link, and I have yet to submit them to this forum for review.
>>> I'll take care of that today. I haven't tried to update to r2512,
>>> but it probably should go smoothly.
>> 
>> 
>> As promised, here are the patches:
> 
> ok, thanks I will give it a try. One question, which version of the
> tools (gccxml, pygccxml, py++) are you using if you rebuild the
> mapping ? . The released versions, the developer versions from the
> sf repository or some custom patched versions ?

GCC-XML: CVS HEAD as of March 26, 2010
pygccxml: SVN trunk r1669
py++: SVN trunk r1669

 -Patrick


--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

The information transmitted in this communication is intended only for
the person or entity to which it is addressed and contains proprietary
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please destroy any copies, contact the sender
and delete the material from any computer.

Re: [Opensg-core] OpenSG 2 python bindings

[Gerrit V. <vo...@vo...>]

Hi David,

On Tue, 2011-01-11 at 07:25 -0600, David Kabala wrote:
> Hi Gerrit,
> 
> I don't have any experience making python bindings, but I do with
> creating Lua bindings for OpenSG.  In the search for good libraries to
> automate the creation of the bindings I found SWIG to be the most
> useful for my purposes. This allowed most of the bindings to be
> automated. However, I did find it useful to code a few by hand.
> 
> Given that Lua, and Python, are dynamically typed, it was possible to
> simplify the binding interface considerably. For all FieldContainers a
> single method can be used for getting a field value and setting a
> field value.  As an example (In LUA):
> 
> local NewMaterial = OSG.createFieldContainer("SimpleMaterial")
> 
> NewMaterial:setFieldValue("ambient", OSG.Color3f(1.0,0.0,0.0))
> NewMaterial:setFieldValue("diffuse", OSG.Color3f(0.0,1.0,0.0))
> 
> local NewGeometry = OSG.createFieldContainer("Geometry")
> NewGeometry:setFieldValue("material", NewMaterial)
> 
> The setFieldValue method is generic and can be used to change the
> value of any field of any FieldContainer.  I don't know if this is any
> help for you, but I wanted to mention it.  The Lua support libraries
> can be found on my github for of OpenSG here.

I'm aware of them ;) and coincidently I restarted to look at the toolbox
repositories, in particular the DevMaster branch to merge some changes
back into the main line. 

I'm also going to start to think about how we can get the whole of the
DevMaster_Toolbox tree back into the mainline. Currently there are 
two elements that I'm not sure about how best to handle, the relatively
big window classes and the event structure. Both are things we have
been avoided to include directly into the core. Similar/limited window
functionality is inside the complex scene manager part, so that part
might be easy to factor out from both variants into a common contrib
lib.
The event structure seems more tricky. Currently the only data flow
model OpenSG is less intrusive working of the changed callbacks as
a model of 'routes' to move data between fields. The event structure
is different in that it is more invasive instantaneous and does not rely
on underlying storage to be changed. What I really would like to avoid
is to have  a split so that parts support either one or the other.
 
But I haven't look at it in to much detail yet, so if anybody has
a good idea how to move forward and get the route/event models into
one model I'm happy to listen ;)

kind regards
  gerrit

Re: [Opensg-core] OpenSG 2 python bindings

[Gerrit V. <vo...@vo...>]

Hi,

On Tue, 2011-01-11 at 08:37 -0600, Patrick Hartling wrote:
> On Jan 11, 2011, at 7:34 AM, Patrick Hartling wrote:
> 
> > On Jan 11, 2011, at 1:49 AM, Gerrit Voß wrote:
> > 
> > > 
> > > Hi,
> > > 
> > > as this came up internally, can somebody give me a hint as to
> > > the status and where I can get started to look at it. It seems
> > > more sooner than later that I will need some form of (at least
> > > basic)
> > > script support. So I would like to have another structured go at
> > > it ;)
> > 
> > PyOpenSG is up to date with r2500 of the SVN trunk and is working
> > well on Linux and Windows. I've only tested 32-bit builds on
> > Windows, but I would like to try a 64-bit build soon. The project is
> > hosted here:
> > 
> > http://code.google.com/p/pyopensg/
> > 
> > I did have to make some patches to OpenSG get PyOpenSG to compile
> > and link, and I have yet to submit them to this forum for review.
> > I'll take care of that today. I haven't tried to update to r2512,
> > but it probably should go smoothly.
> 
> 
> As promised, here are the patches:

ok, thanks I will give it a try. One question, which version of the
tools (gccxml, pygccxml, py++) are you using if you rebuild the
mapping ? . The released versions, the developer versions from the
sf repository or some custom patched versions ?

thanks & kind regards
  gerrit

Re: [Opensg-core] OpenSG 2 python bindings

[Patrick H. <pa...@pr...>]

On Jan 11, 2011, at 7:34 AM, Patrick Hartling wrote:

> On Jan 11, 2011, at 1:49 AM, Gerrit Voß wrote:
> 
>> 
>> Hi,
>> 
>> as this came up internally, can somebody give me a hint as to
>> the status and where I can get started to look at it. It seems
>> more sooner than later that I will need some form of (at least basic)
>> script support. So I would like to have another structured go at it ;)
> 
> PyOpenSG is up to date with r2500 of the SVN trunk and is working well on Linux and Windows. I've only tested 32-bit builds on Windows, but I would like to try a 64-bit build soon. The project is hosted here:
> 
> http://code.google.com/p/pyopensg/
> 
> I did have to make some patches to OpenSG get PyOpenSG to compile and link, and I have yet to submit them to this forum for review. I'll take care of that today. I haven't tried to update to r2512, but it probably should go smoothly.

As promised, here are the patches:

add-FogChunk-methods.patch: Adds missing method definitions to OSG::FogChunk to fix linker errors.
add-TreeBuilderBase-getNodePool.patch: Adds a missing method definition to OSG::TreeBuilderBase to fix a linker error.
fix-64bit.patch: Fixes a compiler error when targeting 64-bit architectures. I am not sure why this one bit only us. In retrospect, this change may have been to silence a compiler warning rather than to fix an error.
fix-Image-clearData.patch: Fixes the implementation of OSG::Image::clearData() to behave the way it was intended.
fix-build-errors.patch: For various instantiations of OSG::Point<V,S> and OSG::Vector<V,S>, compiler errors occurred without these changes. The second block is the critical part. As I recall, Visual C++ reported overload ambiguity errors because it could not deduce the type of multiplying a float by the result of OSG::Vector<V,S>::dot() for some V (OSG::Uint8 maybe?). I have a standalone test program somewhere that demonstrates the issues if this one needs further clarification.
fix-build.patch: Fixes the build to ensure that the correct FreeType ft2build.h is used. (We have our own FreeType build that we use for OpenSG and other packages, so it is important that the OpenSG build pick up the correct headers.)
fix-gdal-include.patch: I haven't seen a GDAL installation where the GDAL headers are under a gdal subdirectory. The build should allow the path to the directories containing the GDAL headers to be specified, right?

With those patches applied to r2500, the current PyOpenSG SVN trunk compiles and links.

 -Patrick


--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

The information transmitted in this communication is intended only for
the person or entity to which it is addressed and contains proprietary
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please destroy any copies, contact the sender
and delete the material from any computer.