Lubomir pointed me at the GIL thread on the list - and I wanted to make a few comments about how I see the relationship between Boost and ASL. The charter for Boost is to vet libraries for possible inclusion in the standard. The charter for ASL is to explore the use of generic and declarative techniques to develop large applications. Our goal is to replace 85% of the imperative code being developed with small declarative constructs. Certainly there is going to be some overlap between the two project and ASL makes _heavy_ use of Boost and borrows ideas from Boost quite freely. For parts of ASL, inclusion into Boost makes perfect sense - and we try to actively defer to Boost when a Boost library can meet our needs. Boost certainly has a significantly larger user base than ASL and far more active developers (anyone interested in helping out ASL???). I _really_ wish that I had enough time/resources on my team to take some parts of ASL and contribute them to Boost. However, my teams focus currently needs to stay on the higher level libraries (which I don't think are ready for Boost yet) and we simply can't afford the time to go through the submission process. But I'm 100% supportive of Lubomir's contribution of GIL (Lubomir is not on my team, and I'm thrilled that he can take the time for this submission to Boost - just I'm I'm thrilled that we were able to release it as part of ASL). GIL is a very significant piece of work. I will also support anyone who would like to borrow portions of ASL to contribute them to Boost. 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> I've started to map the concepts from forest into the terminology of BGL <http://opensource.adobe.com/wiki/index.php/ Edge_Interface_For_Forest_Iterators>. There is also some work here about generic algorithms for node based iterators (see the undocumented code for reverse_append here <http:// opensource.adobe.com/reverse_8hpp-source.html>. With a bit more polish I think this could be a _really_ nice collections of node based algorithms and concepts, which could be applied to a single linked list and other pre-traversed structures such as forest. There are also some forest specific algorithms I'd like to see such as the rotate necessary for balancing AVL trees (any forest is a binary tree, and vice versa - see Knuth). Range Based Algorithms (using the boost range library) <http:// opensource.adobe.com/group__standard__extensions.html> I've just started busting these out into separate headers (along the boost style - for example adobe/algorithm/reverse.hpp) - for inclusion in Boost I'd like to see this complete. This would be pretty simple to incorporate into Boost (and they are quite handy!). CMath C99 compatibility <http://opensource.adobe.com/group__cmath.html> There are also some rounding modes which were missing - This seems like a pretty straight forward "grab". ZUIDs <http://opensource.adobe.com/classadobe_1_1zuid__t.html> I'd like to see some review of the platform dependent code which gathers entropy to ensure we're getting enough entropy. A short tutorial would be good. ZUIDs would be a good addition to the serialization library. md5 and SHA code <http://opensource.adobe.com/classadobe_1_1md5__t.html> <http://opensource.adobe.com/group__adobe__sha.html> Review and a short tutorial ONCE <http://opensource.adobe.com/group__adobe__once.html> The STATIC_INSTANCE stuff might be able to be removed - this was done for the Mac where static initializer on DLLs were getting executed on a thread after load so other functions in the compilation unit could be executed concurrently. That may have been fixed (I haven't tracked the issue) - this library would be a good addition to Boost threads. ThreadID <http://opensource.adobe.com/group__asl__thread__id.html> Another good addition to Boost threads. Final <http://opensource.adobe.com/group__adobe__final.html> I don't use inheritance much but this would be a nice addition to Boost utilities. Counter <http://opensource.adobe.com/classadobe_1_1counter__t.html> If boost would surface the lightweight mutex used in shared_ptr - this would go away. (This is a heavyweight one - as I'm counting on Boost providing a lightweight one in the future :-) ). value_t <http://opensource.adobe.com/classadobe_1_1value__t.html> I think there are some nice ideas here which could be stolen for boost::any - value_t also captures equality comparison, makes use of a variant to avoid heap allocations for some common types (I'm not sure but I think boost any does two heap allocations, and value_t never does more than one). regular_object <http://opensource.adobe.com/ classadobe_1_1regular__object.html> This is a generalization of value_t (and boost any) - the idea is to be able to parameters an "any" object by concept. Mat Marcus has been doing a fair amount of work with this library. Needs better docs and tutorial. dictionary_t, array_t, name_t <http://opensource.adobe.com/ group__asl__tutorials__dictionary__t.html> ASL using these heavily to communicate with the runtime languages - could be used as part of the Python bindings (we're currently looking at doing Lua bindings with them. dictionary_t needs a closed hash implementation - there is one in the /future/ directory in ASL inspired by the Lua table structure, I haven't had a chance to compare it in depth to the Google hash implementations. Copy-On-Write <http://opensource.adobe.com/ classadobe_1_1copy__on__write.html> This is a fairly polished library - I've done lots of experimenting with COW (I prefer the term copy-on-modify - but COM confuses everyone...) over the last 10 years or so. This is a nice, simple, and efficient implementations (but it does need a better counter - see above). XML Parser <http://opensource.adobe.com/ classadobe_1_1xml__parser__t.html> This is a subset of an XML parser developed for xstrings. In our upcoming .18 release it has been expanded to support more uses by Eric Berdahl and Foster Brereton. It is designed to be a very efficient parser which pareses in place, and allows for preorder and postorder handling of elements (allowing for inplace substitutions). Needs a fair amount of work still to be a general XML parser - but I'd like to see that happen. --- Wow - that's not a complete list (much longer than I set out to write - I forget how large of a library we've created!). If you're not aware of ASL - it's all released under the MIT license (making it fairly straight forward to get through a code audit). I'd be happy to help out anyone who has the time to prepare some of these libraries (or any other library from ASL) for inclusion in Boost - ASL would also benefit from such an effort. Sean