[1.43][beta] Fix for MPL under gcc 4.5
Can : https://svn.boost.org/trac/boost/ticket/4061 be fixed by merging the attached trivial patch ? gcc 4.5 borks up on a deep MPL internals that prevent some other component to not compile. Thanks -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
On 4/20/2010 10:30 PM, joel falcou wrote:
Can : https://svn.boost.org/trac/boost/ticket/4061
be fixed by merging the attached trivial patch ?
gcc 4.5 borks up on a deep MPL internals that prevent some other component to not compile.
As much as I would love to see this merged (it's breaking xpressive on gcc-4.5), I think it's too late. It hasn't even been applied to trunk yet. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Wednesday 21 April 2010 08:30:07 Eric Niebler wrote:
On 4/20/2010 10:30 PM, joel falcou wrote:
Can : https://svn.boost.org/trac/boost/ticket/4061
be fixed by merging the attached trivial patch ?
gcc 4.5 borks up on a deep MPL internals that prevent some other component to not compile.
As much as I would love to see this merged (it's breaking xpressive on gcc-4.5), I think it's too late. It hasn't even been applied to trunk yet.
It is not only breaking expressive, parts of fusion are affected too. (See attached testcase).
Eric Niebler wrote:
As much as I would love to see this merged (it's breaking xpressive on gcc-4.5), I think it's too late. It hasn't even been applied to trunk yet.
I thought we have another opportunity to merge bug fix and cycle test once ? Isn't 1.43 scheduled for May, 3rd ? This is a real show-stopper which fix won't broke anything
On 21 April 2010 08:46, Joel Falcou <joel.falcou@lri.fr> wrote:
I thought we have another opportunity to merge bug fix and cycle test once ? Isn't 1.43 scheduled for May, 3rd ?
This is a real show-stopper which fix won't broke anything
The beta cycle is more about fixing regressions caused by changes to boost, rather than existing problems or problems caused by external changes. But the real problem here is that no one has accepted the ticket. If the library was actively maintained, then IMO this would be fine (after testing, naturally). Daniel
Daniel James wrote:
The beta cycle is more about fixing regressions caused by changes to boost, rather than existing problems or problems caused by external changes. But the real problem here is that no one has accepted the ticket. If the library was actively maintained, then IMO this would be fine (after testing, naturally).
I thought MPl was actively maintained considering its use. Anyway to get something done somehow ?
On 21 April 2010 12:47, Joel Falcou <joel.falcou@lri.fr> wrote:
The beta cycle is more about fixing regressions caused by changes to boost, rather than existing problems or problems caused by external changes. But the real problem here is that no one has accepted the ticket. If the library was actively maintained, then IMO this would be fine (after testing, naturally).
I thought MPl was actively maintained considering its use.
It's maintained but slowly. It's pretty stable so that's mostly okay. New versions of gcc do seem to throw up problems (there were also issues with gcc 4.4).
Anyway to get something done somehow ?
I guess that step 1 would be to find an appropriate person to accept the ticket and check a fix into trunk. Daniel
Daniel James wrote:
On 21 April 2010 12:47, Joel Falcou <joel.falcou@lri.fr> wrote:
The beta cycle is more about fixing regressions caused by changes to boost, rather than existing problems or problems caused by external changes. But the real problem here is that no one has accepted the ticket. If the library was actively maintained, then IMO this would be fine (after testing, naturally).
I thought MPl was actively maintained considering its use.
It's maintained but slowly. It's pretty stable so that's mostly okay. New versions of gcc do seem to throw up problems (there were also issues with gcc 4.4).
Anyway to get something done somehow ?
I guess that step 1 would be to find an appropriate person to accept the ticket and check a fix into trunk.
We spoke on IRC and Hartmut has volunteered to commit the fix, babysit the test results and then say when the change is ready for merge. I guess we have a plan now. - Volodya
On 21 April 2010 12:47, Joel Falcou <joel.falcou@lri.fr> wrote:
The beta cycle is more about fixing regressions caused by changes
to
boost, rather than existing problems or problems caused by external changes. But the real problem here is that no one has accepted the ticket. If the library was actively maintained, then IMO this would be fine (after testing, naturally).
I thought MPl was actively maintained considering its use.
It's maintained but slowly. It's pretty stable so that's mostly okay. New versions of gcc do seem to throw up problems (there were also issues with gcc 4.4).
Anyway to get something done somehow ?
I guess that step 1 would be to find an appropriate person to accept the ticket and check a fix into trunk.
We spoke on IRC and Hartmut has volunteered to commit the fix, babysit the test results and then say when the change is ready for merge. I guess we have a plan now.
I applied the patch after regenerating the affected preprocessed files. Here is the commit message: (In [61467]) MPL: fixed #4061: gcc-4.5 compilation problems related to arity_helper, applied attached patch to the main aux_/template_arity.hpp and regenerated the corresponding file preprocessed/gcc/template_arity.hpp. No other preprocessed files are affected. This patch seemed to be fine as all it does is to qualify an internal name in order to avoid it being looked up through ADL. This appears to be reasonably safe as this name is internal and not supposed to be found using ADL in the first place. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
On Wed, 21 Apr 2010 12:20:41 -0500, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
I applied the patch after regenerating the affected preprocessed files. Here is the commit message:
(In [61467]) MPL: fixed #4061: gcc-4.5 compilation problems related to arity_helper, applied attached patch to the main aux_/template_arity.hpp and regenerated the corresponding file preprocessed/gcc/template_arity.hpp. No other preprocessed files are affected.
Thanks, Hartmut!
This patch seemed to be fine as all it does is to qualify an internal name in order to avoid it being looked up through ADL. This appears to be reasonably safe as this name is internal and not supposed to be found using ADL in the first place.
Yep. Plus we have tests :). Thanks again, -- Aleksey Gurtovoy MetaCommunications Engineering
Thanks to everybody for fixing this :) I didn't mean to sound harsh in my initial post and I apologize if I sounded like that. We appreciate all the dedication everyone is providing here :)
On Wed, 21 Apr 2010 06:30:21 -0500, Daniel James <dnljms@gmail.com> wrote:
On 21 April 2010 08:46, Joel Falcou <joel.falcou@lri.fr> wrote:
I thought we have another opportunity to merge bug fix and cycle test once ? Isn't 1.43 scheduled for May, 3rd ?
This is a real show-stopper which fix won't broke anything
The beta cycle is more about fixing regressions caused by changes to boost, rather than existing problems or problems caused by external changes. But the real problem here is that no one has accepted the ticket. If the library was actively maintained, then IMO this would be fine (after testing, naturally).
I've seen the ticket, but the scope/urgency of the issue (show stopper for Fusion and Xpressive) wasn't apparent to me from the ticket's description. My experience as a release manager (admittedly from a long time ago) was that release-critical issues will slip past even the most active library maintainers, and letting them know about it (and occasionally nagging) goes a long way towards "all green" release. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
On Wed, 21 Apr 2010 06:30:21 -0500, Daniel James <dnljms@gmail.com> wrote:
On 21 April 2010 08:46, Joel Falcou <joel.falcou@lri.fr> wrote:
I thought we have another opportunity to merge bug fix and cycle test once ? Isn't 1.43 scheduled for May, 3rd ?
This is a real show-stopper which fix won't broke anything
The beta cycle is more about fixing regressions caused by changes to boost, rather than existing problems or problems caused by external changes. But the real problem here is that no one has accepted the ticket. If the library was actively maintained, then IMO this would be fine (after testing, naturally).
I've seen the ticket, but the scope/urgency of the issue (show stopper for Fusion and Xpressive) wasn't apparent to me from the ticket's description.
My experience as a release manager (admittedly from a long time ago) was that release-critical issues will slip past even the most active library maintainers, and letting them know about it (and occasionally nagging) goes a long way towards "all green" release.
For all I can tell, it was not apparent to *anybody*, so there's nothing we could have done differently -- unless anybody has a pill that give supernatural powers. - Volodya
On Thu, Apr 22, 2010 at 2:39 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Aleksey Gurtovoy wrote:
My experience as a release manager (admittedly from a long time ago) was that release-critical issues will slip past even the most active library maintainers, and letting them know about it (and occasionally nagging) goes a long way towards "all green" release.
For all I can tell, it was not apparent to *anybody*, so there's nothing we could have done differently -- unless anybody has a pill that give supernatural powers.
The case of two major compilers shipping new and important versions just before a Boost release is unusual. If we end up taking an extra week to clear related issues, I don't see that as a problem. --Beman
On 22 April 2010 04:43, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
On Wed, 21 Apr 2010 06:30:21 -0500, Daniel James <dnljms@gmail.com> wrote:
The beta cycle is more about fixing regressions caused by changes to boost, rather than existing problems or problems caused by external changes. But the real problem here is that no one has accepted the ticket. If the library was actively maintained, then IMO this would be fine (after testing, naturally).
I've seen the ticket, but the scope/urgency of the issue (show stopper for Fusion and Xpressive) wasn't apparent to me from the ticket's description.
Just to put what I wrote in context, I've sent a few mails to this list in the past suggesting that we should take greater group ownership, rather than relying on individual maintainers to deal with a library's issues. It wasn't my intent to criticise you for not actively maintaining MPL. I think I might sound too negative about this, there seems to be more people taking on these issues over the past year or so.
My experience as a release manager (admittedly from a long time ago) was that release-critical issues will slip past even the most active library maintainers, and letting them know about it (and occasionally nagging) goes a long way towards "all green" release.
The release process is quite different now. It seems to me that the focus is to get a regular release with the more modest goal of being an incremental improvement, rather than an 'all green' release. If there is a bug that goes unfixed, it can be fixed three months later, which is not that long and quicker than you'd wait for some of the old releases to be finished. If no one's fixing it, and someone cares about it, it's their responsibility to make sure it gets fixed. This reduces the burden on the release managers, which was too high in the old system. For all its faults, the new system feels like an improvement to me. (It's hopefully clear that this is all my opinion, not policy). Daniel
Daniel James wrote:
The release process is quite different now. It seems to me that the focus is to get a regular release with the more modest goal of being an incremental improvement, rather than an 'all green' release.
I don't think there's a conflict here. If the trunk is merged into the release and something doesn't show up as "all green", it should be addressed right then - in only via a markup. That is - the release branch should always be ready for release. Having said that, there is a problem in that it can take quite a while for all the release tests to cycle so one might not notice until some time later - when one is engaged in something else.
If there is a bug that goes unfixed, it can be fixed three months later, which is not that long and quicker than you'd wait for some of the old releases to be finished. If no one's fixing it, and someone cares about it, it's their responsibility to make sure it gets fixed. This reduces the burden on the release managers, which was too high in the old system. For all its faults, the new system feels like an improvement to me. (It's hopefully clear that this is all my opinion, not policy).
It's my opinion also. Robert Ramey
On Thu, 22 Apr 2010 03:10:30 -0500, Daniel James <dnljms@gmail.com> wrote:
On 22 April 2010 04:43, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
My experience as a release manager (admittedly from a long time ago) was that release-critical issues will slip past even the most active library maintainers, and letting them know about it (and occasionally nagging) goes a long way towards "all green" release.
The release process is quite different now. It seems to me that the focus is to get a regular release with the more modest goal of being an incremental improvement, rather than an 'all green' release.
Like Robert, I don't see a conflict here. The "all green" part is exactly about incremental improvement: it says "this release is not worse than the previous one, except for these known issues". It was simply a concise, objective, easy-to-track and easy-to-explain criterion to keep us on track towards that goal. -- Aleksey Gurtovoy MetaCommunications Engineering
On 23 April 2010 04:29, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
On Thu, 22 Apr 2010 03:10:30 -0500, Daniel James <dnljms@gmail.com> >>
The release process is quite different now. It seems to me that the focus is to get a regular release with the more modest goal of being an incremental improvement, rather than an 'all green' release.
Like Robert, I don't see a conflict here. The "all green" part is exactly about incremental improvement: it says "this release is not worse than the previous one, except for these known issues". It was simply a concise, objective, easy-to-track and easy-to-explain criterion to keep us on track towards that goal.
I didn't claim that it conflicts, just that it isn't a requirement for incremental improvement and that it slows down releases and increases work for the release managers. It might be easy to track and explain, but not necessarily to achieve. Daniel
On Fri, 23 Apr 2010 01:21:40 -0500, Daniel James <dnljms@gmail.com> wrote:
On 23 April 2010 04:29, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
On Thu, 22 Apr 2010 03:10:30 -0500, Daniel James <dnljms@gmail.com> >>
The release process is quite different now. It seems to me that the focus is to get a regular release with the more modest goal of being an incremental improvement, rather than an 'all green' release.
Like Robert, I don't see a conflict here. The "all green" part is exactly about incremental improvement: it says "this release is not worse than the previous one, except for these known issues". It was simply a concise, objective, easy-to-track and easy-to-explain criterion to keep us on track towards that goal.
I didn't claim that it conflicts, just that it isn't a requirement for incremental improvement
IMO it is if you actually want to be objective about it rather than just guestimate.
and that it slows down releases
If you mean sometimes not releasing on the cut-off date, yes it does, as would any form of quality guarantee vs cut-off release date. But then you can't actually claim incremental improvement with the no-matter-what cut-off release date, can you?
and increases work for the release managers.
Yes, it does, although I personally disagree with the implication that the increase is inherently substantial, is solely responsible for the unbearably long past release cycles, or is too much of a price to pay for the benefit of being able to say to users "yes, you can upgrade" with any sort of confidence and facts to back it up. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
On Thu, 22 Apr 2010 03:10:30 -0500, Daniel James <dnljms@gmail.com> wrote:
On 22 April 2010 04:43, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
My experience as a release manager (admittedly from a long time ago) was that release-critical issues will slip past even the most active library maintainers, and letting them know about it (and occasionally nagging) goes a long way towards "all green" release.
The release process is quite different now. It seems to me that the focus is to get a regular release with the more modest goal of being an incremental improvement, rather than an 'all green' release.
Like Robert, I don't see a conflict here. The "all green" part is exactly about incremental improvement: it says "this release is not worse than the previous one, except for these known issues". It was simply a concise, objective, easy-to-track and easy-to-explain criterion to keep us on track towards that goal.
I can't resist picking a tiny nit here. I would just say "this release is better than the previous one." If that's not true we shouldn't make new release. And I believe we've been doing exactly this. The current situation illustrates this very well in that the main problem has been very recent new release of compilers we are commited to support. And these releases are less than a month old!!! That this is the only problem (that I can see) tells me that things are working quite well. I see boost constantly improving. The number of bugs we know about tends to increase so it might not look that way. The number of bugs we actually have is decreasing. So things ARE getting very good. Note that I'm assuming that the number of new bugs introduced is only a very small number of bugs reported. I believe this to be true. Also the elapsed time between the time a bug is reported, isolated and appears fixed in the boost deployment has shortened to 3 months for many libraries. Not too many software projects of this scale can claim that !!! Robert Ramey
joel falcou skrev:
Can : https://svn.boost.org/trac/boost/ticket/4061
be fixed by merging the attached trivial patch ?
gcc 4.5 borks up on a deep MPL internals that prevent some other component to not compile.
I in a perfect world, the GCC developers would actually test their compiler on Boost before releasing it, and report back to us that we have invalid code, or fix the compiler. What's stopping them? Or any compiler vendor for that sake? -Thorsten
Thorsten Ottosen wrote:
I in a perfect world, the GCC developers would actually test their compiler on Boost before releasing it, and report back to us that we have invalid code, or fix the compiler.
What's stopping them? Or any compiler vendor for that sake?
See my answer to the opposite question: <http://lists.boost.org/Archives/boost/2010/04/164678.php> Neither msvc-10.0 nor gcc-4.5 are among the compilers that are tested for the release branch <http://www.boost.org/development/tests/release/developer/summary.html> for 1.43. So I guess it is a safe assumption that compatibility with msvc-10.0 or gcc-4.5 is not a release criteria for 1.43. Making 1.44 more compatible with gcc-4.5 and MSVC-10 might be a good idea, but the first step in this direction should be to add msvc-10.0 and gcc-4.5 to the regression tests for the release branch. And no, I won't donate machine time for these regression tests. Regards, Thomas
Thomas Klimpel wrote:
Thorsten Ottosen wrote:
I in a perfect world, the GCC developers would actually test their compiler on Boost before releasing it, and report back to us that we have invalid code, or fix the compiler.
What's stopping them? Or any compiler vendor for that sake?
Neither msvc-10.0 nor gcc-4.5 are among the compilers that are tested for the release branch <http://www.boost.org/development/tests/release/developer/summ ary.html> for 1.43. So I guess it is a safe assumption that compatibility with msvc-10.0 or gcc-4.5 is not a release criteria for 1.43.
You redirected focus on Boost and the 1.43 release, which wasn't Thorsten's point.
Making 1.44 more compatible with gcc-4.5 and MSVC-10 might be a good idea, but the first step in this direction should be to add msvc-10.0 and gcc-4.5 to the regression tests for the release branch. And no, I won't donate machine time for these regression tests.
That's important, but rather late. If the vendors test new compilers against Boost, they'd find errors in their compilers and in Boost. Ideally, they'd fix the former before release, and it would be helpful if they reported the latter here so a coincident or immediately subsequent Boost release can include the necessary changes. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
I could do a run of VC10 and/or Mingw 4.5 on the release branch, but i don't have the resources to do it regularly on top of the ones i'm already testing (VC8/9). I'm personally more interested in 9 and 10 than 8 so i could switch from 8/9 to 9/10, but it seems that no one else is doing 8 at the moment.
On Wed, Apr 21, 2010 at 8:17 AM, Richard Webb <richard.webb@boldonjames.com> wrote:
I could do a run of VC10 and/or Mingw 4.5 on the release branch, but i don't have the resources to do it regularly on top of the ones i'm already testing (VC8/9).
I'm personally more interested in 9 and 10 than 8 so i could switch from 8/9 to 9/10, but it seems that no one else is doing 8 at the moment.
Please go ahead and switch your release testing to VC++ 9/10. I'll try to set my machine up to release test vc++ 8. --Beman
Beman Dawes wrote:
On Wed, Apr 21, 2010 at 8:17 AM, Richard Webb <richard.webb@boldonjames.com> wrote:
I could do a run of VC10 and/or Mingw 4.5 on the release branch, but i don't have the resources to do it regularly on top of the ones i'm already testing (VC8/9).
I'm personally more interested in 9 and 10 than 8 so i could switch from 8/9 to 9/10, but it seems that no one else is doing 8 at the moment.
Please go ahead and switch your release testing to VC++ 9/10. I'll try to set my machine up to release test vc++ 8.
--Beman
I have setup a virtual machine on one of my build servers to perform trunk and release regressions with VC8. The first trunk regression finished a bit ago and the release has started. I have only allocated one processor and 1GB of RAM to the VM. As a result, builds aren't real fast but I am happy to let them run if it is helpful. Best regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On Thu, Apr 22, 2010 at 1:10 AM, Michael Caisse <boost@objectmodelingdesigns.com> wrote:
Beman Dawes wrote:
On Wed, Apr 21, 2010 at 8:17 AM, Richard Webb <richard.webb@boldonjames.com> wrote:
I could do a run of VC10 and/or Mingw 4.5 on the release branch, but i don't have the resources to do it regularly on top of the ones i'm already testing (VC8/9).
I'm personally more interested in 9 and 10 than 8 so i could switch from 8/9 to 9/10, but it seems that no one else is doing 8 at the moment.
Please go ahead and switch your release testing to VC++ 9/10. I'll try to set my machine up to release test vc++ 8.
--Beman
I have setup a virtual machine on one of my build servers to perform trunk and release regressions with VC8. The first trunk regression finished a bit ago and the release has started.
I have only allocated one processor and 1GB of RAM to the VM. As a result, builds aren't real fast but I am happy to let them run if it is helpful.
Definitely helpful! --Beman
VC10 results are now visible for the release branch. Is it a good time to update the expected failures markup with some VC10 results? There are a couple of tests that are failing in the same was as VC9, where they are marked as expected (e.g. conversion/lexical_cast_loopback_test, type_traits/promote_enum_msvc_bug_test).
Thomas Klimpel skrev:
Thorsten Ottosen wrote:
I in a perfect world, the GCC developers would actually test their compiler on Boost before releasing it, and report back to us that we have invalid code, or fix the compiler.
What's stopping them? Or any compiler vendor for that sake?
See my answer to the opposite question: <http://lists.boost.org/Archives/boost/2010/04/164678.php>
How can that possibly answer my question? :-)
Neither msvc-10.0 nor gcc-4.5 are among the compilers that are tested for the release branch <http://www.boost.org/development/tests/release/developer/summary.html> for 1.43. So I guess it is a safe assumption that compatibility with msvc-10.0 or gcc-4.5 is not a release criteria for 1.43.
Making 1.44 more compatible with gcc-4.5 and MSVC-10 might be a good idea, but the first step in this direction should be to add msvc-10.0 and gcc-4.5 to the regression tests for the release branch. And no, I won't donate machine time for these regression tests.
Well, my point was that we might be able to help eachother out. I think Boost is well-known for presenting code that is quite challenging for compilers, and so it seems like Boost itself would be a good test-suite for the compiler vendors. -Thorsten
Can : https://svn.boost.org/trac/boost/ticket/4061
be fixed by merging the attached trivial patch ?
gcc 4.5 borks up on a deep MPL internals that prevent some other component to not compile.
I in a perfect world, the GCC developers would actually test their compiler on Boost before releasing it, and report back to us that we have invalid code, or fix the compiler.
saying `the other ones are responsible' is in no way helpful. this issue has been dealt with on april 1st [1] by the gcc devs, a month before the release of 1.43. however i remember other cases, when tickets with patches were filed against boost, to support new compiler releases, that were not dealt with for quite some time. in a real world, people will have to ship their own patched version of boost in order to support new compilers. tim [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43608 -- tim@klingt.org http://tim.klingt.org After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
Tim Blechmann skrev:
Can : https://svn.boost.org/trac/boost/ticket/4061
be fixed by merging the attached trivial patch ?
gcc 4.5 borks up on a deep MPL internals that prevent some other component to not compile. I in a perfect world, the GCC developers would actually test their compiler on Boost before releasing it, and report back to us that we have invalid code, or fix the compiler.
saying `the other ones are responsible' is in no way helpful. this issue has been dealt with on april 1st [1] by the gcc devs, a month before the release of 1.43. however i remember other cases, when tickets with patches were filed against boost, to support new compiler releases, that were not dealt with for quite some time.
in a real world, people will have to ship their own patched version of boost in order to support new compilers.
Well, I'm merely saying that we are both responsible. When there is a bug in a released compiler, the compiler is responsible, but we end up having to fix it. When the bug is in the library, we are responsible, and we fix it. But other users of compilers will likely need to deal with the same problems. I was merely hoping that we could improve the way we work together, so we for the benefit of both parties can avoid dealing with too many compiler bugs after a release. Dealing with such problems seems to consume quite much of the time of the developers at Boost. -Thorsten
participants (16)
-
Aleksey Gurtovoy -
Beman Dawes -
Daniel James -
Eric Niebler -
Hartmut Kaiser -
joel falcou -
Joel Falcou
-
Michael Caisse -
Richard Webb -
Robert Ramey -
Stewart, Robert -
Thomas Heller -
Thomas Klimpel -
Thorsten Ottosen -
Tim Blechmann -
Vladimir Prus