Hi, what is going on Boost.Log? The library was accepted provisionally on March 2010 * Log - accepted provisionally March 2010; author: Andrey Semashev. Best, Vicente
On 03/31/2011 01:50 AM, Vicente BOTET wrote:
Hi,
what is going on Boost.Log? The library was accepted provisionally on March 2010
* Log - accepted provisionally March 2010; author: Andrey Semashev.
There are still a few things to be done before it can be included into Boost. Most notably, port to Boost.Phoenix3 is still pending as Boost.Phoenix3 has only recently been reviewed.
On 03/30/2011 07:32 PM, Andrey Semashev wrote:
On 03/31/2011 01:50 AM, Vicente BOTET wrote:
Hi,
what is going on Boost.Log? The library was accepted provisionally on March 2010
* Log - accepted provisionally March 2010; author: Andrey Semashev.
There are still a few things to be done before it can be included into Boost. Most notably, port to Boost.Phoenix3 is still pending as Boost.Phoenix3 has only recently been reviewed. _______________________________________________
Does it now work with filesystem V3 ? I'm currently building boost trunk using only V2 for Boost.Log support. michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On 3/31/2011 11:15 AM, Andrey Semashev wrote:
On 03/31/2011 09:29 AM, Michael Caisse wrote:
Does it now work with filesystem V3 ?
I'm currently building boost trunk using only V2 for Boost.Log support.
Yes, the support for Boost.Filesystem v3 is in trunk now. _______________________________________________
Wonderful. Thank you Andrey.
On 03/31/2011 11:15 AM, Andrey Semashev wrote:
On 03/31/2011 09:29 AM, Michael Caisse wrote:
Does it now work with filesystem V3 ?
I'm currently building boost trunk using only V2 for Boost.Log support.
Yes, the support for Boost.Filesystem v3 is in trunk now.
Andrey - Which "trunk" are you talking about? I don't see boost.log in the boost trunk. I assume the sourceforge trunk. Do you need some help migrating to the boost trunk? michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
I'm currently building boost trunk using only V2 for Boost.Log support.
Yes, the support for Boost.Filesystem v3 is in trunk now.
Andrey -
Which "trunk" are you talking about? I don't see boost.log in the boost trunk. I assume the sourceforge trunk.
Yes, the library is hosted at SourceForge.
Do you need some help migrating to the boost trunk?
Migrating is not the problem. There are quite a few things left to be done before merging to Boost SVN.
Message du 31/03/11 04:33 De : "Andrey Semashev" A : boost@lists.boost.org Copie à : Objet : Re: [boost] Boost.Log status
On 03/31/2011 01:50 AM, Vicente BOTET wrote:
Hi,
what is going on Boost.Log? The library was accepted provisionally on March 2010
* Log - accepted provisionally March 2010; author: Andrey Semashev.
There are still a few things to be done before it can be included into Boost. Most notably, port to Boost.Phoenix3 is still pending as Boost.Phoenix3 has only recently been reviewed.
I guess that Boost.Log was not waiting for Boost.Phoenix3 to go to the trunk? best, Vicente
On 03/31/2011 10:29 AM, Vicente BOTET wrote:
There are still a few things to be done before it can be included into Boost. Most notably, port to Boost.Phoenix3 is still pending as Boost.Phoenix3 has only recently been reviewed.
I guess that Boost.Log was not waiting for Boost.Phoenix3 to go to the trunk?
One of the acceptance requirements was to unify formatter and filter syntax. There were also complaints about limitations of lambda expressions of filters and formatters. Boost.Phoenix3 was my choice of solving these problems.
Andrey Semashev wrote:
On 03/31/2011 01:50 AM, Vicente BOTET wrote:
Hi,
what is going on Boost.Log? The library was accepted provisionally on March 2010
* Log - accepted provisionally March 2010; author: Andrey Semashev.
There are still a few things to be done before it can be included into Boost. Most notably, port to Boost.Phoenix3 is still pending as Boost.Phoenix3 has only recently been reviewed.
Ooh. Do you need to go down that rat hole? Is this so critical that cannot be done after the library is added? -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
On Mar 31, 2011, at 3:33 AM, Vladimir Prus wrote:
Andrey Semashev wrote:
There are still a few things to be done before it can be included into Boost. Most notably, port to Boost.Phoenix3 is still pending as Boost.Phoenix3 has only recently been reviewed.
Ooh. Do you need to go down that rat hole? Is this so critical that cannot be done after the library is added?
Not to be snarky, but I agree with the review results:
Critical issues ===============
Use of a custom lambda implementation was pointed by many as not great -- we already have a couple, so let's not add more to the mix.
It's possible that some of the "must fix" issues from a review can be fixed after release, though, right? Cheers, Gordon
On 31 March 2011 09:09, Gordon Woodhull <gordon@woodhull.com> wrote:
Not to be snarky, but I agree with the review results:
Critical issues ===============
Use of a custom lambda implementation was pointed by many as not great -- we already have a couple, so let's not add more to the mix.
It's possible that some of the "must fix" issues from a review can be fixed after release, though, right?
A library needs to satisfy the requirements from its review before it's added to trunk. But it could have used phoenix 2 to do that - if only to get the library in trunk and the regression tests running (which should be done as soon as possible). Anyway, phoenix 3 is in trunk now.
On 03/31/2011 12:44 PM, Daniel James wrote:
On 31 March 2011 09:09, Gordon Woodhull<gordon@woodhull.com> wrote:
Not to be snarky, but I agree with the review results:
Critical issues ===============
Use of a custom lambda implementation was pointed by many as not great -- we already have a couple, so let's not add more to the mix.
It's possible that some of the "must fix" issues from a review can be fixed after release, though, right?
A library needs to satisfy the requirements from its review before it's added to trunk. But it could have used phoenix 2 to do that - if only to get the library in trunk and the regression tests running (which should be done as soon as possible). Anyway, phoenix 3 is in trunk now.
There wasn't much point in porting to Boost.Phoenix2 knowing it would be superseded soon. After all, the Boost.Log lambda expressions do their job well enough, so this improvement does not seem very critical.
On 03/31/2011 11:33 AM, Vladimir Prus wrote:
Andrey Semashev wrote:
On 03/31/2011 01:50 AM, Vicente BOTET wrote:
Hi,
what is going on Boost.Log? The library was accepted provisionally on March 2010
* Log - accepted provisionally March 2010; author: Andrey Semashev.
There are still a few things to be done before it can be included into Boost. Most notably, port to Boost.Phoenix3 is still pending as Boost.Phoenix3 has only recently been reviewed.
Ooh. Do you need to go down that rat hole? Is this so critical that cannot be done after the library is added?
Well, you were the review manager. If you give me a green light, I can merge to Boost SVN and complete my work there. But I don't think that it'd be wise to release Boost.Log v2 as a part of Boost until it's complete, or at least until its interface is stable.
Andrey Semashev wrote:
On 03/31/2011 11:33 AM, Vladimir Prus wrote:
Andrey Semashev wrote:
On 03/31/2011 01:50 AM, Vicente BOTET wrote:
Hi,
what is going on Boost.Log? The library was accepted provisionally on March 2010
* Log - accepted provisionally March 2010; author: Andrey Semashev.
There are still a few things to be done before it can be included into Boost. Most notably, port to Boost.Phoenix3 is still pending as Boost.Phoenix3 has only recently been reviewed.
Ooh. Do you need to go down that rat hole? Is this so critical that cannot be done after the library is added?
Well, you were the review manager. If you give me a green light, I can merge to Boost SVN and complete my work there. But I don't think that it'd be wise to release Boost.Log v2 as a part of Boost until it's complete, or at least until its interface is stable.
What I meant -- do you really want to work against Phoenix V3, which is bleeding edge and might not have yet be fully ready? - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
On 04/01/2011 01:42 AM, Vladimir Prus wrote:
What I meant -- do you really want to work against Phoenix V3, which is bleeding edge and might not have yet be fully ready?
Are there other options? As I said in another reply, porting to Phoenix v2 is not very productive, especially when v3 is in SVN already. Not to do anything and wait until v3 gets more stable and mature? It might be ok, but I'd like to make all interface breaking changes before Boost.Log v2 is released and I don't want to delay the release that long.
Andrey Semashev wrote:
On 04/01/2011 01:42 AM, Vladimir Prus wrote:
What I meant -- do you really want to work against Phoenix V3, which is bleeding edge and might not have yet be fully ready?
Are there other options? As I said in another reply, porting to Phoenix v2 is not very productive, especially when v3 is in SVN already. Not to do anything and wait until v3 gets more stable and mature? It might be ok, but I'd like to make all interface breaking changes before Boost.Log v2 is released and I don't want to delay the release that long.
I honestly have no idea whether using V2 now and porting to V3 later will be more effort or less than using V3 right away. Hopefully, somebody more competent can comment on this -- if not, you get to pick ;-) -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
On Fri, Apr 1, 2011 at 8:10 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Andrey Semashev wrote:
On 04/01/2011 01:42 AM, Vladimir Prus wrote:
What I meant -- do you really want to work against Phoenix V3, which is bleeding edge and might not have yet be fully ready?
Are there other options? As I said in another reply, porting to Phoenix v2 is not very productive, especially when v3 is in SVN already. Not to do anything and wait until v3 gets more stable and mature? It might be ok, but I'd like to make all interface breaking changes before Boost.Log v2 is released and I don't want to delay the release that long.
I honestly have no idea whether using V2 now and porting to V3 later will be more effort or less than using V3 right away. Hopefully, somebody more competent can comment on this -- if not, you get to pick ;-)
Phoenix V3 certainly has some remaining hick ups with certain compilers: http://tinyurl.com/3cytwhu But overall I believe its quite stable. Besides, we will never know if it is really mature enough when everyone decides not to use it cause they think its not mature enough. Viscous circle. I recently ported spirit to Phoenix V3. It was an effort of about a week with only minor changes. The test runner result look okayish ( http://tinyurl.com/3ekulem ). Working on resolving these issues in the next few days. I think porting to Phoenix V3 now is the best option: Phoenix V3 hasn't been part of an official release yet, this means we can change some APIs or semantics easily if you find something that is not working out quite well with your use case. Regards, Thomas
On 04/01/2011 10:44 AM, Thomas Heller wrote:
I think porting to Phoenix V3 now is the best option: Phoenix V3 hasn't been part of an official release yet, this means we can change some APIs or semantics easily if you find something that is not working out quite well with your use case.
Thank you for the info. I will stick to my original plan of porting to v3 then.
participants (7)
-
Andrey Semashev -
Daniel James -
Gordon Woodhull -
Michael Caisse -
Thomas Heller -
Vicente BOTET -
Vladimir Prus