[RangeEx] Where is the current version?
Where is the current version (or a fairly recent version) of RangeEx? I can't find anything on the trunk, the sandbox or the vault.
On Mon, Jul 20, 2009 at 10:28 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
Where is the current version (or a fairly recent version) of RangeEx? I can't find anything on the trunk, the sandbox or the vault.
Latest seems to be http://www.boostpro.com/vault/index.php?action=downloadfile&filename=range_ex.zip&directory=Algorithms& which is from April. I know Neil had quite bit on his plate after the recent review. - Rob.
On Tue, Jul 21, 2009 at 8:37 AM, Robert Jones <robertgbjones@gmail.com>wrote:
On Mon, Jul 20, 2009 at 10:28 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
Where is the current version (or a fairly recent version) of RangeEx? I can't find anything on the trunk, the sandbox or the vault.
Latest seems to be
This is exactly correct. This is the latest version I have released. I have been a little delayed in working on the suggestions from the review. Slightly more alarmingly I made a request a week ago for write access to the subversion repository and did not receive a response. I have been waiting a little while before repeating my request for fear of appearing rude.
which is from April. I know Neil had quite bit on his plate after the recent review.
I have been continuing development of RangeEx, but not uploading as I wish to get everything under sub-version as quickly as possible. The repeated merges from and to zip files seems highly inefficient, especially considering it is now accepted.
- Rob.
Regards, Neil Groves
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi,
Where is the current version (or a fairly recent version) of RangeEx? I can't find anything on the trunk, the sandbox or the vault.
Latest seems to be
(...)
I have been continuing development of RangeEx, but not uploading as I wish to get everything under sub-version as quickly as possible. The repeated merges from and to zip files seems highly inefficient, especially considering it is now accepted.
Is there any news from RangeEx? Where can I find the latest version, is there known when it will be included? Regards, Barend
Is there any news from RangeEx? Where can I find the latest version, is there known when it will be included?
Regards, Barend
The latest version is here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=range_ex.zip&directory=Algorithms& I am attempting to complete the documentation this weekend, and will attempt to perform my first commit to the trunk either this weekend or the next. In the meanwhile if there is anything that you need from me that will help in using the library then please contact me. Regards, Neil Groves
Hi Neil,
The latest version is here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=range_ex.zip&directory=Algorithms&
I am attempting to complete the documentation this weekend, and will attempt to perform my first commit to the trunk either this weekend or the next.
In the meanwhile if there is anything that you need from me that will help in using the library then please contact me.
Thanks for the quick answer. We want to see if we can use it for adding / removing things (points) to ranges (used in geometries) in a generic way. Regards, Barend
Neil Groves wrote:
The latest version is here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=range_ex.zip&directory=Algorithms&
As asked during review, you made boost::adaptors::filtered and friends function objects. However, they take their arguments by copy (which can be a serious problem with ranges), and don't provide a result_type or result<> template. I'm also concerned that the return type of make_filtered_range and friends is a detail and thus unspecified. Was nothing said about that during review?
Mathias Gaunard wrote:
As asked during review, you made boost::adaptors::filtered and friends function objects.
My bad, I was in a hurry and didn't take a proper look. I meant that you made filtered(range, predicate) work, on top of range | filtered(predicate), as was asked by some people during review if I remember well. But it appears you didn't. This version doesn't seem to be any different than the review one.
However, they take their arguments by copy (which can be a serious problem with ranges), and don't provide a result_type or result<> template.
If the function object is only used for the operator| syntax, of course, this is a lesser concern.
On Sun, Feb 28, 2010 at 8:18 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
Mathias Gaunard wrote:
As asked during review, you made boost::adaptors::filtered and friends
function objects.
My bad, I was in a hurry and didn't take a proper look. I meant that you made filtered(range, predicate) work, on top of range | filtered(predicate), as was asked by some people during review if I remember well.
But it appears you didn't. This version doesn't seem to be any different than the review one.
The version uploaded in the vault does lack some changes requested during the review. This specific change is currently in my own version and will be part of the updated code that I shall commit to the trunk in the near future. Once I have committed to the trunk I will solicit feedback from everyone but in particular will seek to ensure that I have met everyones expectations for the post-review changes.
However, they take their arguments by copy (which can be a serious problem
with ranges), and don't provide a result_type or result<> template.
I'm failing to understand your concern about the parameters that are copied. The usual idiom of passing ranges by reference is used, and the parameters can be changed using boost::cref or boost::ref unless I have made an implementation error. I would consider this a defect and I am therefore keen to understand better your concern. I suspect that I am missing a valuable test case, hence your further feedback would be gratefully received.
If the function object is only used for the operator| syntax, of course, this is a lesser concern.
Ah I must confess that my first implementation of the non '|' syntax just forwarded to the '|' syntax. I am correcting this before release as it is rather an unnecessary and convoluted solution. The cost of the adapter holder used in the '|' operator tends to zero on a decent optimized compilation for the cases I have analysed. I do not want the '|' syntax to have inferior performance. If you have data about a performance degradation then again I would be happy to understand your use case. Thank you for your patience and interest. Regards, Neil Groves
As the title said : Where is the current version ? :) It seems to have vanished from the vault !? I can't find any trace here anymore : http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Algorithms Thanks ! 2010/2/27 Neil Groves <neil@grovescomputing.com>
Is there any news from RangeEx? Where can I find the latest version, is there known when it will be included?
Regards, Barend
The latest version is here:
I am attempting to complete the documentation this weekend, and will attempt to perform my first commit to the trunk either this weekend or the next.
In the meanwhile if there is anything that you need from me that will help in using the library then please contact me.
Regards, Neil Groves _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Apr 16, 2010 at 9:52 PM, Thomas Petit <thomas.petit33@gmail.com>wrote:
As the title said : Where is the current version ? :)
It is on the trunk. All you need to do is checkout the trunk from subversion. Boost.Range has all the RangeEx functionality merged in. I am targeting a release in 1.43
It seems to have vanished from the vault !? I can't find any trace here anymore :
http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Algorithms
Yes it has. I remove it to avoid anyone getting the older version before the improvements due to review feedback.
Regards, Neil Groves
Wait ! Did you just wrote that RangeEx is now at last in the trunk and ready for 1.43 ? That's freaking great ! Two comments : 1) Maybe a small oversight* *in boost/range/adaptors.hpp : all adaptors are included except the strided one. 2) Is there somewhere in RangeEx some shortcuts to construct a standard container directly from a range ? Something along the line of : namespace boost { template <typename Range> std::vector<typename Range::value_type> make_vector(Range& rng) { return std::vector<typename Range::value_type>(boost::begin(rng), boost::end(rng)); } } int main() { std::vector<int> v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; std::vector<int> v2 = boost::make_vector(v | boost::adaptors::strided(2)); } Regards. 2010/4/17 Neil Groves <neil@grovescomputing.com>
On Fri, Apr 16, 2010 at 9:52 PM, Thomas Petit <thomas.petit33@gmail.com
wrote:
As the title said : Where is the current version ? :)
It is on the trunk. All you need to do is checkout the trunk from subversion. Boost.Range has all the RangeEx functionality merged in. I am targeting a release in 1.43
It seems to have vanished from the vault !? I can't find any trace here anymore :
http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Algorithms
Yes it has. I remove it to avoid anyone getting the older version before
the improvements due to review feedback.
Regards, Neil Groves _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
More comments : My compiler is vs2010 : for the bullet 2) and 3) I set up this code :
#include <vector> #include <boost/range/algorithm.hpp> #include <boost/range/algorithm_ext.hpp> #include <boost/range/adaptors.hpp> #include <boost/range/adaptor/strided.hpp> int main() { int ar[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; std::vector<int> v(ar, ar+10); ... }
1) Put "using namespace boost::adaptors" brings havoc. Even with an empty main, just write :
#include <boost/range/adaptors.hpp> using namespace boost::adaptors; and then the compiler emits some strange compilation error : "program files\boost\boost\range\iterator.hpp(63): error C2039: 'type' : is not a member of 'boost::mpl::eval_if_c<C,F1,F2>'"
2) Stride adaptor. I tried :
std::vector<int> v2; boost::push_back(v2, v | boost::adaptors::sliced(0, 5) | boost::adaptors::strided(2) );
I expected that my initial set {1, 2, 3, 4, 5, 6, 7, 8, 9, 10} get sliced to {1, 2, 3, 4, 5} and then strided to {1, 3, 5}. But I actually got an MSVC assert : "Expression : vector iterator not dereferencable" 3) Transform adaptor. Isn't there a way to deduce the return type instead of relying on the typedef return_type ? My first impulse was to tried a lambda:
std::vector<int> v3; push_back(v3, v | transformed([](int i){ return i * 10;} ); But it failed because of the lack of return_type typedef inside the lambda. And actually, even without fancy lambdas, it means that a simple free function will fail too.
Should I file some ticket about this three points ? Regards. 2010/4/18 Thomas Petit <thomas.petit33@gmail.com>
Wait ! Did you just wrote that RangeEx is now at last in the trunk and ready for 1.43 ? That's freaking great !
Two comments : 1) Maybe a small oversight* *in boost/range/adaptors.hpp : all adaptors are included except the strided one. 2) Is there somewhere in RangeEx some shortcuts to construct a standard container directly from a range ? Something along the line of :
namespace boost { template <typename Range> std::vector<typename Range::value_type> make_vector(Range& rng) { return std::vector<typename Range::value_type>(boost::begin(rng), boost::end(rng)); } }
int main() { std::vector<int> v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; std::vector<int> v2 = boost::make_vector(v | boost::adaptors::strided(2)); }
Regards.
2010/4/17 Neil Groves <neil@grovescomputing.com>
On Fri, Apr 16, 2010 at 9:52 PM, Thomas Petit <thomas.petit33@gmail.com
wrote:
As the title said : Where is the current version ? :)
It is on the trunk. All you need to do is checkout the trunk from subversion. Boost.Range has all the RangeEx functionality merged in. I am targeting a release in 1.43
It seems to have vanished from the vault !? I can't find any trace here anymore :
http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Algorithms
Yes it has. I remove it to avoid anyone getting the older version before
the improvements due to review feedback.
Regards, Neil Groves _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1) Put "using namespace boost::adaptors" brings havoc. Even with an empty main, just write :
#include <boost/range/adaptors.hpp> using namespace boost::adaptors; and then the compiler emits some strange compilation error : "program files\boost\boost\range\iterator.hpp(63): error C2039: 'type' : is not a member of 'boost::mpl::eval_if_c<C,F1,F2>'"
Almost every Boost.Range adaptor test case has using namespace boost::adaptors. These tests are all passing on VC10 on our trunk testing mechanism. This problem is therefore not as obvious and simple to reproduce as you may have estimated. Would you please raise a trac issue with some source code?
2) Stride adaptor. I tried :
std::vector<int> v2; boost::push_back(v2, v | boost::adaptors::sliced(0, 5) | boost::adaptors::strided(2) );
This fails because 5 - 0 = 5 and 5 is not even. You would need to use boost::adaptors::sliced(0,6) for the result you are expecting. I expected that my initial set {1, 2, 3, 4, 5, 6, 7, 8, 9, 10} get sliced to
{1, 2, 3, 4, 5} and then strided to {1, 3, 5}. But I actually got an MSVC assert : "Expression : vector iterator not dereferencable"
This result is as expected for the code you have supplied.
3) Transform adaptor. Isn't there a way to deduce the return type instead of relying on the typedef return_type ? My first impulse was to tried a lambda:
std::vector<int> v3; push_back(v3, v | transformed([](int i){ return i * 10;} ); But it failed because of the lack of return_type typedef inside the lambda. And actually, even without fancy lambdas, it means that a simple free function will fail too.
This report almost gave me heart failure! I have written a test case (which is yet to be submitted) that does support free functions. It is not correct that transformed does not support free functions. It may well be true that the C++0x lambdas don't work well. This would be frustrating and I will look into this when I have some time. If I can fix this easily I shall attempt to get this into the release as a defect fix.
Should I file some ticket about this three points ?
Yes please and with lots of sample code!
Regards.
2010/4/18 Thomas Petit <thomas.petit33@gmail.com>
Thank you for your feedback,
Neil Groves
participants (5)
-
Barend Gehrels -
Mathias Gaunard -
Neil Groves -
Robert Jones -
Thomas Petit