GSoC: "Boost.Extension and Reflection" library [plugin]
The link from http://code.google.com/soc/boost/about.html states: Title: Boost.Extension and Reflection Student: Mariano Gabriel Consoni Mentor: Hartmut Kaiser "The project that I propose is centered in adding to Boost a library that allows the programmer to include extensions/plugins. Additionally this will be the start point to implement reflection concepts. [...]" I want to ask what is the progress with this library? I remember from GSoC 2006 conclusions that we all agreed that the progress during SoC should be advertised on boost mailing list to encourage participation from other people (especially looking at code during its evolution). I'm not even sure if SoC has already started, or will it start next month? Anyway I want to point out that I'm particularly curious about the progress in this area. PS: why this wiki webpage for GSoC 2007 is wiped out? http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer... -- Janek Kozicki |
Janek Kozicki wrote:
PS: why this wiki webpage for GSoC 2007 is wiped out?
Probably because of SPAM?
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer...
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Janek, I'm going to try and post an initial working release today (the last release was just for API review), to be the official starting point for the SoC project. It will "work" on each platform, but the initial task will be to clean it up to prepare the current library content for review. Then, Mariano will work on adding reflection (correct me if I'm wrong on the ordering). I'll reply to this thread once I get a zip file of the latest code posted on sourceforge. One thing we could really use on the project would be advice from someone who really knows Boost.Build well. Jeremy Pack On 5/28/07, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Rene Rivera wrote:
Janek Kozicki wrote:
PS: why this wiki webpage for GSoC 2007 is wiped out?
Probably because of SPAM?
Yeah, not even 'useful spam'. Restored now.
Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I've got a couple of bugs left with the new "registry" class - which handles loading and unloading of shared libraries (it can unload libraries whose plugins have all been destroyed, for instance). Besides that, it should be functioning well. I will wait to post a zip file until I have the registry working and tested on the target platforms. The source code has been moved (probably permanently) to the sandbox, so feel free to check it out there. There is some documentation available, and two examples. Caveat: If you use the MultipleInheritance sample on a platform other than Windows, you'll have to change your LD_LIBRARY_PATH or move around the generated shared libraries. I just haven't gotten around to figuring out Boost.Build well enough to overcome that. (If you are a Boost.Build genius with some time, drop me a line) And, once again, the standard call: *** If you have questions, please send them - either to this list, Mariano or me. We'll try and put the various questions we get into the FAQ, as well as answering them directly. *** Jeremy Pack On 5/28/07, Jeremy Pack <rostovpack@gmail.com> wrote:
Janek,
I'm going to try and post an initial working release today (the last release was just for API review), to be the official starting point for the SoC project. It will "work" on each platform, but the initial task will be to clean it up to prepare the current library content for review. Then, Mariano will work on adding reflection (correct me if I'm wrong on the ordering).
I'll reply to this thread once I get a zip file of the latest code posted on sourceforge.
One thing we could really use on the project would be advice from someone who really knows Boost.Build well.
Jeremy Pack
On 5/28/07, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Rene Rivera wrote:
Janek Kozicki wrote:
PS: why this wiki webpage for GSoC 2007 is wiped out?
Probably because of SPAM?
Yeah, not even 'useful spam'. Restored now.
Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jeremy Pack said: (by the date of Mon, 28 May 2007 21:36:14 -0700)
The source code has been moved (probably permanently) to the sandbox, so feel free to check it out there.
There is some documentation available, and two examples.
I'll reply to this thread once I get a zip file of the latest code posted on sourceforge.
Great, many thanks. I will try it as soon as possible: should I wait for the zip file, or look at the sanbox? -- Janek Kozicki |
Great, many thanks. I will try it as soon as possible: should I wait for the zip file, or look at the sanbox?
--
You can check it out now - just the "registry" class is incomplete. As far as the rest of the library, check out the sandbox/libs/extension/examples folder to see how it works. There is also some scanty documentation - tutorials 1 and 2 have some information in them already.
Jeremy Pack said: (by the date of Tue, 29 May 2007 08:00:17 -0700)
You can check it out now - just the "registry" class is incomplete. As far as the rest of the library, check out the sandbox/libs/extension/examples folder to see how it works. There is also some scanty documentation - tutorials 1 and 2 have some information in them already.
great, thanks! Expect feedback soon :) -- Janek Kozicki |
All: As I mentioned, I put together a release - it can be considered the starting point for the SoC project. The "registry" class has some bugs with library unloading. The API for it is all in place though. Refer to the registry example to see how to use it. That class will change a bit underneath to maximize the library unloading possible - but the API should stay the same. Refer to the HelloWorld sample for the simplest use of the Extension library. Refer to the MultipleInheritance sample for a complicated use of the library. Note: multiple inheritance across shared library boundaries is messy, and I only made an example of it to show that the library can handle complicated inheritance hierarchies involving dynamic and static linking. Note 2: On Unix systems, you may have to change your LD_LIBRARY_PATH for the multiple inheritance example. The recommended way to use the library (for now) is to download the sandbox SVN repository at svn.boost.org. Then you can sync it later to pick up new changes. You may also download just the Extension library at: http://svn.boost.org/svn/boost/sandbox/libs/extension/Release%205-29-07.zip Send any bug reports, feature requests, or lists of failed tests (along with compiler info) to me or Mariano, and/or to this list. Tested compilers with the very latest build: GCC 4.0 on OS X MSVC 2005 on Windows Thanks! Jeremy On 5/29/07, Janek Kozicki <janek_listy@wp.pl> wrote:
Jeremy Pack said: (by the date of Tue, 29 May 2007 08:00:17 -0700)
You can check it out now - just the "registry" class is incomplete. As far as the rest of the library, check out the sandbox/libs/extension/examples folder to see how it works. There is also some scanty documentation - tutorials 1 and 2 have some information in them already.
great, thanks! Expect feedback soon :)
-- Janek Kozicki | _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Jeremy,
As I mentioned, I put together a release - it can be considered the starting point for the SoC project.
The "registry" class has some bugs with library unloading. The API for it is all in place though. Refer to the registry example to see how to use it. That class will change a bit underneath to maximize the library unloading possible - but the API should stay the same.
Refer to the HelloWorld sample for the simplest use of the Extension library.
Refer to the MultipleInheritance sample for a complicated use of the library. Note: multiple inheritance across shared library boundaries is messy, and I only made an example of it to show that the library can handle complicated inheritance hierarchies involving dynamic and static linking. Note 2: On Unix systems, you may have to change your LD_LIBRARY_PATH for the multiple inheritance example.
The recommended way to use the library (for now) is to download the sandbox SVN repository at svn.boost.org. Then you can sync it later to pick up new changes.
You may also download just the Extension library at: http://svn.boost.org/svn/boost/sandbox/libs/extension/Release%205-29-07.zip
It seems to me your library is missing an interesting feature: loading plugins on demand. Right now it seems you have to know in advance in which library a component resides to load that library, and eventually load the requested component. I guess a little "manager" class, filled from a boring ASCII file (or whatever) containing a list of [component-name] : [library name] would be interesting. The factory_map would go the plugin manager when somebody says: IMyInterface* = gimme<IMyInterface>( "MyConcreteClass" ); The ASCII file(s) could be automatically constructed at build time or carefully handcrafted. HTH. Cheers, Sebastien. -- ################################### # Dr. Sebastien Binet # # Lawrence Berkeley National Lab. # # 1 Cyclotron Road # # Berkeley, CA 94720 # ###################################
Sebastien, You can actually load all of the libraries that contain plugins at once, and then load whichever plugins you would like from them - you don't have to know which specific library it is in. However, there is currently no mechanism to know which libraries are available. Possible methods include: 1 - Put a common extension on each library (in the examples, for instance, every library ends with .extension - which is completely arbitrary), and then use Boost.Filesystem or some other method to iterate through a directory (and, optionally, it's children). This method was implemented earlier, but is not currently part of the library. 2 - Have a config file, as you mention, that lists the shared libraries and their respective loading functions. This is one area where I felt that the user could go into the specifics, instead of the library - but I am putting in so-called convenience headers that can be included if the user wants some of these types of functionality. We could put something similar to what you propose into such a convenience header. It would certainly be a common use case. Jeremy On 6/3/07, Sebastien Binet <hep.sebastien.binet@gmail.com> wrote:
Hi Jeremy,
As I mentioned, I put together a release - it can be considered the starting point for the SoC project.
The "registry" class has some bugs with library unloading. The API for it is all in place though. Refer to the registry example to see how to use it. That class will change a bit underneath to maximize the library unloading possible - but the API should stay the same.
Refer to the HelloWorld sample for the simplest use of the Extension library.
Refer to the MultipleInheritance sample for a complicated use of the library. Note: multiple inheritance across shared library boundaries is messy, and I only made an example of it to show that the library can handle complicated inheritance hierarchies involving dynamic and static linking. Note 2: On Unix systems, you may have to change your LD_LIBRARY_PATH for the multiple inheritance example.
The recommended way to use the library (for now) is to download the sandbox SVN repository at svn.boost.org. Then you can sync it later to pick up new changes.
You may also download just the Extension library at: http://svn.boost.org/svn/boost/sandbox/libs/extension/Release%205-29-07.zip
It seems to me your library is missing an interesting feature: loading plugins on demand. Right now it seems you have to know in advance in which library a component resides to load that library, and eventually load the requested component.
I guess a little "manager" class, filled from a boring ASCII file (or whatever) containing a list of [component-name] : [library name] would be interesting. The factory_map would go the plugin manager when somebody says: IMyInterface* = gimme<IMyInterface>( "MyConcreteClass" );
The ASCII file(s) could be automatically constructed at build time or carefully handcrafted.
HTH.
Cheers, Sebastien. -- ################################### # Dr. Sebastien Binet # # Lawrence Berkeley National Lab. # # 1 Cyclotron Road # # Berkeley, CA 94720 # ###################################
Jeremy Pack said: (by the date of Mon, 4 Jun 2007 13:30:12 -0700)
1 - Put a common extension on each library (in the examples, for instance, every library ends with .extension - which is completely arbitrary),
How do you do this? I was expecting to have .so on linux, and .dll on windows. That's how compiler creates such files by default. Absolutely I'm not saying it's wrong, I'm just curious. -- Janek Kozicki |
Hi Janek,
1 - Put a common extension on each library (in the examples, for instance, every library ends with .extension - which is completely arbitrary),
How do you do this? I was expecting to have .so on linux, and .dll on windows. That's how compiler creates such files by default. Absolutely I'm not saying it's wrong, I'm just curious.
Boost.Build handles this fine. It's certainly not required. So far, it works on each platform that we've tested it on. To make this happen, I just put the following at the top of the Jamfile: import type : change-generated-target-suffix ; import type : change-generated-target-prefix ; type.change-generated-target-suffix SHARED_LIB : : extension ; type.change-generated-target-prefix SHARED_LIB : : lib ; This makes it so that all shared libraries on any platform are of the type: lib[NAME].extension This is very handy for cross-platform code. I used it specifically so that the tests wouldn't have to have special cases or call any special functions to determine the shared library names. There is probably a better way to do this, that doesn't end up requiring all shared libraries in the Jamfile to have the new extensions. Jeremy On 6/4/07, Janek Kozicki <janek_listy@wp.pl> wrote:
Jeremy Pack said: (by the date of Mon, 4 Jun 2007 13:30:12 -0700)
-- Janek Kozicki | _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Janek Kozicki wrote:
The link from http://code.google.com/soc/boost/about.html states:
Title: Boost.Extension and Reflection Student: Mariano Gabriel Consoni Mentor: Hartmut Kaiser
"The project that I propose is centered in adding to Boost a library that allows the programmer to include extensions/plugins. Additionally this will be the start point to implement reflection concepts. [...]"
I want to ask what is the progress with this library?
I remember from GSoC 2006 conclusions that we all agreed that the progress during SoC should be advertised on boost mailing list to encourage participation from other people (especially looking at code during its evolution).
I'm not even sure if SoC has already started, or will it start next month? Anyway I want to point out that I'm particularly curious about the progress in this area.
Janek, I agree that the boost mailing list is the best place to inform and discuss GSoC projects and I'll try to keep the community informed. The program officially starts today :). Besides that we've been planning and doing some work this weeks, mainly minor changes in the actual code in order to prepare it for the program start. I'll keep you posted...!! Thanks for your interest. -- Mariano
participants (6)
-
Janek Kozicki -
Jeff Garland -
Jeremy Pack -
Mariano Gabriel Consoni -
Rene Rivera -
Sebastien Binet