Marcus Lindblom wrote:

>Allen Bierbaum wrote:
>  
>
>>Marcus Lindblom wrote:
>>
>>    
>>
>>>Allen Bierbaum wrote:
>>> 
>>>
>>>[snip on binding dynamically to OpenSGs reflective interface]
>>>That would be nice, yes. But this 'reflective interface' (of which I 
>>>have little knowledge at the moment) is it the fields or a 
>>>member-function binding, similarish to boost::python?
>>>      
>>>
>>The type and field information from OpenSG.  I think we could expand it 
>>a little bit and make it possible to have pyOpenSG discover the fc-based 
>>class types at run-time and dynamically create interfaces for them.  
>>Before delving into this though I would like to see the fc code 
>>stabilize and hopefully merge ref_ptr and fc_ptr in some way (this would 
>>make the binding *much* easier).
>>    
>>
>Couldn't you just use ref_ptr everywhere in ? :) .. or the 2.0 c-ptr's 
>might ease the pain?
>  
>
I am using ref_ptr's everywhere, but it is nasty and evil because I have 
to use magic behind the scenes to map from ptr --> fcPtr --> RefPtr and 
back again.  It is just a completely pain and pretty fragile IMHO.

>Hmm, I'm not sure it would work to create interface dynamically. It 
>would make more sense to bind to user-functions rather than fields. 
>Also, you need to call functions sometimes (window->render()) so there's 
>no way around that (unless, as I said, those functions also were 
>available reflectively.)
>  
>
I can see this in some cases.  I am just trying to use the abilities of 
OpenSG to simplify it if possible.  Also when doing brute force binding 
the pyOpenSG library ends up being fairly huge. :(

>When binding to fields, you need some way to do begin/endedit though 
>(this is what I do in my OpenSG<->xml-bindings). This will, IIRC, be 
>baked into functions for 2.0, so then we need to bind to functions 
>anway. So what you are doing with py++ is the right way anyway. (What I 
>have been thinking of, time to time, is that there should be a generic 
>script binding system, but maybe that will come out of the langbinding 
>site in time.)
>  
>
The thing that py++ gains is that since it is useing gccxml it has 
access to the fully type and signature information so I can write policy 
adapter classes and automatic wrappers.  This would be difficult to 
generate automatically from just the .fcd files.  Possible, but 
difficult.  Probably worth looking into in the future.

>>>Indeed. I was thinking that you'd have this tool (fcdProcess or 
>>>something else) that produced the boost::python code for all functions 
>>>in the XXXBase-class.
>>>      
>>>
>>That may be possible, I really never looked into it because the 
>>boost::python code to be generated it pretty complex and... well... I am 
>>a little scared of the code in fcdProcess. :)
>>    
>>
>I haven't looked. Maybe I shouldn't. (losing sanity points by gaining 
>knowledge :)  .. My thesis work was a code-generator in Haskell 
>(http://www.yar.nu/macke/hspark/) which produced C++ (and planned to do 
>GLSL). And Haskell is pretty nice for those things, so I have some 
>familiarity with such contraptions.
>
>But fcdProcess seems to be just a xml->cpp generator, right, so you 
>could probably roll your own there, if you wanted. But given that py++ 
>does the job pretty good from the generated sources, there's no need in 
>doing something like that. I withdraw my suggestion. :)
>  
>
>>But if you have time and want to look into it or just what I have now, I 
>>would love to have help with pyOpenSG. :)
>>    
>>
>Well, it certainly looks like it's generating useful stuff!  (But whadda 
>ya mean haven't attempted on windows??!?! ;-) I have to dig a bit in 
>py++, pyste and python before I can even beginning to sound to know 
>something about this, but think I can see this going places. :)
>
>I didn't know py++ was this good. It certainly seems to be at least as 
>capable as swig (which I have been messing with), if not better. (since 
>it uses gcc, which makes perfect sense. That is my main grip against 
>swig, and a quite serious one at that).
>  
>
boost.python is definitely capable. It is just a little bit magic to me 
still.  Much of the "real" code is hidden behind preprocessor expansions 
and template meta programming.  It works, but it is a blackbox to many 
people like me.

>All I can say that I won't have time to do anything pythonish until 
>after christmas (i.e. the next project) and I have to be quite 
>persuasive about it to my bosses, but it might happen. If we go python 
>here (and pigs start to fly), I will use some wrapper. Using the same 
>wrapper as OpenSG makes sense, because I need interop between my python 
>bindings and OpenSG. Otherwise, I'll might have to wrap OpenSG by myself 
>(I don't know how compatible different bindings are). So in that case I 
>should be able to help you out getting things going (and since we use 
>windows, I would probably tackle that part of it).
>
>Sorry for being vague on promises though, but I'm getting paid to code, 
>so I therefore must code stuff which someone will pay for. (Fancy 
>frameworks seldom sells, working applications does .. getting enough 
>time & money to be able to work long-term is hard.)
>
>Anywya, I tried looking around to get some grips on the status of 
>pyOpenSG, i.e. current issues and todo-list. But there seems to be 
>little of that. What are the current issues & progress?
>  
>
Currently I am putting a lot of effort into it.  Once I get this push 
done I will release some things and start using the issue tracker a bit 
more. :)

-Allen

>Cheers,
>/Marcus
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Opensg-users mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/opensg-users
>
>  
>


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to