Hi David,
I understand your needs of keeping an hand on the loading/unloading process
and I support the idea of having a wrapper management system.
I was thinking to implement an automatic on-demand loading mechanism that
also allows manual intervention if needed. The automatic part would work
much like osgDB, loading wrappers based on the namespace of the type you
request. For example, if you (or any other code) request information for
type "osgUtil::IntersectVisitor", osgIntrospection would automatically load
the wrapper named "osgWrapper_osgUtil.dll" (or another name depending on the
platform). This means the user will never need to load wrapper manually. But
if manual intervention is required, the user can "subscribe" to load/unload
events and be notified every time osgIntrospection needs to load or unload a
wrapper, possibly replacing existing load/unload functionality with his own
(or disabling it completely). Of course, forced load and unload will also be
supported.
As for the new introspection framework, I've started doing some experiments
but I have no concrete design yet. Anyway, the new framework will be
composed of several layers of abstraction, with the lowest reflecting *only*
things that actually exist in the C++ language and with proper
conversion/lookup semantics. For example, "properties" are not a C++ feature
and so will not be supported by the base layer. Upper abstraction layers
will then be created to support features that don't exist in C++ and to
provide "shortcuts" and syntactic sugar to make things simpler for the final
user.
The new introspection framework will be a separate, open-source project that
will eventually be integrated into OSG after proper adjustment of coding
style and dependencies. Actually, I think it would be better to keep it
separate from OSG and have OSG depend on it instead, because it is a generic
library that is not directly connected to 3D graphics.
The framework will depend on Boost libraries. Not only because I like Boost
so much, but because it contains exactly the constructs I need (such as
Boost.Variant, static visitors and the non-intrusive shared pointer
classes). Rewriting them from scratch when they already exist and are being
used (and reviewed) everyday by C++ gurus, just doesn't make sense to me.
With the powerful compile-time features of Boost the new introspection
framework will be much faster than osgIntrospection. It will probably take
longer to compile, however... But run-time performance is more important.
:-)
Of course, anyone will be able to join the project.
Cheers,
Marco
----- Original Message -----
From: david callu
To: osg users
Sent: Friday, November 17, 2006 10:13 AM
Subject: Re: [osg-users] osgIntrospection Problems
Hi Marco,
Add a proxy in each wrapper could be a good solution, but application
(like osgDesigner) probably needs more flexibilty in the wrapper managment.
If a wrapper load another wrapper directly, the current flexibility will be
lost. So we must add a DynamicLibrary class (or similare component) and a
WrapperRegistry to store DynamicLibrary objects. I explain it later.
The first Miguel's problem is that he could not create a instance of
osgProducer::Viewer without the osgGA wrapper loaded.
I see no reason for this, osgProducer::Viewer is reflected and the
ObjectInstanceCreator<osgProducer::Viewer> is avalaible.
The limitation caused by the unloaded osgGA wrapper is the unaccess of
osgProducer::Viewer's sub-class' properties and methods.
Isn't it ?.
The load and unload of each wrapper must be managed by a class; this allow
the user to keep a hand on the wrapper (in osgDesigner we use a
WrapperManager) This feature is not allowed by osgIntrospection. If a
wrapper could load another wrapper, we must add a generic way in
osgIntrospection to manage load and unload.
see a example on an Unix platform:
1) application request load of wrapper "osgProducer" to
osgIntrospection::WrapperRegistry
2) osgIntrospection::WrapperRegistry load the "osgwrapper_osgProducer.so"
(note the convertion of wrapper name in a specific plateform file name, like
in the osgintrospection example)
3) "osgwrapper_osgProducer.so" request the load of "osg", "osgGA",
"osgUtil", "osgDB", "osgText" to osgIntrospection::WrapperRegistry
4) osgIntrospection::WrapperRegistry load the "osgwrapper_osg.so",
"osgwrapper_osgGA.so", "osgwrapper_osgUtil.so", "osgwrapper_osgDB.so",
"osgwrapper_osgText.so"
5) ... use osgIntrospection
6) application could unload and reload a wrapper if it's need
unload an unused wrapper (with or without its
wrapper dependancies)
request a list of wrapper's name which is
loaded
resolved dependancies of all wrapper (load the
dependant wrapper if it's not already done)
...
7) ... use osgIntrospection
In brief, do a plugin system ...
Currently, unload wrapper is dangerous and cause a segfault no longer after
the unload. I didn't explain the problem here because this is not a small
explication and this is not the topic. A plugin system could solve this
problem, but it must manage dependency between wrapper and which reflector a
wrapper declare (this could solve the namespace reflection problem too).
The unload and managment of wrapper could not be used in a osg binding
project and an automatic wrapper dependancy loading system is a good
solution, but an editor like osgDesigner need this to allow the user (or any
wrapper developper) to do it's own wrapper, load it, test it, unload it,
modify it , reload it, ...,
Marco, Have you start a new design of osgIntrospection ? If yes, are you ok
to do an open discution on it? I have other request more specific to an
editor project than a osg binding project.
For the name convention, "osgwrapper_" for suffix and ".dll" or ".so" or ...
for prefix is a good thing.
Do you want allow the user to load a wrapper without this naming convention?
If yes, just add a function in WrapperRegistry to load a path instead a
name.
Marco, you are the project leader of osgIntrospection so this is your
decision.
Best Regards
David Callu
2006/11/16, Robert Osfield < [EMAIL PROTECTED]>:
Hi David and Marco,
For stepping in an spotting the real cause and potential solution.
From an OSG perspective I'm happy for osgIntrospection to have helper
functions to assist OSG apps. Perhaps the naming library convetions
could be made default along the lines that the OSG uses, but have this
customizable by client applications.
I'm no expect in osgIntrosepction so I'll defer to you guys to decide
on the way forward.
Robet.
On 11/16/06, Marco Jez <[EMAIL PROTECTED]> wrote:
Hi Robert, David, Miguel.
As pointed out by David, the problem is not a compile-time dependency, so
there is no need to modify genwrapper.conf. Instead, the problem is an
unsatisfied run-time dependency between wrappers, which has never been
faced
before. Partly, this behaviour is by design, partly it's not. If you're
confused enough, I'm going to explain it better in a moment. :-)
osgIntrospection was designed to be totally independent from OSG, and in
fact it is. One could strip osgIntrospection off OSG without much effort,
and this presupposes a certain degree of genericity of the
osgIntrospection
code. This requirement of genericity is what prevents osgIntrospection
from
knowing how to load wrapper plugins, because the details of each wrapper
(the file name and location, for example) are only known within the outer
application domain (the OSG domain in this case). In fact, you usually
load
introspection wrappers by calling functions that are *not* defined in
osgIntrospection.
Wrappers that reflect OSG classes are, on the contrary, aware of OSG and
its
classes (it couldn't be otherwise). So, the best place where dependency
between wrappers could be specified is in the wrappers themselves. Without
thinking too much, a possible solution would be to place into each wrapper
a
global variable of some proxy class that automatically loads dependent
wrappers when the DLL is loaded. Genwrapper could be patched to do that
automatically I believe.
Some could argue that this genericity (btw, is "genericity" actually an
english word?) is not required, and that osgIntrospection should be made
OSG-aware. This would give osgIntrospection the means for loading wrappers
dynamically just as osgDB loads reader/writer plugins on demand. Well, I
think this would be a reasonable change, even though it would force
external
projects that use osgIntrospection to be conformant to a certain naming
scheme and file-level granularity for introspection wrappers.
Thoughts?
Marco
----- Original Message -----
From: david callu
To: osg users
Sent: Thursday, November 16, 2006 1:59 PM
Subject: Re: [osg-users] osgIntrospection Problems
Hi Robert, Hi Miguel
2006/11/15, Robert Osfield < [EMAIL PROTECTED] >:
Hi Miguel,
On 11/14/06, Miguel Escriva < [EMAIL PROTECTED]> wrote:
I have a problem with osgIntrospection Wrappers. There are no dependencies
between wrapper libraries.
For example, imagine this scenerio:
1.- load osg wrapper
2.- load osgProducer wrapper
3.- Create a instance of osgProducer.Viewer
BOOM! A exception is throw: (type `N5osgGA16GUIActionAdapterE' is declared
but not defined)
The exception happens because osgGA wrapper is not loaded. I think
Producer
wrapper should depend from osgGA wrapper.
Thanks for the notification. I have modified the
genwrapper/genwrapper.conf
file to include osgGA in osgProducer link line, and uploaded the new
genwrapper to wiki:
Robert, In the genwrapper.conf you do :
configure library "osgProducer"
dependency win32-debug "Producerd.lib"
dependency win32-release " Producer.lib "
- dependency unix
"-losgUtil -losgDB -lProducer -losgGA -losgText"
+ dependency unix
"-losgUtil -losgGA -losgDB -lProducer -losgGA -losgText"
end
so add the -losgGA. But it is already in the osgProducer line.
To solve the Miguel problem, you must include the -losgwrapper_osgGA line,
but this create a dependance between wrapper
First, I think is not the good way.
1) If osgwrapper_osgProducer didn't need to osgwrapper_osgGA to compile
or
run well, there are no reason to link osgwrapper_osgProducer with
osgwrapper_osgGA.
2) I think an exception is an run time error (error that can't be handle
at
compile time), that the program must catch and give to the user, but that
only the user can resolved.
This could be a good way to say to the user, that the osg file he
loading with osgViewer, require an OpenGL version or extension unavailable
on the system. Then the user could continue or stop the application.
With the wrapper, you could say to the user what is the problem ( try
{ ... } catch(osgIntrospection::Exception & ex) {cout << ex.what() <<
std::endl; }, and he must solved it
or try to parse the ex.what() message to search the wrapper you must
load to solve the problem.
3) If we do dependancies between wrapper, we must do it for all wrapper.
And the only one wrapper indepandent of another wrapper will be the
osgwrapper_osg.
Secondly, perhaps the problem is not in the build dependancies but in
osgIntrospection.
The wrapper must give the possibility to create, use and delete (when it
is
possible) an object that it reflect.
If the object you want create is not defined, you can't create this only
because the reflector which do a "new Class" is not loaded.
But if the object you want create is defined, you have the reflector and
it
can do a "new Class".
If the class that you create is defined but the sub-class is not, you can
use the class methods and properties, but not the sub-class methodes and
properties.
So If the behavious described is the good, there are a problem in
osgIntrospection.
Marco's help is need here to confirme or not this.
http://www.openscenegraph.org/osgwiki/pmwiki.php/Tasks/GenWrapper
I have also updated the osgWrappers and checked them into CVS. These
changes should fix the above problems, let me know if it doesn't.
I have another problem with getAllMethods method in Type class. For
example
you can get a Type for osg::CollectOccludersVisitor and then call
getAllMethods(), the result is a exception. The reason that
osg::CollectOccludersVisitor inherits from osg::CullStack and CullStack is
not exported by osgIntrospection.
There exists a src/osgWrappers/osg/CullStack.cpp, so it would it seem that
osg::CullStack has been exported.
in the genwrapper.conf, there are a line for CullStack:
suppress reflector "osg::CullStack"
So the osg::CullStack is not reflected. I remove this line and try to
understand where is the problem with this reflector.
see you soon
David
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
