- Boost - lists.boost.org

[GSoC] interested in implementing numerical algorithms for uBLAS
by Ganesh Prasad 17 Feb '15

17 Feb '15

Hi I am interested in implementing numerical algorithms optimized for distributed/parallel architectures for Boost.uBLAS. I have been applying for this project for previous 2 years, so I have definitely done some research in this field. Also, I have been working on Clusters for last 7 months as an Academic project (Product Development). So, basically I am acquainted with programming for distributed architectures with MPI. best wishes Ganesh Prasad

2 1

[threads] Win32 Events on POSIX
by Fu ji 17 Feb '15

17 Feb '15

Hello, I want to port win32 events on Posix using Boost. To avoid the re-invented the wheel I use PEvents: https://github.com/neosmart/pevents which is on MIT licence. But with my current knowledge I do some mistakes because I have deadlock. Maybe someone with bigger knowledge about differencies in boost and pevents might help with this ? I know that there is also thread-safe boost.signals2 with observer pattern but it does not provide WaitForMultipleObjects functionality. Best regards.

5 16

[nowide] Bug fix for older Windows versions
by Michael Smith 17 Feb '15

17 Feb '15

I found an issue with the implementation of cout/cerr in Boost.Nowide. It will fail in the middle of writing output due to a segfault in VerifyConsoleIoHandle (during WriteConsoleW). See the attached files for a patch and example (I've tested with MinGW-w64 4.8.3).

1 0

Fwd: Boost.Fixed_Point for GSoC 2015?
by Nikhar Agrawal 17 Feb '15

17 Feb '15

Hi everyone, I'm Nikhar Agrawal, currently an undergraduate student at IIIT-Hyderabad pursuing a degree in Computer Science and Engineering. I have been a succesful GSoC participant twice in a row. In 2013, I did GSoC under Boost C++ libraries under the mentorship of Christopher Kormanyos with continuous guidance from John Maddock and Paul Bristow. In 2014, I did GSoC under GNOME. In 2014, I had also submitted a proposal for Boost.Fixed_Point. Here's the link to the proposal I submitted last year: https://docs.google.com/document/d/1Ylc_OJBpoN_lNgMrYh0l-O_qCb-EDJQy0JGoh5u… Unfortunately, the project couldn't go through because of lack of slots. I would like to try again this year. Christopher isn't available as a mentor though. Chris and Niall suggested that I float a mail through the mailing list to see if there are any takers for this project who'd be willing to mentor it. The proposal hasn't changed much from what I submitted last year. We may have to limit it's scope to something that'd be ideal for one summer though. I'll be more than happy to discuss it with anyone who's interested in the project. Thanks. Nikhar P.S.: I'm attaching some mails from the conversation I've had with Niall and Christopher in this regard. ---------- Forwarded message ---------- From: Niall Douglas <s_sourceforge(a)nedprod.com> Date: Wed, Feb 11, 2015 at 8:12 AM Subject: Re: Boost.Fixed_Point for GSoC 2015? To: nikharagrawal2006(a)gmail.com Cc: Christopher Kormanyos <e_float(a)yahoo.com> Nikhar, Firstly my commendation to you on keeping up interest after not getting a place last year. For your information, we requested 12 slots and received just 7, and after I begged Google for another we got eight for 2014. That meant four projects did not get funding, and yours was one. Can I suggest that you perhaps consider approaching potential mentors in Boost and see if you can find one interested? Please do CC my email in your approaches so they know I have vetted you, and mention you were a successful student in 2013. Given that Chris won't be available this year, you may need to consider not doing fixed point as I am unaware of a suitable alternative mentor who is available. When approaching potential mentors, try to suggest ideas that are something the mentor badly wants in their particular specialism. Try searching the mailing lists and past GSoC ideas to see which mentors might have which pet projects which get them enthusiastic. Just this week a student called Damian Vicino managed to persuade Robert Ramey to mentor work on safe_numerics. I did not know Robert had an interest in this, but Damian obviously figured it out and won a mentor. Good luck in your efforts. Niall On 10 Feb 2015 at 21:24, Christopher Kormanyos wrote: > Hi Niall, > I will not be available as a GSoC mentor this year. > Just a heads-up, Nikhar Agrawal, a successful veteranGSoC candidate, has expressed interest in thefixed-point project. > I do not know if anyone would like to mentor it. > > See text below. > Thank you for your continued support. > Best regards, Chris > > > It seems that the discussions for GSoC 2015 have begun> on the mailing list. > > The fixed point project couldn't make through last year.> Is there interest in it for this year from you guys?> Would you like me to post about it on the mailing list?> I'm still very much interested in this. I contacted about this> project a couple of times last year after the summers> but everyone was busy with other stuff. And I think the> GSoC deadlines provide a lot of motivation anyways. > So let me know what you guys think about it and> if I should apply for the project. > Cheers. :)> Nikhar > Hi Nikhar, > Thank you for keeping in touch. > I will not be available as a GSoC mentor this year.In my opinion, the fixed-point project is a good one.We just need to find a mentor for the project. > The fixed-point project needs to have a clearly definedscope. The preliminary specification suggested byLawrence Crowl represents man-years of coding effort. > > If there is a way to limit the scope of the project toa reasonable level for one summer and find a mentor,then go for it ! > Please post any suggestions and or comments or questionson the board. > You were a very successful participant in GSoC 2013.With help from John and Paul, the ground work you did hasbeen included in Boost. We now have Bernoulli, high-precisiontgamma(), and also polygamma() for integer order. > > Boost is a long-term endeavor. I encourage you to stickwith it --- and keep up the good work ! > Good luck. > > Cheers, Chris > > > On Tuesday, February 10, 2015 4:29 PM, Nikhar Agrawal < nikharagrawal2006(a)gmail.com> wrote: > > > Hi everyone, > How are you all doing? > > It seems that the discussions for GSoC 2015 have begun on the mailing list. > The fixed point project couldn't make through last year. Is there interest in it for this year from you guys? Would you like me to post about it on the mailing list? I'm still very much interested in this. I contacted about this project a couple of times last year after the summers but everyone was busy with other stuff. And I think the GSoC deadlines provide a lot of motivation anyways. > So let me know what you guys think about it and if I should apply for the project. > Cheers. :)Nikhar > > On Tue, Apr 22, 2014 at 1:25 AM, Nikhar Agrawal < nikharagrawal2006(a)gmail.com> wrote: > > Hi all, > GSoC results are out and unfortunately, the fixed-point project didn't go through. However, the last couple of months or so, having invested time in discussing various design issues and going through various code prototypes, I have become really interested in developing a fixed-point library. And I stick to my word of being willing to develop library outside of GSoC as well. It would be great to have your continued guidance. Though with GSoC in summer, I wonder you'd have your official projects as first priority. I had submitted another proposal to GNOME and I got into GSoC via that as well. > So, I was wondering what could be a good way forward? How I could contribute to fixed-point library? The first question is if there's an interest in the library still from all your sides as well now that it's not an official GSoC project? If yes, I guess we could continue our collaborations just like they happened during last GSoC? Though probably less frequently? What do you guys think? > Also, if it's not an inappropriate thing to ask, could you kindly elaborate why the project didn't go through? Seeing the comments of everyone involved, I had a feeling that proposal was very well received. > Thanks.Nikhar > > > > > > > > --- Boost C++ Libraries Google Summer of Code 2015 admin https://svn.boost.org/trac/boost/wiki/SoC2015

1 0

Interested in choosing a Boost C++ project for GSOC 2015
by Prasad Priyadarshana Fernando 17 Feb '15

17 Feb '15

Hi, I am interested in choosing a Boost C++ project for GSOC 2015. Can anbody kindly let me know what are the projects you have for this years GSOC and How to interact with those projects to do bug fixes and to get familiar with the existing code bases. Thanks *Prasad Priyadarshana Fernando <http://www.linkedin.com/in/prasadfernando>* Mobile: +1 330 283 5827

3 7

GSOC 2015 Applicant
by Muhammad Junaid Muzammil 17 Feb '15

17 Feb '15

Hello, I am Muhammad Junaid Muzammil interested in extending the PRNG support primarily for the Boost Compute library as a GSOC project. In this regard, the basic aim is to add the support of stateless counter based PRNG to the library. Different families of RNG from Random123, including Threefry, Philox and ARS will be incorporated in the library. Potential mentor for this particular project could be Kyle Lutz. Thanks, Junaid.

3 4

[gsoc15] Org application closes on Friday 20th
by Niall Douglas 17 Feb '15

17 Feb '15

Three days remain until the GSoC org application closes on Friday 20th of April. As can be seen at https://svn.boost.org/trac/boost/wiki/SoC2015, we have just SIX project proposals and FIVE mentors who have publicly made themselves available on the ideas list this year. This is significantly lower than this time last year. If you would like to attract students to work on your Boost library in 2015, please consider adding a formal project idea to the list above before Friday. If you would like to mentor in some topic or field, please make yourself known to us so we can add you to the list of available mentors for 2015. Oh, and don't forget to mention the fields you are interested in! Thanks, Niall and Boris --- Boost C++ Libraries Google Summer of Code 2015 admin https://svn.boost.org/trac/boost/wiki/SoC2015

1 0

[config] clang on Windows and BOOST_SYMBOL_EXPORT problem
by Edward Diener 15 Feb '15

15 Feb '15

I have been recently discussing a problem regarding clang on Windows on the clang developers mailing list, but without any final resolution yet. This problem affects those using clang on Windows with Boost along with exported classes. This combination occurs when testing Boost.Test but I imagine also occurs with other Boost libraries and of course could affect Boost end-users using clang on Windows. The problem does not occur with clang on Linux for reasons which shall be understood in the explanation. The bug manifests itself in such code, compiled with clang, as: #include <boost/config.hpp> #include <boost/scoped_ptr.hpp> class BOOST_SYMBOL_EXPORT AClass { boost::scoped_ptr<int> sp_pointer; }; int main() { return 0; } On Windows for clang the BOOST_SYMBOL_EXPORT becomes __declspec(dllexport) whereas on Linux it becomes __attribute__((__visibility__("default"))). Clang decides with __declspec(dllexport) or its equivalent __attribute__((dllexport)), but not with __attribute__((__visibility__("default"))), that after generating a default copy constructor and assignment operator for a class which has not defined is own, even if an object of that class is never copied or assigned, if the default copy constructor or assignment operator is invalid the compilation is in error. Since the above class has a member which is non-copyable and non-assignable we get errors from clang along the lines of: > test_clang_bug.cpp:3:1: error: field of type 'boost::scoped_ptr<int>' has private copy constructor > AClass { boost::scoped_ptr<int> sp_pointer; }; > ^ > ..\..\..\boost/smart_ptr/scoped_ptr.hpp:47:5: note: declared private here > scoped_ptr(scoped_ptr const &); > ^ > test_clang_bug.cpp:3:1: note: implicit copy constructor for 'AClass' first required here > AClass { boost::scoped_ptr<int> sp_pointer; }; > ^ > test_clang_bug.cpp:3:1: error: 'operator=' is a private member of 'boost::scoped_ptr<int>' > AClass { boost::scoped_ptr<int> sp_pointer; }; > ^ > ..\..\..\boost/smart_ptr/scoped_ptr.hpp:48:18: note: declared private here > scoped_ptr & operator=(scoped_ptr const &); > ^ > test_clang_bug.cpp:3:1: note: implicit copy assignment operator for 'AClass' first required here > AClass { boost::scoped_ptr<int> sp_pointer; }; > ^ > 2 errors generated. I have argued on the clang developers list that requiring C++ programmers to provide a default copy constructor for a class whose object is never meant to be copied or a default assignment operator for a class which is never meant to be assigned, even if that means private declarations in C++03 or deleted declarations in C++11, can never be a good idea and goes against the C++ standard. The clang answer has been that exporting classes is outside the C++ standard so the C++ standard rules do not apply in this case. Note again that having BOOST_SYMBOL_EXPORT become __attribute__((__visibility__("default"))) for clang on Windows targeting mingw/gcc fixes this problem for that compilation environment. In fact for gcc using mingw/gcc we do indeed use __attribute__((__visibility__("default"))) and that works fine with mingw/gcc in the exact same exporting situations. Similarly for VC++ compilation having BOOST_SYMBOL_EXPORT be __declspec(dllexport) works fine also. I have not yet been able to get from clang developer why exporting a class using __declspec(dllexport) or its equivalent __attribute__((dllexport)) works the way it does, but using __attribute__((__visibility__("default"))) gives no problems. The discussion still appears to be ongoing. Do we want to change BOOST_SYMBOL_EXPORT on clang with Windows targeting mingw/gcc to specify __attribute__((__visibility__("default"))) as we do with mingw/gcc ? It is a fairly simple change which I can make. I just wanted to bring this whole issue to the attention of Boost before I implement any change. I am of course still hoping tha clang changes the way it views the exporting situation and still think they are wrong.

2 5

[GSOC] Devector project
by Divyansh Gupta 15 Feb '15

15 Feb '15

Hi all, I've been following the mailing list for a few months and I wanted to know more about the Devector project idea that was being discussed last week. I couldn't find it on the 2015 ideas page so I read about it on the 2009 page and I'm really interested in doing it as a GSOC project. So then I also read the segmented iterators paper and the std::vector and std::deque references. I found an existing implementation of devector on GitHub ( https://github.com/orlp/devector/blob/master/readme.md) Some of the shortcomings of this implementation as per the 2009 ideas page: 1. Does not provide reference stability on insertion since it's just one continuous block of memory which has to be reallocated in its entirety. 2. Hence obviously does not provide option for setting chunk size or use segmented iterators. I was hoping that the devector idea is added to the 2015 ideas page with a competency test since I don't have any open source contributions besides the research projects in my institute. But I'm a quick learner and am confident that I can prove my worth through a competency test. Thus I kindly request Thorsten or Niall to please add devector to the ideas page and provide a competency test if possible. Regards, Divyansh Gupta, Sophomore Undergraduate Student, Indian Institute of Technology - Kharagpur

1 0

[PropertyTree] In-Memory Performance of Xml/Json Serialization?
by john smith 15 Feb '15

15 Feb '15

I'm personally more interested in the Xml characteristics, but I have noticed that the JSON parsing is much slower as it doesn't use rapidXml. The implementation of the JSON and XML read/write methods both use std::basic_*stream which is slow for in-memory usage. In the xml methods there also appears to be a strong assumption that "Key" is a std::string which then follows that the "Ptree::key_type::value_type" is of type char. Is there or would there be any opposition to the development of more performant write_xml() and read_xml() methods for in-memory use? These new performant overloads could either use std::string or char* directly instead of the slower stringstream classes? If the Key template argument is an std::string, the *printf* c-style methods could be used to improve performance and eliminate the locks that stringstreams uses. There is already an std::string based arg set that is used for a filename, so that would need to be overcome.

1 0