[spirit] trunk: circular dependency parse <-> construct <-> assign_to (?)
Hey Hartmut, Joel, I started playing with spirit-2/lex (on the trunk), specifically examples/lex/example4.cpp, thought I'd try to parse some python. I've hit an error that was already asked about a month or so ago. It appears to be because this guy: http://svn.boost.org/trac/boost/browser/trunk/boost/spirit/home/qi/detail/as... doesn't have 'construct' overloads for various types (conversion to unsigned is the one that comes up in the example). I dug around and found construct.hpp, http://svn.boost.org/trac/boost/browser/trunk/boost/spirit/home/qi/detail/co... which does have them, but they forward to parse(), using proto placeholders from over in support/placeholders.hpp. This ends up coming round again to assign_to. At this point I can't decide whether this is going to be detangleable or not. I thought I'd ask for some hints on what things are supposed to look like in the end, if so. In any event, the code is absolutely fascinating. Time well spent. Thanks, -t
Troy,
I started playing with spirit-2/lex (on the trunk), specifically examples/lex/example4.cpp, thought I'd try to parse some python. I've hit an error that was already asked about a month or so ago.
What problem have you hit?
It appears to be because this guy:
http://svn.boost.org/trac/boost/browser/trunk/boost/spirit/home/qi/deta il/assign_to.hpp
doesn't have 'construct' overloads for various types (conversion to unsigned is the one that comes up in the example). I dug around and found construct.hpp,
http://svn.boost.org/trac/boost/browser/trunk/boost/spirit/home/qi/deta il/construct.hpp
which does have them, but they forward to parse(), using proto placeholders from over in support/placeholders.hpp. This ends up coming round again to assign_to.
At this point I can't decide whether this is going to be detangleable or not. I thought I'd ask for some hints on what things are supposed to look like in the end, if so. In any event, the code is absolutely fascinating. Time well spent.
It's supposed to work as follows: - Any parser uses one of the assign_to() overloads to assign it's attribute value to the specified destination. - The assign_to() functions use construct overloads to do the conversion from an iterator range to the requested type (if appropriate). This distinction has been made decouple Spirit specifics from the conversion itself and to allow the user to provide his/her own construct() overloads for custom parsers (to be found via ADL). - Some of the (predefined) construct() functions use Spirit parsers themselves to do the conversion. But here we use only parser primitives which provide their attributes as (already converted) values, not as iterator ranges. I still have a hard time to see your problem. The construct() functions use qi::parse only for the conversion of iterator ranges to the attribute type, so there shouldn't be any cyclic dependencies. HTH Regards Hartmut
Hey Hartmut, Hartmut Kaiser wrote:
What problem have you hit?
Here's the error: gfilt -o example4 example4.cpp -I ../boost/trunk -lstdc++ (where example4.cpp is: BD Software STL Message Decryptor v3.10 for gcc 2/3/4 ../boost/trunk/boost/spirit/home/qi/detail/assign_to.hpp: In function 'void boost::spirit::qi::detail::construct_::construct( unsigned int &, const __normal_iterator<char *, string> & , const __normal_iterator<char *, string> & )': ../boost/trunk/boost/spirit/home/qi/detail/assign_to.hpp:70: instantiated from 'void boost::spirit::qi::detail::assign_to( const __normal_iterator<char *, string> & , const __normal_iterator<char *, string> &, unsigned int & )' ../boost/trunk/boost/spirit/home/lex/lexer/lexertl/lexertl_token.hpp:348: instantiated from 'void boost::spirit::lex::construct( unsigned int & , boost::spirit::lex::lexertl_token< __normal_iterator<char *, string> , boost::mpl::vector<unsigned int, string>, mpl_::bool_<true> > & )' ../boost/trunk/boost/spirit/home/qi/detail/assign_to.hpp:92: instantiated from 'void boost::spirit::qi::detail::assign_to( boost::spirit::lex::lexertl_token< __normal_iterator<char *, string> , boost::mpl::vector<unsigned int, string>, mpl_::bool_<true> > &, unsigned int & )' ../boost/trunk/boost/spirit/home/lex/lexer/token_def.hpp:125: instantiated from 'bool boost::spirit::lex::token_def<unsigned int, char, unsigned int> ::parse( boost::spirit::lex::lexertl_iterator< boost::spirit::lex::lexertl_functor< boost::spirit::lex::lexertl_token< __normal_iterator<char *, string> , boost::mpl::vector<unsigned int, string> , mpl_::bool_<true> >, __normal_iterator<char *, string>, mpl_::bool_<false> , mpl_::bool_<true> > > & (skip to bottom of stack) example4.cpp:239: instantiated from here ../boost/trunk/boost/spirit/home/qi/detail/assign_to.hpp:27: error: functional cast expression list treated as compound expression ../boost/trunk/boost/spirit/home/qi/detail/assign_to.hpp:27: error: invalid cast from type 'const __normal_iterator<char *, string>' to type 'unsigned int' example4.cpp:239 is just 'return 0;' from main(). Foo. I discovered that I could toggle the error by removing 'tok.constant[_val = _1]' from this part of example4's : expression = tok.identifier [ _val = _1 ] | tok.constant [ _val = _1 ] // problem here ; The 'tok.constant [_val = _1 ]' ends up here, in the first construct() in assign_to.hpp: /////////////////////////////////////////////////////////////////////// // This is used to allow to overload of the attribute creation for // arbitrary types /////////////////////////////////////////////////////////////////////// template <typename Attribute, typename Iterator> inline void construct(Attribute& attr, Iterator const& first, Iterator const& last) { attr = Attribute(first, last); } so you get attr = unsigned int(first, last); and boom. In the (working) case of tok.identifier, attr is a string, and it gets constructed directly from the two iterators, no problem.
It's supposed to work as follows:
- Any parser uses one of the assign_to() overloads to assign it's attribute value to the specified destination. - The assign_to() functions use construct overloads to do the conversion from an iterator range to the requested type (if appropriate). This distinction has been made decouple Spirit specifics from the conversion itself and to allow the user to provide his/her own construct() overloads for custom parsers (to be found via ADL). - Some of the (predefined) construct() functions use Spirit parsers themselves to do the conversion. But here we use only parser primitives which provide their attributes as (already converted) values, not as iterator ranges.
I still have a hard time to see your problem. The construct() functions use qi::parse only for the conversion of iterator ranges to the attribute type, so there shouldn't be any cyclic dependencies.
Thanks for the explanation, I'm digging round again with those points in mind, seeing more than I did last time. Note that the namespace boost::spirit::qi::detail::construct_ appears in *two* different places: one in construct.hpp (where I see a sensible-looking wall of overloads for primitive type, some of which call parse(), as you say), and also at the top of assign_to.hpp, which looks to my untrained eye like it might be a placeholder. http://svn.boost.org/trac/boost/browser/trunk/boost/spirit/home/qi/detail/co... http://svn.boost.org/trac/boost/browser/trunk/boost/spirit/home/qi/detail/as... It was when I tried to redirect the calls into the assign_to.hpp version of ...::construct_ over to the construct.hpp version of ...::construct_ that this unsightly tailspin began. Looking back at the other error that had been posted that I thought was the same... maybe not. I was up all night, sorry. I hope that's clear. Thanks for looking at this. -t
HTH Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
troy d. straszheim wrote:
appears in *two* different places: one in construct.hpp (where I see a sensible-looking wall of overloads for primitive type, some of which call parse(), as you say), and also at the top of assign_to.hpp, which looks to my untrained eye like it might be a placeholder.
Or not. Naturally a light bulb went on at the moment I hit 'send': Hartmut wrote:
- The assign_to() functions use construct overloads to do the conversion from an iterator range to the requested type (if appropriate). This distinction has been made decouple Spirit specifics from the conversion itself and to allow the user to provide his/her own construct() overloads for custom parsers (to be found via ADL).
I can get things working by pulling the construct.hpp overloads into namespace std: namespace std { using boost::spirit::qi::detail::construct_::construct; } at the top of example4.cpp. Not especially pretty. Guessing there are some ADL tricks here that I don't know about. Continuing to poke at it. Best, -t
Troy,
What problem have you hit?
Here's the error:
gfilt -o example4 example4.cpp -I ../boost/trunk -lstdc++
Hold on. Is it just lex/example4.cpp failing? It does compile for me! Did you change anything? Regards Hartmut
Am Donnerstag 29 Mai 2008 19:46:24 schrieb Hartmut Kaiser:
Troy,
What problem have you hit?
Here's the error:
gfilt -o example4 example4.cpp -I ../boost/trunk -lstdc++
Hold on. Is it just lex/example4.cpp failing? It does compile for me! Did you change anything?
Don't know if it helps... but I tried to compile lex/example4.cpp using - gcc-3.4 - gcc-4.2 - gcc-4.3 <boost-trunk> maik@localhost:~/workspace/boost$ svn up Revision 45916. </boost-trunk> <gcc-3.4> ... example4.cpp:207: instantiated from here /home/maik/workspace/boost/boost/xpressive/proto/matches.hpp:139: internal compiler error: in lookup_member, at cp/search.c:1300 Please submit a full bug report, with preprocessed source if appropriate. </gcc-3.4> <gcc-4.2> example4.cpp:239: instantiated from here /home/maik/workspace/boost/boost/spirit/home/qi/detail/assign_to.hpp:27: error: functional cast expression list treated as compound expression /home/maik/workspace/boost/boost/spirit/home/qi/detail/assign_to.hpp:27: error: invalid cast from type ‘const __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >’ to type ‘unsigned in </gcc-4.2> <gcc-4.3> example4.cpp:240: instantiated from here /home/maik/workspace/boost/boost/spirit/home/qi/detail/assign_to.hpp:27: error: functional cast expression list treated as compound expression /home/maik/workspace/boost/boost/spirit/home/qi/detail/assign_to.hpp:27: error: invalid cast from type ‘const __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >’ to type ‘unsigned int’ </gcc-4.3> Thank you for your work Hartmut, -- Maik
Hartmut Kaiser wrote:
Troy,
What problem have you hit? Here's the error:
gfilt -o example4 example4.cpp -I ../boost/trunk -lstdc++
Hold on. Is it just lex/example4.cpp failing? It does compile for me! Did you change anything?
I sure hope not. Before I ask for your time I triple-check everything. I see that Maik gets the same error (thanks Maik, that does indeed help); here's a transcript: troy@uranium:~/Projects/boost/trunk % gcc --version gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. troy@uranium:~/Projects/boost/trunk % svn info Path: . URL: https://svn.boost.org/svn/boost/trunk Repository Root: https://svn.boost.org/svn/boost Repository UUID: b8fc166d-592f-0410-95f2-cb63ce0dd405 Revision: 45896 Node Kind: directory Schedule: normal Last Changed Author: bemandawes Last Changed Rev: 45894 Last Changed Date: 2008-05-28 21:34:53 -0400 (Wed, 28 May 2008) troy@uranium:~/Projects/boost/trunk % svn update At revision 45915. troy@uranium:~/Projects/boost/trunk % svn status troy@uranium:~/Projects/boost/trunk % cd libs/spirit/example/lex troy@uranium:~/Projects/boost/trunk/libs/spirit/example/lex % for e in example?.cpp do echo ----- $e ----- ; gcc -o $e.out $e -I . -I ../../../.. -lstdc++ 2>&1 | tail -2 done ----- example1.cpp ----- ----- example2.cpp ----- ----- example3.cpp ----- ----- example4.cpp ----- ../../../../boost/spirit/home/qi/detail/assign_to.hpp:27: error: functional cast expression list treated as compound expression ../../../../boost/spirit/home/qi/detail/assign_to.hpp:27: error: invalid cast from type 'const __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >' to type 'unsigned int' ----- example5.cpp ----- ../../../../boost/spirit/home/qi/detail/assign_to.hpp:27: error: functional cast expression list treated as compound expression ../../../../boost/spirit/home/qi/detail/assign_to.hpp:27: error: invalid cast from type 'const __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >' to type 'unsigned int' ----- example6.cpp ----- ../../../../boost/spirit/home/qi/detail/assign_to.hpp:27: error: functional cast expression list treated as compound expression ../../../../boost/spirit/home/qi/detail/assign_to.hpp:27: error: invalid cast from type 'const __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >' to type 'unsigned int' I get identical errors w/ gcc-4.1. thanks again for having a look at this. I'm still prodding at it. Best, -t
Hey Hartmut, I've got a workaround, like so: If you forward declare the construct() overloads for the different primitive Attribute types, gcc seems to not greedily match this one (the current error): template <typename Attribute, typename Iterator> inline void construct(Attribute& attr, Iterator const& first, Iterator const& last) { attr = Attribute(first, last); } and instead to wait for this one (correct): template <typename Iterator> inline void construct(unsigned int& attr, Iterator const& first, Iterator const& last) { Iterator first_ = first; parse(first_, last, uint_, attr); } So I've got local mods of adding #include <boost/spirit/home/qi/detail/construct_fwd.hpp> to the top of assign_to.hpp, and the construct_fwd.hpp is attached. I don't entirely get it, but I do like the looks of this: troy@uranium:~/Projects/boost/trunk/libs/spirit/example/lex % gcc -o example4 example4.cpp -I . -I ../../../.. -lstdc++ troy@uranium:~/Projects/boost/trunk/libs/spirit/example/lex % ./example4 assignment statement to: a if expression: variable assignment statement to: b if expression: 2 assignment statement to: c assignment statement to: d if expression: x while expression: 10 assignment statement to: variable ------------------------- Parsing succeeded ------------------------- Bye... :-) Best, -t
Thanks Troy! I just wanted to start investigating and - voila! You already did it! I'll incorporate your patch asap. Regards Hartmut
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost- bounces@lists.boost.org] On Behalf Of troy d. straszheim Sent: Thursday, May 29, 2008 2:29 PM To: boost@lists.boost.org Subject: Re: [boost] [spirit] trunk: circular dependency parse <-> construct <-> assign_to (?)
Hey Hartmut,
I've got a workaround, like so:
If you forward declare the construct() overloads for the different primitive Attribute types, gcc seems to not greedily match this one (the current error):
template <typename Attribute, typename Iterator> inline void construct(Attribute& attr, Iterator const& first, Iterator const& last) { attr = Attribute(first, last); }
and instead to wait for this one (correct):
template <typename Iterator> inline void construct(unsigned int& attr, Iterator const& first, Iterator const& last) { Iterator first_ = first; parse(first_, last, uint_, attr); }
So I've got local mods of adding
#include <boost/spirit/home/qi/detail/construct_fwd.hpp>
to the top of assign_to.hpp, and the construct_fwd.hpp is attached.
I don't entirely get it, but I do like the looks of this:
troy@uranium:~/Projects/boost/trunk/libs/spirit/example/lex % gcc -o example4 example4.cpp -I . -I ../../../.. -lstdc++
troy@uranium:~/Projects/boost/trunk/libs/spirit/example/lex % ./example4 assignment statement to: a if expression: variable assignment statement to: b if expression: 2 assignment statement to: c assignment statement to: d if expression: x while expression: 10 assignment statement to: variable ------------------------- Parsing succeeded ------------------------- Bye... :-)
Best,
-t
Am Freitag 30 Mai 2008 01:59:28 schrieb Hartmut Kaiser:
Thanks Troy!
I just wanted to start investigating and - voila! You already did it! I'll incorporate your patch asap.
Regards Hartmut
Due to troy's commit which made the example*.cpp work I became curious if the other files at the lex/examples folder compile as well. Running {{{ $ cd libs/spirit/example/qi && $(BJAM) variant=debug $(BJAM_FLAGS) | tee spirit.log }}} gives me 4 failed targets. The files gcc tries to compile are - print_numbers.cpp - word_count.cpp - strip_comments_lexer.cpp - strip_comments.cpp The log is gigantic (3 MB ... may c++0x and it's concepts come ASAP), thus, Hartmut, I'll send you the log off-list in case you like to take a look (or is pastebin more suitable?). I've run gfilt using an linewrap of 125 character to get the log more readable. -- Maik
Due to troy's commit which made the example*.cpp work I became curious if the other files at the lex/examples folder compile as well. Running {{{ $ cd libs/spirit/example/qi && $(BJAM) variant=debug $(BJAM_FLAGS) | tee spirit.log }}}
gives me 4 failed targets. The files gcc tries to compile are - print_numbers.cpp - word_count.cpp - strip_comments_lexer.cpp - strip_comments.cpp
The log is gigantic (3 MB ... may c++0x and it's concepts come ASAP), thus, Hartmut, I'll send you the log off-list in case you like to take a look (or is pastebin more suitable?). I've run gfilt using an linewrap of 125 character to get the log more readable.
Thanks Maik, please send it to me offlist. I have to admit I never tried to compile these examples using gcc 4.x yet... Obviously, I should have done so, though. So much time so little to do :-P Regards Hartmut
Am Freitag 30 Mai 2008 17:08:19 schrieb Maik Beckmann:
Due to troy's commit which made the example*.cpp work I became curious if the other files at the lex/examples folder compile as well. Running {{{ $ cd libs/spirit/example/qi && $(BJAM) variant=debug $(BJAM_FLAGS) | tee spirit.log }}}
gives me 4 failed targets. The files gcc tries to compile are - print_numbers.cpp - word_count.cpp - strip_comments_lexer.cpp - strip_comments.cpp
The log is gigantic (3 MB ... may c++0x and it's concepts come ASAP), thus, Hartmut, I'll send you the log off-list in case you like to take a look (or is pastebin more suitable?). I've run gfilt using an linewrap of 125 character to get the log more readable.
Ok, compiling at command line {{{ $ LC_ALL=en_US.UTF-8 gfilt /width:120 -I ../../../../ foo.cpp > foo.log }}} without any -Wxxx flags shortens the logs a bit :-). They are attached. Best, -- Maik
Due to troy's commit which made the example*.cpp work I became curious if the other files at the lex/examples folder compile as well. Running {{{ $ cd libs/spirit/example/qi && $(BJAM) variant=debug $(BJAM_FLAGS) | tee spirit.log }}}
gives me 4 failed targets. The files gcc tries to compile are - print_numbers.cpp - word_count.cpp - strip_comments_lexer.cpp - strip_comments.cpp
The log is gigantic (3 MB ... may c++0x and it's concepts come ASAP), thus, Hartmut, I'll send you the log off-list in case you like to take a look (or is pastebin more suitable?). I've run gfilt using an linewrap of 125 character to get the log more readable.
Ok, compiling at command line {{{ $ LC_ALL=en_US.UTF-8 gfilt /width:120 -I ../../../../ foo.cpp > foo.log }}} without any -Wxxx flags shortens the logs a bit :-). They are attached.
Everything should be fixed now. Thanks again! Regards Hartmut
Am Freitag 30 Mai 2008 20:39:28 schrieb Hartmut Kaiser:
Everything should be fixed now. Thanks again!
Regards Hartmut
Sorry... but the result of this {{{ $ LC_ALL=en_US.UTF-8 gfilt /width:85 -I ../../../../ word_count_lexer.cpp > word_count_lexer.log }}} is attached. -- Maik PS: maik@localhost:~/workspace/boost$ svn up Revision 45959.
Am Freitag 30 Mai 2008 20:39:28 schrieb Hartmut Kaiser:
Everything should be fixed now. Thanks again!
Regards Hartmut
Sorry... but the result of this {{{ $ LC_ALL=en_US.UTF-8 gfilt /width:85 -I ../../../../ word_count_lexer.cpp > word_count_lexer.log }}} is attached.
Ok fixed. This is just one of these cases where you don't know how it ever worked at all... Regards Hartmut
uuup, hit the reply button at the wrong message... Am Freitag 30 Mai 2008 21:56:05 schrieb Hartmut Kaiser:
Am Freitag 30 Mai 2008 20:39:28 schrieb Hartmut Kaiser:
Everything should be fixed now. Thanks again!
Regards Hartmut
Sorry... but the result of this {{{ $ LC_ALL=en_US.UTF-8 gfilt /width:85 -I ../../../../ word_count_lexer.cpp > word_count_lexer.log }}} is attached.
Ok fixed. This is just one of these cases where you don't know how it ever worked at all...
Regards Hartmut
{{{ $ LC_ALL=en_US.UTF-8 gfilt /width:100 -I ../../../../ strip_comments_lexer.cpp |tee strip_comments_lexer.log }}} Because strip_comments_lexer.log is 34K big I zipped it. -- Maik PS: I would love to help patching this, but I fear my skills are yet not good enough for this level of template coding.
Am Freitag 30 Mai 2008 22:37:34 schrieb Maik Beckmann:
uuup, hit the reply button at the wrong message...
Am Freitag 30 Mai 2008 21:56:05 schrieb Hartmut Kaiser:
Am Freitag 30 Mai 2008 20:39:28 schrieb Hartmut Kaiser:
Everything should be fixed now. Thanks again!
Regards Hartmut
Sorry... but the result of this {{{ $ LC_ALL=en_US.UTF-8 gfilt /width:85 -I ../../../../ word_count_lexer.cpp > word_count_lexer.log }}} is attached.
Ok fixed. This is just one of these cases where you don't know how it ever worked at all...
Regards Hartmut
{{{ $ LC_ALL=en_US.UTF-8 gfilt /width:100 -I ../../../../ strip_comments_lexer.cpp |tee strip_comments_lexer.log }}}
Because strip_comments_lexer.log is 34K big I zipped it.
-- Maik
PS: I would love to help patching this, but I fear my skills are yet not good enough for this level of template coding.
The following message contained restricted attachment(s) which have been removed: From : beckmann.maik@googlemail.com To : lutzh@autonomy.com Subject : Re: [boost] [spirit] trunk: circular dependency parse <-> construct <-> assign_to (?) Message-ID: <200805302237.34188.beckmann.maik@googlemail.com> Attachment(s) removed: ----------------------------------------- strip_comments_lexer.zip Arrgggg... Ok pastebin, its your turn.. - http://pastebin.com/m74a6afce
Ok, I'll first have to find a gcc 4.x platform before posting any future success stories... Thanks! Regards Hartmut
uuup, hit the reply button at the wrong message...
Am Freitag 30 Mai 2008 21:56:05 schrieb Hartmut Kaiser:
Am Freitag 30 Mai 2008 20:39:28 schrieb Hartmut Kaiser:
Everything should be fixed now. Thanks again!
Regards Hartmut
Sorry... but the result of this {{{ $ LC_ALL=en_US.UTF-8 gfilt /width:85 -I ../../../../ word_count_lexer.cpp > word_count_lexer.log }}} is attached.
Ok fixed. This is just one of these cases where you don't know how it ever worked at all...
Regards Hartmut
{{{ $ LC_ALL=en_US.UTF-8 gfilt /width:100 -I ../../../../ strip_comments_lexer.cpp |tee strip_comments_lexer.log }}}
Because strip_comments_lexer.log is 34K big I zipped it.
-- Maik
PS: I would love to help patching this, but I fear my skills are yet not good enough for this level of template coding.
Am Freitag 30 Mai 2008 22:42:45 schrieb Hartmut Kaiser:
Ok, I'll first have to find a gcc 4.x platform before posting any future success stories...
Thanks! Regards Hartmut
Hopefully gcc-4.3 will become the stable compiler for mingw soon. This would be a boost for boost ^^ Anyway, if you got access to a pre-gcc-4.x Linux distro I propose downloading the current gcc tarball, untar it, copy the attached Makefile into this dir and run {{{ make do_configure make -j2 make install }}} No root rights are needed. The Makefile configured gcc to be installed into the a subdir called stage. Now you should be able to just use the compile by rferring to it via the absolute path {{{ export CXX=/path/to/stage/bin/g++ $CXX foo.cpp -o bar }}} or in user-config.jam {{{ using gcc : 4.3 : /path/to/stage/bin/g++ ; }}} HTH, -- Maik
Maik,
Ok, I'll first have to find a gcc 4.x platform before posting any future success stories...
Ok, now everything compiles using gcc 4.3. Thanks again for providing the mingw compiler! Regards Hartmut
Am Freitag 30 Mai 2008 20:39:28 schrieb Hartmut Kaiser:
Everything should be fixed now. Thanks again!
Regards Hartmut
{{{ $ LC_ALL=en_US.UTF-8 gfilt /width:100 -I ../../../../ strip_comments_lexer.cpp |tee strip_comments_lexer.log }}} Because strip_comments_lexer.log is 34K big I zipped it. -- Maik PS: I would love to help patching this, but I fear my skills are yet not good enough for this level of template coding.
participants (3)
-
Hartmut Kaiser -
Maik Beckmann -
troy d. straszheim