Phoenix as a Boost library
I am curious to know if Phoenix will ever be released as a Boost library, or is it meant to be forever coupled with Spirit ? I have avoided it because it has never been released separately or had its documentation appear among the list of Boost libraries. I got the impression that it would be released separately, and expected to see it in Boost 1.44, but evidently that did not happen.
On 10/14/2010 10:41 AM, Edward Diener wrote:
I am curious to know if Phoenix will ever be released as a Boost library, or is it meant to be forever coupled with Spirit ?
I have avoided it because it has never been released separately or had its documentation appear among the list of Boost libraries. I got the impression that it would be released separately, and expected to see it in Boost 1.44, but evidently that did not happen.
Thomas Heller completed the Proto port last July. Now the next step is to have a mini-review. Then, Boost integration, IFF it passes the mini-review. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On 10/13/2010 10:50 PM, Joel de Guzman wrote:
On 10/14/2010 10:41 AM, Edward Diener wrote:
I am curious to know if Phoenix will ever be released as a Boost library, or is it meant to be forever coupled with Spirit ?
I have avoided it because it has never been released separately or had its documentation appear among the list of Boost libraries. I got the impression that it would be released separately, and expected to see it in Boost 1.44, but evidently that did not happen.
Thomas Heller completed the Proto port last July. Now the next step is to have a mini-review. Then, Boost integration, IFF it passes the mini-review.
Thanks ! I am sure I am not the only one looking forward to seeing it as a library of its own, and using it, if it passes the mini-review.
On 10/14/2010 11:22 AM, Edward Diener wrote:
On 10/13/2010 10:50 PM, Joel de Guzman wrote:
On 10/14/2010 10:41 AM, Edward Diener wrote:
I am curious to know if Phoenix will ever be released as a Boost library, or is it meant to be forever coupled with Spirit ?
I have avoided it because it has never been released separately or had its documentation appear among the list of Boost libraries. I got the impression that it would be released separately, and expected to see it in Boost 1.44, but evidently that did not happen.
Thomas Heller completed the Proto port last July. Now the next step is to have a mini-review. Then, Boost integration, IFF it passes the mini-review.
Thanks ! I am sure I am not the only one looking forward to seeing it as a library of its own, and using it, if it passes the mini-review.
Let us request for a mini-review then. I think it's about time. Thomas? Eric? Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On 10/13/2010 8:39 PM, Joel de Guzman wrote:
On 10/14/2010 11:22 AM, Edward Diener wrote:
On 10/13/2010 10:50 PM, Joel de Guzman wrote:
On 10/14/2010 10:41 AM, Edward Diener wrote:
I am curious to know if Phoenix will ever be released as a Boost library, or is it meant to be forever coupled with Spirit?
I have avoided it because it has never been released separately or had its documentation appear among the list of Boost libraries. I got the impression that it would be released separately, and expected to see it in Boost 1.44, but evidently that did not happen.
Thomas Heller completed the Proto port last July. Now the next step is to have a mini-review. Then, Boost integration, IFF it passes the mini-review.
Thanks ! I am sure I am not the only one looking forward to seeing it as a library of its own, and using it, if it passes the mini-review.
Let us request for a mini-review then. I think it's about time. Thomas? Eric?
The Proto port is done, but in the process of writing docs, Thomas realized there were some things about the Phoenix intermediate representation that would make extensibility difficult. He's been working on it. The design discussion is active on the proto list. (Chime in, I'd love your feedback.) Thomas' suggested design has some nice properties, but (not having yet fully wrapped my head around it) I feel that it may be too complex. (Thoughts?) Assessing the design and offering suggestions is now my #1 priority. Hopefully, we'll have a concrete suggestion in the near future. I should point out that we're talking about fairly minor tweaks at this point, not a major redesign or rewrite. But still, I think a mini-review would be premature because the customization points are still in flux. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
On 10/13/2010 8:39 PM, Joel de Guzman wrote:
On 10/14/2010 11:22 AM, Edward Diener wrote:
On 10/13/2010 10:50 PM, Joel de Guzman wrote:
On 10/14/2010 10:41 AM, Edward Diener wrote:
I am curious to know if Phoenix will ever be released as a Boost library, or is it meant to be forever coupled with Spirit?
I have avoided it because it has never been released separately or had its documentation appear among the list of Boost libraries. I got the impression that it would be released separately, and expected to see it in Boost 1.44, but evidently that did not happen.
Thomas Heller completed the Proto port last July. Now the next step is to have a mini-review. Then, Boost integration, IFF it passes the mini-review.
Thanks ! I am sure I am not the only one looking forward to seeing it as a library of its own, and using it, if it passes the mini-review.
Let us request for a mini-review then. I think it's about time. Thomas? Eric?
The Proto port is done, but in the process of writing docs, Thomas realized there were some things about the Phoenix intermediate representation that would make extensibility difficult. He's been working on it. The design discussion is active on the proto list. (Chime in, I'd love your feedback.)
Indeed, I was missing you in the whole discussion Joel :)
Thomas' suggested design has some nice properties, but (not having yet fully wrapped my head around it) I feel that it may be too complex. (Thoughts?) Assessing the design and offering suggestions is now my #1 priority. Hopefully, we'll have a concrete suggestion in the near future.
I hope my last post sched some more light on it.
I should point out that we're talking about fairly minor tweaks at this point, not a major redesign or rewrite. But still, I think a mini-review would be premature because the customization points are still in flux.
Agreed. It really is only about tweaking the "low level" part of phoenix. The high level customization point (phoenix::function) is already here. Although most of the stuff is working already there is still need for some tweaks: - Boost.Bind compatibility is not yet complete (around 90% is done) - phoenix::lambda is currently not always working as expected (there are some minor bugs that needs to be tackled)
On 10/14/2010 2:36 PM, Thomas Heller wrote:
Eric Niebler wrote:
On 10/13/2010 8:39 PM, Joel de Guzman wrote:
On 10/14/2010 11:22 AM, Edward Diener wrote:
On 10/13/2010 10:50 PM, Joel de Guzman wrote:
On 10/14/2010 10:41 AM, Edward Diener wrote:
I am curious to know if Phoenix will ever be released as a Boost library, or is it meant to be forever coupled with Spirit?
I have avoided it because it has never been released separately or had its documentation appear among the list of Boost libraries. I got the impression that it would be released separately, and expected to see it in Boost 1.44, but evidently that did not happen.
Thomas Heller completed the Proto port last July. Now the next step is to have a mini-review. Then, Boost integration, IFF it passes the mini-review.
Thanks ! I am sure I am not the only one looking forward to seeing it as a library of its own, and using it, if it passes the mini-review.
Let us request for a mini-review then. I think it's about time. Thomas? Eric?
The Proto port is done, but in the process of writing docs, Thomas realized there were some things about the Phoenix intermediate representation that would make extensibility difficult. He's been working on it. The design discussion is active on the proto list. (Chime in, I'd love your feedback.)
Indeed, I was missing you in the whole discussion Joel :)
Oh my, I just looked and you guys are miles ahead. I'm not sure I can keep up. Anyway, having said that, just keep in mind that people have been clamoring for phoenix and I'd prefer something done sooner rather than later. We can tweak the library later as long as the main interface (not the extension interface) is stable. And it has remained more or less stable for a long time now. IMO, it should be a priority to focus on the remaining incompatibilities before anything else. IMO, phoenix has surpassed the Boost bar even at V2. Interestingly, the bar has been set higher for this particular library due to other factors such as putting on the shoes of lambda, the inter-operability and proto, etc. I think it's about time to finish up and conclude that it is "good enough" :-) I'm sure, thanks to you, Eric and all the amazing people here, that it'll get better over time. But let us get it into boost first. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On 10/15/2010 4:41 PM, Joel de Guzman wrote:
Anyway, having said that, just keep in mind that people have been clamoring for phoenix and I'd prefer something done sooner rather than later. We can tweak the library later as long as the main interface (not the extension interface) is stable. And it has remained more or less stable for a long time now. IMO, it should be a priority to focus on the remaining incompatibilities before anything else.
Hmm, good point.
IMO, phoenix has surpassed the Boost bar even at V2. Interestingly, the bar has been set higher for this particular library due to other factors such as putting on the shoes of lambda, the inter-operability and proto, etc. I think it's about time to finish up and conclude that it is "good enough" :-)
I'm sure, thanks to you, Eric and all the amazing people here, that it'll get better over time. But let us get it into boost first.
Thomas is currently assessing the suggested extension point design. If he likes it, it wouldn't take long to add it. The mini-review was precisely to assess the Proto port---I personally would like to hear feedback about the intermediate form and extensibility points since that's a major new feature of Phoenix3. But it's your call, and you make a valid point: we'd be serving a huge community by doing this sooner rather than later, and I'd be happy either way. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Sat, Oct 16, 2010 at 9:55 AM, Eric Niebler <eric@boostpro.com> wrote:
On 10/15/2010 4:41 PM, Joel de Guzman wrote:
Anyway, having said that, just keep in mind that people have been clamoring for phoenix and I'd prefer something done sooner rather than later. We can tweak the library later as long as the main interface (not the extension interface) is stable. And it has remained more or less stable for a long time now. IMO, it should be a priority to focus on the remaining incompatibilities before anything else.
Hmm, good point.
Definitely a good point. Though, most of the stuff that doesn't work just yet was very difficult with the current intermediate form. That is why I started the discussion about that new design. So, even if the top level API is fixed (it was fixed already before, no real breakage between V2 and V3), I think we should focus to get the things behind the scene right so people are not getting used to the current intermediate form, which makes changing it very difficult. Let me remind me you what we were advertising for phoenix3 ... We simply can not hold on to all that with the current intermediate form.
IMO, phoenix has surpassed the Boost bar even at V2. Interestingly, the bar has been set higher for this particular library due to other factors such as putting on the shoes of lambda, the inter-operability and proto, etc. I think it's about time to finish up and conclude that it is "good enough" :-)
I'm sure, thanks to you, Eric and all the amazing people here, that it'll get better over time. But let us get it into boost first.
Thomas is currently assessing the suggested extension point design. If he likes it, it wouldn't take long to add it. The mini-review was precisely to assess the Proto port---I personally would like to hear feedback about the intermediate form and extensibility points since that's a major new feature of Phoenix3.
I agree. I will work on this new extension point design tonight. Additionally, I still would like your comments on that current discussions. Since it still is your library, and I don't feel very comfortable changing such a major part of the design without your accommodation.
But it's your call, and you make a valid point: we'd be serving a huge community by doing this sooner rather than later, and I'd be happy either way.
Yeah, people are waiting on it ... I was waiting on you to look and comment on my recent effots to change the intermediate form. Whenever a decision about that was made. It would be a matter of a few days to get phoenix3 ready for a mini review.
On 10/16/2010 9:34 PM, Thomas Heller wrote:
Thomas is currently assessing the suggested extension point design. If he likes it, it wouldn't take long to add it. The mini-review was precisely to assess the Proto port---I personally would like to hear feedback about the intermediate form and extensibility points since that's a major new feature of Phoenix3.
I agree. I will work on this new extension point design tonight. Additionally, I still would like your comments on that current discussions. Since it still is your library, and I don't feel very comfortable changing such a major part of the design without your accommodation.
But it's your call, and you make a valid point: we'd be serving a huge community by doing this sooner rather than later, and I'd be happy either way.
Yeah, people are waiting on it ... I was waiting on you to look and comment on my recent effots to change the intermediate form. Whenever a decision about that was made. It would be a matter of a few days to get phoenix3 ready for a mini review.
Understood. Pardon me for my long hiatus. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Le 16/10/2010 14:34, Thomas Heller a écrit :
On Sat, Oct 16, 2010 at 9:55 AM, Eric Niebler<eric@boostpro.com> wrote:
On 10/15/2010 4:41 PM, Joel de Guzman wrote:
Anyway, having said that, just keep in mind that people have been clamoring for phoenix and I'd prefer something done sooner rather than later. We can tweak the library later as long as the main interface (not the extension interface) is stable. And it has remained more or less stable for a long time now. IMO, it should be a priority to focus on the remaining incompatibilities before anything else.
Hmm, good point.
Definitely a good point. Though, most of the stuff that doesn't work just yet was very difficult with the current intermediate form. That is why I started the discussion about that new design. So, even if the top level API is fixed (it was fixed already before, no real breakage between V2 and V3)
I thought V2 doesn't follow the result_of protocol, and didn't do perfect forwarding either. Those are the reasons I'm not using it and waiting for V3.
On 10/16/2010 4:41 PM, Mathias Gaunard wrote:
I thought V2 doesn't follow the result_of protocol,
True.
and didn't do perfect forwarding either.
I don't think v3 will do perfect forwarding either. At least not with C++03. It's just too expensive at compile time. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 10/17/2010 8:37 AM, Eric Niebler wrote:
On 10/16/2010 4:41 PM, Mathias Gaunard wrote:
I thought V2 doesn't follow the result_of protocol,
True.
and didn't do perfect forwarding either.
I don't think v3 will do perfect forwarding either. At least not with C++03. It's just too expensive at compile time.
Yep. It won't be perfect, but at least we can offer something better than what we have with V2. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On Oct 16, 2010, at 8:37 PM, Eric Niebler <eric@boostpro.com> wrote:
n 10/16/2010 4:41 PM, Mathias Gaunard wrote:
I thought V2 doesn't follow the result_of protocol,
True.
and didn't do perfect forwarding either.
I don't think v3 will do perfect forwarding either. At least not with C++03. It's just too expensive at compile time.
You could approximate it for up to 3-5 arguments. But you can't actually do it perfectly in C++03 even for 1 argument because you will erase rvalue-ness no matter what. -- BoostPro Computing * http://boostpro.com [Sent from coveted but awkward mobile device]
On 10/17/2010 11:32 AM, Dave Abrahams wrote:
On Oct 16, 2010, at 8:37 PM, Eric Niebler<eric@boostpro.com> wrote:
n 10/16/2010 4:41 PM, Mathias Gaunard wrote:
I thought V2 doesn't follow the result_of protocol,
True.
and didn't do perfect forwarding either.
I don't think v3 will do perfect forwarding either. At least not with C++03. It's just too expensive at compile time.
You could approximate it for up to 3-5 arguments. But you can't actually do it perfectly in C++03 even for 1 argument because you will erase rvalue-ness no matter what.
Yeah, that's what we do for 03. Let's call it less-than-perfect forwarding. It's the best we can do. Right now we have a PP constant for that. Mind you, even 3 args is still quite expensive! Then we have 2 more PP constants for all refs and another for all const refs. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
At Sun, 17 Oct 2010 13:01:08 +0800, Joel de Guzman wrote:
You could approximate it for up to 3-5 arguments. But you can't actually do it perfectly in C++03 even for 1 argument because you will erase rvalue-ness no matter what.
Yeah, that's what we do for 03. Let's call it less-than-perfect forwarding. It's the best we can do. Right now we have a PP constant for that. Mind you, even 3 args is still quite expensive! Then we have 2 more PP constants for all refs and another for all const refs.
I think it's only useful to have one of those be higher than the first PP constant, because you'll just get ambiguities. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 10/17/2010 6:38 PM, David Abrahams wrote:
At Sun, 17 Oct 2010 13:01:08 +0800, Joel de Guzman wrote:
You could approximate it for up to 3-5 arguments. But you can't actually do it perfectly in C++03 even for 1 argument because you will erase rvalue-ness no matter what.
Yeah, that's what we do for 03. Let's call it less-than-perfect forwarding. It's the best we can do. Right now we have a PP constant for that. Mind you, even 3 args is still quite expensive! Then we have 2 more PP constants for all refs and another for all const refs.
I think it's only useful to have one of those be higher than the first PP constant, because you'll just get ambiguities.
Yep. That's how it's done AFAIK. Cheers, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On 17/10/2010 06:01, Joel de Guzman wrote:
Yeah, that's what we do for 03. Let's call it less-than-perfect forwarding. It's the best we can do. Right now we have a PP constant for that. Mind you, even 3 args is still quite expensive!
What's expensive? The generation of all these overloads with the preprocessor or the actual lookup with that many overloads? If it's the former, I don't think that's very relevant. If you want to use a tool like Phoenix, you probably should use a PCH version of it. As a side note, more and more Boost libraries are making compilation very slow, and it would be nice to integrate standardized PCH headers as part of the Boost distribution, which would be automatically generated at installation time.
At Sun, 17 Oct 2010 12:17:08 +0100, Mathias Gaunard wrote:
On 17/10/2010 06:01, Joel de Guzman wrote:
Yeah, that's what we do for 03. Let's call it less-than-perfect forwarding. It's the best we can do. Right now we have a PP constant for that. Mind you, even 3 args is still quite expensive!
What's expensive? The generation of all these overloads with the preprocessor or the actual lookup with that many overloads?
If it's the former, I don't think that's very relevant. If you want to use a tool like Phoenix, you probably should use a PCH version of it.
As a side note, more and more Boost libraries are making compilation very slow, and it would be nice to integrate standardized PCH headers as part of the Boost distribution, which would be automatically generated at installation time.
Indeed! -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 10/17/10 7:17 PM, Mathias Gaunard wrote:
On 17/10/2010 06:01, Joel de Guzman wrote:
Yeah, that's what we do for 03. Let's call it less-than-perfect forwarding. It's the best we can do. Right now we have a PP constant for that. Mind you, even 3 args is still quite expensive!
What's expensive? The generation of all these overloads with the preprocessor or the actual lookup with that many overloads?
If it's the former, I don't think that's very relevant. If you want to use a tool like Phoenix, you probably should use a PCH version of it.
I'm not sure. We'll need formalized tests to be sure. Perhaps Thomas knows better.
As a side note, more and more Boost libraries are making compilation very slow, and it would be nice to integrate standardized PCH headers as part of the Boost distribution, which would be automatically generated at installation time.
Agreed. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On Mon, Oct 18, 2010 at 1:43 AM, Joel de Guzman <joel@boost-consulting.com> wrote:
On 10/17/10 7:17 PM, Mathias Gaunard wrote:
On 17/10/2010 06:01, Joel de Guzman wrote:
Yeah, that's what we do for 03. Let's call it less-than-perfect forwarding. It's the best we can do. Right now we have a PP constant for that. Mind you, even 3 args is still quite expensive!
What's expensive? The generation of all these overloads with the preprocessor or the actual lookup with that many overloads?
If it's the former, I don't think that's very relevant. If you want to use a tool like Phoenix, you probably should use a PCH version of it.
I'm not sure. We'll need formalized tests to be sure. Perhaps Thomas knows better.
Preprocessor code generation takes time, and the time it takes is significant. The most annoying fact is that even if we took care about not instantiating templates if the user doesn't want them, the user pays for these preprocessor iterations. Think about it, in the case of perfect forward emulation the number of overload created is O(N!). Even if N is large, the search for the right overload shouldn't be a problem (searching is in O(log(N))).
As a side note, more and more Boost libraries are making compilation very slow, and it would be nice to integrate standardized PCH headers as part of the Boost distribution, which would be automatically generated at installation time.
Agreed.
Instead of providing PCH headers, we could just preprocess our headers with some kind of boost.wave driver, like MPL already does.
At Mon, 18 Oct 2010 07:40:21 +0200, Thomas Heller wrote:
Preprocessor code generation takes time, and the time it takes is significant. The most annoying fact is that even if we took care about not instantiating templates if the user doesn't want them, the user pays for these preprocessor iterations. Think about it, in the case of perfect forward emulation the number of overload created is O(N!). Even if N is large, the search for the right overload shouldn't be a problem (searching is in O(log(N))).
The answer for that is easy: preprocess the code yourself, the way MPL does, for the minimum or default number of arguments you're going to support.
As a side note, more and more Boost libraries are making compilation very slow, and it would be nice to integrate standardized PCH headers as part of the Boost distribution, which would be automatically generated at installation time.
Agreed.
Instead of providing PCH headers, we could just preprocess our headers with some kind of boost.wave driver, like MPL already does.
<cough>Right.</cough> -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 10/17/2010 7:41 AM, Mathias Gaunard wrote:
Le 16/10/2010 14:34, Thomas Heller a écrit :
On Sat, Oct 16, 2010 at 9:55 AM, Eric Niebler<eric@boostpro.com> wrote:
On 10/15/2010 4:41 PM, Joel de Guzman wrote:
Anyway, having said that, just keep in mind that people have been clamoring for phoenix and I'd prefer something done sooner rather than later. We can tweak the library later as long as the main interface (not the extension interface) is stable. And it has remained more or less stable for a long time now. IMO, it should be a priority to focus on the remaining incompatibilities before anything else.
Hmm, good point.
Definitely a good point. Though, most of the stuff that doesn't work just yet was very difficult with the current intermediate form. That is why I started the discussion about that new design. So, even if the top level API is fixed (it was fixed already before, no real breakage between V2 and V3)
I thought V2 doesn't follow the result_of protocol, and didn't do perfect forwarding either. Those are the reasons I'm not using it and waiting for V3.
Those are really low hanging fruits that were the first to be implemented in V3. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On 10/13/2010 8:39 PM, Joel de Guzman wrote:
On 10/14/2010 11:22 AM, Edward Diener wrote:
On 10/13/2010 10:50 PM, Joel de Guzman wrote:
On 10/14/2010 10:41 AM, Edward Diener wrote: > I am curious to know if Phoenix will ever be released as a Boost > library, or is it meant to be forever coupled with Spirit? > > I have avoided it because it has never been released separately > or had its documentation appear among the list of Boost > libraries. I got the impression that it would be released > separately, and expected to see it in Boost 1.44, but evidently > that did not happen.
Thomas Heller completed the Proto port last July. Now the next step is to have a mini-review. Then, Boost integration, IFF it passes the mini-review.
Thanks ! I am sure I am not the only one looking forward to seeing it as a library of its own, and using it, if it passes the mini-review.
Let us request for a mini-review then. I think it's about time. Thomas? Eric?
The Proto port is done, but in the process of writing docs, Thomas realized there were some things about the Phoenix intermediate representation that would make extensibility difficult. He's been working on it. The design discussion is active on the proto list. (Chime in, I'd love your feedback.)
Indeed, I was missing you in the whole discussion Joel :)
Oh my, I just looked and you guys are miles ahead. I'm not sure I can keep up.
Anyway, having said that, just keep in mind that people have been clamoring for phoenix and I'd prefer something done sooner rather than later. We can tweak the library later as long as the main interface (not the extension interface) is stable. And it has remained more or less stable for a long time now. IMO, it should be a priority to focus on the remaining incompatibilities before anything else.
IMO, phoenix has surpassed the Boost bar even at V2. Interestingly, the bar has been set higher for this particular library due to other factors such as putting on the shoes of lambda, the inter-operability and proto, etc. I think it's about time to finish up and conclude that it is "good enough" :-)
I'm sure, thanks to you, Eric and all the amazing people here, that it'll get better over time. But let us get it into boost first.
FWIW, as the review manager of Phoenix2, and the one who suggested this mini review, I'd be happy to manage that review as well (if nobody objects, that is). Regards Hartmut --------------- http://boost-spirit.com
On 10/16/2010 9:33 PM, Hartmut Kaiser wrote:
FWIW, as the review manager of Phoenix2, and the one who suggested this mini review, I'd be happy to manage that review as well (if nobody objects, that is).
Ooops, I missed this. Needless to say, that would be great, Hartmut. Thank you very much! As soon as Thomas and Eric irons out all the issues (it's very close), then I'll ask for a mini-review. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On 10/25/2010 6:57 PM, Joel de Guzman wrote:
As soon as Thomas and Eric irons out all the issues (it's very close), then I'll ask for a mini-review.
For all those interested: after a lengthy and productive discussion, the details have been agreed as of today. Now Thomas just needs to make the required tweaks. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Tue, Oct 26, 2010 at 5:19 AM, Eric Niebler <eric@boostpro.com> wrote:
On 10/25/2010 6:57 PM, Joel de Guzman wrote:
As soon as Thomas and Eric irons out all the issues (it's very close), then I'll ask for a mini-review.
For all those interested: after a lengthy and productive discussion, the details have been agreed as of today. Now Thomas just needs to make the required tweaks.
I will get to it very soon. It shouldn't take long. I am very happy about the conclusion we came to ;) I guess it makes sense to schedule the review now.
At Thu, 14 Oct 2010 11:39:29 +0800, Joel de Guzman wrote:
On 10/14/2010 11:22 AM, Edward Diener wrote:
On 10/13/2010 10:50 PM, Joel de Guzman wrote:
On 10/14/2010 10:41 AM, Edward Diener wrote:
I am curious to know if Phoenix will ever be released as a Boost library, or is it meant to be forever coupled with Spirit ?
I have avoided it because it has never been released separately or had its documentation appear among the list of Boost libraries. I got the impression that it would be released separately, and expected to see it in Boost 1.44, but evidently that did not happen.
Thomas Heller completed the Proto port last July. Now the next step is to have a mini-review. Then, Boost integration, IFF it passes the mini-review.
Thanks ! I am sure I am not the only one looking forward to seeing it as a library of its own, and using it, if it passes the mini-review.
Let us request for a mini-review then. I think it's about time. Thomas? Eric?
Oh, please oh please? Can we? I've been waiting for this to happen for years. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Oct 14, 2010 at 4:22 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 10/13/2010 10:50 PM, Joel de Guzman wrote:
On 10/14/2010 10:41 AM, Edward Diener wrote:
I am curious to know if Phoenix will ever be released as a Boost library, or is it meant to be forever coupled with Spirit ?
I have avoided it because it has never been released separately or had its documentation appear among the list of Boost libraries. I got the impression that it would be released separately, and expected to see it in Boost 1.44, but evidently that did not happen.
Thomas Heller completed the Proto port last July. Now the next step is to have a mini-review. Then, Boost integration, IFF it passes the mini-review.
Thanks ! I am sure I am not the only one looking forward to seeing it as a library of its own, and using it, if it passes the mini-review.
Me too! There's something holding me back conceptually using Phoenix in contexts where no Spirit parsing is actually taking place. Pete
PB wrote:
On Thu, Oct 14, 2010 at 4:22 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 10/13/2010 10:50 PM, Joel de Guzman wrote:
On 10/14/2010 10:41 AM, Edward Diener wrote:
I am curious to know if Phoenix will ever be released as a Boost library, or is it meant to be forever coupled with Spirit ?
I have avoided it because it has never been released separately or had its documentation appear among the list of Boost libraries. I got the impression that it would be released separately, and expected to see it in Boost 1.44, but evidently that did not happen.
Thomas Heller completed the Proto port last July. Now the next step is to have a mini-review. Then, Boost integration, IFF it passes the mini-review.
Thanks ! I am sure I am not the only one looking forward to seeing it as a library of its own, and using it, if it passes the mini-review.
Me too! There's something holding me back conceptually using Phoenix in contexts where no Spirit parsing is actually taking place.
Is it just because you need to include header from a spirit subdirectory? If you just want to use phoenix, use it! There is nothing wrong with phoenix v2. Once v3 got accepted, the only thing you need to change is the include directive (plus some little nifty detail: return type calculation protocol for function changed).
On Thu, Oct 14, 2010 at 3:02 PM, Thomas Heller <thom.heller@googlemail.com> wrote:
PB wrote:
On Thu, Oct 14, 2010 at 4:22 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 10/13/2010 10:50 PM, Joel de Guzman wrote:
On 10/14/2010 10:41 AM, Edward Diener wrote:
I am curious to know if Phoenix will ever be released as a Boost library, or is it meant to be forever coupled with Spirit ?
I have avoided it because it has never been released separately or had its documentation appear among the list of Boost libraries. I got the impression that it would be released separately, and expected to see it in Boost 1.44, but evidently that did not happen.
Thomas Heller completed the Proto port last July. Now the next step is to have a mini-review. Then, Boost integration, IFF it passes the mini-review.
Thanks ! I am sure I am not the only one looking forward to seeing it as a library of its own, and using it, if it passes the mini-review.
Me too! There's something holding me back conceptually using Phoenix in contexts where no Spirit parsing is actually taking place.
Is it just because you need to include header from a spirit subdirectory?
In a nutshell, yes. I will just use it when I properly learn it. I've only done some mild Spirit semantic actions with it so far. Other team members who don't follow Boost at all (it's left to me here pretty much) will also get confused when they see Spirit headers being included and no apparent parsing taking place. With it not being a top-level library, they can't quickly get documentation on it either. I know where to dig to get it. Thanks, Pete
On Oct 14, 2010, at 10:32 AM, PB <newbarker@gmail.com> wrote:
With it not being a top-level library, they can't quickly get documentation on it either. I know where to dig to get it.
Yeah, it's almost impossible to find. -- BoostPro Computing * http://boostpro.com [Sent from coveted but awkward mobile device]
participants (9)
-
Dave Abrahams -
David Abrahams
-
Edward Diener -
Eric Niebler -
Hartmut Kaiser -
Joel de Guzman -
Mathias Gaunard -
PB -
Thomas Heller