[Ann] Boost and Google Summer of Code 2007
Dear Boosters, It is a pleasure to announce that Boost will be applying as a mentoring organization for the upcoming Google Summer of Code 2007. There is a lot of preparation work to be done and little time to do it. A page has been set up at the Boost Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer... which will hold a list of preliminary ideas for students to take up and use in their own applications to GSoC07. Please feel free to contribute by directly editing the Wiki page. Any questions, requests for feedback etc. can be conducted through the Boost lists. Remember that this initiative, as Boost itself, is the result of many individuals' contribution and ideas, which means we are looking forward to *your* feedback. Sincerely, John Maddock
John Maddock wrote:
It is a pleasure to announce that Boost will be applying as a mentoring organization for the upcoming Google Summer of Code 2007. There is a lot of preparation work to be done and little time to do it.
A page has been set up at the Boost Wiki:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer...
which will hold a list of preliminary ideas for students to take up and use in their own applications to GSoC07.
What's the point of recursive regexes since we have xpressive? Before application level networking protocols, wouldn't it be better to have an iostreams wrapper for asio?
On 3/2/07, Mathias Gaunard <mathias.gaunard@etu.u-bordeaux1.fr> wrote:
Before application level networking protocols, wouldn't it be better to have an iostreams wrapper for asio?
Doesn't it have that already? http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/reference/a00167.... http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/examples/iostream... http://asio.sourceforge.net/boost_asio_0_3_7/libs/asio/doc/examples/iostream...
Mathias Gaunard wrote:
What's the point of recursive regexes since we have xpressive?
xpressive can do that with static regexes, but not dynamic ones (interpreted strings). However, you can view that as a "seeder" proposal to get things started if you wish. Aside: last year we mostly had "big" projects - write a new library from scratch and so on - and as you may have noticed so far only one has come to review. It's true that there are more in the works, but I notice that many of the other projects had their students submitting patches to their existing code base, with more of a series of targets, rather than "one big hit" hoped for at the end. I'd be interested in hearing whether people think a similar approach - for some of our projects anyway - would be beneficial for Boost too. John.
John Maddock wrote:
Mathias Gaunard wrote:
What's the point of recursive regexes since we have xpressive?
xpressive can do that with static regexes, but not dynamic ones (interpreted strings).
However, you can view that as a "seeder" proposal to get things started if you wish.
Aside: last year we mostly had "big" projects - write a new library from scratch and so on - and as you may have noticed so far only one has come to review.
And actually that one is based on an existing Boost lib. Also, it should be noted that there was at least one successful graph lib project that was an extension that has been added to the repository.
It's true that there are more in the works, but I notice that many of the other projects had their students submitting patches to their existing code base, with more of a series of targets, rather than "one big hit" hoped for at the end. I'd be interested in hearing whether people think a similar approach - for some of our projects anyway - would be beneficial for Boost too.
As one of the SoC project selectors I'm more inclined to look at smaller extension projects this year. For the simple reason that the results are more immediate and tangible -- and experience from last year is that these projects have more benefit to Boost overall. So I'd encourage other Boost authors or students with library extension ideas to write those up. Jeff
Jeff Garland wrote:
John Maddock wrote:
As one of the SoC project selectors I'm more inclined to look at smaller extension projects this year. For the simple reason that the results are more immediate and tangible -- and experience from last year is that these projects have more benefit to Boost overall. So I'd encourage other Boost authors or students with library extension ideas to write those up.
Agreed 100%. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
John Maddock wrote:
I'd be interested in hearing whether people think a similar approach - for some of our projects anyway - would be beneficial for Boost too.
I would be interested in seeing support for some of our infrastructure. For whatever reasons, boost 1.34 has taken significantly longer to release than previous versions, and I see no reason to assume that 1.35 will go any more smoothly - lots of new libraries accepted while testing has focussed on release branch rather than head, the plan to start testing release as well as debug builds, and talk of moving to an SVN repository instead of CVS. I could imagine several small tools to give more consistent automated results (e.g. something to diagnose build environment rather than rely on user naming conventions), perhaps enhanced report pages so we can see warnings, or easily group by platform rather than vendor, or ... (although Aleksey is already doing some work on report pages) Are there more automated tools we want to run like the license/copyright checker? etc. And again, these or the sort of changes that could have an immediate impact, even during the SoC project itself - which could be very positive feedback for the student(s) involved. -- AlisdairM
I think this is an excellent suggestion. There are a number of things that should be done to enhance the current situation. For example: * Pick up the work that Rene did on a buildbot harness for boost to better formalize automated building, testing, and report generation. * Suggest paths to modularize boost: - analyze dependencies and suggest changes to be able to compile / install / package individual subpackages - changes to the build system supporting the same - build tools to assist packaging (rpm spec files, etc.) * Enhanced testing support * Etc. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
AlisdairM wrote:
John Maddock wrote:
I'd be interested in hearing whether people think a similar approach - for some of our projects anyway - would be beneficial for Boost too.
I would be interested in seeing support for some of our infrastructure. For whatever reasons, boost 1.34 has taken significantly longer to release than previous versions, and I see no reason to assume that 1.35 will go any more smoothly - lots of new libraries accepted while testing has focussed on release branch rather than head, the plan to start testing release as well as debug builds, and talk of moving to an SVN repository instead of CVS.
I could imagine several small tools to give more consistent automated results (e.g. something to diagnose build environment rather than rely on user naming conventions), perhaps enhanced report pages so we can see warnings, or easily group by platform rather than vendor, or ... (although Aleksey is already doing some work on report pages)
Are there more automated tools we want to run like the license/copyright checker?
etc.
And again, these or the sort of changes that could have an immediate impact, even during the SoC project itself - which could be very positive feedback for the student(s) involved.
Speaking of tools... I like Boost.Build a lot but a major stumbling block for integrating it into our company is that our programmers are mostly familiar with IDE environments like CodeWarrior, Visual Studio, XCode, etc. A program that could transform a bbv2 project into IDE projects would make the barrier to adoption much smaller. Especially if that tool was extensible so new modules could be added to support different IDEs. Thanks, Michael Marcin
Michael Marcin wrote:
Speaking of tools...
I like Boost.Build a lot but a major stumbling block for integrating it into our company is that our programmers are mostly familiar with IDE environments like CodeWarrior, Visual Studio, XCode, etc. A program that could transform a bbv2 project into IDE projects would make the barrier to adoption much smaller. Especially if that tool was extensible so new modules could be added to support different IDEs.
You could use MPC (make project creator). It's a set of perl scripts that generate native makefiles for various platforms -- various solution files for VC*, nmake, borland make, Makefiles for *nix, etc. This is the system used to maintain makefiles for ACE/TAO which is ported to tons of platforms. You can download the tool from: info --> http://www.ociweb.com/products/mpc download --> http://www.ociweb.com/products/mpc/down.html Someone of the folks at OCI previously put together a set of boost project files. Those are in the vault at: http://www.boost-consulting.com/vault/index.php?PHPSESSID=kk5srbfv8nefn8mhg7h7v8qan5&direction=0&order=&directory=Miscellaneous Note, I haven't tried the Boost files, but I've used MPC on cross-platform projects -- it's a nifty solution. As for SoC maybe we could tranlate bbv2 into MPC and use MPC to generate native files -- essentially using it as the 'compiler backend'. Not sure if there would be too much overlap there with bbv2, but it would be worth looking at as an approach. Jeff
Jeff Garland wrote:
Michael Marcin wrote:
Speaking of tools...
I like Boost.Build a lot but a major stumbling block for integrating it into our company is that our programmers are mostly familiar with IDE environments like CodeWarrior, Visual Studio, XCode, etc. A program that could transform a bbv2 project into IDE projects would make the barrier to adoption much smaller. Especially if that tool was extensible so new modules could be added to support different IDEs.
You could use MPC (make project creator). It's a set of perl scripts that generate native makefiles for various platforms -- various solution files for VC*, nmake, borland make, Makefiles for *nix, etc. This is the system used to maintain makefiles for ACE/TAO which is ported to tons of platforms. You can download the tool from:
info --> http://www.ociweb.com/products/mpc download --> http://www.ociweb.com/products/mpc/down.html
MPC is nice and could be part of a solution if the requirements only where to produce IDE project and solution files from Jamfiles. Boost.Build and/or bjam could be extended to produce a <sub-project>.mpc file for each Jamfile and a <tool>.mpt file per tool(-set) used and then invoke mpc to generate the buildfiles. This should be recursive for a full project source tree. By the way, http://www.trolltech.com has a similar solution called qmake which is used in Qt. This may or may not be more appropriate in an optional add-on to Boost.Build. This highlights another nice feature of such tools, which I have met. If you have an opensource project in which you do not expect users to be familiar with your build system. You can provide pre-built IDE projects for libraries, executables and/or example and tutorial code.
Someone of the folks at OCI previously put together a set of boost project files. Those are in the vault at:
These seems to be hand crafted. Is that correct? In that case I do not think this is the way to go.
Note, I haven't tried the Boost files, but I've used MPC on cross-platform projects -- it's a nifty solution.
Agree, Many developers prefer their native IDE project- , build-, and debug-management . The challenges do however soon become clear. Sooner or later changes to the native build files must go back to the .mpc or jam files. That becomes annoying, error prone, or outright neglected.
As for SoC maybe we could tranlate bbv2 into MPC and use MPC to generate native files -- essentially using it as the 'compiler backend'. Not sure if there would be too much overlap there with bbv2, but it would be worth looking at as an approach.
The MPC .mpt template files for the tools should be generated as well. This would be based on bbv2 so most redundant overlap should be avoidable. Even if the mpc and qmake have their shiny aspects, I would be much more interested in good plug-in support for bbv2/bjam in IDEs such as Eclipse/CDE, VisualStudio, etc. In the IDE this should have the look and feel of the native build system if possible. This involves: - adding and removing source files from projects in the IDE - creating new projects - starting bbv2 builds which reports errors into the IDE interface - execute or debug sessions should invoke build with bbv2 and offer to rebuild first if required - saving files could start background builds like in Eclipse managed C++ projects The funny thing is that I don't care that much myself for these features, I am more than happy with emacs + Boost.Build or whatever other _real_ build system is I use. What frustrates me is that so many developers use build systems that come with their IDE without any regard to the possible downsides they bring with them. Also, I believe real IDE plug-in support could be a boost in the popularity of bjam and Boost.Build. -- Bjørn Roald
Bjørn Roald wrote:
Jeff Garland wrote:
By the way, http://www.trolltech.com has a similar solution called qmake which is used in Qt. This may or may not be more appropriate in an optional add-on to Boost.Build.
Non-technical issue: MPC has a boost compatible license -- I doubt QT does.
Someone of the folks at OCI previously put together a set of boost project files. Those are in the vault at:
These seems to be hand crafted. Is that correct? In that case I do not think this is the way to go.
Yes.
Note, I haven't tried the Boost files, but I've used MPC on cross-platform projects -- it's a nifty solution.
Agree, Many developers prefer their native IDE project- , build-, and debug-management . The challenges do however soon become clear. Sooner or later changes to the native build files must go back to the .mpc or jam files. That becomes annoying, error prone, or outright neglected.
Yes.
Even if the mpc and qmake have their shiny aspects, I would be much more interested in good plug-in support for bbv2/bjam in IDEs such as Eclipse/CDE, VisualStudio, etc. In the IDE this should have the look and feel of the native build system if possible. This involves:
- adding and removing source files from projects in the IDE - creating new projects - starting bbv2 builds which reports errors into the IDE interface - execute or debug sessions should invoke build with bbv2 and offer to rebuild first if required - saving files could start background builds like in Eclipse managed C++ projects
Yeah, that's a different way, but doesn't this mean that people would have to use bbv2 for their whole project?
The funny thing is that I don't care that much myself for these features, I am more than happy with emacs + Boost.Build or whatever other _real_ build system is I use.
Funny, me too :-)
What frustrates me is that so many developers use build systems that come with their IDE without any regard to the possible downsides they bring with them.
Hmm, no kidding -- like the scenario where 20 developers trying to collaborate and needing to have consistent settings in the project files? So you wind up with 200 project files with different settings and then you burn a couple weeks of someones time to get things consistent and setup new common build targets (yes, it's happened to me). Of course this can trivially be done with #include and a common makefile with common setting -- something that often hasn't been available in ide setups (may be now, but I haven't seen it done). And then there's the 'daily build/regression test' stuff -- still haven't seen anyone serious about doing this job do it thru and ide.
Also, I believe real IDE plug-in support could be a boost in the popularity of bjam and Boost.Build.
Possibly. My sense is that this is a quasi religious issue. There's lots of projects that will never switch to bjam even if you could prove it's the best build system ever. So I think producing native ide files instead of trying to sell bjam gets more boost users in the end. Jeff
Jeff Garland wrote:
Bjørn Roald wrote:
Jeff Garland wrote:
By the way, http://www.trolltech.com has a similar solution called qmake which is used in Qt. This may or may not be more appropriate in an optional add-on to Boost.Build.
Non-technical issue: MPC has a boost compatible license -- I doubt QT does.
Unless I completely miss the point I don't think licensing issues play any role here. What is suggested is not to integrate any boost code with any Qt code, but instead to provide an interface for boost *users* to more easily access build parameters used when developing *with* boost libraries. I don't think there is much value in providing alternative build tools to build boost itself. If building boost is an issue for people, let's 1) enhance boost.build itself and 2) provide more convenient (e.g. modular) binary boost packages. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Jeff Garland wrote:
Bjørn Roald wrote:
Jeff Garland wrote: By the way, http://www.trolltech.com has a similar solution called qmake which is used in Qt. This may or may not be more appropriate in an optional add-on to Boost.Build. Non-technical issue: MPC has a boost compatible license -- I doubt QT does.
Unless I completely miss the point I don't think licensing issues play any role here. What is suggested is not to integrate any boost code with any Qt code, but instead to provide an interface for boost *users* to more easily access build parameters used when developing *with* boost libraries.
Well, perhaps not, but in the past we've been fairly averse to requiring other tools form other sources so ultimately some parts of these systems might need to be in the boost tools tree.
I don't think there is much value in providing alternative build tools to build boost itself. If building boost is an issue for people, let's
1) enhance boost.build itself and 2) provide more convenient (e.g. modular) binary boost packages.
I mostly agree with this in that a) most boost libs still require no building, b) there's a windows installer now available from boost consulting, c) various *nix systems have binaries available (I can do apt-get on my Linux system one lib at a time for the 'built libs' -- others can use RPMs). So given all that is it really worth pursuing this stuff at all? Jeff
Jeff Garland wrote:
Stefan Seefeld wrote:
Jeff Garland wrote:
Bjørn Roald wrote:
Jeff Garland wrote: By the way, http://www.trolltech.com has a similar solution called qmake which is used in Qt. This may or may not be more appropriate in an optional add-on to Boost.Build. Non-technical issue: MPC has a boost compatible license -- I doubt QT does. Unless I completely miss the point I don't think licensing issues play any role here. What is suggested is not to integrate any boost code with any Qt code, but instead to provide an interface for boost *users* to more easily access build parameters used when developing *with* boost libraries.
Well, perhaps not, but in the past we've been fairly averse to requiring other tools form other sources so ultimately some parts of these systems might need to be in the boost tools tree.
I'm not sure I understand. Somewhere in the boost repository there are MS project files, too. And MSVC is hardly required for boost.
I don't think there is much value in providing alternative build tools to build boost itself. If building boost is an issue for people, let's
1) enhance boost.build itself and 2) provide more convenient (e.g. modular) binary boost packages.
I mostly agree with this in that a) most boost libs still require no building, b) there's a windows installer now available from boost consulting, c) various *nix systems have binaries available (I can do apt-get on my Linux system one lib at a time for the 'built libs' -- others can use RPMs).
So given all that is it really worth pursuing this stuff at all?
I thought the ultimate interest is in ways to assist developing *with* boost, not developing boost. Thus, we are talking about tools that help to integrate boost-specific compilation flags into existing build systems, i.e. things akin to pkg-config etc. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Jeff Garland wrote:
1) enhance boost.build itself and 2) provide more convenient (e.g. modular) binary boost packages.
I mostly agree with this in that a) most boost libs still require no building, b) there's a windows installer now available from boost consulting, c) various *nix systems have binaries available (I can do apt-get on my Linux system one lib at a time for the 'built libs' -- others can use RPMs).
So given all that is it really worth pursuing this stuff at all?
Yes! The windows installer and prebuilt binaries are only available on some platforms. My company in particular works on many closed platforms that probably cannot be openly supported and tested by Boost. Even if they were available we wouldn't use them because a prebuilt binary removes one the biggest reasons we feel comfortable using Boost. If we find a problem we have the entire source available to us and can fix the problem locally without having to depend on arbitrary 3rd party. If we don't build that binaries from source we can't be sure we'll be able to later if a problem arises. P.S. IMO Boost is already reasonably modular, portions of MPL, Preprocessor, and Type Traits are used by almost every library I've needed so far but not much more - Michael Marcin
Jeff Garland wrote:
Stefan Seefeld wrote:
Jeff Garland wrote:
Bjørn Roald wrote:
Jeff Garland wrote: By the way, http://www.trolltech.com has a similar solution called qmake which is used in Qt. This may or may not be more appropriate in an optional add-on to Boost.Build. Non-technical issue: MPC has a boost compatible license -- I doubt QT does. Unless I completely miss the point I don't think licensing issues play any role here. What is suggested is not to integrate any boost code with any Qt code, but instead to provide an interface for boost *users* to more easily access build parameters used when developing *with* boost libraries.
Well, perhaps not, but in the past we've been fairly averse to requiring other tools form other sources so ultimately some parts of these systems might need to be in the boost tools tree.
We have offered before to provide an initial set of MPC files and to help maintain them. If you are interested in accepting MPC files into boost, please let us know. BTW, MPC comes with boost base projects to derive from to make it very easy to use boost with a project. For, example here is a mpc file contents for a project that uses boost_thread and boost_unit_test_framework: project : boost_unit_test_framework, boost_thread { } That is the complete file. MPC uses the concept of good defaults to make most mpc files very simple. KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com
Kevin Heifner wrote:
Jeff Garland wrote:
Stefan Seefeld wrote:
Jeff Garland wrote:
Bjørn Roald wrote:
Jeff Garland wrote: By the way, http://www.trolltech.com has a similar solution called qmake which is used in Qt. This may or may not be more appropriate in an optional add-on to Boost.Build.
Non-technical issue: MPC has a boost compatible license -- I doubt QT does.
Unless I completely miss the point I don't think licensing issues play any role here. What is suggested is not to integrate any boost code with any Qt code, but instead to provide an interface for boost *users* to more easily access build parameters used when developing *with* boost libraries.
Well, perhaps not, but in the past we've been fairly averse to requiring other tools form other sources so ultimately some parts of these systems might need to be in the boost tools tree.
We have offered before to provide an initial set of MPC files and to help maintain them. If you are interested in accepting MPC files into boost, please let us know.
BTW, MPC comes with boost base projects to derive from to make it very easy to use boost with a project. For, example here is a mpc file contents for a project that uses boost_thread and boost_unit_test_framework:
project : boost_unit_test_framework, boost_thread { }
Typically I guess you would at least list some source files as well: project : boost_unit_test_framework, boost_thread { Source_Files { a.cpp b.cpp } } But yes, they are simple enough. Especially compared to typical IDE based project files. If you compare them to Boost.Build files the difference is not that great. I guess the annoying thing is that they pretty much reflect the same information, so the tools could at least in concept have been inter operable on the same set of project files.
That is the complete file. MPC uses the concept of good defaults to make most mpc files very simple.
So does Boost.Build :-) A study of the format differences and similarities of the Jamfile and .mpc files would be interesting. Has anybody looked into this? -- Bjørn Roald
Bjørn Roald wrote:
Kevin Heifner wrote:
BTW, MPC comes with boost base projects to derive from to make it very easy to use boost with a project. For, example here is a mpc file contents for a project that uses boost_thread and boost_unit_test_framework:
project : boost_unit_test_framework, boost_thread { }
Typically I guess you would at least list some source files as well:
project : boost_unit_test_framework, boost_thread { Source_Files { a.cpp b.cpp } }
Actually the default is to grab all the *.cpp files in the directory. So this is all that is needed: project : boost_unit_test_framework, boost_thread { } As long as you want all the source files in the directory.
But yes, they are simple enough. Especially compared to typical IDE based project files. If you compare them to Boost.Build files the difference is not that great. I guess the annoying thing is that they pretty much reflect the same information, so the tools could at least in concept have been inter operable on the same set of project files.
Agreed.
So does Boost.Build :-) A study of the format differences and similarities of the Jamfile and .mpc files would be interesting. Has anybody looked into this?
That would be interesting. I confess that I'm not that familiar with Boost.Build. KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com
Kevin Heifner wrote:
Bjørn Roald wrote:
A study of the format differences and similarities of the Jamfile and .mpc files would be interesting. Has anybody looked into this?
That would be interesting. I confess that I'm not that familiar with Boost.Build.
I will take a look at this. Is there other MPC documentation than the README and USAGE files in the ACE distro, and FAQ at the http://www.ociweb.com/products/mpc/faq.html that I should know of? I am not an expert on neighter bbv2 or mpc, so I will do this to learn a bit for myself. -- Bjørn Roald
Bjørn Roald wrote:
Kevin Heifner wrote:
Bjørn Roald wrote:
A study of the format differences and similarities of the Jamfile and .mpc files would be interesting. Has anybody looked into this?
That would be interesting. I confess that I'm not that familiar with Boost.Build.
I will take a look at this. Is there other MPC documentation than the README and USAGE files in the ACE distro, and FAQ at the http://www.ociweb.com/products/mpc/faq.html that I should know of? I am not an expert on neighter bbv2 or mpc, so I will do this to learn a bit for myself.
The README is the best. There is also the Chapter from the TAO 1.4a Developer's Guide that can be found here: http://downloads.ociweb.com/MPC/MakeProjectCreator.pdf You can also take a look at the mpc files in the boost vault. http://www.boost-consulting.com/vault/index.php?PHPSESSID=kk5srbfv8nefn8mhg7h7v8qan5&direction=0&order=&directory=Miscellaneous When these were created you could build all/most (don't remember) of Boost with them. Also feel free to email me with any questions. Off list is fine. KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com
Bjørn Roald wrote:
Jeff Garland wrote: MPC is nice and could be part of a solution if the requirements only where to produce IDE project and solution files from Jamfiles. Boost.Build and/or bjam could be extended to produce a <sub-project>.mpc file for each Jamfile and a <tool>.mpt file per tool(-set) used and then invoke mpc to generate the buildfiles. This should be recursive for a full project source tree.
We have thought about extending MPC to generate Jamfiles, but it has never risen to the top of things to do.
Someone of the folks at OCI previously put together a set of boost project files. Those are in the vault at:
These seems to be hand crafted. Is that correct? In that case I do not think this is the way to go.
Yes, these particular files were hand crafted. One of the nice things about MPC, however, is how easy it is to maintain the MPC files. Its inheritance feature of common base projects makes it very easy to make project wide changes to a build system. It is also very nice that source files do not have to be listed explicitly. To add a new file to a project is just a matter of running MPC, no modification to the build files are needed.
Note, I haven't tried the Boost files, but I've used MPC on cross-platform projects -- it's a nifty solution.
On behalf of Chad Elliott, Justin Michel, and OCI, Thanks.
Agree, Many developers prefer their native IDE project- , build-, and debug-management . The challenges do however soon become clear. Sooner or later changes to the native build files must go back to the .mpc or jam files. That becomes annoying, error prone, or outright neglected.
There are many reasons to prefer the native IDEs build/debug systems. One goal of MPC is to allow each developer to choose what they want to use. On the same project one developer can use Visual Studio 7.1 another 8 another NMake another gmake on Linux etc.
The MPC .mpt template files for the tools should be generated as well. This would be based on bbv2 so most redundant overlap should be avoidable.
Many template files are already available. New template files are needed only for new build systems.
Even if the mpc and qmake have their shiny aspects, I would be much more interested in good plug-in support for bbv2/bjam in IDEs such as Eclipse/CDE, VisualStudio, etc. In the IDE this should have the look and feel of the native build system if possible. This involves:
- adding and removing source files from projects in the IDE - creating new projects - starting bbv2 builds which reports errors into the IDE interface - execute or debug sessions should invoke build with bbv2 and offer to rebuild first if required - saving files could start background builds like in Eclipse managed C++ projects
This would seem much more difficult to produce/maintain and would likely never be as complete as using the native build system directly.
The funny thing is that I don't care that much myself for these features, I am more than happy with emacs + Boost.Build or whatever other _real_ build system is I use. What frustrates me is that so many developers use build systems that come with their IDE without any regard to the possible downsides they bring with them. Also, I believe real IDE plug-in support could be a boost in the popularity of bjam and Boost.Build.
With MPC you get the best of both worlds. I simply generate the native build files that I choose to use. Unfortunately, Jamfiles is not one of the supported output formats. KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com
Kevin Heifner wrote:
Subject: Re: [Ann] Boost and Google Summer of Code 2007
There are many reasons to prefer the native IDEs build/debug systems. One goal of MPC is to allow each developer to choose what they want to use. On the same project one developer can use Visual Studio 7.1 another 8 another NMake another gmake on Linux etc.
I've never head of MPC before this thread but it sounds interesting. Currently we are using .mmp files and makmake to generate CodeWarrior and Visual Studio projects. A .mpp file is horribly limited and we essentially just use it as a last resort to regenerate the native projects if something goes wrong. It sounds like MPC preforms a similar task to makmake just presumably much better. Would it be possible to set up a bbv2 Jamfile->MPC->{CodeWarrior .mcp | Visual Studio vcproj | etc.} chain so we could use Boost.Build as the primary build description and then use native IDE projects for the daily work (having MPC as an implementation detail presumably only on and run by the build server nightly to build fresh IDE projects from the Jamfiles)? Thanks, Michael Marcin
Kevin Heifner wrote:
Bjørn Roald wrote:
Jeff Garland wrote: MPC is nice and could be part of a solution if the requirements only where to produce IDE project and solution files from Jamfiles. Boost.Build and/or bjam could be extended to produce a <sub-project>.mpc file for each Jamfile and a <tool>.mpt file per tool(-set) used and then invoke mpc to generate the buildfiles. This should be recursive for a full project source tree.
We have thought about extending MPC to generate Jamfiles, but it has never risen to the top of things to do.
Understood. I guess from the MPC perspective Boost.Build is just another build tool that need to be supported. I do however not think .mpc files are likely to replace Jamfiles in boost as long as developers here are happy with bbv2. So from the Boost perspective, MPC is a tool that could bring the boost build configurations into most IDEs.
Someone of the folks at OCI previously put together a set of boost project files. Those are in the vault at:
These seems to be hand crafted. Is that correct? In that case I do not think this is the way to go.
Yes, these particular files were hand crafted. One of the nice things about MPC, however, is how easy it is to maintain the MPC files. Its inheritance feature of common base projects makes it very easy to make project wide changes to a build system. It is also very nice that source files do not have to be listed explicitly. To add a new file to a project is just a matter of running MPC, no modification to the build files are needed.
I was not aware of this. Is this similar to file-set feature in Ant. I guess you soon need some 'exclude' feature to support ignoring specific files.
Note, I haven't tried the Boost files, but I've used MPC on cross-platform projects -- it's a nifty solution.
On behalf of Chad Elliott, Justin Michel, and OCI, Thanks.
Agree, Many developers prefer their native IDE project- , build-, and debug-management . The challenges do however soon become clear. Sooner or later changes to the native build files must go back to the .mpc or jam files. That becomes annoying, error prone, or outright neglected.
There are many reasons to prefer the native IDEs build/debug systems. One goal of MPC is to allow each developer to choose what they want to use. On the same project one developer can use Visual Studio 7.1 another 8 another NMake another gmake on Linux etc.
That is nice, the question is if it is needed. Boost need support for compilers, not make tools. Hence Boost.Build has focus compiler support, not build tool support. It is a build tool itself, and with a set of Jamfiles it becomes a build system. It is however a fact that there are many features in the typical IDE which are useful for developers. So the features of MPC is most likely on the wish list for many Boost users, and probably some of the library authors and maintainers as well.
The MPC .mpt template files for the tools should be generated as well. This would be based on bbv2 so most redundant overlap should be avoidable.
Many template files are already available. New template files are needed only for new build systems.
How would compiler options be controlled, I envisioned that a different template was needed to set different defaults for the compiler. But I am probably wrong.
Even if the mpc and qmake have their shiny aspects, I would be much more interested in good plug-in support for bbv2/bjam in IDEs such as Eclipse/CDE, VisualStudio, etc. In the IDE this should have the look and feel of the native build system if possible. This involves:
- adding and removing source files from projects in the IDE - creating new projects - starting bbv2 builds which reports errors into the IDE interface - execute or debug sessions should invoke build with bbv2 and offer to rebuild first if required - saving files could start background builds like in Eclipse managed C++ projects
This would seem much more difficult to produce/maintain and would likely never be as complete as using the native build system directly.
Depend on who you think this is difficult for. My experience is that most developers do not pay much attentions to details in their build settings. That is also why all sorts of IDEs with wizards setting up projects this and that is so popular. When the individual project is set up, there is a set of inviting dialog boxes with a zillion option and check boxes to play with for each projects compiler options. When the projects become large, this approach does not scale. Someone has to start clean up and insert some control and discipline. So plain native build system does not work in real projects. The MPC approach fixes most problems, but it require developers to maintain the simpler configuration files manually. Well, they will not start using it until somebody forces them to do it. The create project menu in the IDE is too tempting. So to me it become clear that adding and removing files from projects in the build system should be integrated in the IDE. The MPC/qmake approach just make this a little tricky since the project/solution would need to be reloaded. I guess some sort of file-level synchronization is possible, but that would also be tricky.
The funny thing is that I don't care that much myself for these features, I am more than happy with emacs + Boost.Build or whatever other _real_ build system is I use. What frustrates me is that so many developers use build systems that come with their IDE without any regard to the possible downsides they bring with them. Also, I believe real IDE plug-in support could be a boost in the popularity of bjam and Boost.Build.
With MPC you get the best of both worlds. I simply generate the native build files that I choose to use. Unfortunately, Jamfiles is not one of the supported output formats.
Or input file formats ;-) Most people her at Boost would probably like that a lot. Thanks for a great tool anyway. -- Bjørn Roald
Bjørn Roald wrote:
Kevin Heifner wrote:
Understood. I guess from the MPC perspective Boost.Build is just another build tool that need to be supported. I do however not think .mpc files are likely to replace Jamfiles in boost as long as developers here are happy with bbv2. So from the Boost perspective, MPC is a tool that could bring the boost build configurations into most IDEs.
I understand. You are happy with bbv2 and see no reason to move away from it. So if MPC is going to be a part of Boost one of the following must happen: 1. New support to generate Jamfiles is added to MPC. 2. Something is created that can generate MPC files from Jamfiles. 3. Maintain two sets of files: MPC and Jamfiles. 4. (added after reading the last section of the email) Add Jamfile input file support to MPC.
Yes, these particular files were hand crafted. One of the nice things about MPC, however, is how easy it is to maintain the MPC files. Its inheritance feature of common base projects makes it very easy to make project wide changes to a build system. It is also very nice that source files do not have to be listed explicitly. To add a new file to a project is just a matter of running MPC, no modification to the build files are needed.
I was not aware of this. Is this similar to file-set feature in Ant. I guess you soon need some 'exclude' feature to support ignoring specific files.
Yes MPC allows the following: Source_Files { ^something.cpp !other.cpp } Both of these exclude the file. I however do not like source files laying around if they are not used; it is very confusing.
Many template files are already available. New template files are needed only for new build systems.
How would compiler options be controlled, I envisioned that a different template was needed to set different defaults for the compiler. But I am probably wrong.
Compiler options are controlled by commands in MPC files. For example, if you want to pass a particular macro to the compiler: macros += _AFXEXT
Depend on who you think this is difficult for. My experience is that most developers do not pay much attentions to details in their build settings. That is also why all sorts of IDEs with wizards setting up projects this and that is so popular. When the individual project is set up, there is a set of inviting dialog boxes with a zillion option and check boxes to play with for each projects compiler options. When the projects become large, this approach does not scale. Someone has to start clean up and insert some control and discipline. So plain native build system does not work in real projects. The MPC approach fixes most problems, but it require developers to maintain the simpler configuration files manually. Well, they will not start using it until somebody forces them to do it. The create project menu in the IDE is too tempting. So to me it become clear that adding and removing files from projects in the build system should be integrated in the IDE. The MPC/qmake approach just make this a little tricky since the project/solution would need to be reloaded. I guess some sort of file-level synchronization is possible, but that would also be tricky.
The difficultly I was referring to was the actual creation/maintenance of the plugins. Since MPC can pick up files automatically in most cases, normally all that is required is rerunning MPC. My daily activity on a project is to follow every cvs/svn update with a run of MPC. If I need to add/remove a file all that is likely needed is to rerun MPC.
With MPC you get the best of both worlds. I simply generate the native build files that I choose to use. Unfortunately, Jamfiles is not one of the supported output formats.
Or input file formats ;-) Most people her at Boost would probably like that a lot. Thanks for a great tool anyway.
That is one option I had not considered. I don't think it very likely, but still something to think about. KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com
Kevin Heifner wrote:
Bjørn Roald wrote:
Kevin Heifner wrote:
Understood. I guess from the MPC perspective Boost.Build is just another build tool that need to be supported. I do however not think .mpc files are likely to replace Jamfiles in boost as long as developers here are happy with bbv2. So from the Boost perspective, MPC is a tool that could bring the boost build configurations into most IDEs.
I understand. You are happy with bbv2 and see no reason to move away from it. So if MPC is going to be a part of Boost one of the following must happen:
1. New support to generate Jamfiles is added to MPC.
I think this is mainly a benefit to those who have selected .mpc files as method to specify projects. This is not the case for the boost libraries. I can not speak for the authors, but I do not think there are compelling reasons to switch.
2. Something is created that can generate MPC files from Jamfiles.
This would be useful. MPC itself does not need to be in the boost distro for this scheme to work. All that is needed is that something can generate the .mpc files. One natural choice would be an add-on to bbv2 since it already parses the Jamfiles.
3. Maintain two sets of files: MPC and Jamfiles.
I prefer to ignore this option until other options are tried.
4. (added after reading the last section of the email) Add Jamfile input file support to MPC.
Yes, If the semantics of the information in .mpc files and Jamfiles are close, this may be feasible. Would be fun to try it out anyway. Think I need better understanding of the two file formats first. <snipped a lot>
Depend on who you think this is difficult for. My experience is that most developers do not pay much attentions to details in their build settings. That is also why all sorts of IDEs with wizards setting up projects this and that is so popular. When the individual project is set up, there is a set of inviting dialog boxes with a zillion option and check boxes to play with for each projects compiler options. When the projects become large, this approach does not scale. Someone has to start clean up and insert some control and discipline. So plain native build system does not work in real projects. The MPC approach fixes most problems, but it require developers to maintain the simpler configuration files manually. Well, they will not start using it until somebody forces them to do it. The create project menu in the IDE is too tempting. So to me it become clear that adding and removing files from projects in the build system should be integrated in the IDE. The MPC/qmake approach just make this a little tricky since the project/solution would need to be reloaded. I guess some sort of file-level synchronization is possible, but that would also be tricky.
The difficultly I was referring to was the actual creation/maintenance of the plugins.
I think I knew that was what you referred to ;-) I do not contend that this may be challenging, but if it succeeds it would be the solution that added most value to users of the tool.
Since MPC can pick up files automatically in most cases, normally all that is required is rerunning MPC. My daily activity on a project is to follow every cvs/svn update with a run of MPC. If I need to add/remove a file all that is likely needed is to rerun MPC.
Then reload the solution/project in your IDE.
With MPC you get the best of both worlds. I simply generate the native build files that I choose to use. Unfortunately, Jamfiles is not one of the supported output formats.
Or input file formats ;-) Most people her at Boost would probably like that a lot. Thanks for a great tool anyway.
That is one option I had not considered. I don't think it very likely, but still something to think about.
Maybe somebody around here would contribute an optional parser to MPC ;-) -- Bjørn Roald
Bjørn Roald wrote: I'll just comment on the options that I think have potential. The others probably won't fly given that bjam isn't going to be dumped as the primary developer interface at this stage.
2. Something is created that can generate MPC files from Jamfiles.
This would be useful. MPC itself does not need to be in the boost distro for this scheme to work. All that is needed is that something can generate the .mpc files. One natural choice would be an add-on to bbv2 since it already parses the Jamfiles.
Agree that this would be handy and would go over well with fans of boost build. If you took a particular library it would somehow have to get all the rules from the tools/build/v2/*.jam files for a given environment to produce the needed mpc information. The potential problem I see is that MPC embeds some of this same information in it's template files...so you might have to 'templatize the mpc templates' so the nitty gritty details of toolset configurations can be exposed.
3. Maintain two sets of files: MPC and Jamfiles.
I prefer to ignore this option until other options are tried.
Probably not.
4. (added after reading the last section of the email) Add Jamfile input file support to MPC.
Yes, If the semantics of the information in .mpc files and Jamfiles are close, this may be feasible. Would be fun to try it out anyway. Think I need better understanding of the two file formats first.
MPC isn't a build system, so it's a bit different. None-the-less all the details of how to configure compile options and such need to be in the MPC and Jamfiles. Both MPC and Jam put this mostly behind the scenes with a good set of defaults. So, this also might be another valid approach. Jeff
Jeff Garland wrote:
Bjørn Roald wrote:
2. Something is created that can generate MPC files from Jamfiles.
This would be useful. MPC itself does not need to be in the boost distro for this scheme to work. All that is needed is that something can generate the .mpc files. One natural choice would be an add-on to bbv2 since it already parses the Jamfiles.
Agree that this would be handy and would go over well with fans of boost build. If you took a particular library it would somehow have to get all the rules from the tools/build/v2/*.jam files for a given environment to produce the needed mpc information. The potential problem I see is that MPC embeds some of this same information in it's template files...so you might have to 'templatize the mpc templates' so the nitty gritty details of toolset configurations can be exposed.
OCI is going to take a look at developing a perl script that will convert Jamfiles to MPC files.
4. (added after reading the last section of the email) Add Jamfile input file support to MPC.
Yes, If the semantics of the information in .mpc files and Jamfiles are close, this may be feasible. Would be fun to try it out anyway. Think I need better understanding of the two file formats first.
MPC isn't a build system, so it's a bit different. None-the-less all the details of how to configure compile options and such need to be in the MPC and Jamfiles. Both MPC and Jam put this mostly behind the scenes with a good set of defaults. So, this also might be another valid approach.
After discussing this with Chad Elliott the main MPC developer we don't believe that this would be appropriate. KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com
Kevin Heifner wrote:
Jeff Garland wrote:
Bjørn Roald wrote:
2. Something is created that can generate MPC files from Jamfiles.
This would be useful. MPC itself does not need to be in the boost distro for this scheme to work. All that is needed is that something can generate the .mpc files. One natural choice would be an add-on to bbv2 since it already parses the Jamfiles.
Agree that this would be handy and would go over well with fans of boost build. If you took a particular library it would somehow have to get all the rules from the tools/build/v2/*.jam files for a given environment to produce the needed mpc information. The potential problem I see is that MPC embeds some of this same information in it's template files...so you might have to 'templatize the mpc templates' so the nitty gritty details of toolset configurations can be exposed.
OCI is going to take a look at developing a perl script that will convert Jamfiles to MPC files.
Great :-) I may help out a bit if needed.
4. (added after reading the last section of the email) Add Jamfile input file support to MPC.
Yes, If the semantics of the information in .mpc files and Jamfiles are close, this may be feasible. Would be fun to try it out anyway. Think I need better understanding of the two file formats first.
MPC isn't a build system, so it's a bit different. None-the-less all the details of how to configure compile options and such need to be in the MPC and Jamfiles. Both MPC and Jam put this mostly behind the scenes with a good set of defaults. So, this also might be another valid approach.
After discussing this with Chad Elliott the main MPC developer we don't believe that this would be appropriate.
I can understand that as it would complicate MPC itself. -- Bjørn Roald
Jeff Garland wrote:
Bjørn Roald wrote:
I'll just comment on the options that I think have potential. The others probably won't fly given that bjam isn't going to be dumped as the primary developer interface at this stage.
2. Something is created that can generate MPC files from Jamfiles.
This would be useful. MPC itself does not need to be in the boost distro for this scheme to work. All that is needed is that something can generate the .mpc files. One natural choice would be an add-on to bbv2 since it already parses the Jamfiles.
Agree that this would be handy and would go over well with fans of boost build. If you took a particular library it would somehow have to get all the rules from the tools/build/v2/*.jam files for a given environment to produce the needed mpc information. The potential problem I see is that MPC embeds some of this same information in it's template files...so you might have to 'templatize the mpc templates' so the nitty gritty details of toolset configurations can be exposed.
I agree. But I am not sure if all of this need to be addressed at the first shot at a tool. I spend some time reading docs for bbv2 and mpc now, so soon I will have better understanding of formats and semantics.
4. (added after reading the last section of the email) Add Jamfile input file support to MPC.
Yes, If the semantics of the information in .mpc files and Jamfiles are close, this may be feasible. Would be fun to try it out anyway. Think I need better understanding of the two file formats first.
MPC isn't a build system, so it's a bit different. None-the-less all the details of how to configure compile options and such need to be in the MPC and Jamfiles. Both MPC and Jam put this mostly behind the scenes with a good set of defaults. So, this also might be another valid approach.
I guess this can be done in two steps 1. Translates Jamfiles to mpc files (as OCI is now offering support for) 2. MPC generate workspace/project files (as supported by in existing MPC) This may be an ok solution. -- Bjørn Roald
John Maddock wrote:
Mathias Gaunard wrote:
What's the point of recursive regexes since we have xpressive?
xpressive can do that with static regexes, but not dynamic ones (interpreted strings).
This was on my TODO list for a long time, so I just implemented it. You can now build grammars with dynamic regexes, parsed at runtime. Here is a regex that matches infix algebraic expressions: using namespace boost::xpressive; using namespace regex_constants; sregex expr; { sregex_compiler compiler; syntax_option_type x = ignore_white_space; compiler.compile( "(? $group = ) \\( (? $expr ) \\) ", x); compiler.compile( "(? $factor = ) \\d+ | (? $group ) ", x); compiler.compile( "(? $term = ) (? $factor ) " " ( \\* (? $factor ) | / (? $factor ) )* ", x); expr = compiler.compile( "(? $expr = ) (? $term ) " " ( \\+ (? $term ) | - (? $term ) )* ", x); } std::string str("foo 9*(10+3) bar"); smatch what; if(regex_search(str, what, expr)) { // This prints "9*(10+3)": std::cout << what[0] << std::endl; } After the match, match results object contains the complete parse tree, where each invocation of a named regex creates a nested match results object. It's a runtime configurable recursive descent parser (w/o semantic actions), with exhaustive backtracking semantics. -- Eric Niebler Boost Consulting www.boost-consulting.com
Hi, I am wondering whatever happened to the few interesting projects from last years SOC (2006). How many are going to see the day of light in Boost if ever (well at least bimap got accepted, thanks Matias). Its just taking too long and the Boost patching/submission/review etc. all need to be reviewed. Just look at how long 1.34 is taking. I feel like swearing :-(
From SOC 2006 I was really looking forward to boost::process.
Shams -- "Mathias Gaunard" <mathias.gaunard@etu.u-bordeaux1.fr> wrote in message news:es9muf$rf$1@sea.gmane.org...
John Maddock wrote:
It is a pleasure to announce that Boost will be applying as a mentoring organization for the upcoming Google Summer of Code 2007. There is a lot of preparation work to be done and little time to do it.
A page has been set up at the Boost Wiki:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer...
which will hold a list of preliminary ideas for students to take up and use in their own applications to GSoC07.
What's the point of recursive regexes since we have xpressive?
Before application level networking protocols, wouldn't it be better to have an iostreams wrapper for asio?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Shams wrote:
Hi,
I am wondering whatever happened to the few interesting projects from last years SOC (2006). How many are going to see the day of light in Boost if ever (well at least bimap got accepted, thanks Matias). Its just taking too long and the Boost patching/submission/review etc. all need to be reviewed. Just look at how long 1.34 is taking.
I feel like swearing :-(
From SOC 2006 I was really looking forward to boost::process.
At least a few of them are still being worked on. I update my local checkout of the SoC repository every few weeks. I was delighted to see new work on the concurrency project recently. - Michael Marcin
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 02 March 2007 13:51 To: Boost mailing list; boost-users; boost-announce Subject: [boost] [Ann] Boost and Google Summer of Code 2007
Dear Boosters,
It is a pleasure to announce that Boost will be applying as a mentoring organization for the upcoming Google Summer of Code 2007. There is a lot of preparation work to be done and little time to do it.
A page has been set up at the Boost Wiki:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl? Google_Summer_Of_Code_2007
HTML and RST to QuickBook converter has been proposed. I strongly support this. It may appear an obscure utility but it would help to overcome some of the serious documentation problems we have - the invaluable and essential Boost.Test for a very important example. In an attempt to help improve the documentation, I spent some time installing Dreamweaver (thereby clogging up my already bloated registry so it takes even longer to boot up and close down :-(( ). It is a fine tool for producing fancy 'designer' documents, but has a substantial learning curve, and it far too complicated for the job in hand. It also only works on Windows. Similarly Mozilla while portable doesn't handle the output from Dreamweaver well. So it proved impossible to work JOINTLY with Gennadiy on the document. On the other hand QuickBook (very similar to DocBook as used on Wikipedia) only needs an IQ into double figures and Notepad, and does the job in hand. Most important, for joint development, I found it very easy to use files in the Boost-sandbox with CVS and correct spelling mistakes in John Maddock's Math Toolkit ;-)) This would allow users to add their bits to a sandbox version and the author could accept or reject for the next release. The final Quickbook source is then in a standardized format that can output in html and pdf etc. It is already possible to use 'Find' on a pdf document - something that is a reasonable substitute for an index - and that would have avoided much of the difficulty using Boost Test documentation (and other html docus) - knowing something is there but not being able to find it. Finally I'd like to add a requirement for an indexing tool for Quickbook, perhaps using Google Indexing service. (John and I also found producing simple graphs of math functions messy - and would like a version that output nice small (Scalable Vector Graphics) SVGs. A Boost C++ tool to produce these from vectors, say, might be a small suitable project?). Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul A Bristow Sent: 03 March 2007 12:11 To: boost@lists.boost.org Subject: Re: [boost] [Ann] Boost and Google Summer of Code 2007 - html & RSTto Quickbook
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 02 March 2007 13:51 To: Boost mailing list; boost-users; boost-announce Subject: [boost] [Ann] Boost and Google Summer of Code 2007
snip
(John and I also found producing simple graphs of math functions messy - and would like a version that output nice small (Scalable Vector Graphics) SVGs.
A Boost C++ tool to produce these from vectors, say, might be a small suitable project?).
A proposal has been added to the wiki
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl? Google_Summer_Of_Code_2007
- this project is small enough to have a good chance of completion in the short time. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow wrote:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl? Google_Summer_Of_Code_2007
HTML and RST to QuickBook converter has been proposed.
Yes. I proposed that. In case anybody ws wondering. -Thorsten
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Thorsten Ottosen Sent: 05 March 2007 21:34 To: boost@lists.boost.org Subject: Re: [boost] [Ann] Boost and Google Summer of Code 2007 - html & RST to Quickbook
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl? Google_Summer_Of_Code_2007
HTML and RST to QuickBook converter has been proposed.
Yes. I proposed that. In case anybody ws wondering.
Should the proposer's name be shown somewhere on the GSOC wiki page? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Thorsten Ottosen wrote:
Paul A Bristow wrote:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl? Google_Summer_Of_Code_2007
HTML and RST to QuickBook converter has been proposed.
Yes. I proposed that. In case anybody ws wondering.
FYI... Once upon a time I posted a CSS file that would render any of the Boost pages as close to valid QuickBook. Assuming that the browser would allow it one could copy+paste the result into a new file. At the time only Opera allowed that though. -- -- 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
Rene Rivera wrote:
Thorsten Ottosen wrote:
Paul A Bristow wrote:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl? Google_Summer_Of_Code_2007 HTML and RST to QuickBook converter has been proposed. Yes. I proposed that. In case anybody ws wondering.
FYI... Once upon a time I posted a CSS file that would render any of the Boost pages as close to valid QuickBook. Assuming that the browser would allow it one could copy+paste the result into a new file. At the time only Opera allowed that though.
PS... Here's the post <http://article.gmane.org/gmane.comp.lib.boost.documentation/1632> -- -- 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
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: 06 March 2007 02:09 To: boost@lists.boost.org Subject: Re: [boost] [Ann] Boost and Google Summer of Code 2007 - html & RST to Quickbook
FYI... Once upon a time I posted a CSS file that would render any of the Boost pages as close to valid QuickBook. Assuming that the browser would allow it one could copy+paste the result into a new file. At the time only Opera allowed that though.
PS... Here's the post <http://article.gmane.org/gmane.comp.lib.boost.documentation/1632>
But don't' we want to take a whole doc SET of linked pages - Boost.Test for example and convert it ALL to Quickbook file(s?). Only then can everyone contribute to improvements? (I also worry about the amount of noise and clutter - from my terrible experience of Word to html and glancing at the output from Dreamweaver.) Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow wrote:
[mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera
FYI... Once upon a time I posted a CSS file that would render any of the Boost pages as close to valid QuickBook. Assuming that the browser would allow it one could copy+paste the result into a new file. At the time only Opera allowed that though. PS... Here's the post <http://article.gmane.org/gmane.comp.lib.boost.documentation/1632>
But don't' we want to take a whole doc SET of linked pages - Boost.Test for example and convert it ALL to Quickbook file(s?). Only then can everyone contribute to improvements?
Yes! That's why I mention in the post that my CSS is a "gag". It so happens that it might help a person save a few minutes if they are doing a manual translation but it's not a real solution. -- -- 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
John Maddock wrote:
Dear Boosters,
It is a pleasure to announce that Boost will be applying as a mentoring organization for the upcoming Google Summer of Code 2007. There is a lot of preparation work to be done and little time to do it.
A page has been set up at the Boost Wiki:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer...
Interestingly, 2 out of 7 proposals are extensions for the asio library. These are: - Implementing application level protocols using asio - Implementing an ORB/RPC system using asio First of all, both proposals don't say if they are server side or client side projects. Second, libhttp referenced in the first project already implements some functionality of both proposals. More to the point, it is released under BSD and Boost licenses and IS BASED on asio. I don't know if the author is a student and willing to participate. In my opinion, the second project is too big for one student. I don't know much about ORB but CORBA standards assume that language binding code is generated from IDL. This means that a student should first implement a parser (or use existing license compatible parser) and a code generator. There is another approach for server side. Use Boost.Langbinding syntax instead of IDL but this already if big enough for a separate project. So, I would spent time on libhttp rather than on these projects. Other interesting project related to asio is asyncronous database access. Postgres and Sybase client libraries have async interface. Postgres is probably only available on POSIX (I haven't checked it) but Sybase has dbpoll on systems where connection fd (in unix terminology) doesn't not exist. -- Alexander Nasonov http://nasonov.blogspot.com The one thing I want to leave my children is an honorable name. -- Theodore Roosevelt -- This quote is generated by: /usr/pkg/bin/curl -L http://tinyurl.com/veusy \ | sed -e 's/^document\.write(.//' -e 's/.);$/ --/' \ -e 's/<[^>]*>//g' -e 's/^More quotes from //' \ | fmt | tee ~/.signature-quote
Alexander Nasonov wrote:
Other interesting project related to asio is asyncronous database access.
I am personally still looking forward to asynchronous access to pipes and such. I thought this was supposed to come with a later version of boost.process, but I don't even know what the status of boost.process is now.
On 04/03/2007, at 3:08, Mathias Gaunard wrote:
Alexander Nasonov wrote:
Other interesting project related to asio is asyncronous database access.
I am personally still looking forward to asynchronous access to pipes and such. I thought this was supposed to come with a later version of boost.process, but I don't even know what the status of boost.process is now.
This is something I want to continue working on eventually, but other stuff (university and some other projects) have got in the way :-( I think the version in the Subversion repository works, and it has evolved somewhat since the 0.1 release was published based on multiple suggestions from the preliminary review. Fortunately, when I get back to this, development should be far easier thanks to Parallels and virtualization, that I can now run in my machine :-) FWIW the next step in Boost.Process I was going to take was exactly that: allow asynchronous communication with child processes and asynchronous notification of their termination. But I got stalled trying to understand how to merge this features properly into Boost.Asio and didn't have enough time to continue investigating how to achieve this. Kind regards, -- Julio M. Merino Vidal <jmmv84@gmail.com>
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Alexander Nasonov Sent: Saturday, March 03, 2007 11:49 PM Subject: [boost] asio projects (was: Boost and Google Summer of Code 2007)
In my opinion, the second project is too big for one student. I don't know much about ORB but CORBA standards assume that language binding code is generated from IDL. This means that a student should first implement a parser (or use existing license compatible parser) and a code generator. There is another approach for server side. Use Boost.Langbinding syntax instead of IDL but this already if big enough for a separate project.
So, I would spent time on libhttp rather than on these projects.
I beg to differ, at least somehow. Although I'm with you, that a whole ORB implementation would not even remotely be feasible, I think a more constraint approach could be both interesting and useful. Would it be possible to rephrase that proposal to sth. like: 'Implement GIOP 1.2 on top of asio'? It would probably be most natural to concentrate on the asynchronous flavours of CORBA: * AMI on the client side (it's in the offical CORBA specs) * AMH for the server side (it's a proposal by Douglas Schmidt and implemented in TAO, see www.cs.wustl.edu/~schmidt/PDF/AMH.pdf for example) Both flavours shouldn't differ on the protocol level from the normal synchronous approach but most probably they will affect the API layer. Some further points may be important: * Nicely separate layers 7 (GIOP primitives) and 6 (CDR) * Use TAO, OmniORB and/or a Java ORB (JacORB or the Sun ORB) to test interoperability * Provide an API to enable tampering with other protocol implementations (this would include the ability to customise the stack down to the bits) * Provide backwards compatibility with GIOP 1.1 and 1.0 As a possible outcome/proof of concept I could imagine the following (in ascending order of complexity): * Provide a transparent GIOP proxy, e.g. for logging the traffic between two ORBs * Try to replace the native GIOP stack in TAO or OmniORB with the new one and measure performance differences for common usage scenarios * Provide python bindings for the mentioned tamoering API cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | ames AT avaya DOT com Sitz der Gesellschaft: Stuttgart Registergericht: Amtsgericht Stuttgart - HRB 22107 Geschäftsführer: Andreas von Meyer zu Knonow, Udo Bühler, Thomas Kreikemeier
Ames Andreas wrote:
I beg to differ, at least somehow. Although I'm with you, that a whole ORB implementation would not even remotely be feasible, I think a more constraint approach could be both interesting and useful.
Would it be possible to rephrase that proposal to sth. like:
'Implement GIOP 1.2 on top of asio'?
It would probably be most natural to concentrate on the asynchronous flavours of CORBA:
* AMI on the client side (it's in the offical CORBA specs)
* AMH for the server side (it's a proposal by Douglas Schmidt and implemented in TAO, see www.cs.wustl.edu/~schmidt/PDF/AMH.pdf for example)
I know nothing about AMI and AMH but it seems like a good approach.
Both flavours shouldn't differ on the protocol level from the normal synchronous approach but most probably they will affect the API layer.
Some further points may be important:
* Nicely separate layers 7 (GIOP primitives) and 6 (CDR)
* Use TAO, OmniORB and/or a Java ORB (JacORB or the Sun ORB) to test interoperability
* Provide an API to enable tampering with other protocol implementations (this would include the ability to customise the stack down to the bits)
* Provide backwards compatibility with GIOP 1.1 and 1.0
As a possible outcome/proof of concept I could imagine the following (in ascending order of complexity):
* Provide a transparent GIOP proxy, e.g. for logging the traffic between two ORBs
If the proxy is the only thing an end-user could try, it is probably not worth the effort.
* Try to replace the native GIOP stack in TAO or OmniORB with the new one and measure performance differences for common usage scenarios
I like the idea. This would open up a possibility to share asio "channel" with other network activities of an application. Do you have a estimate on a completity of this task?
* Provide python bindings for the mentioned tamoering API
-- Alexander Nasonov http://nasonov.blogspot.com God loves each of us as if there were only one of us. -- Saint Augustine -- This quote is generated by: /usr/pkg/bin/curl -L http://tinyurl.com/veusy \ | sed -e 's/^document\.write(.//' -e 's/.);$/ --/' \ -e 's/<[^>]*>//g' -e 's/^More quotes from //' \ | fmt | tee ~/.signature-quote
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Alexander Nasonov Sent: Monday, March 05, 2007 8:33 PM Subject: Re: [boost] asio projects (was: Boost and Google Summer of Code2007)
If the proxy is the only thing an end-user could try, it is probably not worth the effort.
Granted, it wouldn't possibly be too challenging. But it would be a reasonable, assesable target for a time constraint project.
* Try to replace the native GIOP stack in TAO or OmniORB with the new one and measure performance differences for common usage scenarios
I like the idea. This would open up a possibility to share asio "channel" with other network activities of an application. Do you have a estimate on a completity of this task?
To be honest, I don't know; such an estimation would need to be part of the project itself. Nevertheless I would guess that it's feasible given that TAO has an explicit API to replace its own GIOP stack, see: www.cs.wustl.edu/~schmidt/PDF/pluggable_protocols.pdf I don't know of a similar API in omniORB but at least it supports a 'pluggable transport framework', i.e. you can 'easily' replace the transport layer beneath GIOP (usually IIOP). How this extends to a GIOP replacement would need to be researched separately. FWIW, the CORBA spec explicitly mentions that protocols other than GIOP should be possible (within the abstract CORBA architecture). Another interesting project goal would be to create an API that allows writing compliant objects and/or clients without IDL support. CORBA has the Dynamic Invocation Interface (client side) and the Dynamic Skeleton API (server side). Maybe a student would be interested in trying to create a good generic interface to show off the power of generic programming compared to those more traditional approaches. cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | ames AT avaya DOT com Sitz der Gesellschaft: Stuttgart Registergericht: Amtsgericht Stuttgart - HRB 22107 Geschäftsführer: Andreas von Meyer zu Knonow, Udo Bühler, Thomas Kreikemeier
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Ames Andreas Sent: Tuesday, March 06, 2007 11:05 AM Subject: Re: [boost] asio projects (was: Boost and Google Summer of Code2007)
Another interesting project goal would be to create an API that allows writing compliant objects and/or clients without IDL support. CORBA has the Dynamic Invocation Interface (client side) and the Dynamic Skeleton API (server side). Maybe a student would be interested in trying to create a good generic interface to show off the power of generic programming compared to those more traditional approaches.
Following up to myself, a further building block could be to try to create a CDR archive for Boost.Serialization... cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | ames AT avaya DOT com Sitz der Gesellschaft: Stuttgart Registergericht: Amtsgericht Stuttgart - HRB 22107 Geschäftsführer: Andreas von Meyer zu Knonow, Udo Bühler, Thomas Kreikemeier
Alexander Nasonov wrote:
Ames Andreas wrote:
I beg to differ, at least somehow. Although I'm with you, that a whole ORB implementation would not even remotely be feasible, I think a more constraint approach could be both interesting and useful.
I've added a note to the Wiki to this effect -- hopefully warning students away. I see no way that this project is feasible within the time constraints of an SoC project, so it's unlikely that the mentoring team will approve it. The scope would need to be much more limited and defined. Jeff
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Garland Sent: Tuesday, March 06, 2007 3:49 PM Subject: Re: [boost] [soc] orb project was (asio projects)
The scope would need to be much more limited and defined.
How can I do that? Should I directly edit the wiki? If so, should I edit the proposal or write a new one? Or should I write a summary of the ideas mentioned in this thread (concerning this project) to the list? cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | ames AT avaya DOT com Sitz der Gesellschaft: Stuttgart Registergericht: Amtsgericht Stuttgart - HRB 22107 Geschäftsführer: Andreas von Meyer zu Knonow, Udo Bühler, Thomas Kreikemeier
Ames Andreas wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Garland Sent: Tuesday, March 06, 2007 3:49 PM Subject: Re: [boost] [soc] orb project was (asio projects)
The scope would need to be much more limited and defined.
How can I do that? Should I directly edit the wiki?
Yes.
If so, should I edit the proposal or write a new one?
Either way.
Or should I write a summary of the ideas mentioned in this thread (concerning this project) to the list?
That would be a start, but I'm still concerned there isn't enough depth in any of the discussion of a reasonable project size. I can see CDR archive for serialization lib as doable -- too small really. Frankly the only way I can see something going towards ORB implementation is if the student had some significant experience with ACE/TAO/Boost and could show that the project would be doable. Not trying to discourage, but a couple months go really quick... Jeff
Jeff Garland wrote:
Alexander Nasonov wrote:
Ames Andreas wrote:
I beg to differ, at least somehow. Although I'm with you, that a whole ORB implementation would not even remotely be feasible, I think a more constraint approach could be both interesting and useful.
I've added a note to the Wiki to this effect -- hopefully warning students away. I see no way that this project is feasible within the time constraints of an SoC project, so it's unlikely that the mentoring team will approve it. The scope would need to be much more limited and defined.
Out of curiosity: What's the relationship between an ORB and boost.org, and why would boost.org want to have its own ? Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Jeff Garland wrote:
Alexander Nasonov wrote:
Ames Andreas wrote:
I beg to differ, at least somehow. Although I'm with you, that a whole ORB implementation would not even remotely be feasible, I think a more constraint approach could be both interesting and useful. I've added a note to the Wiki to this effect -- hopefully warning students away. I see no way that this project is feasible within the time constraints of an SoC project, so it's unlikely that the mentoring team will approve it. The scope would need to be much more limited and defined.
Out of curiosity: What's the relationship between an ORB and boost.org, and why would boost.org want to have its own ?
Good question. Some would probably like to have an ORB solution based on Boost because it would be 'lighter weight' than an ACE/TAO solution. The problem I see is that there's alot of stuff needed to use an ORB (like an IDL compiler) that Boost won't have. So, for a long time you'd wind up with ACE/TAO and Boost. A project that would align more closely with the Boost mission would be a redo of the CORBA binding (it's awful) for C++ using TR1 and other modern C++. This might be more of a design and prototype project that would require both Boost (for things like smart ptrs) and TAO. That's probably too big a project for SoC, but it would be working with a current well defined interface. And there wouldn't be any illusion that it would be going into Boost right away...although that makes is less attractive as a Boost project. Jeff
Jeff Garland wrote:
Stefan Seefeld wrote:
Out of curiosity: What's the relationship between an ORB and boost.org, and why would boost.org want to have its own ?
Good question. Some would probably like to have an ORB solution based on Boost because it would be 'lighter weight' than an ACE/TAO solution. The
What makes you think that ? ACE (and TAO) has been worked on for a long time. (The same is true for other ORBs, such as OmniORB.) Do you seriously thinking an ORB will be 'better' just because it's built on boost.org components ?
problem I see is that there's alot of stuff needed to use an ORB (like an IDL compiler) that Boost won't have. So, for a long time you'd wind up with ACE/TAO and Boost.
That, too. I'm just wondering what the intend is, as it seems to me to be completely out-of-scope.
A project that would align more closely with the Boost mission would be a redo of the CORBA binding (it's awful) for C++ using TR1 and other modern C++.
Indeed, that would be good, though judging from history, a process that may be even longer than TR3. :-) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Garland Sent: Tuesday, March 06, 2007 4:32 PM Subject: Re: [boost] [soc] orb project was (asio projects)
Stefan Seefeld wrote:
Jeff Garland wrote: Out of curiosity: What's the relationship between an ORB and boost.org, and why would boost.org want to have its own ?
Good question. Some would probably like to have an ORB
I'd say, there is no such relation. As I said before, I don't think a useful ORB implementation would be doable in 3 month (or even thirteen months). The proposal as it stands is not practical (if such a thing as a Boost ORB would be considered useful at all). I propose a different project, maybe as a subproject of 'Implementing application level protocols using asio'. Proposal -------- Implement GIOP 1.2 on top of asio Introduction ------------ GIOP is commonly used as an communications protocal between CORBA ORBs. Unfortunately the programming model that CORBA exposes is cumbersome (although portable and language agnostic). Furthermore standard CORBA doesn't provide an asynchronous API on the server side. This project should create a strictly asynchronous API for low-level GIOP programming on top of boost's asio library. Goal ---- The library created by this project should enable writing servers and/or clients purely in C++ (i.e. without IDL etc.) that can communicate with CORBA ORB implementations (analogy: you can implement HTTP communications without a SOAP framework). The protocol is well documented and features only eight message types. Additional points of interest: * The lib should cleanly seperate OSI layer 7 (GIOP messages) from layer 6 (CDR). Layer 6 could perhaps be implemented as a serialization archive. * Only IIOP and TCP as transport layer is of interest. * The lib should/could provide a whole range of customisation points such that the user can directly control possibly every aspect of message assembly down to the bitstream. This could be useful to test ORB applications. * The implementation should provide backwards compatibility to GIOP 1.0 and 1.1. * An optional goal could be to show off the interoperability of the protocol implementation by providing a simple 'transparent' gateway between a traditional CORBA object and a traditional CORBA client (like between the usual 'echo' object and its client) Requirements: ------------ Knowledge or the ability to become acquainted with: * C++ * Selected Boost libraries (at least asio and serialization, hopefully others) * Event-driven programming * Understanding and implementing network protocols cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | ames AT avaya DOT com Sitz der Gesellschaft: Stuttgart Registergericht: Amtsgericht Stuttgart - HRB 22107 Geschäftsführer: Andreas von Meyer zu Knonow, Udo Bühler, Thomas Kreikemeier
As a former CORBA user, I'm just concerned that there is not a real need for an ORB from Boost. The only way I could see it being more useful than others would be if it changed the current C++ bindings, as mentioned by a previous post (Bjarne Stroustrup has mentioned this too). This would take a lot of work, and it might only be feasible with the support of the C++ standards committee or the OMG. In addition, CORBA does seem to be rather out of fashion (I don't know how much of that is just because of the API, or better marketing from the latest fads). Working on other extensions to Boost.Asio would probably be more useful. Not to discourage you, but I think it may be better to focus energies elsewhere. Jeremy Pack On 3/6/07, Ames Andreas <Andreas.Ames@comergo.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Garland Sent: Tuesday, March 06, 2007 4:32 PM Subject: Re: [boost] [soc] orb project was (asio projects)
Stefan Seefeld wrote:
Jeff Garland wrote: Out of curiosity: What's the relationship between an ORB and boost.org, and why would boost.org want to have its own ?
Good question. Some would probably like to have an ORB
I'd say, there is no such relation. As I said before, I don't think a useful ORB implementation would be doable in 3 month (or even thirteen months). The proposal as it stands is not practical (if such a thing as a Boost ORB would be considered useful at all).
I propose a different project, maybe as a subproject of 'Implementing application level protocols using asio'.
Proposal --------
Implement GIOP 1.2 on top of asio
Introduction ------------
GIOP is commonly used as an communications protocal between CORBA ORBs. Unfortunately the programming model that CORBA exposes is cumbersome (although portable and language agnostic). Furthermore standard CORBA doesn't provide an asynchronous API on the server side. This project should create a strictly asynchronous API for low-level GIOP programming on top of boost's asio library.
Goal ----
The library created by this project should enable writing servers and/or clients purely in C++ (i.e. without IDL etc.) that can communicate with CORBA ORB implementations (analogy: you can implement HTTP communications without a SOAP framework).
The protocol is well documented and features only eight message types.
Additional points of interest:
* The lib should cleanly seperate OSI layer 7 (GIOP messages) from layer 6 (CDR). Layer 6 could perhaps be implemented as a serialization archive.
* Only IIOP and TCP as transport layer is of interest.
* The lib should/could provide a whole range of customisation points such that the user can directly control possibly every aspect of message assembly down to the bitstream. This could be useful to test ORB applications.
* The implementation should provide backwards compatibility to GIOP 1.0 and 1.1.
* An optional goal could be to show off the interoperability of the protocol implementation by providing a simple 'transparent' gateway between a traditional CORBA object and a traditional CORBA client (like between the usual 'echo' object and its client)
Requirements: ------------
Knowledge or the ability to become acquainted with:
* C++
* Selected Boost libraries (at least asio and serialization, hopefully others)
* Event-driven programming
* Understanding and implementing network protocols
cheers,
aa
-- Andreas Ames | Programmer | Comergo GmbH | ames AT avaya DOT com
Sitz der Gesellschaft: Stuttgart Registergericht: Amtsgericht Stuttgart - HRB 22107 Geschäftsführer: Andreas von Meyer zu Knonow, Udo Bühler, Thomas Kreikemeier _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, 06 Mar 2007 08:31:55 -0700 Jeff Garland <jeff@crystalclearsoftware.com> wrote:
A project that would align more closely with the Boost mission would be a redo of the CORBA binding (it's awful) for C++ using TR1 and other modern C++.
Yes! The CORBA C++ binding is truly awful in many ways. Supporting a modern binding using standard C++, TR1, and Boost facilities would go a long way towards simplifying and "robustifying" CORBA use in C++ apps. I'm sure other orgs or people have tried this in the past (probably not with Boost or TR1, though), so I would assume there's some case studies available (specially if the project was unsuccessful - that would give a good idea of the scope and challenges involved). Cliff
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Cliff Green
Yes! The CORBA C++ binding is truly awful in many ways. Supporting a modern binding using standard C++, TR1, and Boost facilities would go a long way towards simplifying and "robustifying" CORBA use in C++ apps. I'm sure other orgs or people have tried this in the past (probably not with Boost or TR1, though), so I would assume there's some case studies available (specially if the project was unsuccessful -
Typically, people don't advertise their failures (especially corporations) so you might find it harder to get this data (though I hope I'm wrong!)
Cliff Green wrote:
On Tue, 06 Mar 2007 08:31:55 -0700 Jeff Garland <jeff@crystalclearsoftware.com> wrote:
A project that would align more closely with the Boost mission would be a redo of the CORBA binding (it's awful) for C++ using TR1 and other modern C++.
Yes! The CORBA C++ binding is truly awful in many ways. Supporting a modern binding using standard C++, TR1, and Boost facilities would go a long way towards simplifying and "robustifying" CORBA use in C++ apps. I'm sure other orgs or people have tried this in the past (probably not with Boost or TR1, though), so I would assume there's some case studies available (specially if the project was unsuccessful - that would give a good idea of the scope and challenges involved).
(If this project is indeed going to take off, I'd suggest to have a good look into the OmniORB project (http://omniorb.sourceforge.net/). Not only is this a very robust and high-performance CORBA implementation, it also has a very clean code base. In particular, the IDL compiler is very well designed, making it straight forward to plug in a new backend, e.g. when prototyping new bindings. I'm using the OmniORB IDL parser myself in an unrelated project.) FWIW, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Cliff Green wrote:
On Tue, 06 Mar 2007 08:31:55 -0700 Jeff Garland <jeff@crystalclearsoftware.com> wrote:
A project that would align more closely with the Boost mission would be a redo of the CORBA binding (it's awful) for C++ using TR1 and other modern C++.
Yes! The CORBA C++ binding is truly awful in many ways. Supporting a modern binding using standard C++, TR1, and Boost facilities would go a long way towards simplifying and "robustifying" CORBA use in C++ apps. I'm sure other orgs or people have tried this in the past (probably not with Boost or TR1, though), so I would assume there's some case studies available (specially if the project was unsuccessful - that would give a good idea of the scope and challenges involved).
The OMG is finally going to discuss the possibility of a new C++ mapping at, I believe, their next meeting. Doug Schmidt is going to present his ideas. I have not seen the proposal yet, so I can't comment on it. However, I would guess it would be based on ideas that he presented in: http://www.ddj.com/dept/cpp/184403765 http://www.ddj.com/dept/cpp/184403778 KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com
On Sun, 4 Mar 2007 01:48:33 +0300, "Alexander Nasonov" <alnsn@yandex.ru> said:
John Maddock wrote:
Dear Boosters,
It is a pleasure to announce that Boost will be applying as a mentoring organization for the upcoming Google Summer of Code 2007. There is a lot of preparation work to be done and little time to do it.
A page has been set up at the Boost Wiki:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer...
Interestingly, 2 out of 7 proposals are extensions for the asio library. These are: - Implementing application level protocols using asio - Implementing an ORB/RPC system using asio
This grew into quite a long thread during my absence, so I'll just quickly toss my 2 cents in here. - I think for the application level protocols, it would be better to pick one commonly used and non-trivial protocol (whether it be HTTP, FTP or something else) but preferably with the intent of implementing both client and server side. Implementing the protocol is almost the easy bit. Surveying existing practice, designing a reusable API, and demonstrating that it is reusable is more of a challenge. - Agree that a whole ORB is too ambitious. Anyway, aren't ORBs a bit passe? ;) - Semi-discrete additions to asio functionality (async file support, pipes, database access etc) also sound worth pursuing. However don't let that stop anyone from suggesting other, possibly totally novel, ideas for asio projects! Cheers, Chris
participants (23)
-
Alexander Nasonov -
AlisdairM -
Ames Andreas -
Bjørn Roald -
Christopher Kohlhoff -
Cliff Green -
Eric Niebler -
Jeff Garland -
Jeremy Pack -
Joel de Guzman -
John Maddock -
Julio M. Merino Vidal -
Kevin Heifner -
Mathias Gaunard -
me22 -
Michael Marcin -
Michael Marcin -
Paul A Bristow -
Rene Rivera -
Shams -
Sohail Somani -
Stefan Seefeld -
Thorsten Ottosen