- Boost - lists.boost.org

[Review] GIL io_new
by Roland Bock 11 Dec '10

11 Dec '10

Hi, here is a short review of GIL new IO (I missed the documentation of the toolbox, which is why I concentrated on IO). > - What is your evaluation of the design? Quite elegant and intuitive. I think it would be nice to add iterator pairs and boost::range as additional devices, though. > - What is your evaluation of the implementation? All the code I've looked at so far looks well organized and well readable. Some remarks: * Why are the following files in the detail folder? io_new/detail/read_and_convert_image.hpp io_new/detail/read_and_convert_view.hpp io_new/detail/read_image.hpp io_new/detail/read_image_info.hpp io_new/detail/read_view.hpp io_new/detail/write_view.hpp They define functions of the public interface like read_image(). There is no need to include them directly, but still, when I want to look at documented functions, it seems weird to go into the detail folder... * There seem to be some remnants from earlier versions. For instance: struct tiff_indexed is defined in io_new/tiff_tags.hpp, but never used anywhere else (or did I miss something?) io_new/detail/typedefs.hpp ends with } // namespace details <-- notice the 's' :-) >- What is your evaluation of the documentation? As stated above, I missed the documentation on the toolbox. The documentation is well readable and easy to understand. There seem to be broken links: * "section Extending GIL::IO with new Formats" links to index.html * "Please see section Supported Image Formats." links to index.html * "sections _Supported_Formats_ for more details." links to / It would be good to have code samples for read_and_convert_image, read_view and read_and_convert_view in the tutorial. The "Using IO" section seems to assume that they are already documented: "As the Tutorial demonstrated there are a few ways to read images." Additionally, it would be great to have a reference section. :-) I stumbled over a few typos and grammatically unusual sentences (IMHO): * s/supoorted/supported/ * "Before we can read or write image one thing." I know what that means in German, but does this make sense in English? * "If the user doesn't know what he is dealing with it can use read_and_convert_image()." s/it/he/ I think it would make much sense to give the text to an English native speaker. > - What is your evaluation of the potential usefulness of the extensions? Very useful! > - Did you try to use the extensions? With what compiler? Did you have any problems? I did not actually build anything. Sorry :-( But I am looking forward to doing so! > - How much effort did you put into your evaluation? A glance? A quick > - reading? In-depth study? About half a day of reading. > - Are you knowledgeable about the problem domain? I have used several other libraries over the last 15 years, but I never delved into the innards of image file formats... > - Do you think the extensions should be accepted as a part of Boost.GIL library? Yes, with a few wishes (see above): - documentation: - typos and grammar - add reference section - add a few more code samples in the tutorial - file structure - move parts of the public interface into the non-detail area - interface: - add support for iterators and ranges Again, I did not evaluate the toolbox part. Thanks writing this extension! Roland

2 2

Formal Review of IO and Toolbox extensions to Boost.GIL starts TOMORROW
by Mateusz Loskot 11 Dec '10

11 Dec '10

Dear All, According to the Boost Formal Review Schedule [1], review of Christian Henning's extensions to the Boost Generic Image Library (Boost.GIL, [2]), it is: * Boost.GIL.IO * Boost.GIL.Toolbox starts on December 1st and lasts until December 10th, 2010. [1] http://www.boost.org/community/review_schedule.html [2] http://www.boost.org/doc/libs/release/libs/gil/doc/index.html =========== What is it? =========== The Boost.GIL.IO extension provides an easy to use interface for reading and writing various image formats. It also includes a framework for adding new formats. The Boost.GIL.IO is indent to replace the current IO extension which is part of Boost for several years now. Features: * A unified way to read and write image encoded in BMP, JPEG, PNG, PNM, and TIFF formats. The capabilities to read and write in various formats have improved dramatically. * Image data can be provided via standard file or string streams The Boost.GIL.Toolbox provides new color spaces and other small code to ease programming with Boost.GIL. Features: * Implementation of color spaces: Gray_Alpha, HSL, HSV, LAB, and XYZ * Utilities to support dynamic image workflows and color conversions. * Collection of metafunctions to determine alignment, similarity and homogeneity at pixel level. The Boost.GIL as well as the proposed extensions are provided in form of a headers-only library Although, some image formats come with their format dependency, it is corresponding third-party libraries: JPEG - libjpeg PNG - libpng TIFF - libtiff =================== Getting the library =================== The latest version of both extensions can be downloaded as Zip package: http://gil-contributions.googlecode.com/files/boost_review.zip or directly from the Subversion repository: http://code.google.com/p/gil-contributions/source/browse/trunk/gil_2/ and the docs can built as usual with bjam and quickbook tools from within libs/gil/io_new/doc directory The libs/gil/io_new/test/readme.txt provides a step by step guide to configuring, building and running the unit tests. The boost_review.zip is about 20MB due to its extensive collection of test images. They are part of the test suite to make sure that different variations of each image format is read and written correctly. Please, be aware no guarantee can be given that all formats in their all variants are completely supported. ================ Writing a review ================ If you feel the new IO and Toolbox are interesting extensions to the Boost.GIL library, then please submit your review to the developer list (preferably), or to the review manager (mateusz at loskot dot _n_e_t_) Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the extensions? - Did you try to use the extensions? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick - reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the extensions should be accepted as a part of Boost.GIL library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Mateusz Review Manager for the proposed Boost.GIL.IO and Boost.GIL.Toolbox extensions -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

9 30

[BoostCon 2011] 2nd Call for participation
by Hartmut Kaiser 11 Dec '10

11 Dec '10

Hey all, please find below the updated CfP for BoostCon 2011. Note, we extended the submission deadline. The new submission deadline is January, 10th 2011. ----------------------------------------------------------------- 5TH ANNUAL BOOST CONFERENCE 2011 Aspen CO, USA, May 15 - 20, 2011, www.boostcon.com CALL FOR PARTICIPATION We invite you to submit session proposals to the 5th Annual Boost Conference: BoostCon 2011 (Aspen CO, USA, May 15 - 20, 2011). Traditionally the main face-to-face event for all things Boost (www.boost.org) BoostCon 2011 will present leading speakers from the whole C++ community. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and the new C++ Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at three constituencies: Boost end-users, hard-core Boost library and tool developers, and academics focusing on research. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. SESSION TOPICS Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it changes life for users and library writers * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the nature of both the on-line Boost community and the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS Presentations ------------- Presentations focus on a practitioner's ideas and experience with anything relevant to Boost and Boost users. Panels ------------- Panels feature three or four people presenting their ideas and experiences relating to Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials ------------- Tutorials are sessions at which instructors teach conference participants specific Boost-relevant skills. Workshops ------------- Workshops provide an active arena for advancements in Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations ------------- These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors Presentations ------------- We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10-20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). SUBMISSION DETAILS All submissions have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon2011. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the BoostCon website and will be available to attendees. For general information on the BoostCon 2011 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon2011(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to BoostCon. IMPORTANT DATES New proposal submissions due: January 10th, 2011. Proposals decisions sent (tentative program): February 17th, 2011. Fully scheduled program available: February 25th, 2011. Session materials due: April 15th, 2011. Hartmut Kaiser: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

GIL.IO documentation
by Christian Henning 11 Dec '10

11 Dec '10

Hi all, I have uploaded the docs here: http://gil-contributions.googlecode.com/files/io_new_docs.zip Thank you, Nathan! Regards, Christian

2 1

Sandbox and externals
by Domagoj Saric 11 Dec '10

11 Dec '10

Hi, could someone please tell me whether the use of SVN externals is allowed in the Boost Sandbox? For example, I'm working on two projects/libraries and have a header that is a collection of various platform specifics that I'd like to use in both libraries but would also like to not have to manually update two copies of it (rather have one of the libraries use it as a SVN external)... I was unable to find this information at https://svn.boost.org/trac/boost/wiki/BoostSandbox... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

3 2

[Iterator] transform_iterator should use result_of
by Michel MORIN 11 Dec '10

11 Dec '10

Documents of Boost.Iterator say that transform_iterator uses result_of to compute "reference" nested-type. But, in Boost 1.45, transform_iterator does not use result_of; It uses result_type. This bug is fixed in trunk. See the following ticket: [iterator] transform_iterator should use boost::result_of to determine functor result type https://svn.boost.org/trac/boost/ticket/1427 Considering the fix was merged into trunk six months ago, it seems low-risk to merged into release. Does anyone merge this into release? Regards, Michel

2 5

[program_options] A couple of proposed changes (patches included)
by jcwilson.boost＠nym.hush.com 10 Dec '10

10 Dec '10

I've been making use of this library for the past week and it's been very helpful. I've found a couple of ways to improve it for my use and wanted to see if it'd be worth sending the changes upstream, too. 1) Allow default value specification at option query time. This would override the default value (if any) defined in the options_description for this particular query. buffer_size = options["buffer_size"].as<unsigned int>(1024); 2) Add the option name as a parameter to the "notifier" function signature. This became necessary when I started using the wildcard(*) functionality. How else am I to know what the matched config variable was? I just replaced boost::function1 with boost::function2. I imagine this one would need a bit more work since it would break any current users. I could take a stab at it, but if it seems useful, maybe someone more familiar with the library would rather take care of it instead. I'm pretty new to Boost development, so I'm not sure what the next steps would be. The attached patches are against the boost_1_45_0 release. -Josh

2 1

serialization crash with polymorphic classes, shared_ptr and std::map
by Allan Johns 10 Dec '10

10 Dec '10

Hi. I have hit a problem with boost serialization (occurs in all versions of boost - 1.37.0 .. 1.45.0). Summary: I have virtual base class A, derived B, and an AMap class (also A-derived) which holds shared_ptr<A>'s. I get different data written out depending on whether I serialise out an AMap stored in a shared_ptr<A> or a shared_ptr<const A>, and in one case (non-const) I get a segfault on load. The following code illustrates the problem in entirety and is the simplest case I found which generates the problem (I tried several variations - saving the map directly, removing A as AMap's base class etc, etc, to no avail). You should be able to cut'n'paste and compile into a single executable. I am testing on linux + centOS. ############################################################################################################## lib.h #ifndef __TESTLIB__H_ #define __TESTLIB__H_ #include <map> #include <boost/serialization/nvp.hpp> #include <boost/serialization/shared_ptr.hpp> #include <boost/serialization/base_object.hpp> class A { public: A(){} virtual ~A(){} template<class Archive> void serialize(Archive & ar, const unsigned int version){} }; typedef boost::shared_ptr<A> a_ptr; typedef boost::shared_ptr<const A> c_a_ptr; typedef std::map<int, a_ptr> a_map; class B : public A{ public: B(){} virtual ~B(){} template<class Archive> void serialize(Archive & ar, const unsigned int version){ ar & boost::serialization::make_nvp("base_class", boost::serialization::base_object<A>(*this)); } }; class AMap : public A { public: AMap(){} virtual ~AMap(){} template<class Archive> void serialize(Archive & ar, const unsigned int version){ ar & boost::serialization::make_nvp("base_class_a", boost::serialization::base_object<A>(*this)); ar & boost::serialization::make_nvp("map", m_map); } a_map m_map; }; #endif ############################################################################################################## lib.cpp #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include "lib.h" #include <boost/serialization/map.hpp> #include <boost/serialization/export.hpp> BOOST_CLASS_EXPORT(A); BOOST_CLASS_EXPORT(B); BOOST_CLASS_EXPORT(AMap); ############################################################################################################## main.cpp #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/serialization/map.hpp> #include <fstream> #include <iostream> #include "lib.h" const char* fname="/tmp/testlib.xml"; void save(*a_ptr* a) // NOTE!!! change me to c_a_ptr to get a segfault on load { std::ofstream fs(fname); boost::archive::xml_oarchive ar(fs); ar & boost::serialization::make_nvp("root", a); } int main(int argc, char** argv) { { std::cout << "saving..." << std::endl; AMap* pam = new AMap(); a_ptr a(new B()); pam->m_map.insert(a_map::value_type(1, a)); a_ptr am(pam); save(am); } { std::cout << "loading..." << std::endl; a_ptr am; std::ifstream fs(fname); boost::archive::xml_iarchive ar(fs); ar & boost::serialization::make_nvp("root", am); assert(am); } return 0; } Note that changing main's save() arg to a shared_ptr<const A> changes the data written out. Here is an example xml archive resulting from saving via a non-const shared_ptr (the case that WORKS on load): <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="5"> <root class_id="0" tracking_level="0" version="1"> <px class_id="2" class_name="AMap" tracking_level="1" version="0" object_id="_0"> <base_class_a class_id="1" tracking_level="1" version="0" object_id="_1"></base_class_a> <base_class_map class_id="3" tracking_level="0" version="0"> <count>1</count> <item_version>0</item_version> <item class_id="4" tracking_level="0" version="0"> <first>1</first> <second> <px class_id="5" class_name="B" tracking_level="1" version="0" object_id="_2"> <base_class object_id="_3"></base_class> </px> </second> </item> </base_class_map> </px> </root> </boost_serialization> Here is the same data but written out via the CONST shared_ptr (the case that FAILS on load): <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="5"> <root class_id="0" tracking_level="0" version="1"> <px class_id="2" class_name="AMap" tracking_level="1" version="0" object_id="_0"> <base_class_a class_id="1" tracking_level="1" version="0" object_id="_1"></base_class_a> <base_class_map class_id="3" tracking_level="0" version="0"> <count>1</count> <item_version>0</item_version> <item class_id="4" tracking_level="0" version="0"> <first>1</first> <second *class_id="5" tracking_level="0" version="1"*> <px class_id="6" class_name="B" tracking_level="1" version="0" object_id="_2"> <base_class object_id="_3"></base_class> </px> </second> </item> </base_class_map> </px> </root> </boost_serialization> Note the difference, which I've put in bold. If somebody could explain what is happening here I'd be very grateful. Obviously something is going on with the object tracking... and what I find most strange is that the data that loads correctly actually looks incorrect (<second> doesn't have tracking-level=0, whereas tracking-level=0 wherever else there's a shared_ptr, as I'd expect). Note: I have tested using the xml and binary archives... xml segfaults, binary throws a stream_error. Thanks in advance Allan

2 3

is there a bug in ini_parser.hpp?
by Bernd Prager 10 Dec '10

10 Dec '10

Hi, Following program does not pertain a proper "other" value: #include <iostream> #include <boost/property_tree/ptree.hpp> #include <boost/property_tree/ini_parser.hpp> using namespace std; using boost::property_tree::ptree; int main() { ptree pt; pt.put("debug.filename", "tst.log"); pt.put("other", "tst"); cout << "debug.filename: " << pt.get("debug.filename", "filename not found") << endl << "other: " << pt.get("other", "other not found") << endl; boost::property_tree::write_ini("tst.ini", pt); boost::property_tree::read_ini("tst.ini", pt); cout << "debug.filename: " << pt.get("debug.filename", "filename not found") << endl << "other: " << pt.get("other", "other not found") << endl; return EXIT_SUCCESS; } The ini file contains: [debug] filename=tst.log other=tst Do I do anything wrong or is that a bug? Thanks for help or suggestions, -- Bernd

1 0

Formal Review of IO and Toolbox extensions to Boost.GIL extended until December 17th, 2010
by Mateusz Loskot 09 Dec '10

09 Dec '10

Dear All, Today, I announced we are close to the end of the review: http://lists.boost.org/boost-announce/2010/12/0275.php Later on, Christian asked for extension of the review. The Review Wizards agreed and suggested to extend the review until Friday, December 17th, 2010 So, I'm happy to announce that the new cut-off date of the reviews submission is December 17th. Let's say Midnight, UTC Time. Thanks to all reviewers who submitted their comments, to the Review Wizards for the extension and we are hoping to receive more feedback from the reviewers. Mateusz Review Manager for the proposed Boost.GIL.IO and Boost.GIL.Toolbox extensions On 09/12/10 11:37, Mateusz Loskot wrote: > Dear All, > > The formal review of the IO and Toolbox extensions terminates > tomorrow. I'd like to set the cut-off time at Midnight on Saturday, > 11 December 2010, UTC Time > > (http://www.timeanddate.com/worldclock/fixedtime.html?day=11&month=12&year=2…) > > > I think we have been doing well and received decent amount of > feedback. However, anyone feels there is a need for extension, > please let me know as soon as possible, so I will have time to > negotiate it with the Review Wizards. > > Mateusz Review Manager for the proposed Boost.GIL.IO and > Boost.GIL.Toolbox extensions > > > On 30/11/10 18:01, Mateusz Loskot wrote: >> Dear All, >> >> According to the Boost Formal Review Schedule [1], review of >> Christian Henning's extensions to the Boost Generic Image Library >> (Boost.GIL, [2]), it is: * Boost.GIL.IO * Boost.GIL.Toolbox starts >> on December 1st and lasts until December 10th, 2010. >> >> [1] http://www.boost.org/community/review_schedule.html [2] >> http://www.boost.org/doc/libs/release/libs/gil/doc/index.html >> >> =========== What is it? =========== >> >> The Boost.GIL.IO extension provides an easy to use interface for >> reading and writing various image formats. It also includes a >> framework for adding new formats. The Boost.GIL.IO is indent to >> replace the current IO extension which is part of Boost for >> several years now. >> >> Features: >> >> * A unified way to read and write image encoded in BMP, JPEG, PNG, >> PNM, and TIFF formats. The capabilities to read and write in >> various formats have improved dramatically. >> >> * Image data can be provided via standard file or string streams >> >> The Boost.GIL.Toolbox provides new color spaces and other small >> code to ease programming with Boost.GIL. >> >> Features: >> >> * Implementation of color spaces: Gray_Alpha, HSL, HSV, LAB, and >> XYZ * Utilities to support dynamic image workflows and color >> conversions. * Collection of metafunctions to determine alignment, >> similarity and homogeneity at pixel level. >> >> The Boost.GIL as well as the proposed extensions are provided in >> form of a headers-only library Although, some image formats come >> with their format dependency, it is corresponding third-party >> libraries: >> >> JPEG - libjpeg PNG - libpng TIFF - libtiff >> >> =================== Getting the library =================== >> >> The latest version of both extensions can be downloaded as Zip >> package: >> >> http://gil-contributions.googlecode.com/files/boost_review.zip >> >> or directly from the Subversion repository: >> >> http://code.google.com/p/gil-contributions/source/browse/trunk/gil_2/ >> >> >> >> and the docs can built as usual with bjam and quickbook tools >> from within libs/gil/io_new/doc directory >> >> The libs/gil/io_new/test/readme.txt provides a step by step guide >> to configuring, building and running the unit tests. >> >> The boost_review.zip is about 20MB due to its extensive collection >> of test images. They are part of the test suite to make sure that >> different variations of each image format is read and written >> correctly. >> >> Please, be aware no guarantee can be given that all formats in >> their all variants are completely supported. >> >> ================ Writing a review ================ >> >> If you feel the new IO and Toolbox are interesting extensions to >> the Boost.GIL library, then please submit your review to the >> developer list (preferably), or to the review manager (mateusz at >> loskot dot _n_e_t_) >> >> Here are some questions you might want to answer in your review: >> >> - What is your evaluation of the design? - What is your evaluation >> of the implementation? - What is your evaluation of the >> documentation? - What is your evaluation of the potential >> usefulness of the extensions? - Did you try to use the extensions? >> With what compiler? Did you have any problems? - How much effort >> did you put into your evaluation? A glance? A quick - reading? >> In-depth study? - Are you knowledgeable about the problem domain? >> >> And finally, every review should answer this question: >> >> - Do you think the extensions should be accepted as a part of >> Boost.GIL library? >> >> Be sure to say this explicitly so that your other comments don't >> obscure your overall opinion. >> >> Mateusz Review Manager for the proposed Boost.GIL.IO and >> Boost.GIL.Toolbox extensions > > -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 0