- Boost - lists.boost.org

Re: [boost] Boost.Locale and the standard "message" facet
by Vicente BOTET 04 May '11

04 May '11

Hi, > Message du 30/04/11 15:48 > De : "Artyom" > A : boost(a)lists.boost.org > Copie à : > Objet : Re: [boost] Boost.Locale and the standard "message" facet > > > Subject: [boost] Boost.Locale and the standard "message" facet > > > > Hi, > > > > I was wondering how Boost.Locale is related > > to the standard message facet which is used > > to translate messages. > > > The standard message catalogs allow to extract > messages by integer identifiers but may use string > identifiers and it is implementation defined > > It is undefined how to load message facets Well implementation defined doesn't mean undefined. > or format them and so on. The formatting can always be done on top of this facet, isn't it? > It does not support plural forms and context. I'm not an expert, but doesn't catalogs and the set parameter can be used for your domain an context? Respect to plural forms, how Boost.Locale manages with locales that have 3 or 4 forms of plurals (If I understood your private mail, Hebrew is an example of this)? I've the impression that Boost.Locale manage simple plurals but not all kind of plurals? BTW, what is the criteria in Boost.Locale to identify a plural form? How your library manage plurals for message that have several parameters? For example translate("%1 hours, %2 minutes, %3 seconds") % h % m % s > It is the most unless facet around. What do you mean? That the scope is reduced? > > Note that the facet > > interface work with integer identifiers > > avoiding all the issues raised by the > > get_text/translate functions > > provided by Boost.Locale. > > > > Use of integer identifiers is the best > way to screw the localization in the software. > > What does 3456 means? Do you really think > it is good to write translate(MY_MESSAGE_OPENING_FILE) Why not? Note that we can also write translate(MyMessage::OpeningFile) if this seems clearer to you > No, never - never - never - never - never > use such "constant" or "integer" identifiers. I understand that some as you can find that the use of integers scale worst than the use of strings as we need to maintain constants unique on a given context, but this can be checked on debug mode. Some time ago when I had to write a localization application, we used integer identifier to log internationalizable messages. This reduced drastically the size of the log. I guess only this advantage was enough to take integers instead of strings, for us of course. An advantage I see is that you need to concentrate all the message id of a set/context in a single file so no need to have tools that parse your code to get the strings to translate. BTW, how do you recover message translation from a domain with your underlying implementation, copy/paste or is there a possibility to have specific files for specific domains, or there is a single translation file by locale? I've not take a look at your implementation yet. Please could you tell me when the translation file is read? Is the file parsed only once and the translations stored on a cache? > Always use natural text. I think your natural language interface lets the user to have the impression that anything is possible, when a lot of limitations seem to be there as other have already commented in this ML. > > Is there any reason Boost.Locale > > could not follow the standard design? > > The standard message catalogs to weak I would like to here the rationale of the standard message design by someone that is aware of it (some pointers will be welcome also). > > What are the advantages of the Boost.Locale design? > > > > 1. Defined way to load and format catalogs You could provide a defined way on top of this facet, isn't it? > 2. Support of pural forms Plural forms can be designed on top of the message facet? > 3. Support of message-context As I said, I suspect that the set parameter is interpreted as your context. > 4. Using natural language identifiers as keys See below. This is not always an advantage, and as far as I see adds some constraints on the interface so the tool can take care to automatically extract the strings to translate. > 5. Convenense interface What do you mean? Could you compare both? > More? Well, I think that it would be great if you can add a complete comparison of the interfaces and a rationale why you think your design is superior on the documentation. Best, Vicente

2 7

[range] as_literal always returning iterator_range
by Tobias Germer 04 May '11

04 May '11

Hi all, I think there is a problem with the behavior of boost::as_literal. If I got it right, it is supposed to create an iterator_range from null-terminated strings, which is fine. However, it also creates iterator_ranges from exisiting ranges, i.e., it converts general ranges to iterator_ranges. I think as_literal should fall back to identity (i.e., just return its argument) if its argument is already a range. With the current behavior, the type information of the range is lost. This is a problem if I write generic code and want to dispatch several cases based on the type of the range. Consider the following example: ------------------------------- template<class Rng> void f( Rng const& r ) {...} template<class T> void f( iterator_range<T*> const& r ) {...} void f( std::string const& s ) {...} void f( std::vector const& v ) {...} template<class Rng> void g( Rng const& r ) { f(as_literal(r)); ... } ------------------------------- Function g() accepts general ranges as well as zero-terminated strings. It dispatches its argument using the type of the range and the overloads of f(), in order to execute special code for some ranges like strings and vectors. (In my particular case, I have special treatment for ranges of contiguous memory.) This is not possible anymore after calling as_literal, because it always returns an iterator_range. Wouldn't it be better to return the original range, for example like this: template< class Rng > typename enable_if< has_range_const_iterator<Rng>, Rng &>::type as_literal (Rng& r ) { return r; } Regards, Tobias -- Dr. Tobias Germer | tgermer(a)think-cell.com Software Engineer think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

3 2

Boost announce mailing list messages
by Edward Diener 04 May '11

04 May '11

My messages to the Boost announce mailing list, despite being the review manager for the Boost.Convert library, are being ignored. Why is this ? I was able to post an initial announcement on the Boost announce mailing list when the review of the Boost.Convert library started, but my message to that mailing list, when the Boost vault was down and I wanted to alert uses to the subversion URL I had created for the Boost.Convert library, never got posted on the Boost announce mailing list. Now that I have sent another message to the Boost announce mailing list, signalling the result of the Boost.Convert library review, it is again being ignored.

2 1

boost in linux repository
by Krzysztof 04 May '11

04 May '11

When the newer version of boost library is expected to be in linux repository? Now, it has version 1.42. -- Regards Krzysztof J.

3 3

[atomic] Status?
by vicente.botet 04 May '11

04 May '11

Hi, There are some libraries that would prefer to be reviewed after Boost.Atomic is reviewed, otherwise them should move the library as an internal detail of the implementation. Could the people working on Boost.Atomic tell us what is the state of the library? Which platforms have been handled? Which part of the standard has been implemented? Could others having knowledge in assembler participate in this project? When we can expect the library to be ready for review? Best, Vicente

10 20

Re: [boost] [asio] Randomly having problems reading from the socket
by Torben Wiggerich 04 May '11

04 May '11

Hi Jinqiang, thanks for your answer. What I forgot to mention was that I'm using the localhost for the socket connection. So there shouldn't be any errors caused by the physical network, I guess. I changed the code to evaluate the 'ignored error'. But an error never occurs there . It just falls asleep for 5 seconds. Kind regards Torben > > > -------- Original-Nachricht -------- > Betreff: Re: [boost] [asio] Randomly having problems reading from the > socket > Datum: Tue, 3 May 2011 08:57:27 +1000 > Von: Jinqiang Zhang <jasonzha(a)gmail.com> <mailto:jasonzha@gmail.com> > Antwort an: boost(a)lists.boost.org <mailto:boost@lists.boost.org> > An: boost(a)lists.boost.org <mailto:boost@lists.boost.org> > > > > Hi Torben, > > Firstly I claim I always use async way of asio, so I don't get the same > problem as yours. But for your code, I might suggest, because you are > transferring big chunk of data, if network condition is bad, you might get > some error, so maybe you want to see the 'error' while not use 'ignored > error' ? > > cheers, > Jinqiang > > On Mon, May 2, 2011 at 10:28 PM, Torben Wiggerich<torben.wiggerich(a)nisys.de > > <mailto:torben.wiggerich@nisys.de> wrote: > > > Hi all, > > > > I have some problems using the boost.asio.read for a TCP-socket. So far it > > works fine, but it randomly stops the transfer for at least 5 seconds. > > To resolve the error I used a simple synchronous server and client from the > > boost examples and modified it too send a larger amount of data. (307400 > > Bytes; this size comes from the program I'm trying to get run). On the > > client side I also changed the reading from the socket to read the complete > > data with boost.asio.read and transfer_all as argument. > > > > Both, server and client, measure the time for sending and reading to the > > socket and will give an error if it needs more than 1 second. > > > > Here is the sourcecode for the server: > > > > #include<iostream> > > #include<string> > > #include<boost/asio.hpp> > > #include<boost/date_time/posix_time/posix_time.hpp> > > > > using boost::asio::ip::tcp; > > using namespace boost::posix_time; > > > > int main() > > { > > try > > { > > boost::asio::io_service io_service; > > > > tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 8002)); > > > > tcp::socket socket(io_service); > > acceptor.accept(socket); > > > > unsigned char * array = new unsigned char[307400]; > > > > for (;;) > > { > > boost::system::error_code ignored_error; > > > > ptime startTime = microsec_clock::universal_time(); > > > > boost::asio::write(socket, boost::asio::buffer( array, 307400 ), > > boost::asio::transfer_all(), ignored_error); > > > > time_duration neededTime = microsec_clock::universal_time() - > > startTime; > > > > if ( neededTime.total_milliseconds()> 1000 ) { > > std::cout<< "ERROR needed too much time: "<< > > neededTime.total_milliseconds()<< "ms"<< std::endl; > > } > > } > > } > > catch (std::exception& e) > > { > > std::cerr<< e.what()<< std::endl; > > } > > > > return 0; > > } > > > > > > My client sourcecode: > > > > #include<iostream> > > #include<boost/array.hpp> > > #include<boost/asio.hpp> > > #include<boost/date_time/posix_time/posix_time.hpp> > > > > using boost::asio::ip::tcp; > > using namespace boost::posix_time; > > > > int main(int argc, char* argv[]) > > { > > try > > { > > if (argc != 2) > > { > > std::cerr<< "Usage: client<host>"<< std::endl; > > return 1; > > } > > > > boost::asio::io_service io_service; > > boost::asio::ip::tcp::endpoint endpoint( > > boost::asio::ip::address::from_string( argv[1] ), 8002 ); > > > > tcp::socket socket(io_service); > > boost::system::error_code error = boost::asio::error::host_not_found; > > socket.connect( endpoint, error ); > > if (error) > > throw boost::system::system_error(error); > > > > int counter = 0; > > unsigned char* array = new unsigned char[307400]; > > for (;;) > > { > > boost::system::error_code error; > > > > ptime startTime = microsec_clock::universal_time(); > > size_t len = boost::asio::read( socket, > > boost::asio::buffer( array, 307400 ), > > boost::asio::transfer_all(), > > error ); > > time_duration neededTime = microsec_clock::universal_time() - > > startTime; > > > > if ( error ) { > > printf( "body read error %s\n", error.message().c_str() ); > > } > > > > if ( counter % 5000 == 0 ) { > > std::cout<< "passed: "<< counter<< "\r"; > > } > > ++counter; > > > > if ( neededTime.total_milliseconds()> 1000 ) { > > std::cout<< "ERROR needed too much time: "<< > > neededTime.total_milliseconds()<< "ms"<< std::endl; > > } > > } > > } > > catch (std::exception& e) > > { > > std::cerr<< e.what()<< std::endl; > > } > > > > return 0; > > } > > > > To reproduce the error just let it run for a while. It can take up to 30 > > minutes or even more... > > After a while it will produce the line: "ERROR needed too much time: > > 5007ms". Maybe with slightly different times, but all around 5 seconds. > > I tested it on different machines with Windows Vista and Seven. > > > > So am I'm doing sth. wrong? Is the reading from the socket correct? > > > > I'm using boost version 1.44. > > > > Kind regards > > Torben Wiggerich > > > > _______________________________________________ > > Unsubscribe& other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > _______________________________________________ > Unsubscribe& other changes:http://lists.boost.org/mailman/listinfo.cgi/boost > > > ----- > eMail ist virenfrei. > Von AVG uberpruft -www.avg.de <http://www.avg.de> > Version: 10.0.1209 / Virendatenbank: 1500/3610 - Ausgabedatum: 02.05.2011 >

1 0

[config] Regression tests and warnings
by Edward Diener 04 May '11

04 May '11

It appears that the config regression tests treat all warnings as errors. Where is this specified in the jamfiles for config ? I need to run the config regression tests where -Wno-variadic-macros is defined for gcc, so that the warnings for using variadic macros are turned off and therefore no errors occur. What is the best way of modifying the config regression tests to do this ?

2 3

Porting boost::lexical_cast tests to boost::convert
by Jeroen Habraken 03 May '11

03 May '11

Hi, Since boost::convert is promoting itself as an alternative to boost::lexical_cast I decided to port the boost::lexical_cast test suite (which can be found in BOOST_ROOT/libs/conversion/lexical_cast_test.cpp) to boost::convert. I've simply replaced lexical_cast<T>(U) with convert<T>::from(U) and bad_lexical_cast with std::invalid_argument, whether this is a valid approach I'm not sure. To actually get the test suite to compile for boost::convert I had to comment out a lot of them and even then there are quite a few failures. This needs to be looked at (I've attached the code), what are actual boost::convert failures (both at compile- and runtime) and what is caused by my porting? Regards, Jeroen

2 1

[Review] Boost.Convert library has ended
by Edward Diener 03 May '11

03 May '11

The review period for the Boost.Convert library has officially ended. I will continue to read posts about the library while I make my review decision, so please do not stop discussing the library as appropriate because the review period has ended. I have received one personal request for a late review, and I am willing to accept any other requests for a late review to be made through Wednesday and posted to the mailing list, but I will not consider any other late review in my decision unless someone requests it of me personally. I know this is a fine line between an official review and just comments about what others have said before, but I need to make my decision based on some finite set of reviews and their subsequent discussion. I would like to thank everyone who has officially reviewed Boost.Convert as well as all who have made subsequent comments. The more input received, the easier it becomes for me as a reviewer to make a final decision. I would also like to thank the implementer of the Boost.Convert library, Vladimir Batov, for his willingness to address issues, answer criticism, and engage in discussion about his library. My review decision should be made and posted to the mailing list no later than by the end of Sunday, May 8.

4 3

[Review] Boost.Convert library, new subversion URL
by Edward Diener 03 May '11

03 May '11

This is a reminder that formal review of the Boost.Convert library by Vladimir Batov starts today, April 23, and is scheduled to last through May 2. *************** * Its Purpose * *************** The library builds on the past boost::lexical_cast experience, then takes those conversion-related ideas further to suit better today's applications and programing needs. It still offers simple, minimal interface, familiar conversion behavior and additionally provides: * throwing and non-throwing conversion-failure behavior; * support for the default/fallback value to be returned when conversion fails; * two types of the conversion-failure check - basic/simple and better/safe; * formatting support based on the standard std::streams and std::stream-based manipulators (like std::hex, std::scientific, etc.); * support for different locales; * support for boost::range-compliant char and wchar_t-based containers; * no DefaultConstructibility requirement for the Target/Destination type; * consistent framework to uniformly incorporate any type-to-type conversions, extensibility and additional room to grow. With its present support for string-to-type and type-to-string conversions it is an essential tool for applications making extensive use of configuration or MS-Windows-Registry-style files or having to process/prepare considerable amounts of data in, say, XML, etc. More so, it is easily extendable to accommodate, specialize and uniformly deploy new user-defined type-to-type conversions. ******************* * Where to get it * ******************* Normally you can find Boost.Convert here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-… However because the boostpro web site is having problems and will likely be down for the weekend, I have put the library into the Boost sandbox temporarily, since the Boost sandbox is up. So you can get the library, using Subversion, from https://svn.boost.org/svn/boost/sandbox/convert. This is exactly the same as the vault with the files unzipped. The HTML documentation is part of the distribution and can be found at libs/convert/index.html in the distribution above. ******************** * Writing a review * ******************** The reviews and all comments should be submitted to the developers list, and the email should have "[convert] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - 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 library? - Did you try to use the library? 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 library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Edward Diener, Review Manager

12 19