April 2004 - Boost - lists.boost.org

RE: [boost] RE: [program_options] Unicode support
by Ferdinand Prantl 07 Apr '04

07 Apr '04

Hi Volodya, > From: Vladimir Prus [mailto:ghost@cs.msu.su] > > > I would make program_options support an imbue() function > that allows a > > locale to be specified (otherwise use the default locale) > > Why bother? As I've indicated, internal processing will work > just fine with UTF-8, and no interface of the library will > expose a UTF-8 encoded string. Yes - that's it. There can be a locale en_US.UTF-8, and then the application must accept it. If it does not, it has conversion support, imbuable or not. Application should not require the library to have a unified encoding of char * on all environments; that's not STL style. > imbue() is a good thing for specifying what encoding char** > input has, but it's orthogonal to the rest of the library -- > it's used only on interface boundary. Yes, that's also my opinion. > > This provides much more flexibility than just supporting UTF-8. > > UTF-8 is a really impractical encoding for almost any > locale where the > > majority of text is not ASCII like and the user may well prefer to > > encode text is Shift-JIS or other encodings. > > Again, in my case the user does not use UTF-8 string, so why > would he care how the strings are encoded internally? Yes again, now it seems to me we try to persuade each other about the same thing :-) Ferda > - Volodya

2 1

RE: [boost] RE: Re: [program_options] Re: Unicode support
by Ferdinand Prantl 07 Apr '04

07 Apr '04

Hi Volodya, > From: Vladimir Prus [mailto:ghost@cs.msu.su] > > > UCS-2 held all characters in Unicode 1.1, There was a need for more > > unique numbers and UCS-4 was introduced in Unicode 2.0. > Unfortunately > > there is no 4-byte character specialization for > basic_string<> in STL yet. > > Or, to be exact, there's no agreement if wchar_t should be > 32-bit or 16-bit. > Linux (or gcc specifically) uses 32 bits, and Windows 16, > which means wstring only suitable for UCS-2. Wow, I did not know that about gcc, what a smart compiler... ;-) MSVC does it usually because Win32 API id ANSI/UCS-2, so the usage is straightforward then. > Besides, UCS-2 > has a mechanism to represent characters outside of 16-bit > space with two elements, which, I suspect, won't work if > wchar_t is 16 bit. Actually, not UCS-2, but another variable-sized character encoding was introduced in Unicode 2.0 - UTF-16. It serves for the 16-bit characters similarly like UTF-8 for the 8-bit ones. Using numbers from the unused (and forbidden) space it allows to encode characters in more than one element and so break the constraint of the 16-bits. It works with wchar_t, if only UCS-2 characters are stored in it; because the special characters are forbidden in UCS-2 anyway. However, UTF-16 brings the inconvenience of variable-sized character and those, who used UCS-2 and "enjoyed" the fixed character size should switch to UCS-4 to carry on... Not all applications need it, indeed, UCS-2 is enough, usually. > > Generally speaking UTF encodings (e.g. UTF-8 or UTF-16) are not > > suitable for the fast in-memory usage because some operations, for > > example at(int) and length() have not O(1) but O(n) to give > a result. > > I believe UTF-8 is popular party because such operations are > believed to be rare. Really? string.length() ? You must have been joking... :-) UTF-8 is popular because the vast amount of texts contains much more ASCII characters than the accented ones. It saves space to store them in this encoding. It was with the UTF-7 encoding also the first one, thus the oldest. It can be also comfortable for the application not to perform any conversion and work with the text in its native encoding - here can help the stringized interface working with UTF-8. Not for all applications, however. For example, XML parsers tend to work in UTF-16 internally, because UCS-4 eats much memory and UTF-8 as well for East Asian encodings. I also feel, that the applications, which parse texts and extracts string parameters to be used in some structures or as user input are processed usually with fixed-size strings, because the string operations are easier. > > They (UTF, > > T=Transformation) are better for storing texts as they save > place by > > using variable number of bytes for a character. However UCS (e.g. > > UCS-2 or > > UCS-4) are fast for memory operations because they use > fixed character > > size. > > What about representing values with two 16-bit values (that's > what I've mentioned above)? You mean UTF-16. Yes, it is also a possiblity, but having wchar_t not fixed sized, you would have to provide basic_string<char16_t>... I see it pretty the same like your UTF-8 option, because both encodings use variable-sized character, being so incompatible with the shared implementation of basic_string<> for char and wchar_t. Moreover, if basic_string<char> from the API would produce UTF-8 string, that it would be only consistent, if basic_string<wchar_t> produced UTF-16 and not UCS-2. To say nothing of support of 4-byte wchar_t and UTF-32 :-) > (BTW, for reference to those interested, > http://www.cl.cam.ac.uk/~mgk25/unicode.html#ucsutf > talks about different encodings). > > > That is why I would not like to use basic_string<utf8char> > in memory, > > rather basic_string<ucs4char> instead, but I would not > generalize it > > for all possible applications. > > In case of program options, I suspect that everything will > work for UTF-8 strings. IOW, the library does not care that > any given 'char' might be part of some Unicode character. > That's why it's attractive for me. It depends on the way of usage of basic_string<> inside and outside of the program_options. The implemenation of basic_string<> is done for fixed-size characters. It does not do searching/iterating/length counting with regards to the character size, which can vary from 1 to 6 bytes in UTF-8. For example string.find() would produce unexpected results if in haystack was stored UTF-8 and a needle was in ANSI, where all 255 numbers are allowed. Not only the library must be aware of it, but also the users, that for example basic_string<char>.size() does not deliver the count of characters but the count of bytes in a string then. That is why I do not like usage of basic_string<> for variable sized characters; basic_string<char> would not have consistent behavior for different encodings; as long as it is used for different ANSI encodings, the only misunderstanding is when two different characters in two local alphabets share the same character above ASCII. For other methods is basic_string<char> consistent. > > You can expect initialization from (const char * argv []) on all > > platforms or (const wchar_t * argv []) on Windows in UCS-2. > With the > > basic_string<> you already have support for the parameters from the > > current locale (char) and for parameters in UCS-2. > > What do you mean by 'parameters from the current locale'? If you set LC_CTYPE to something like "cs_CZ.iso8859-2" on UN*Xes or choose "Czech" in Windows Control Panel, command line shell (well, not only it) will start to accept and deliver in (char * argv []) also characters from a local alphabet (here Czech, for example). Such string you would have convert into UTF-8, if you wanted to have an UTF-8 interface. It means, you would have to do more than basic_string<char>(argv[x])... > I > am not sure that ctype::widen is required to care about > user-selected character encoding. > Not do I think it's requires from default codecvt facet. AFAIK it must care; the method widen() needs locale to provide an extension from char to a templated char_type. STL in MSVC uses correctly mbcstowc() to perform the conversion from the local alphabet to the UCS-2. I hope that no-one simply casts to wchar_t, being so reliable only for 7-bit characters. Anyway, it is always possible to write an own converting facet and force its usage for widen by with imbue. > If my locale on Linux is ru_RU.KOI8-R I don't think standard > requires codecvt<wchar_t, char> facet in default instance of > 'locale' to do meaningfull conversion from KOI8-R into unicode. Hmm, I am not sure about the ISO/C++ definition. If the standard implementation were something like "return (wchar_t) x" then it would be useless for anything except 7-bit ASCII. MSVC works with locale and it should be according to the standard, hopefully. Yet delivers the shell the variable "char * argv []" in ru_RU.KOI8-R to you. > > If we take an option to read parameters into > basic_string<wchar_t> or > > basic_string<ucs4char_t>, where the character size or > encoding is not > > the same as the native encoding on the command line, there is an > > affinity to streams. Some shells allow usage of UTF-8 encoded > > parameters or, generally, usage of characters out of the current > > locale. It means, that a program can choose the way, how to > encode all > > characters from Unicode to char. UTF-7/8, etc. I would like > to have a solution similar to streams: > > imbue(). Having this, you could convert internally every > argv[x] using > > imbue(y) applied to a stringstream, where the facet y > provides the caller. > > That's right. There should be some mechanism to convert from > current 8-bit encoding and source code encoding into unicode. > At least at linux there's a mechanism to do the first thing, > but I'm not aware about Windows. There are such methods in stdlib.h, which produce a wide character or a string of wide characters: int mbtowc(wchar_t *pwc, const char *s, size_t n); size_t mbstowcs(wchar_t *pwcs, const char *s, size_t n); These methods work with the locale supported in the operating system and thus you can always get a wchar_t from a char. And these should be used in the default facet in STL. > > On the other hand, such a conversion can be performed also > by a user. > > The parameters sent to main() are char* or wchar_t* and thus > > program_options can give them back just as they are in > > basic_string<char> and basic_string<wchar_t>. The client > can use his > > facet to imbue a basic_stringstream<> initialized with the > parameter from program_options. > > Or a conversion library could be used to perform the conversion, > > something like lexical_cast<> does for type converions. It > is a matter > > of convenience only - separate converions library (no support for > > encoding in > > program_options) or imbue(), performing the conversion inside the > > program_options. However, the conversion should not be > implemented for > > program_options only, that is why I suggested an existing > interface - > > facets. > > I agree with basing the mechanism on facets. OTOH, it's > really can be made orthogonal to program options. So > initially program_options can support only ascii (strict > 7-bit) and unicode, for which conversion is trivial. Hmm, if it was orthogonal to program options, like facets are to streams, then there is no need to declare support of encodings. char * and basic_string<char> are simply in the local encoding and wchar_t * and basic_string<wchar_t> are wide according to the understanding of "wideness" on a platform (Unicode). It will also support the input, which you can expect for program_options from main(): char * in the current locale encoding. If someone wants something else, he can use facet and streams to convert it (which could be hidden in program_options with imbue, but not necessarily). I think the point is not to support UTF-8 or UCS-2 but to support encodings explicitely declared or not. I would not implicitely return UTF-8 or UTF-16 basic_string<>s, not only because STL handles their chars implicitely according to the current locale, but also because basic_string<char>(argv[x]) does not behave this way. Having the encoding independent on program_options using some external conversions, possibly imbuable into program_options, make the library thinner and more concentrated on the problem: parse the command line. Like the streams - read characters from input. Those, who say "we need full Unicode, UTF-8 or UCS-4" have the same option as if working with streams - imbue or convert. Otherwise they have currebnt locale char from istream or wchar_t from wistream. > > You can find come converting facets for UTF-8 raedy for > imbue() to a > > stream in the files section on yahoo. Unfortunately not finished or > > not reviewed... > > Yea, I can find some facets, including one written by myself > ;-( And yea, unfortunately they are not in Boost yet. Great! You can probly prepare it for review, if your time allows it... :-) Ferda > > - Volodya > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

Uploaded/checked in Wave V 1.1.4
by hartmutkaiser＠t-online.de 07 Apr '04

07 Apr '04

Hi all, I've just uploaded a new version of the Wave preprocesor library (V1.1.4) to the yahoo files section here: http://tinyurl.com/yul67. The same version is checked into the boost-sandbox CVS. There were a lot of changes recently: - Adjusted to use the new version of the program_options library. - Fixed a bunch of minor bugs in the expression evaluation engine. - Made a lot of other rather unrelated bug fixes (see in the ChangeLog file contained inside the distribution). Besides passing its own test suite Wave now passes 98% of the preprocessor validation suite published here: http://tinyurl.com/yul67. The remaining open issues are in the field of wide character and multibyte character handling, which are implementation depended anyway. But I'm still working hard on fixing the remaining issues. Regards Hartmut

2 2

Tokenizer doc problems/confusion (?)
by David Abrahams 07 Apr '04

07 Apr '04

1. http://www.boost.org/libs/tokenizer/tokenizer.htm says: template < class TokenizerFunc = char_delimiters_separator<char>, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ class Iterator = std::string::const_iterator, class Type = std::string > class tokenizer Yet char_delimiters_separator is officially deprecated. Is that really intentional? Wow, it appears to be using the deprecated class template for the default! Now, I wanted to tokenize an input stream, without putting it in a string first. It seems to be much harder than neccessary: #include <map> #include <string> #include <iostream> #include <boost/tokenizer.hpp> #include <boost/lambda/lambda.hpp> #include <iterator> int main() { typedef std::map<std::string, unsigned> fmap; // Seems awfully complicated boost::tokenizer< boost::char_delimiters_separator<char>, std::istreambuf_iterator<char> > t( (std::istreambuf_iterator<char>(std::cin)) , std::istreambuf_iterator<char>() ); fmap f; std::string s; using namespace boost::lambda; std::for_each(t.begin(), t.end(), ++var(f)[_1]); for (fmap::iterator p = f.begin(), e = f.end(); p != e; ++p) std::cout << p->second << ": " << p->first << "\n"; } I can think of lots of ways to simplify the interface, most of which center on eliminating redundant mentions of istreambuf_iterator<char>. When I throw the following text at it: ------ how much wood could a woodchuck chuck, if a woodchuck could chuck wood? ------ I get: 2: a 2: chuck 2: could 1: how 1: if 1: much 2: wood 2: woodchuck as desired. But if I replace char_delimiters_separator with char_separator, I get: 15: What's up with that?? Even if char_separator did what it was advertised to (and it's not clear that it does), it wouldn't give me the simple "find the words functionality" of char_delimiters_separator... so I'm baffled by the deprecation. 2. http://www.boost.org/libs/tokenizer/char_separator.htm says: explicit char_separator() The function std::isspace() is used to identify dropped delimiters and std::ispunct() is used to identify kept delimiters. In addition, empty tokens are dropped. which seems strange in light of the fact that there's no ctor taking _functions_ to be used to determine kept/dropped delimiters, and nowhere in the text do you indicate that functions are called internally. Help? Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

RE: [boost] Generic non-derivable base class
by Reece Dunn 07 Apr '04

07 Apr '04

Matthew Vogt wrote: >The following simple base class implements the mechanism as dicussed on >Stroustrup's FAQ page, and encapsulates the virtual inheritance so that the >class can be non-virtually inherited, removing the most obvious chance of >implementation error. >Will this code work on multiple platforms? I have only tested on gcc >3.2... >[snip] I have tested on MS VC 6.0 sp5, 7.0 and 7.1 without any problems. On Borland 5.5.1 however, I am getting the following errors (tested in my errorcheck component): [log] Error E2404 d:\devel\adl++\include\boost/errorcheck.hpp 23: Dependent type qualifier 'boost::detail::nonderivable_base<boost::errorcheck<boost::policy::error_storage<int>,boost::policy::no_errormsg_storage> >' has no member type named 'identity' in function main() Error E2061 d:\devel\adl++\include\boost/errorcheck.hpp 23: Friends must be functions or classes in function main() Error E2029 d:\devel\adl++\include\boost/errorcheck.hpp 33: 'boost::detail::nonderivable_base<boost::errorcheck<boost::policy::error_storage<int>,boost::policy::no_errormsg_storage> >' must be a previously defined class or struct in function main() Error E2029 d:\devel\adl++\include\boost/errorcheck.hpp 136: 'boost::nonderivable<boost::errorcheck<boost::policy::error_storage<int>,boost::policy::no_errormsg_storage> >' must be a previously defined class or struct in function main() [/log] I don't have any workarounds at present. Regards, Reece _________________________________________________________________ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband

1 0

Re:[boost] Re: FC++ -- Formal Review Result
by Robert Ramey 07 Apr '04

07 Apr '04

David Abrahams wrote >> Andy Little wrote >> > Whether anyone has the guts to employ you I have no idea, but I >> > wish you all the best for the future. > Condescension and insult. FWIW - I read that as a complement. IMO many employers ARE reluctant to hire out of the box thinkers. Of course my view may be skewed as I've been a freelancer for 35 years. Robert Ramey

1 0

RE: [boost] Formal Review: Assignment Library
by Powell, Gary 07 Apr '04

07 Apr '04

Either I missed it or, I'm confused, why is the make_insert functions for set & map using the "hint" of c.end() for the insert? Is there any advantage to this? -Gary-

2 1

FC++ -- Formal Review Result
by Mat Marcus 06 Apr '04

06 Apr '04

The formal review for FC++ has completed. I am sorry to say that FC++ is not accepted into boost at this time. It may be possible for the library to be accepted in the future, but not without changes substantial enough to warrant an additional review. I will describe some possible strategies for later acceptance together with the rationale for my decision. Note that while the library is not accepted, the author has successfully established some of the merits of the functional programming paradigm and we should not require him to re-establish those same points in a future review. For that matter, I'm not convinced that we should have asked him to establish these points in the first place. * Rationale This was a very difficult decision, and I spent a long time sitting on the fence. I believe that the functional programming paradigm is important for C++ programmers, and that there are many interesting features available in FC++ such as lazy lists and the standard prelude functionality. In addition, though there was not a consensus amongst reviewers to accept (see Opinions of the Reviewers below), several boost library authors offered positive reviews of FC++. I finally managed to gather my thoughts and come to a decision -- thanks to all for your patience. In formulating my decision, I realized that one of the important questions to ask of a candidate boost library is: "Can I in good faith recommend to any C++ programmer with interest in domain X that they spend the time and effort to learn library Y and consider using it in relevant projects?" For FC++ I can not yet in good faith answer yes. I do think that it is worthwhile for *some* programmers to look at and would certainly consider pointing to FC++ in its present form from the boost web site as an "interesting third party library" if we maintained such links. But as I said I am not yet ready to put the boost "brand" on FC++. Why not? My evaluation was based on two main criteria, practicality and educational value, of which detailed accounts follow. ** Evaluation of Practicality Today FC++ is a largely monolithic library with a fair degree of overlap with other boost components. This led to a good deal of confusion/discussion during the review period. Such a state of affairs (monolith with substantial overlap) could conceivably be acceptable if there were clear problems for which FC++ was a uniquely suited practical solution. Exact Reals (see footnote *** below) notwithstanding, I don't believe that the *practical* value of FC++ as a *monolithic* embedded DSL in C++ supporting mixed paradigm programming has been satisfactorily established. [footnote ***: The existence of clients such as the Exact Real lib help demonstrate some degree of practicality. During the review I briefly examined the Exact Real site. This looked like an interesting application though I could not yet say how much practicality was demonstrated since, for example, the performance characteristics of lazy lists and constructive reals were not immediately clear to me. If FC++ is to be accepted on practical grounds potential users may want to be able to understand performance characteristics.] If the authors were to break FC++ into smaller pieces and should they participate in a future lambda, phoenix, FC++ merger then the above concerns would be addressed. It surely doesn't hurt that the authors of those other libraries expressed strong interest in the above direction. And as was pointed out in the review some of the ideas from FC++ might successfully be applied to other boost libraries such as function and/or bind. If FC++ was part of a single consistent set of FP components within boost then there would be good odds of achieving consensus to accept. The changes to bring this about would be of significant enough magnitude however that I would not be comfortable with provisional acceptance today -- a future review (or reviews of pieces are submitted independently) would be required. ** Evaluation of Educational Value Since boost is not necessarily restricted to purely practical libraries I also considered accepting FC++ into boost on the grounds that it provides an environment in which C++ programmers can learn more about and experiment with FP. FC++ enjoys some degree of success in this area. However I found it disturbing that during the review a number of traditional/imperative-style C++ programmers were just not "getting it" about FP. Perhaps a case could be made for accepting FC++ in its entirety on educational grounds after some of the improvements suggested by reviewers were implemented, e.g. improvements to the documentation and naming (useful in any case), the completion of some additional features such as Monads, or deeper documentation of the useful implementation techniques. But I must admit that I find this strategy less attractive, and I would urge you to try to break things up instead. One of the difficulties in finding acceptance on purely educational grounds might be characterized like this: if I was to recommend a way for an imperative programmer to learn more about functional programming today I would probably suggest a jump into an (OCa)ml, Haskell, or even a Lisp/Scheme environment. I am not sure that this I would recommend the FC++ environment for this purpose even with the changes suggested above. That is, I am not entirely convinced of the *purely educational value* of working with a functional programming DSL within C++. I really would prefer to see the FC++ ideas used in a practical mixed paradigm setting. * Opinions of the reviewers I was a bit concerned about the dearth of reviews during the first week so I decided to extend the review. The final number of reviews was still lower than I would have liked, but in the end I received approximately 4 no votes and 7 yes votes, with varying amounts of effort spent. Of the no votes, there was some support for acceptance after a later review, pending certain improvements. At the same time a number of the yes votes urged acceptance only after similar concerns were addressed. From this one could argue that there was near consensus that the community would be interested in accepting FC++ after these issues were addressed. The issues include the state of the documentation, the monolithic nature of the lib, and the incomplete nature of some components of the lib, e.g. monads. So I view some of the yes votes and no votes as differing mainly on whether to accept now with the above provisions or whether to require a second review after the above concerns were addressed. I spent some time vacillating between those options before finally settling on my decision to require a second review before acceptance. Given the significant nature of the requested changes I was only comfortable choosing the latter option. * Conclusion Though I am sorry not to be able to accept FC++ into boost today I would like to acknowledge its authors for the influence this library has had on other boost components. I strongly encourage you to keep working to bring the innovations from FC++ into boost in the future. I would also like to acknowledge Brian for his many creative contributions to the boost community and his thoughtful and professional posts. I am sure that I am not alone in saying thanks for all your efforts and I look forward to hearing more from you in the future. - Mat

9 14

RE: [boost] Re: [program_options] Re: Unicode support
by Ferdinand Prantl 06 Apr '04

06 Apr '04

Hello, > From: Vladimir Prus [mailto:ghost@cs.msu.su] > > > glib did a very good > > implementation of UTF-8 handling and Glibmm is a well done > C++ wrapper > > but it lacks the "standardness". Something like > boost::ustring COULD > > bring a widely accepted UTF-8 aware unicode string to C++ > programmers. > > A somewhat relieving thought. > > I am not exactly sure if UTF-8 or UCS-4 is better as > universal solution, but some solution is surely needed. I am afraid there is no universal solution for all users. The easiest solution is based on the native basic_string<>, which is specialized for char (8-bit) to support ASCII/ANSI encodings and for wchar_t (16-bit) usually used for UCS-2 encoded strings. UCS-4 (32-bit) encoding would require another basic_string<> specialization. UCS-2 held all characters in Unicode 1.1, There was a need for more unique numbers and UCS-4 was introduced in Unicode 2.0. Unfortunately there is no 4-byte character specialization for basic_string<> in STL yet. Generally speaking UTF encodings (e.g. UTF-8 or UTF-16) are not suitable for the fast in-memory usage because some operations, for example at(int) and length() have not O(1) but O(n) to give a result. They (UTF, T=Transformation) are better for storing texts as they save place by using variable number of bytes for a character. However UCS (e.g. UCS-2 or UCS-4) are fast for memory operations because they use fixed character size. That is why I would not like to use basic_string<utf8char> in memory, rather basic_string<ucs4char> instead, but I would not generalize it for all possible applications. You can expect initialization from (const char * argv []) on all platforms or (const wchar_t * argv []) on Windows in UCS-2. With the basic_string<> you already have support for the parameters from the current locale (char) and for parameters in UCS-2. If we take an option to read parameters into basic_string<wchar_t> or basic_string<ucs4char_t>, where the character size or encoding is not the same as the native encoding on the command line, there is an affinity to streams. Some shells allow usage of UTF-8 encoded parameters or, generally, usage of characters out of the current locale. It means, that a program can choose the way, how to encode all characters from Unicode to char. UTF-7/8, etc. I would like to have a solution similar to streams: imbue(). Having this, you could convert internally every argv[x] using imbue(y) applied to a stringstream, where the facet y provides the caller. The target character capabilities could choose the caller by providing a basic_string<> specialization. On the other hand, such a conversion can be performed also by a user. The parameters sent to main() are char* or wchar_t* and thus program_options can give them back just as they are in basic_string<char> and basic_string<wchar_t>. The client can use his facet to imbue a basic_stringstream<> initialized with the parameter from program_options. Or a conversion library could be used to perform the conversion, something like lexical_cast<> does for type converions. It is a matter of convenience only - separate converions library (no support for encoding in program_options) or imbue(), performing the conversion inside the program_options. However, the conversion should not be implemented for program_options only, that is why I suggested an existing interface - facets. > > Or did I miss something? Is something like this part of > boost already? > > Nope :-( Even UTF-8 encoder is not in boost yet. You can find come converting facets for UTF-8 raedy for imbue() to a stream in the files section on yahoo. Unfortunately not finished or not reviewed... Ferda > > - Volodya

4 3

Planning Next Release
by Aleksey Gurtovoy 06 Apr '04

06 Apr '04

Hi all, I'd like to test the waters for the last week of June -- let's say Monday, June 28 -- being the target date for the next major release, which I am volunteering to manage. Correspondingly, June 21 or so would be a branch-for-release date, by which everything should be in CVS and in the releasable shape. What is a "releasable shape" is a separate question I'd like to postpone for now, but basically the proposed target date implies that the for all the new stuff to get into release it'd have to be in the CVS by the middle of June -- which gives us about two months to prepare/finish things up. How does this sound for everybody? Any objections/adjustments to the dates? -- Aleksey Gurtovoy MetaCommunications Engineering

6 7