You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(9) |
Oct
(16) |
Nov
(14) |
Dec
(24) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(14) |
Feb
(57) |
Mar
(72) |
Apr
(37) |
May
(21) |
Jun
(12) |
Jul
(16) |
Aug
(33) |
Sep
(24) |
Oct
|
Nov
(10) |
Dec
(8) |
2004 |
Jan
(6) |
Feb
(14) |
Mar
(47) |
Apr
(41) |
May
(16) |
Jun
(31) |
Jul
(78) |
Aug
(62) |
Sep
(99) |
Oct
(43) |
Nov
(35) |
Dec
(9) |
2005 |
Jan
(19) |
Feb
(22) |
Mar
(7) |
Apr
|
May
(5) |
Jun
(4) |
Jul
(2) |
Aug
(9) |
Sep
(15) |
Oct
(23) |
Nov
(2) |
Dec
(20) |
2006 |
Jan
|
Feb
(2) |
Mar
(7) |
Apr
|
May
|
Jun
(8) |
Jul
(15) |
Aug
(1) |
Sep
(4) |
Oct
|
Nov
(9) |
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(11) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <se...@in...> - 2005-11-29 20:54:40
|
On Tue, 2005-11-29 at 00:28 -0800, zbyte pepsi-hola wrote: > Unfortunately I have not seen examples of OpenC++ one larger > applications. So as a result I am uncertain about how/where the code > is put when generated and wether linking problems will become an > issue. To illistrate my question, lets say I have the following: > > foo.cc & foo.hh > bar.cc & bar.hh > > now, bar.cc includes both bar.hh and foo.hh. foo.hh implements a > metaclass. Now I compile both foo and bar and link it together. So my > question is, how many times is foo preprocessed, 1 or 2 times? if > twice, how does openc++ take care of duplicate linking issues? If this > is a problem, how do I get around it? try, $ occ2 --help if it does not answer your question, ask again. hope it help |
From: zbyte pepsi-h. <zb...@gm...> - 2005-11-29 08:28:21
|
Unfortunately I have not seen examples of OpenC++ one larger applications. So as a result I am uncertain about how/where the code is put when generate= d and wether linking problems will become an issue. To illistrate my question= , lets say I have the following: foo.cc & foo.hh bar.cc & bar.hh now, bar.cc includes both bar.hh and foo.hh. foo.hh implements a metaclass. Now I compile both foo and bar and link it together. So my question is, how many times is foo preprocessed, 1 or 2 times? if twice, how does openc++ take care of duplicate linking issues? If this is a problem, how do I get around it? |
From: Stefan S. <se...@sy...> - 2005-10-21 02:37:38
|
Gilles J. Seguin wrote: >>3- is >> const static size_t __align = ( >> __alignof__(_Tp) >= sizeof(_Block_record) >> ? __alignof__(_Tp) >> : sizeof(_Block_record) >> ); > > > we accept static const > static > const > but not const static Right, that's another point. occ expects declarations to start with an optional storage-class-specifier, followed by a type-id and a declarator-list, while the actual C++ grammar lets declarations start with a decl-specifier-seq, followed by a declarator-list. Thus, 'static' may appear (much to my own surprize when I looked that up in the spec not long ago !) in the middle of the decl-specifier-seq, as does 'typedef' and 'mutable'. Fixing this in the occ parser is almost impossible, and it would impact the parse tree structure. (meaning all the walkers need to be updated !) Luckily, not many will write code like int typedef Int; void static foo(); but once you get such code from a std library you are in trouble. Regards, Stefan |
From: <se...@in...> - 2005-10-20 23:20:26
|
On Thu, 2005-10-20 at 06:03 -0400, Gilles J. Seguin wrote: > after applying patch for bits/cpp_type_traits.h known problem > > "make check" fails > 1- /usr/include/c++/4.0.1/bits/stl_algobase.h:164 > 2- /usr/include/c++/4.0.1/ext/mt_allocator.h:498 > 3- /usr/include/c++/4.0.1/ext/mt_allocator.h:544 > [...] > 2- is > const static size_t __align = ( > __alignof__(_Tp) >= sizeof(_Block_record) > ? __alignof__(_Tp) > : sizeof(_Block_record) > ); > > 3- is > const static size_t __align = ( > __alignof__(_Tp) >= sizeof(_Block_record) > ? __alignof__(_Tp) > : sizeof(_Block_record) > ); we accept static const static const but not const static |
From: Stefan S. <se...@sy...> - 2005-10-20 11:53:36
|
Gilles J. Seguin wrote: > On Thu, 2005-10-20 at 06:03 -0400, Gilles J. Seguin wrote: > >>after applying patch for bits/cpp_type_traits.h known problem >> >>"make check" fails >>1- /usr/include/c++/4.0.1/bits/stl_algobase.h:164 >>2- /usr/include/c++/4.0.1/ext/mt_allocator.h:498 >>3- /usr/include/c++/4.0.1/ext/mt_allocator.h:544 >> >>1- is >> std::__iter_swap< >> __are_same<_ValueType1, _ValueType2>::__value >> && __are_same<_ValueType1 &, _ReferenceType1>::__value >> && __are_same<_ValueType2 &, _ReferenceType2>::__value >> >::iter_swap(__a, __b); > > > made this one to pass, if the template parameter of __iter_swap is > put between parenthesis in stl_algobase.h > > that is > std::__iter_swap<( > __are_same<_ValueType1, _ValueType2>::__value > && __are_same<_ValueType1 &, _ReferenceType1>::__value > && __are_same<_ValueType2 &, _ReferenceType2>::__value > )>::iter_swap(__a, __b); Good ! That helps to understand what is going on. It appears this way you give a hint to occ to interpret the content of the parens as a primary-expression, I think. Unfortunately the libstdc++ maintainer's are unlikely to accept patches to satisfy occ ;-) Regards, Stefan |
From: <se...@in...> - 2005-10-20 08:18:19
|
On Thu, 2005-10-20 at 06:03 -0400, Gilles J. Seguin wrote: > after applying patch for bits/cpp_type_traits.h known problem > > "make check" fails > 1- /usr/include/c++/4.0.1/bits/stl_algobase.h:164 > 2- /usr/include/c++/4.0.1/ext/mt_allocator.h:498 > 3- /usr/include/c++/4.0.1/ext/mt_allocator.h:544 > > 1- is > std::__iter_swap< > __are_same<_ValueType1, _ValueType2>::__value > && __are_same<_ValueType1 &, _ReferenceType1>::__value > && __are_same<_ValueType2 &, _ReferenceType2>::__value > >::iter_swap(__a, __b); made this one to pass, if the template parameter of __iter_swap is put between parenthesis in stl_algobase.h that is std::__iter_swap<( __are_same<_ValueType1, _ValueType2>::__value && __are_same<_ValueType1 &, _ReferenceType1>::__value && __are_same<_ValueType2 &, _ReferenceType2>::__value )>::iter_swap(__a, __b); see also testcase attachment occ2 gilles3.cc -o gilles3.exe |
From: <se...@in...> - 2005-10-20 05:07:26
|
On Wed, 2005-10-19 at 14:11 -0400, Stefan Seefeld wrote: > Hi Gilles, Hi stefan, > > Gilles J. Seguin wrote: > > after applying patch for bits/cpp_type_traits.h known problem > > > > "make check" fails > > 1- /usr/include/c++/4.0.1/bits/stl_algobase.h:164 > > 2- /usr/include/c++/4.0.1/ext/mt_allocator.h:498 > > 3- /usr/include/c++/4.0.1/ext/mt_allocator.h:544 > You didn't say what exactly fails, so I guess it is the occ parser. > Could you paste the actual error message(s) ? 1- go to the Makefile of examples/before for me it is /home1/h5/opencxx/build/examples/before 2- ../../occ2 ../../../opencxx/examples/before/BeforeClass.mc \ -o BeforeClass.exe you should have something like (after email formating !!) occ2: command failed: libtool -dlopen /home1/h5/opencxx/build/opencxx/libocc_mop.la --mode=execute /home1/h5/opencxx/build/occ --private--external-driver -E <BeforeClass.ii --private--output BeforeClass.occ.tmp 2>BeforeClass.feedback 3- cat BeforeClass.feedback |
From: Stefan S. <se...@sy...> - 2005-10-19 18:13:12
|
Hi Gilles, Gilles J. Seguin wrote: > after applying patch for bits/cpp_type_traits.h known problem > > "make check" fails > 1- /usr/include/c++/4.0.1/bits/stl_algobase.h:164 > 2- /usr/include/c++/4.0.1/ext/mt_allocator.h:498 > 3- /usr/include/c++/4.0.1/ext/mt_allocator.h:544 > > 1- is > std::__iter_swap< > __are_same<_ValueType1, _ValueType2>::__value > && __are_same<_ValueType1 &, _ReferenceType1>::__value > && __are_same<_ValueType2 &, _ReferenceType2>::__value > >::iter_swap(__a, __b); > > 2- is > const static size_t __align = ( > __alignof__(_Tp) >= sizeof(_Block_record) > ? __alignof__(_Tp) > : sizeof(_Block_record) > ); > > 3- is > const static size_t __align = ( > __alignof__(_Tp) >= sizeof(_Block_record) > ? __alignof__(_Tp) > : sizeof(_Block_record) > ); > You didn't say what exactly fails, so I guess it is the occ parser. Could you paste the actual error message(s) ? The first failed code looks suspiciously like code I had trouble with, too, as a compliant parser has to figure out that '__are_same' is a template-name in order to parse the following tokens as a template-id. It could well be that occ's heuristics start to fail here. I'm not sure what the problem with 2 and 3 is though. As long as 'sizeof' and '__alignof__' are recognized by the lexer this should be fine. (The second is actually a GCC extension, I believe.) Regards, Stefan PS: The actual code that I tried to parse before realizing it was time for a complete parser rewrite was this, FWIW: typedef typename ITE_Type<FixedDim == 0, ITE_Type<Dim1 < Dim2, As_type<row2_type>, As_type<col2_type> >, ITE_Type<FixedDim == 1, ITE_Type<Dim0 < Dim2, As_type<row2_type>, As_type<col2_type> >, ITE_Type<Dim0 < Dim1, As_type<row2_type>, As_type<col2_type> > > >::type type; |
From: <se...@in...> - 2005-10-19 17:51:25
|
after applying patch for bits/cpp_type_traits.h known problem "make check" fails 1- /usr/include/c++/4.0.1/bits/stl_algobase.h:164 2- /usr/include/c++/4.0.1/ext/mt_allocator.h:498 3- /usr/include/c++/4.0.1/ext/mt_allocator.h:544 1- is std::__iter_swap< __are_same<_ValueType1, _ValueType2>::__value && __are_same<_ValueType1 &, _ReferenceType1>::__value && __are_same<_ValueType2 &, _ReferenceType2>::__value >::iter_swap(__a, __b); 2- is const static size_t __align = ( __alignof__(_Tp) >= sizeof(_Block_record) ? __alignof__(_Tp) : sizeof(_Block_record) ); 3- is const static size_t __align = ( __alignof__(_Tp) >= sizeof(_Block_record) ? __alignof__(_Tp) : sizeof(_Block_record) ); needs investigation. so, i am stock there |
From: Jonathan G. <gt...@ma...> - 2005-10-16 19:04:54
|
Grzegorz Jakacki wrote: >--- Stefan Seefeld <se...@sy...> wrote: > > > >>Jonathan Gdalevich wrote: >> >> >>>Dear OpenC++ users, >>> >>>While trying to learn and using OpenC++, I noticed that most of the >>>available documentation is severely outdated. For example, the >>> >>> >>tutorial >> >> >>>pdf has been created in 1996 while the command reference on >>> >>> >>sourceforge >> >> >>>still uses occ instead of occ2. I am in the process of writing >>> >>> >>some >> >> >>>documentation for the project that I am working on and was >>> >>> >>wondering if >> >> >>>anyone out there created any APIs, documents, examples, makefiles, >>> >>> >>or >> >> >>>anything else that could prove helpful to a person trying to learn >>>OpenC++. >>> >>> >>Knowing what you want to do with OpenC++ would be helpful when trying >>to answer your questions. >>While The OpenC++ code has been adjusted to compile with modern >>compilers, >>not much energy has been put into development. >> >> > >Many people contributed their time into making the code better and what >you say is clear depreciation of their contributions. It is strange, >because you were a contributor too. > >BR >Grzegorz > > > > >>As a consequence, the >>original >>documentation (user's guide, reference) is still largely accurate. >> >>You may want to browse the mailing list archive to learn more about >>the project / status. >> >>Regards, >> Stefan >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: >>Power Architecture Resource Center: Free content, downloads, >>discussions, >>and more. http://solutions.newsforge.com/ibmarch.tmpl >>_______________________________________________ >>Opencxx-users mailing list >>Ope...@li... >>https://lists.sourceforge.net/lists/listinfo/opencxx-users >> >> >> > > > > >__________________________________ >Yahoo! Music Unlimited >Access over 1 million songs. Try it free. >http://music.yahoo.com/unlimited/ > > >------------------------------------------------------- >This SF.Net email is sponsored by: >Power Architecture Resource Center: Free content, downloads, discussions, >and more. http://solutions.newsforge.com/ibmarch.tmpl >_______________________________________________ >Opencxx-users mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opencxx-users > > > Thank you very much, Great example! The paper is really good. I am going to have to write something similar by the end of December. I will try to combine your example with other to create so kind of an example package and descriptions. Sincerely, -- Jonathan Gdalevich Georgia Institute of Technology, Atlanta Georgia, 30332 Email: gt...@pr... |
From: Stefan S. <se...@sy...> - 2005-10-16 15:31:34
|
Grzegorz Jakacki wrote: >>While The OpenC++ code has been adjusted to compile with modern >>compilers, >>not much energy has been put into development. > > > Many people contributed their time into making the code better and what > you say is clear depreciation of their contributions. It is strange, > because you were a contributor too. Grzegorz, I didn't mean to undervalue anybody's work. The point I was trying to make was simply that there were no user-visible changes that would render the documentation Chiba wrote in '96 outdated. Work has mainly been directed towards maintenance, i.e. minor adjustments. Regards, Stefan |
From: Grzegorz J. <sof...@ya...> - 2005-10-16 13:45:15
|
--- "Gilles J. Seguin" <se...@in...> wrote: > Grzegorz can i have the go ahead for a new release. Hi Gilles, Sure. Make it 2.9; if you are lucky things will just happen by themselves with 'make dist' :-) version number is in configure.in; I gave you release privledges, let me know if you need any more. Make sure you are properly credited in AUTHORS. Good luck Grzegorz > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Opencxx-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opencxx-users > __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ |
From: Grzegorz J. <sof...@ya...> - 2005-10-16 13:38:01
|
--- "Scott D. Fleming" <sd...@cs...> wrote: > Hi Maciek, > Your problem looks like one that I've reported (and suggested a patch > for) twice in recent history to the OpenC++ mailing list. I'm sure > the > maintainers will add a patch to the CVS repository and update the CVS > snapshots soon (hint hint). Here's a copy of my previous post: Scott, I am sorry, in the past few months I had very little resources to put into this. If you want to apply the patch yourself, go ahead (e-mail me if you need privledges). Guilles will be releasing 2.9 soon, ask him if he will be willing to sneak your contribution under this release. Even if not, take your time, apply the patch and we can release 2.10 then, even if it is soon after 2.9. BR Grzegorz > > There is a mistake in the grammar that OpenC++'s parser expects. > Prior > to GCC 3.4, this was never a problem, but since GCC 3.4, the STL > library > uses the syntax that the broken grammar doesn't accept. In > particular > OpenC++ expects template declarations to look like this: > > template<typename T>... > > With an identifier like "T" following typename, but in fact the > following is legal C++: > > template<typename>... > > This causes occ to issue errors whenever it parses the GCC library > files > that include the latter syntax (e.g., bits/cpp_type_traits.h). I > fixed > the problem by changing the Parser::rTempArgDeclaration member > function > definition in parser/Parser.cc. I changed this line (roughly the > third > line in the function): > > if(t0 == CLASS && lex->LookAhead(1) == Identifier){ > > To this: > > if(t0 == CLASS && !(lex->LookAhead(1) == Identifier)){ > lex->GetToken(tk1); > decl = PtreeUtil::List(new Leaf(tk1)); > } > else if(t0 == CLASS && lex->LookAhead(1) == Identifier){ > > I am not positive that my Ptree representation for the template > argument > declaration (temp.arg.declaration) is exactly what the OpenC++ > maintainers would want, but it seemed to make sense to me. > > Cheers, Scott > > > On 10/13/05, Maciej Leks <Mac...@be...> wrote: > > Hi All, > > > > I've made the latest version of OpenC++ based on the snapshot given > by > > some of this list expert on Cygwin 1.5.18-1 (gcc 3.4.4.). > > > > Then, I was trying to compile one of the example that is injected > with the > > distribution, as follows: > > > > $ occ2 BeforeClass.mc > > occ2: command failed: /usr/local/bin/occ --private--external-driver > -E > > <BeforeClass.ii --private--output BeforeClass.occ.tmp > > 2>BeforeClass.feedback > > > > ..and the content of the BeforeClass.feedback is: > > > > $ cat BeforeClass.feedback > > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/cpp_type_traits.h:83: > > parse error before `>' > > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/cpp_type_traits.h:90: > > parse error before `template' > > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/cpp_type_traits.h:102: > > parse error before `>' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_tree.h:72: > parse > > error before `std' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:66: > parse > > error before `std' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:119: > parse > > error before `typedef' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:126: > parse > > error before `typedef' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:624: > parse > > error before `template' > > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_multimap.h:66: > > parse error before `std' > > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/char_traits.h:49: > parse > > error before `__gnu_cxx' > > > > The same output I get when I try to use other examples. > > > > Any suggestion? > > > > Best Rgds, > > Maciek Leks > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: > > Power Architecture Resource Center: Free content, downloads, > discussions, > > and more. http://solutions.newsforge.com/ibmarch.tmpl > > _______________________________________________ > > Opencxx-users mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opencxx-users > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Opencxx-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opencxx-users > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Grzegorz J. <sof...@ya...> - 2005-10-16 13:33:34
|
--- Stefan Seefeld <se...@sy...> wrote: > Jonathan Gdalevich wrote: > > Dear OpenC++ users, > > > > While trying to learn and using OpenC++, I noticed that most of the > > available documentation is severely outdated. For example, the > tutorial > > pdf has been created in 1996 while the command reference on > sourceforge > > still uses occ instead of occ2. I am in the process of writing > some > > documentation for the project that I am working on and was > wondering if > > anyone out there created any APIs, documents, examples, makefiles, > or > > anything else that could prove helpful to a person trying to learn > > OpenC++. > > Knowing what you want to do with OpenC++ would be helpful when trying > to answer your questions. > While The OpenC++ code has been adjusted to compile with modern > compilers, > not much energy has been put into development. Many people contributed their time into making the code better and what you say is clear depreciation of their contributions. It is strange, because you were a contributor too. BR Grzegorz > As a consequence, the > original > documentation (user's guide, reference) is still largely accurate. > > You may want to browse the mailing list archive to learn more about > the project / status. > > Regards, > Stefan > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Opencxx-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opencxx-users > __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ |
From: Grzegorz J. <sof...@ya...> - 2005-10-16 13:19:33
|
--- Jonathan Gdalevich <gt...@ma...> wrote: > Dear OpenC++ users, > > I am in the process of writing some > documentation for the project Cool. > that I am working on and was wondering > if > anyone out there created any APIs, documents, examples, makefiles, or > anything else that could prove helpful to a person trying to learn > OpenC++. Let me grep my disk and get back to you on that. BR Grzegorz > If you could send them to me, I could combine and summarize > everything into a help file that can be posted on this newsgroup, the > OpenC++ website and maybe included in the next release. > > Sincerely, > > -- > Jonathan Gdalevich > Georgia Institute of Technology, Atlanta Georgia, 30332 > Email: gt...@pr... > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Opencxx-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opencxx-users > __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ |
From: Maciej L. <Mac...@be...> - 2005-10-14 21:39:25
|
> Stefan wrote: > Could you please post the actual code which occ complains about ? (Just > the surrounding lines will probably do.) > > Chances are indeed that occ is getting to its limits with modern C++ > code (such as the type traits). > > The problem stems from occ being a 'context-free' parser, > when the actual C++ grammar is not context-free. Specifically, a > conformant > parser has to consider a symbol's type when it attemps to decide on > a particular production. Depending on whether a given symbol corresponds > to a variable, type, or template, the token stream is interpreted > differently > (expression or type-id ? relational-expression or template-id ? Etc.) > > As occ builds its symbol table only after the parsing stage is over, it > has to rely on heuristics, which sometimes fail. > > I have been able to work with a (slightly enhanced) form of the OpenC++ > parser class for some time, but as I'm now trying to parse template-heavy > code, even my version fails. > In the context of the synopsis project (http://synopsis.fresco.org) I > have thus started to rewrite the Parser class from scratch. > Thanks to all for rescue me :) Scott are right it is a problem with template parameter identifier, i.e. the error message I’ve attached in the first post: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/cpp_type_traits.h:83: parse error before `>' points at: // Compare for equality of type template<typename, typename> I’ve made change in Parser.cc file as Scott wrote, and now it’s working well. At least I can start working with OpenC++ :) P.S. It’s worth taking Scott’s patch and make a new snapshot. Sincerely, Maciek Leks |
From: Scott D. F. <sd...@ms...> - 2005-10-14 18:26:26
|
If you do produce a new release, *please* see that the problem described below is corrected in it. I believe it affects enough users to justify making it a priority. Many thanks, Scott There is a mistake in the grammar that OpenC++'s parser expects. Prior to GCC 3.4, this was never a problem, but since GCC 3.4, the STL library uses the syntax that the broken grammar doesn't accept. In particular OpenC++ expects template declarations to look like this: template<typename T>... With an identifier like "T" following typename, but in fact the following is legal C++: template<typename>... This causes occ to issue errors whenever it parses the GCC library files that include the latter syntax (e.g., bits/cpp_type_traits.h). I fixed the problem by changing the Parser::rTempArgDeclaration member function definition in parser/Parser.cc. I changed this line (roughly the third line in the function): if(t0 =3D=3D CLASS && lex->LookAhead(1) =3D=3D Identifier){ To this: if(t0 =3D=3D CLASS && !(lex->LookAhead(1) =3D=3D Identifier)){ lex->GetToken(tk1); decl =3D PtreeUtil::List(new Leaf(tk1)); } else if(t0 =3D=3D CLASS && lex->LookAhead(1) =3D=3D Identifier){ I am not positive that my Ptree representation for the template argument declaration (temp.arg.declaration) is exactly what the OpenC++ maintainers would want, but it seemed to make sense to me. On 10/14/05, Gilles J. Seguin <se...@in...> wrote: > > Grzegorz can i have the go ahead for a new release. > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Opencxx-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opencxx-users > |
From: <se...@in...> - 2005-10-14 17:08:29
|
Grzegorz can i have the go ahead for a new release. |
From: Stefan S. <se...@sy...> - 2005-10-13 20:23:13
|
Maciej Leks wrote: > Hi All, > > I’ve made the latest version of OpenC++ based on the snapshot given by > some of this list expert on Cygwin 1.5.18-1 (gcc 3.4.4.). > > Then, I was trying to compile one of the example that is injected with > the distribution, as follows: > > $ occ2 BeforeClass.mc > occ2: command failed: /usr/local/bin/occ --private--external-driver -E > <BeforeClass.ii --private--output BeforeClass.occ.tmp > 2>BeforeClass.feedback > > ..and the content of the BeforeClass.feedback is: Could you please post the actual code which occ complains about ? (Just the surrounding lines will probably do.) Chances are indeed that occ is getting to its limits with modern C++ code (such as the type traits). The problem stems from occ being a 'context-free' parser, when the actual C++ grammar is not context-free. Specifically, a conformant parser has to consider a symbol's type when it attemps to decide on a particular production. Depending on whether a given symbol corresponds to a variable, type, or template, the token stream is interpreted differently (expression or type-id ? relational-expression or template-id ? Etc.) As occ builds its symbol table only after the parsing stage is over, it has to rely on heuristics, which sometimes fail. I have been able to work with a (slightly enhanced) form of the OpenC++ parser class for some time, but as I'm now trying to parse template-heavy code, even my version fails. In the context of the synopsis project (http://synopsis.fresco.org) I have thus started to rewrite the Parser class from scratch. Regards, Stefan |
From: Scott D. F. <sd...@cs...> - 2005-10-13 20:07:07
|
Hi Maciek, Your problem looks like one that I've reported (and suggested a patch for) twice in recent history to the OpenC++ mailing list. I'm sure the maintainers will add a patch to the CVS repository and update the CVS snapshots soon (hint hint). Here's a copy of my previous post: There is a mistake in the grammar that OpenC++'s parser expects. Prior to GCC 3.4, this was never a problem, but since GCC 3.4, the STL library uses the syntax that the broken grammar doesn't accept. In particular OpenC++ expects template declarations to look like this: template<typename T>... With an identifier like "T" following typename, but in fact the following is legal C++: template<typename>... This causes occ to issue errors whenever it parses the GCC library files that include the latter syntax (e.g., bits/cpp_type_traits.h). I fixed the problem by changing the Parser::rTempArgDeclaration member function definition in parser/Parser.cc. I changed this line (roughly the third line in the function): if(t0 =3D=3D CLASS && lex->LookAhead(1) =3D=3D Identifier){ To this: if(t0 =3D=3D CLASS && !(lex->LookAhead(1) =3D=3D Identifier)){ lex->GetToken(tk1); decl =3D PtreeUtil::List(new Leaf(tk1)); } else if(t0 =3D=3D CLASS && lex->LookAhead(1) =3D=3D Identifier){ I am not positive that my Ptree representation for the template argument declaration (temp.arg.declaration) is exactly what the OpenC++ maintainers would want, but it seemed to make sense to me. Cheers, Scott On 10/13/05, Maciej Leks <Mac...@be...> wrote: > Hi All, > > I've made the latest version of OpenC++ based on the snapshot given by > some of this list expert on Cygwin 1.5.18-1 (gcc 3.4.4.). > > Then, I was trying to compile one of the example that is injected with th= e > distribution, as follows: > > $ occ2 BeforeClass.mc > occ2: command failed: /usr/local/bin/occ --private--external-driver -E > <BeforeClass.ii --private--output BeforeClass.occ.tmp > 2>BeforeClass.feedback > > ..and the content of the BeforeClass.feedback is: > > $ cat BeforeClass.feedback > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/cpp_type_traits.h:83: > parse error before `>' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/cpp_type_traits.h:90: > parse error before `template' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/cpp_type_traits.h:102: > parse error before `>' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_tree.h:72: parse > error before `std' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:66: parse > error before `std' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:119: parse > error before `typedef' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:126: parse > error before `typedef' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:624: parse > error before `template' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_multimap.h:66: > parse error before `std' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/char_traits.h:49: pars= e > error before `__gnu_cxx' > > The same output I get when I try to use other examples. > > Any suggestion? > > Best Rgds, > Maciek Leks > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Opencxx-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opencxx-users > |
From: Jonathan G. <gt...@ma...> - 2005-10-13 20:00:58
|
Maciej Leks wrote: > Hi All, > > I=E2=80=99ve made the latest version of OpenC++ based on the snapshot g= iven > by some of this list expert on Cygwin 1.5.18-1 (gcc 3.4.4.). > > Then, I was trying to compile one of the example that is injected with > the distribution, as follows: > > $ occ2 BeforeClass.mc > occ2: command failed: /usr/local/bin/occ --private--external-driver > -E <BeforeClass.ii --private--output BeforeClass.occ.tmp=20 > 2>BeforeClass.feedback > > ..and the content of the BeforeClass.feedback is: > > $ cat BeforeClass.feedback > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/cpp_type_traits.h:83= :=20 > parse error before `>' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/cpp_type_traits.h:90= :=20 > parse error before `template' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/cpp_type_traits.h:10= 2:=20 > parse error before `>' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_tree.h:72: > parse error before `std' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:66: > parse error before `std' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:119: > parse error before `typedef' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:126: > parse error before `typedef' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:624: > parse error before `template' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_multimap.h:66:=20 > parse error before `std' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/char_traits.h:49: > parse error before `__gnu_cxx' > > The same output I get when I try to use other examples. > > Any suggestion? > > Best Rgds, > Maciek Leks > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussion= s, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Opencxx-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opencxx-users > Hi, I used the following commands to run the before example: occ2 ./BeforeClass.mc -o BeforeClass.exe ./BeforeClass.exe -- -g -o before-test ./before-test.cc Try them to see if they work or on which one the failure occures. Sincerely, Jonathan Gdalevich Georgia Institute of Technology, Atlanta Georgia, 30332 Email: gt...@pr... |
From: Maciej L. <Mac...@be...> - 2005-10-13 19:46:26
|
Hi All, I’ve made the latest version of OpenC++ based on the snapshot given by some of this list expert on Cygwin 1.5.18-1 (gcc 3.4.4.). Then, I was trying to compile one of the example that is injected with the distribution, as follows: $ occ2 BeforeClass.mc occ2: command failed: /usr/local/bin/occ --private--external-driver -E <BeforeClass.ii --private--output BeforeClass.occ.tmp 2>BeforeClass.feedback ..and the content of the BeforeClass.feedback is: $ cat BeforeClass.feedback /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/cpp_type_traits.h:83: parse error before `>' /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/cpp_type_traits.h:90: parse error before `template' /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/cpp_type_traits.h:102: parse error before `>' /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_tree.h:72: parse error before `std' /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:66: parse error before `std' /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:119: parse error before `typedef' /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:126: parse error before `typedef' /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_map.h:624: parse error before `template' /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_multimap.h:66: parse error before `std' /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/char_traits.h:49: parse error before `__gnu_cxx' The same output I get when I try to use other examples. Any suggestion? Best Rgds, Maciek Leks |
From: Jonathan G. <gt...@ma...> - 2005-10-13 16:32:31
|
Stefan Seefeld wrote: > Knowing what you want to do with OpenC++ would be helpful when trying > to answer your questions. > While The OpenC++ code has been adjusted to compile with modern > compilers, > not much energy has been put into development. As a consequence, the > original > documentation (user's guide, reference) is still largely accurate. > > You may want to browse the mailing list archive to learn more about > the project / status. > > Regards, > Stefan > Thanks for the reply, I am working on implementing a constraint guarantee system based on OCL. I already have one using C++ templates and want to write one with OpenC++ to compare the approaches. Part of the project involves writing documentation like how OpenC++ can be used (to generate mediators, to add code, to create wrappers). I am sure someone else out there had to do something similar. By combining various documents and examples, I hope that to create a package which anyone can use. Sincerely, Jonathan Gdalevich Georgia Institute of Technology, Atlanta Georgia, 30332 Email: gt...@pr... |
From: Stefan S. <se...@sy...> - 2005-10-13 11:55:36
|
Jonathan Gdalevich wrote: > Dear OpenC++ users, > > While trying to learn and using OpenC++, I noticed that most of the > available documentation is severely outdated. For example, the tutorial > pdf has been created in 1996 while the command reference on sourceforge > still uses occ instead of occ2. I am in the process of writing some > documentation for the project that I am working on and was wondering if > anyone out there created any APIs, documents, examples, makefiles, or > anything else that could prove helpful to a person trying to learn > OpenC++. Knowing what you want to do with OpenC++ would be helpful when trying to answer your questions. While The OpenC++ code has been adjusted to compile with modern compilers, not much energy has been put into development. As a consequence, the original documentation (user's guide, reference) is still largely accurate. You may want to browse the mailing list archive to learn more about the project / status. Regards, Stefan |
From: Jonathan G. <gt...@ma...> - 2005-10-13 04:24:12
|
Dear OpenC++ users, While trying to learn and using OpenC++, I noticed that most of the available documentation is severely outdated. For example, the tutorial pdf has been created in 1996 while the command reference on sourceforge still uses occ instead of occ2. I am in the process of writing some documentation for the project that I am working on and was wondering if anyone out there created any APIs, documents, examples, makefiles, or anything else that could prove helpful to a person trying to learn OpenC++. If you could send them to me, I could combine and summarize everything into a help file that can be posted on this newsgroup, the OpenC++ website and maybe included in the next release. Sincerely, -- Jonathan Gdalevich Georgia Institute of Technology, Atlanta Georgia, 30332 Email: gt...@pr... |