As far as I'm aware, there are three new libraries intended for 1.47 - chrono, ratio and geometry. Any others? Daniel
On Wed, Mar 16, 2011 at 10:43 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 16/03/2011 22:35, Daniel James wrote:
As far as I'm aware, there are three new libraries intended for 1.47 - chrono, ratio and geometry. Any others?
Wasn't move planned for 1.47 as well?
What about Phoenix v3 which was recently added to the trunk?
There are still some unresolved issues. Mainly how to deal with the migration of Boost.Bind, Boost.Lambda and Phoenix V2. There hasn't been any discussion regarding that. Depending on how fast we can come to a consensus regarding, phoenix can be part of 1.47. Regards, Thomas
On 17 March 2011 08:52, Thomas Heller <thom.heller@googlemail.com> wrote:
There are still some unresolved issues. Mainly how to deal with the migration of Boost.Bind, Boost.Lambda and Phoenix V2. There hasn't been any discussion regarding that.
I don't think it'd be a good idea to do anything to bind or lambda in this release. Was there a consensus on replacing them? Personally, I'd like to keep the existing Boost.Bind, even if in a different namespace. I appreciate its relative simplicity and portability. Daniel
On Thu, Mar 17, 2011 at 10:24 AM, Daniel James <dnljms@gmail.com> wrote:
On 17 March 2011 08:52, Thomas Heller <thom.heller@googlemail.com> wrote:
There are still some unresolved issues. Mainly how to deal with the migration of Boost.Bind, Boost.Lambda and Phoenix V2. There hasn't been any discussion regarding that.
I don't think it'd be a good idea to do anything to bind or lambda in this release. Was there a consensus on replacing them? Personally, I'd like to keep the existing Boost.Bind, even if in a different namespace. I appreciate its relative simplicity and portability.
I agree, I will propose a battle plan later today on which we can base a discussion and find a consensus. Quick outline on what i have in mind: phoenix::bind is (almost) completely compatible with boost::bind (as already mentioned, I ported all unit tests of boost.bind to phoenix and they pass). The only thing phoenix::bind doesn't support yet is the explicit specification of the return type. I will add support for those. The options here would be to forward boost/bind.hpp to boost/phoenix/bind.hpp and have a macro that allows to use the old bind, defaulting to use the old bind as a start. The situation with Boost.Lambda is different, the interfaces of the libraries are not really compatible. There needs to be more documentation on the phoenix side to guide a BLL to Phoenix. - Thomas
On 3/17/11 5:24 PM, Daniel James wrote:
On 17 March 2011 08:52, Thomas Heller<thom.heller@googlemail.com> wrote:
There are still some unresolved issues. Mainly how to deal with the migration of Boost.Bind, Boost.Lambda and Phoenix V2. There hasn't been any discussion regarding that.
I don't think it'd be a good idea to do anything to bind or lambda in this release. Was there a consensus on replacing them? Personally, I'd like to keep the existing Boost.Bind, even if in a different namespace. I appreciate its relative simplicity and portability.
Bind should not be touched. People rely on Bind esp. those using old compilers. Also, Bind is extremely lightweight with almost zero dependencies. Phoenix cannot get anywhere near that. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On 3/17/2011 6:17 PM, Joel de Guzman wrote:
On 3/17/11 5:24 PM, Daniel James wrote:
On 17 March 2011 08:52, Thomas Heller<thom.heller@googlemail.com> wrote:
There are still some unresolved issues. Mainly how to deal with the migration of Boost.Bind, Boost.Lambda and Phoenix V2. There hasn't been any discussion regarding that.
I don't think it'd be a good idea to do anything to bind or lambda in this release. Was there a consensus on replacing them? Personally, I'd like to keep the existing Boost.Bind, even if in a different namespace. I appreciate its relative simplicity and portability.
Bind should not be touched. People rely on Bind esp. those using old compilers. Also, Bind is extremely lightweight with almost zero dependencies. Phoenix cannot get anywhere near that.
Joel is right. The best we can do is make phoenix::bind a drop-in replacement and let people choose. OTOH, it would be very nice if Bind's placeholders were the same as Phoenix's. So it would be worth taking the time to see if we could refactor Proto such that terminals could be defined in a very light-weight way. But I also know that Bind jumps through hoops of fire with the placeholder definitions to support ancient compilers, so this might not be possible. However, if it /were/ possible (and we navigate the tricky proto-domain waters), then I suggestion the placeholders be spun into their own mini-library that can be shared across all the EDSLs in Boost that require placeholders. (Except MPL, where the placeholders are types and not objects.) -- Eric Niebler BoostPro Computing http://www.boostpro.com
Bind should not be touched. People rely on Bind esp. those using old compilers. Also, Bind is extremely lightweight with almost zero dependencies. Phoenix cannot get anywhere near that.
Joel is right. The best we can do is make phoenix::bind a drop-in replacement and let people choose.
I second that. OTOH, the migration strategy for Phoenix V2 -> V3 needs to be defined carefully to minimize disruptions.
OTOH, it would be very nice if Bind's placeholders were the same as Phoenix's. So it would be worth taking the time to see if we could refactor Proto such that terminals could be defined in a very light-weight way. But I also know that Bind jumps through hoops of fire with the placeholder definitions to support ancient compilers, so this might not be possible.
However, if it /were/ possible (and we navigate the tricky proto-domain waters), then I suggestion the placeholders be spun into their own mini- library that can be shared across all the EDSLs in Boost that require placeholders. (Except MPL, where the placeholders are types and not objects.)
AFAIR, boost::bind placeholders can already be used out of the box with Phoenix V3. Thomas? Regards Hartmut --------------- http://boost-spirit.com
On Thu, Mar 17, 2011 at 1:33 PM, Eric Niebler <eric@boostpro.com> wrote:
On 3/17/2011 6:17 PM, Joel de Guzman wrote:
On 3/17/11 5:24 PM, Daniel James wrote:
On 17 March 2011 08:52, Thomas Heller<thom.heller@googlemail.com> wrote:
There are still some unresolved issues. Mainly how to deal with the migration of Boost.Bind, Boost.Lambda and Phoenix V2. There hasn't been any discussion regarding that.
I don't think it'd be a good idea to do anything to bind or lambda in this release. Was there a consensus on replacing them? Personally, I'd like to keep the existing Boost.Bind, even if in a different namespace. I appreciate its relative simplicity and portability.
Bind should not be touched. People rely on Bind esp. those using old compilers. Also, Bind is extremely lightweight with almost zero dependencies. Phoenix cannot get anywhere near that.
Joel is right. The best we can do is make phoenix::bind a drop-in replacement and let people choose.
OTOH, it would be very nice if Bind's placeholders were the same as Phoenix's. So it would be worth taking the time to see if we could refactor Proto such that terminals could be defined in a very light-weight way. But I also know that Bind jumps through hoops of fire with the placeholder definitions to support ancient compilers, so this might not be possible.
Right now, the placeholders defined in Boost.Bind can be used with just one little minor inconvience* inside Phoenix. *The problem is that Boost.Bind placeholders are not wrapped inside any proto terminal stuff or phoenix actor. This means that we can not except something like ::_1 + ::_2 to be seen as a phoenix expression. BUT: ::_1 + phoenix::placeholders::_2 or phoenix::bind(::_1, ::_2) or phoenix::bind(::_1, phoenix::placeholders::_2) will work just fine! The same is true for the placeholders defined in BLL ... though i haven't checked if they specialize boost::is_placeholder.
However, if it /were/ possible (and we navigate the tricky proto-domain waters), then I suggestion the placeholders be spun into their own mini-library that can be shared across all the EDSLs in Boost that require placeholders. (Except MPL, where the placeholders are types and not objects.)
Oh ... proto-domain waters *shiver* .... we need to investigate that topic very well ... This topic still needs very deep research .... Consider the above: ::_1 + phoenix::placeholders::_2 If ::_1 (magically, somehow) belongs to something like bind_domain and phoenix::placeholders::_2 to phoenix_domain. It is not clear in which domain the resulting expression will be, and not clear how to handle the resulting expression. Three cases: 1) phoenix_domain is the super domain of bind_domain: Ok, no problem here, the resulting expression will be in phoenix_domain and we can evaluate without problems in phoenix. However, what is the scenario for other libraries that feel the need to reuse ::_1 ... 2) The common domain of phoenix_domain and bind_domain is proto::default_domain: The resulting expression is in neither domain and we have lost the ability to evaluate the resulting expression in the bind_domain sense or in the phoenix_domain sense. 3) The common domain of phoenix_domain and bind_domain is proto::not_a_domain: The expression will be not valid. Problem solved, somehow ;)
On 3/17/2011 7:55 PM, Thomas Heller wrote:
On Thu, Mar 17, 2011 at 1:33 PM, Eric Niebler <eric@boostpro.com> wrote:
OTOH, it would be very nice if Bind's placeholders were the same as Phoenix's. So it would be worth taking the time to see if we could refactor Proto such that terminals could be defined in a very light-weight way. But I also know that Bind jumps through hoops of fire with the placeholder definitions to support ancient compilers, so this might not be possible.
Right now, the placeholders defined in Boost.Bind can be used with just one little minor inconvience* inside Phoenix.
*The problem is that Boost.Bind placeholders are not wrapped inside any proto terminal stuff or phoenix actor. This means that we can not except something like ::_1 + ::_2 to be seen as a phoenix expression. BUT: ::_1 + phoenix::placeholders::_2 or phoenix::bind(::_1, ::_2) or phoenix::bind(::_1, phoenix::placeholders::_2) will work just fine! The same is true for the placeholders defined in BLL ... though i haven't checked if they specialize boost::is_placeholder.
Very cool.
However, if it /were/ possible (and we navigate the tricky proto-domain waters), then I suggestion the placeholders be spun into their own mini-library that can be shared across all the EDSLs in Boost that require placeholders. (Except MPL, where the placeholders are types and not objects.)
Oh ... proto-domain waters *shiver* .... we need to investigate that topic very well ... This topic still needs very deep research .... Consider the above: ::_1 + phoenix::placeholders::_2 <snip>
If we can't make these two one and the same (via a using declaration), then there's no point. I'm hoping to avoid the ambiguous-_1-symbol errors a few folks have complained about. So, _1 would have to be in the phoenix domain, which is a subdomain of the default domain, making it inherently weak wrt domain resolution. So ::_1 + 1 is a phoenix expression, but ::_1 >> spirit::qi::char_ is a spirit expression (assuming that spirit::qi::char_ is in a domain, which I'm uncertain of, but the point remains). That all just works. What we need to ensure is that phoenix::placeholder::_1 can be defined without dragging in a whole lot of gunk. For instance, bind doesn't need proto's operator overloads. We need *just* enough to define a terminal in a domain. Nothing more. I think we can do this. Certainly, older compilers cannot enter that brave new world, so on those, the placeholders will have to stay separate. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 03/17/2011 02:24 AM, Daniel James wrote:
On 17 March 2011 08:52, Thomas Heller<thom.heller@googlemail.com> wrote:
There are still some unresolved issues. Mainly how to deal with the migration of Boost.Bind, Boost.Lambda and Phoenix V2. There hasn't been any discussion regarding that.
I don't think it'd be a good idea to do anything to bind or lambda in this release. Was there a consensus on replacing them? Personally, I'd like to keep the existing Boost.Bind, even if in a different namespace. I appreciate its relative simplicity and portability.
Daniel _______________________________________________
I would like to echo this sentiment. IMHO a good plan would be to release Phoenix V3 in 1.47 as a first class citizen. That will increase the exposure of the library and provide more confidence to users in selecting Phoenix over BLL and possibly Boost.Bind. As releases continue, then we can add forwarding headers and other mechanism to eventually deprecate BLL. Thomas has done an excellent job at mitigating the technical issues for migration to Phoenix; however, we should not hold up release of the library while the logistics are being considered. michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On 3/17/2011 12:41 PM, Michael Caisse wrote:
On 03/17/2011 02:24 AM, Daniel James wrote:
There are still some unresolved issues. Mainly how to deal with the migration of Boost.Bind, Boost.Lambda and Phoenix V2. There hasn't been any discussion regarding that. I don't think it'd be a good idea to do anything to bind or lambda in
On 17 March 2011 08:52, Thomas Heller<thom.heller@googlemail.com> wrote: this release. Was there a consensus on replacing them? Personally, I'd like to keep the existing Boost.Bind, even if in a different namespace. I appreciate its relative simplicity and portability.
Daniel _______________________________________________
I would like to echo this sentiment. IMHO a good plan would be to release Phoenix V3 in 1.47 as a first class citizen. That will increase the exposure of the library and provide more confidence to users in selecting Phoenix over BLL and possibly Boost.Bind. As releases continue, then we can add forwarding headers and other mechanism to eventually deprecate BLL.
Thomas has done an excellent job at mitigating the technical issues for migration to Phoenix; however, we should not hold up release of the library while the logistics are being considered.
+1 How many years has it been that Phoenix has been held up from being released as a first class Boost library ? Let's get it out so that people will actually have the docs and can try it, and then think in the future of how bind and/or lambda can be transitioned to Phoenix if it provides a suitable replacement. I will not believe it if Phoenix is held up once again for yet another technical reason.
On 3/17/2011 12:41 PM, Michael Caisse wrote:
On 03/17/2011 02:24 AM, Daniel James wrote:
There are still some unresolved issues. Mainly how to deal with the migration of Boost.Bind, Boost.Lambda and Phoenix V2. There hasn't been any discussion regarding that. I don't think it'd be a good idea to do anything to bind or lambda in
On 17 March 2011 08:52, Thomas Heller<thom.heller@googlemail.com> wrote: this release. Was there a consensus on replacing them? Personally, I'd like to keep the existing Boost.Bind, even if in a different namespace. I appreciate its relative simplicity and portability.
Daniel _______________________________________________
I would like to echo this sentiment. IMHO a good plan would be to release Phoenix V3 in 1.47 as a first class citizen. That will increase the exposure of the library and provide more confidence to users in selecting Phoenix over BLL and possibly Boost.Bind. As releases continue, then we can add forwarding headers and other mechanism to eventually deprecate BLL.
Thomas has done an excellent job at mitigating the technical issues for migration to Phoenix; however, we should not hold up release of the library while the logistics are being considered.
+1
How many years has it been that Phoenix has been held up from being released as a first class Boost library ? Let's get it out so that people will actually have the docs and can try it, and then think in the future of how bind and/or lambda can be transitioned to Phoenix if it provides a suitable replacement. I will not believe it if Phoenix is held up once again for yet another technical reason.
+1 As a boost user, I must demand, that such a library should be a proper part of boost. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
On 3/18/2011 7:34 AM, Jens Weller wrote:
On 3/17/2011 12:41 PM, Michael Caisse wrote:
On 03/17/2011 02:24 AM, Daniel James wrote:
There are still some unresolved issues. Mainly how to deal with the migration of Boost.Bind, Boost.Lambda and Phoenix V2. There hasn't been any discussion regarding that. I don't think it'd be a good idea to do anything to bind or lambda in
On 17 March 2011 08:52, Thomas Heller<thom.heller@googlemail.com> wrote: this release. Was there a consensus on replacing them? Personally, I'd like to keep the existing Boost.Bind, even if in a different namespace. I appreciate its relative simplicity and portability.
Daniel _______________________________________________
I would like to echo this sentiment. IMHO a good plan would be to release Phoenix V3 in 1.47 as a first class citizen. That will increase the exposure of the library and provide more confidence to users in selecting Phoenix over BLL and possibly Boost.Bind. As releases continue, then we can add forwarding headers and other mechanism to eventually deprecate BLL.
Thomas has done an excellent job at mitigating the technical issues for migration to Phoenix; however, we should not hold up release of the library while the logistics are being considered.
+1
How many years has it been that Phoenix has been held up from being released as a first class Boost library ? Let's get it out so that people will actually have the docs and can try it, and then think in the future of how bind and/or lambda can be transitioned to Phoenix if it provides a suitable replacement. I will not believe it if Phoenix is held up once again for yet another technical reason.
+1 As a boost user, I must demand, that such a library should be a proper part of boost.
We hear ya :-) We'll make it a point to have it in 1.47 then. Thank you all for your support! Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
El 16/03/2011 22:43, Mathias Gaunard escribió:
On 16/03/2011 22:35, Daniel James wrote:
As far as I'm aware, there are three new libraries intended for 1.47 - chrono, ratio and geometry. Any others?
Wasn't move planned for 1.47 as well?
Yes, it is. I plan to upload to trunk today or tomorrow with an updated Interprocess library adapted to the new move library. I don't know if making Intrusive move-aware will be possible for 1.47. Best, Ion
2011/3/17 Frédéric Bron <frederic.bron@m4x.org>:
As far as I'm aware, there are three new libraries intended for 1.47 - chrono, ratio and geometry. Any others?
What is the deadline for libraries to be part of 1.47?
We haven't set a schedule yet. We're actually past the normal deadline, so we need to get new libraries ready pretty quickly. Daniel
Daniel James-3 wrote:
2011/3/17 Frédéric Bron <frederic.bron@m4x.org>:
As far as I'm aware, there are three new libraries intended for 1.47 - chrono, ratio and geometry. Any others?
What is the deadline for libraries to be part of 1.47?
We haven't set a schedule yet. We're actually past the normal deadline, so we need to get new libraries ready pretty quickly.
Hi Daniel, I have no see a post for opening the release branch. Can we merge to release Boost.Geometry, Boost.Chrono and Boost.Ratio? Thanks, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/1-47-New-libraries-tp3383100p3385929.html Sent from the Boost - Dev mailing list archive at Nabble.com.
On 18 March 2011 00:20, Vicente Botet <vicente.botet@wanadoo.fr> wrote:
I have no see a post for opening the release branch. Can we merge to release Boost.Geometry, Boost.Chrono and Boost.Ratio?
No. The release branch isn't open yet, and new libraries need to wait until we (the release managers) give you the go ahead. Daniel
participants (13)
-
Daniel James -
Edward Diener -
Eric Niebler -
Frédéric Bron -
Hartmut Kaiser -
Ion Gaztañaga -
Jens Weller -
Joel de Guzman -
Mathias Gaunard -
Michael Caisse -
Michael Goldshteyn -
Thomas Heller -
Vicente Botet