Sean Parent wrote:
Hi Jeff,
Some libraries that I think would be interesting to get into Boost with some comments about what I see as still needing to be done.
Forest <http://opensource.adobe.com/ group__asl__tutorials__forest.html> ..... We have an active SOC project to build a generic tree...
https://boost-consulting.com:8443/trac/soc/wiki/tree https://boost-consulting.com:8443/trac/soc/wiki/tree/design Are there links to these on port 80? I can't get to 8443 from inside Adobe.
There isn't I'm afraid. There's more here: http://code.google.com/soc/boost/appinfo.html?csaid=E17EA7C7C537C131 including a pointer to the developers blog. It has some of the design stuff, but not all of it.
Eric Niebler has written some range algorithms in the vault -- be nice to see if he's covered all the ones you'all have:
http://www.boost-consulting.com/vault/index.php? &direction=0&order=&directory=Algorithms There is some nice work here to specialize for the standard containers - something I hadn't considered and isn't part of my library. Thanks for the pointer!
Sure :-)
ZUIDs <http://opensource.adobe.com/classadobe_1_1zuid__t.html>
I'll defer to the new thread on this topic.
Anybody know how to contact Andy Tompkins to see if he wants to collaborate?
I don't. Searching the list archive the last message I found was in 2004...I guess that doesn't bode well...
I don't know if we've really found an active maintainer for Boost.Threads....library abandonment is starting to become a much bigger issue for Boost as time goes on :-(
Maintenance for any large library is problematic. I ask that for each release, my developers improve one existing library (both documentation and code) - we release once a month so this helps to keep things from stagnating. Right now I don't mandate _which_ library is improved but at some point I'll have to start dictating the priority. Of course, the folks working for me aren't quite volunteers so I can get away with that. But some possible suggestions for boost -
1. Speed up the release cycle - I would try to get two two releases a year at a minimum. Just upping the release pace will help avoid stagnation.
We all want that -- there's been some discussion of how to provide a more continuous release process. Hopefully that will improve things.
2. Make maintenance part of the cost of admission - "We're really happy to take your GIL submission, but part of contributing to Boost is to assist with the general maintenance. Here's a short list of tasks we'd like you to take on..." (Sorry Lubomir!)
Yeah, well I'm afraid the cost of admission is already a pretty high -- adding a non-related task sounds like it might kill off some authors to me.
I'm constantly looking at ways that we can improve this with ASL - honestly the library as it stands today is large enough that I could burn my entire team just maintaining and improving the current libraries without ever adding any more (at least for the next few years). Balancing this with adding new libraries and showing forward progress is very difficult.
Yep -- been there before. The good thing is that the folks working on ASL are being paid to work on it. Most Boost authors don't get paid -- at least not directly. So there's a simple limit there on how much time they can spend and 'feed their families' as well.
regular_object <http://opensource.adobe.com/ classadobe_1_1regular__object.html>
We're currently putting a fair amount of emphasis on this work - the general idea is that the requirement of polymorphism comes from the requirement to apply algorithms to heterogeneous collections of objects. Hence - runtime polymorphism should be based on Concepts and cannot be properly described by intrusive means (such as inheritance). I'm currently collaborating on a paper on the topic that I'm hoping to have ready for LCSD <http://lcsd.cs.tamu.edu/2006/>
Cool, I'll be at OOPSLA so I'll be there for sure :-) I read through you slides on this subject and I found the case quite compelling -- nothing quite like the 'here's ugly code' to 'here's beautiful code' story to sell a programmer.
XML Parser <http://opensource.adobe.com/ classadobe_1_1xml__parser__t.html> There is a Boost xml, but I haven't seen much Boost activity here. Property tree does some too, but full XML support is hard enough that it will be hard to do in Boost.
http://www.boost-consulting.com/vault/index.php? direction=0&order=&directory=Progamming%20Interfaces
We're getting close to a complete XML parser - this is not a DOM, the idea is that a DOM would be a separate library that could be used with the parser - but the parser can be used just fine without a DOM.
Excellent -- XML parsing is certainly something frequently requested in Boost. I don't think you need a DOM parser, btw, just one that meets the Boost standards -- which I'm sure yours will.
Hopefully people will make you very busy :-) Already you've given me some nice references. Thanks.
You're welcome. Jeff