Menu
▾
▴
opencxx-users
|
From: skaller <sk...@us...> - 2006-07-18 17:53:00
|
All the tests fail on my system (Ubuntu Dapper amd64), apparently due to problems with libtool: Date: Wed Jul 19 03:37:27 EST 2006 User: skaller Host: x86_64-unknown-linux-gnu Testing comp/tnested/compilation ... + cd testsuite.dir/comp/tnested/compilation + /home/skaller/opencxx/opencxx-2.8/occ2 /home/skaller/opencxx/opencxx-2.8/testsuite/comp/tnested-class.mc -o tnested-class occ2: command failed: libtool -dlopen /home/skaller/opencxx/opencxx-2.8/opencxx/libocc_mop.la --mode=execute /home/skaller/opencxx/opencxx-2.8/occ --private--external-driver -E <tnested-class.ii --private--output tnested-class.occ.tmp 2>tnested-class.feedback FAIL: comp/tnested/compilation -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net |
|
From: Grzegorz J. <sof...@ya...> - 2006-07-20 12:04:29
|
--- skaller <sk...@us...> wrote: > All the tests fail on my system (Ubuntu Dapper amd64), > apparently due to problems with libtool: > > Date: Wed Jul 19 03:37:27 EST 2006 > User: skaller > Host: x86_64-unknown-linux-gnu > > Testing comp/tnested/compilation ... > + cd testsuite.dir/comp/tnested/compilation > + /home/skaller/opencxx/opencxx-2.8/occ2 > /home/skaller/opencxx/opencxx-2.8/testsuite/comp/tnested-class.mc -o > tnested-class > occ2: command failed: libtool > -dlopen /home/skaller/opencxx/opencxx-2.8/opencxx/libocc_mop.la > --mode=execute /home/skaller/opencxx/opencxx-2.8/occ > --private--external-driver -E <tnested-class.ii --private--output > tnested-class.occ.tmp 2>tnested-class.feedback > FAIL: comp/tnested/compilation Run the failing command by hand and/or inspect tnested-class.feedback to see the error message. BR Grzegorz > > -- > John Skaller <skaller at users dot sf dot net> > Felix, successor to C++: http://felix.sf.net > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > 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: skaller <sk...@us...> - 2006-07-20 14:33:05
|
On Thu, 2006-07-20 at 05:04 -0700, Grzegorz Jakacki wrote: > > FAIL: comp/tnested/compilation > > Run the failing command by hand and/or inspect tnested-class.feedback > to see the error message. I have. I've been informed by John Meacham that in fact the bug is in the test case, not the library. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net |
|
From: Grzegorz J. <sof...@ya...> - 2006-07-21 15:22:46
|
--- skaller <sk...@us...> wrote: > On Thu, 2006-07-20 at 05:04 -0700, Grzegorz Jakacki wrote: > > > > FAIL: comp/tnested/compilation > > > > Run the failing command by hand and/or inspect > tnested-class.feedback > > to see the error message. > > I have. I've been informed by John Meacham that in fact the > bug is in the test case, not the library. Could you guys send a patch? BR Grzegorz __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: skaller <sk...@us...> - 2006-07-21 15:58:20
|
On Fri, 2006-07-21 at 08:22 -0700, Grzegorz Jakacki wrote: > > --- skaller <sk...@us...> wrote: > > > On Thu, 2006-07-20 at 05:04 -0700, Grzegorz Jakacki wrote: > > > > > > FAIL: comp/tnested/compilation > > > > > > Run the failing command by hand and/or inspect > > tnested-class.feedback > > > to see the error message. > > > > I have. I've been informed by John Meacham that in fact the > > bug is in the test case, not the library. > > Could you guys send a patch? Aw, I think I'm confused. The bug John reported to me was in Judy not openC++, sorry .. sigh. I get this: tnested-class.feedback: /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c ++/4.0.3/bits/cpp_type_traits.h:116: parse error before `>' /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c ++/4.0.3/bits/cpp_type_traits.h:121: parse error before `template' /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c ++/4.0.3/bits/cpp_type_traits.h:131: parse error before `>' /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c ++/4.0.3/bits/stl_iterator_base_types.h:69: parse error before `std' /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c ++/4.0.3/bits/stl_iterator_base_funcs.h:70: parse error before `std' /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c ++/4.0.3/bits/stl_iterator_base_funcs.h:81: parse error before `__first' /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c ++/4.0.3/bits/stl_iterator_base_funcs.h:84: parse error before `;' /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c ++/4.0.3/bits/stl_iterator_base_funcs.h:86: parse error before `__n' /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c ++/4.0.3/bits/stl_iterator_base_funcs.h:89: parse error before `<' /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c ++/4.0.3/bits/stl_iterator_base_funcs.h:112: parse error before `<' occ: too many errors I really have no idea what's going on. I tried a couple of the examples from the tutorial and they failed with libtool problems. Don't have a record of that and can't find the examples now .. the instructions are buried somewhere in one of pdf files. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net |
|
From: Grzegorz J. <sof...@ya...> - 2006-07-24 13:51:17
|
This is a problem with template parsing in OpenC++. No easy fix at the moment, sorry. BR Greg --- skaller <sk...@us...> wrote: > On Fri, 2006-07-21 at 08:22 -0700, Grzegorz Jakacki wrote: > > > > --- skaller <sk...@us...> wrote: > > > > > On Thu, 2006-07-20 at 05:04 -0700, Grzegorz Jakacki wrote: > > > > > > > > FAIL: comp/tnested/compilation > > > > > > > > Run the failing command by hand and/or inspect > > > tnested-class.feedback > > > > to see the error message. > > > > > > I have. I've been informed by John Meacham that in fact the > > > bug is in the test case, not the library. > > > > Could you guys send a patch? > > Aw, I think I'm confused. The bug John reported to me > was in Judy not openC++, sorry .. sigh. > > I get this: > > tnested-class.feedback: > > /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c > ++/4.0.3/bits/cpp_type_traits.h:116: parse error before `>' > /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c > ++/4.0.3/bits/cpp_type_traits.h:121: parse error before `template' > /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c > ++/4.0.3/bits/cpp_type_traits.h:131: parse error before `>' > /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c > ++/4.0.3/bits/stl_iterator_base_types.h:69: parse error before `std' > /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c > ++/4.0.3/bits/stl_iterator_base_funcs.h:70: parse error before `std' > /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c > ++/4.0.3/bits/stl_iterator_base_funcs.h:81: parse error before > `__first' > /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c > ++/4.0.3/bits/stl_iterator_base_funcs.h:84: parse error before `;' > /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c > ++/4.0.3/bits/stl_iterator_base_funcs.h:86: parse error before `__n' > /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c > ++/4.0.3/bits/stl_iterator_base_funcs.h:89: parse error before `<' > /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c > ++/4.0.3/bits/stl_iterator_base_funcs.h:112: parse error before `<' > occ: too many errors > > I really have no idea what's going on. I tried a couple of > the examples from the tutorial and they failed with libtool > problems. Don't have a record of that and can't find the > examples now .. the instructions are buried somewhere in > one of pdf files. > > -- > John Skaller <skaller at users dot sf dot net> > Felix, successor to C++: http://felix.sf.net > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Stefan S. <se...@sy...> - 2006-07-24 14:14:03
|
Grzegorz Jakacki wrote: > This is a problem with template parsing in OpenC++. No easy fix at the > moment, sorry. As some readers here know, this quite fundamental limitation of the OpenC++ parser has let me to rewrite the C++ parser / frontend from scratch as part of the Synopsis (http://synopsis.fresco.org) project. Since Synopsis started a couple of years ago from the same code base as OpenC++, its design is quite similar. (The first internal representation being built during parsing is a parse tree, for example.) The rewrite isn't complete yet, as there isn't any support for type analysis yet (which is required for correct parsing of non-trivial template declarations). However, since there hasn't been much development going on inside OpenC++ over the last couple of years, this may be a viable alternative for people interested into a free, iso-conformant C++ parser frontend. FWIW. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin... |
|
From: skaller <sk...@us...> - 2006-07-24 18:06:38
|
On Mon, 2006-07-24 at 10:13 -0400, Stefan Seefeld wrote: > Grzegorz Jakacki wrote: > > This is a problem with template parsing in OpenC++. No easy fix at the > > moment, sorry. > > As some readers here know, this quite fundamental limitation of the OpenC++ > parser has let me to rewrite the C++ parser / frontend from scratch as > part of the Synopsis (http://synopsis.fresco.org) project. > Since Synopsis started a couple of years ago from the same code base as > OpenC++, its design is quite similar. (The first internal representation > being built during parsing is a parse tree, for example.) > > The rewrite isn't complete yet, as there isn't any support for type analysis > yet (which is required for correct parsing of non-trivial template declarations). > However, since there hasn't been much development going on inside OpenC++ over the > last couple of years, this may be a viable alternative for people interested > into a free, iso-conformant C++ parser frontend. FWIW the Scott McPeak's Elsa, based on Elkhound, claims full ISO C++ conformance except for template templates. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net |
|
From: Stefan S. <se...@sy...> - 2006-07-24 18:15:17
|
skaller wrote: > On Mon, 2006-07-24 at 10:13 -0400, Stefan Seefeld wrote: >> Grzegorz Jakacki wrote: >>> This is a problem with template parsing in OpenC++. No easy fix at the >>> moment, sorry. >> As some readers here know, this quite fundamental limitation of the OpenC++ >> parser has let me to rewrite the C++ parser / frontend from scratch as >> part of the Synopsis (http://synopsis.fresco.org) project. >> Since Synopsis started a couple of years ago from the same code base as >> OpenC++, its design is quite similar. (The first internal representation >> being built during parsing is a parse tree, for example.) >> >> The rewrite isn't complete yet, as there isn't any support for type analysis >> yet (which is required for correct parsing of non-trivial template declarations). >> However, since there hasn't been much development going on inside OpenC++ over the >> last couple of years, this may be a viable alternative for people interested >> into a free, iso-conformant C++ parser frontend. > > FWIW the Scott McPeak's Elsa, based on Elkhound, claims > full ISO C++ conformance except for template templates. Right. Elsa uses some interesting alternative approach (retaining all possible parse subtrees until at a later stage of semantic analysis the wrong ones can be eliminated). However, Synopsis, given its history, shares with OpenC++ one particular feature: the input data are fully preserved, thus making it particularly easy to write a 'minimally intrusive' and non-lossy source-to-source translator, since, after local modifications are applied to the parse tree / buffer, the latter is reserialized to a file. With other parsers you would have to generate the new code from scratch. Of course, that may not be a feature you are particularly interested in. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin... |
|
From: skaller <sk...@us...> - 2006-07-24 18:39:11
|
On Mon, 2006-07-24 at 14:14 -0400, Stefan Seefeld wrote: > skaller wrote: > Right. Elsa uses some interesting alternative approach (retaining all possible > parse subtrees until at a later stage of semantic analysis the wrong ones can > be eliminated). Actually it prunes them as it goes, it applies a whole lot of nasty heuristics to try to prune branches ASAP. > However, Synopsis, given its history, shares with OpenC++ one particular feature: > the input data are fully preserved, thus making it particularly easy to write > a 'minimally intrusive' and non-lossy source-to-source translator, since, after > local modifications are applied to the parse tree / buffer, the latter is > reserialized to a file. In other words it generates an actual parse tree, rather than an abstract syntax tree? -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net |
|
From: Stefan S. <se...@sy...> - 2006-07-24 18:53:45
|
skaller wrote: > On Mon, 2006-07-24 at 14:14 -0400, Stefan Seefeld wrote: >> skaller wrote: > >> Right. Elsa uses some interesting alternative approach (retaining all possible >> parse subtrees until at a later stage of semantic analysis the wrong ones can >> be eliminated). > > Actually it prunes them as it goes, it applies a whole lot > of nasty heuristics to try to prune branches ASAP. Right, ASAP. Some disambiguation requires type analysis, and as this is done in a phase following parsing, the AST resulting from parsing still may contain alternatives (see http://www.cs.berkeley.edu/~smcpeak/elkhound/sources/elsa/doc/design.html#ast_build). >> However, Synopsis, given its history, shares with OpenC++ one particular feature: >> the input data are fully preserved, thus making it particularly easy to write >> a 'minimally intrusive' and non-lossy source-to-source translator, since, after >> local modifications are applied to the parse tree / buffer, the latter is >> reserialized to a file. > > In other words it generates an actual parse tree, rather than > an abstract syntax tree? Exactly. OpenC++ generates a parse tree, and does everything else in a secondary pass. However, it doesn't preserve alternatives resulting from ambiguous syntax, but rather uses some heuristics to 'guess' the right interpretation of the syntax... which may fail. Synopsis on the other hand does construct a symbol table during parsing, and thus can disambiguate on-the-fly (much like g++ actually). The result is still a parse tree (using a cleaned up and enhanced version of OpenC++'s own PTree design), and all higher level representations (such as AST) are then built by traversing the parse tree, symbol table, and type repository (once completed). Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin... |
|
From: <se...@in...> - 2006-07-25 14:04:08
|
On Mon, 2006-07-24 at 14:53 -0400, Stefan Seefeld wrote: > skaller wrote: > > On Mon, 2006-07-24 at 14:14 -0400, Stefan Seefeld wrote: > >> skaller wrote: > > [...] > > In other words it generates an actual parse tree, rather than > > an abstract syntax tree? the "rather" may mislead, the parse tree is an augmented AST. And further more, for C++, abstract syntax tree(AST) is kind of wrong. That is, as pointed out by stefan below, that the resulting AST received from a particular translation unit, can not be is representation without semantic analysis. Abstract semantic tree anyone. Let say also, that grammar for openc++ need a major refresh. I means, it is not the same as the one given in appendix A of the ISO standard. So it cost you more for changing or applying desired behaviors. > Exactly. OpenC++ generates a parse tree, and does everything else in a secondary > pass. However, it doesn't preserve alternatives resulting from ambiguous syntax, > but rather uses some heuristics to 'guess' the right interpretation of the syntax... > which may fail. > > Synopsis on the other hand does construct a symbol table during parsing, and thus > can disambiguate on-the-fly (much like g++ actually). > The result is still a parse tree (using a cleaned up and enhanced version of OpenC++'s > own PTree design), and all higher level representations (such as AST) are then built > by traversing the parse tree, symbol table, and type repository (once completed). > > Regards, > Stefan > |
|
From: Stefan S. <se...@sy...> - 2006-07-25 14:15:20
|
Gilles J. Seguin wrote:
> On Mon, 2006-07-24 at 14:53 -0400, Stefan Seefeld wrote:
>> skaller wrote:
>>> On Mon, 2006-07-24 at 14:14 -0400, Stefan Seefeld wrote:
>>>> skaller wrote:
> [...]
>>> In other words it generates an actual parse tree, rather than
>>> an abstract syntax tree?
>
> the "rather" may mislead, the parse tree is an augmented AST.
Well, considering how both representations are actually built,
I would phrase it differently. You don't generate a parse tree
from an AST by adding to it, but rather, you create an AST by
removing ('abstracting away') things from the parse tree.
The way I read the question concerns more the API useful to developers
who want to hook up to the representation(s) coming out of the parser.
So, tools that only return an AST aren't suitable for tasks where
you need access to a low level representation, as some relevant information
may already be destroyed.
Ideally, the tool can generate multiple representations, and let users
control the processing pipeline, and only build the representation required
for a particular task.
Regards,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
|
|
From: skaller <sk...@us...> - 2006-07-25 16:34:01
|
On Tue, 2006-07-25 at 10:14 -0400, Stefan Seefeld wrote:
> Gilles J. Seguin wrote:
> > On Mon, 2006-07-24 at 14:53 -0400, Stefan Seefeld wrote:
> >> skaller wrote:
> >>> On Mon, 2006-07-24 at 14:14 -0400, Stefan Seefeld wrote:
> >>>> skaller wrote:
> > [...]
> >>> In other words it generates an actual parse tree, rather than
> >>> an abstract syntax tree?
> >
> > the "rather" may mislead, the parse tree is an augmented AST.
>
> Well, considering how both representations are actually built,
> I would phrase it differently. You don't generate a parse tree
> from an AST by adding to it, but rather, you create an AST by
> removing ('abstracting away') things from the parse tree.
Of course I use the term AST loosely :) In theory it is a
representation in abstract syntax which has specific
mathematical properties which few production parser ASTs
actually have.
> Ideally, the tool can generate multiple representations, and let users
> control the processing pipeline, and only build the representation required
> for a particular task.
Of course this is very easy to do in functional language using
folds ..
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X