opencxx-users

Re: [Opencxx-users] test build failure: Ubuntu Dapper Amd64/libtool

[Stefan S. <se...@sy...>]

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...

Re: [Opencxx-users] test build failure: Ubuntu Dapper Amd64/libtool

[<se...@in...>]

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
> 

Re: [Opencxx-users] test build failure: Ubuntu Dapper Amd64/libtool

[Stefan S. <se...@sy...>]

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...

Re: [Opencxx-users] test build failure: Ubuntu Dapper Amd64/libtool

[skaller <sk...@us...>]

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

Re: [Opencxx-users] test build failure: Ubuntu Dapper Amd64/libtool

[Stefan S. <se...@sy...>]

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...

Re: [Opencxx-users] test build failure: Ubuntu Dapper Amd64/libtool

[skaller <sk...@us...>]

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

Re: [Opencxx-users] test build failure: Ubuntu Dapper Amd64/libtool

[Stefan S. <se...@sy...>]

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...

Re: [Opencxx-users] test build failure: Ubuntu Dapper Amd64/libtool

[Grzegorz J. <sof...@ya...>]

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 

Re: [Opencxx-users] test build failure: Ubuntu Dapper Amd64/libtool

[skaller <sk...@us...>]

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

Re: [Opencxx-users] test build failure: Ubuntu Dapper Amd64/libtool

[Grzegorz J. <sof...@ya...>]

--- 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 

Re: [Opencxx-users] test build failure: Ubuntu Dapper Amd64/libtool

[skaller <sk...@us...>]

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

Re: [Opencxx-users] test build failure: Ubuntu Dapper Amd64/libtool

[Grzegorz J. <sof...@ya...>]

--- 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 

[Opencxx-users] test build failure: Ubuntu Dapper Amd64/libtool

[skaller <sk...@us...>]

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

[Opencxx-users] opencxx and templates

[<sa...@we...>]

Hello all,

I am wondering if someone already used opencxx with template classes, if it works, and what I should do additionally to avoid the "parsing error" that I always get for the moment, and which refers to the line "template<class T>" in the source code... I tried to follow the advices in the appendix but I may be doing sth wrong because it doesn't help.

Thanks a lot,
Sam
______________________________________________________________________
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!		
Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130

Re: [Opencxx-users] libtool error with gcc3.3

[<se...@in...>]

On Mon, 2006-06-26 at 11:42 +0200, sa...@we... wrote:
> Hello,
> 
> I could install opencxx-2.8 successfully on my computer using gcc-3.3, but I still cannot run occ2. Trying the basic example:
> occ2 VerboseClass.mc -o VerboseClass.exe

can we see result of
occ2 --verbose VerboseClass.mc -o VerboseClass.exe

result from using a build directory
$ ../../occ2 --verbose ../../../opencxx29/examples/verbose/VerboseClass.mc -o VerboseClass
occ2: preproc1: g++ -E -x c++ -D__opencxx -I/home1/p0/opencxx/build/../opencxx29 -I/home1/p0/opencxx/build -I/usr/include ../../../opencxx29/examples/verbose/VerboseClass.mc -o VerboseClass.ii
occ2: parse-and-translate: libtool -dlopen /home1/p0/opencxx/build/opencxx/libocc_mop.la --mode=execute /home1/p0/opencxx/build/occ --private--external-driver -E <VerboseClass.ii --private--output VerboseClass.occ.tmp 2>VerboseClass.feedback
occ2: parse-and-translate: mv VerboseClass.occ.tmp VerboseClass.occ
occ2: preproc2: cp VerboseClass.occ VerboseClass.2.ii
occ2: compile: libtool --tag=CXX --mode=compile g++ -c VerboseClass.2.ii -o VerboseClass.lo
 g++ -c VerboseClass.2.ii  -fPIC -DPIC -o .libs/VerboseClass.o
 g++ -c VerboseClass.2.ii -o VerboseClass.o >/dev/null 2>&1
occ2: linking: libtool --tag=CXX --mode=link g++ VerboseClass.lo -L/home1/p0/opencxx/build -L/usr/lib -locc -o VerboseClass
g++ .libs/VerboseClass.o -o .libs/VerboseClass  -L/home1/p0/opencxx/build -L/usr/lib /home1/p0/opencxx/build/.libs/libocc.so /usr/lib/libltdl.so -ldl
creating VerboseClass

can you try also,
from the directory where you build the package,
$ make check
or
$ cd testsuite
$ make check   # not sure here, can be only make

result should be
$ make check
./tester2
Testing comp/tnested/compilation ...
PASS: comp/tnested/compilation
Directory not empty
Testing comp/tstart/compilation ...
PASS: comp/tstart/compilation
Testing comp/typeidv/compilation ...
PASS: comp/typeidv/compilation
Testing comp/typeidt/compilation ...
PASS: comp/typeidt/compilation
Testing exec/before/execution ...
PASS: exec/before/execution
Testing exec/parse1/execution ...
PASS: exec/parse1/execution
Testing exec/verbose/execution ...
PASS: exec/verbose/execution
Testing exec/verbose2/execution ...
PASS: exec/verbose2/execution
Testing comp/tnested/compilation-via-plugin ...
PASS: comp/tnested/compilation-via-plugin
Testing comp/tstart/compilation-via-plugin ...
PASS: comp/tstart/compilation-via-plugin
Testing comp/typeidv/compilation-via-plugin ...
PASS: comp/typeidv/compilation-via-plugin
Testing comp/typeidt/compilation-via-plugin ...
PASS: comp/typeidt/compilation-via-plugin
==============================================================
    PASSes : 12
    SKIPs  : 0
    FAILs  : 0
    -------------------
    total  : 12

Detailed info has been logged in `tester2.log'
sed 's:\(@\)abs_top_builddir\(@
\):/home1/p0/opencxx/build/testsuite/../.:g'
<../../opencxx29/testsuite/occ2-test.in >occ2-test.tmp
chmod +x occ2-test.tmp
mv occ2-test.tmp occ2-test
./occ2-test
occ2-test: minus_Wt ...
occ2-test: minus_Wt PASS
occ2-test: minus_Wt_and_minus_S ...
occ2-test: minus_Wt_and_minus_S PASS
occ2-test: minus_Wt_and_minus_p ...
occ2-test: minus_Wt_and_minus_p PASS
occ2-test: minus_Wt_and_minus_p_and_minus_S ...
occ2-test: minus_Wt_and_minus_p_and_minus_S PASS
occ2-test: minus_Wl ...
occ2-test: minus_Wl PASS
occ2-test: minus_Wc ...
occ2-test: minus_Wc PASS
occ2-test: minus_Wp_and_minus_P ...
occ2-test: minus_Wp_and_minus_P PASS
occ2-test: minus_Wp1 ...
occ2-test: minus_Wp1 PASS
occ2-test: minus_Wp2 ...
occ2-test: minus_Wp2 PASS
occ2-test: minus_Wp ...
occ2-test: minus_Wp PASS
occ2-test: minus_L_and_minus_l ...
occ2-test: minus_L_and_minus_l PASS
occ2-test: translation_with_plugin ...
occ2-test: translation_with_plugin PASS
occ2-test: include_dirs_and_minus_P ...
occ2-test: include_dirs_and_minus_P PASS
occ2-test: include_dirs ...
occ2-test: include_dirs PASS
occ2-test: minus_P ...
occ2-test: minus_P PASS
occ2-test: minus_c ...
occ2-test: minus_c PASS
occ2-test: minus_E ...
occ2-test: minus_E PASS
occ2-test: minus_p ...
occ2-test: minus_p PASS
occ2-test: minus_n_lo_extension ...
occ2-test: minus_n_lo_extension PASS
occ2-test: minus_n ...
occ2-test: minus_n PASS
occ2-test: standard_path_lo_extension ...
occ2-test: standard_path_lo_extension PASS
occ2-test: standard_path_occ_extension ...
occ2-test: standard_path_occ_extension PASS
occ2-test: standard_path_ii_extension ...
occ2-test: standard_path_ii_extension PASS
occ2-test: standard_path_mc_extension ...
occ2-test: standard_path_mc_extension PASS
occ2-test: standard_path_cc_extension ...
occ2-test: standard_path_cc_extension PASS
echo PASS > unittests

> I get:
> libtool: unrecognized option `--tag=CXX'
> Try `libtool --help' for more information.
> occ2: command failed: libtool --tag=CXX --mode=compile --silent g++-3.3 -c VerboseClass.2.ii -o VerboseClass.lo

make no sense to me,
you should not have succeed to make the package,
because the libtool utility is used to compile every thing.

> My environment variables are set in my .bashrc in the following way: 
> export CC=gcc-3.3
> export CPP='gcc-3.3 -E'
> export CXX=g++-3.3
> export CXXCPP='g++-3.3 -E'
> 
> How can I solve this problem ? It's important for me to have it work so any clue and help would be appreciated...

Re: [Opencxx-users] ROSE AST

[Stefan S. <se...@sy...>]

Andreas Sæbjørnsen wrote:

>> Interesting. As you may have gathered from the online docs, Synopsis was
>> originally
>> designed as a more flexible and powerful alternative to doxygen.
>> However, over the years I realized that what I came up with has the
>> potential to do
>> quite a bit more. The 'AST' I originally designed (and which, I believe
>> should be
>> renamed as it doesn't have anything to do with syntax) is just one
>> particular
>> representation of the code. Another one is the parse tree (now available
>> as the C++
>> Synopsis::PTree namespace), which provides very fine-grained control over
>> the
>> code, inclusively formatting.
>> I hope that I will be able to reuse the 'processor pipeline' design
>> (http://synopsis.fresco.org/docs/Tutorial/pipeline.html) to not only
>> process the
>> AST, but in fact any representation synopsis is or will be able to
>> construct and
>> expose (call graphs come to mind).
> 
> 
> That is great! So if what you call an AST is not an Abstract Syntax Tree,
> does it have
> anything in common with an Abstract Syntax tree?

That depends on what 'Abstract Syntax Tree' stands for in a particular context.
I think the way it is presently used in synopsis is relatively common (though
we only represent declarations, not arbitrary statements, and no expressions either).

However, there really isn't anything related to syntax in this representation,
i.e. specific syntactic constructs are abstracted away (or else I wouldn't be able
to use the same representation for multiple languages syntactically as different
as python and C++).

So, may be 'Abstract Semantic Graph' would be a better description of what this
is about.

> Also I have a question
> regarding
> why you have chosen to work with a C++ parse tree as an intermediate
> representation
> instead of an Abstract Syntax Tree?

I simply follow a processing model where the first thing obtained from the
parser is a parse tree. That, together with a symbol table and some type
repository, can be processed into higher level representations such as
the AST that is presently at the heart of synopsis.

The parse tree is simply a different representation exposing much more
detail at a much lower level. There are tasks that are best done on
that low level, and others, which work better on a higher level.

The PTree is currently only available as a C++ API / representation,
but I plan to expose that to python (via boost.python) as soon as it
stabilizes sufficiently (and is complemented by the two other representations:
symbol table and type repository). In fact, some first draft of such a
python module is already in the snapshots, within the sandbox/ directory.

[...]

> The
> feature which we think separates us the most from other source-to-source
> translators
> is that we can do whole program analysis, e.g we can merge the ASTs of all
> the
> separate compilations in a program into one big AST.

Right, 'linking' different ASTs is done in synopsis, too, so it is straight
forward to generate a source code navigation tool that is able to link the
correct symbols across different source files.

> One notable feature of the PTree is that it is non-lossy, i.e. the leaf
>> nodes ('atoms')
>> point into a buffer, and so I'm able to serialize it again, using the
>> exact same
>> formatting as the original input file (I can even 'un-preprocess' the
>> code, since I
>> retain all macro expansion information from the preprocessor, which is
>> just another
>> processor generating part of a representation of the code).
> 
> 
> That is very interesting. Is this done by copying the lines from the
> original source file when
> you have not done any changes to the corresponding nodes in the AST? We are
> interested
> in the same kind of problems as we can not just expect to translate
> homebody's source code
> and them to just replace their source code with the output from ROSE.  In
> order to achieve
> this we are working on a copy unparser, which will only unparse the
> portions
> of the AST that
> we have changed and copy the rest from the original source-file. This
> enables us to diff the
> original source file and the translated output from ROSE in order to create
> a patch file. It is
> much more likely that people will be comfortable with a minimal patch-file
> rather than a whole
> source-file. We preserve preprocessor directives and comments by annotating
> the ROSE AST,
> but we still have some work to do in order to rewrap macro calls (replace
> expanded macros in
> the unparsed AST with the macro call). Have you addressed the problem with
> rewrapping macros,
> and if so how?

Right. Synopsis uses a 'Cpp' parser to preprocess source files. This processor
will not only preprocess the source file into some '.i' temporary file, but
it will record all macro definitions, macro calls, file inclusions, etc., etc.
(I currently use ucpp (http://pornin.nerim.net/ucpp/), and boost.wave
(http://www.boost.org/libs/wave/index.html) as possible Cpp backends.)

This information is available through the internal representation so later
processors in the pipeline can use it to 'un-preprocess' the file.
The actual C/C++ parser will read the (potentially preprocessed) file into
a memory buffer, and then generate parse tree nodes such that leaf nodes
point into that buffer (lexical tokens are actually tuples (type, pointer, length)).

Thus, modifying the source is best done by replacing a specific node in the parse
tree by some new code. These 'Replacements' are registered with the 'Buffer'
instance, so when writing it out into a source file the buffer iterator can
take care to generate the correct stream.

I have used that technique for example to generate a cross-referenced html-
formatted source view of the original source code.

> And finally, the original C++ parser was adapted from OpenC++, a project to
>> provide
>> some metaprogramming facilities (by embedding some extension language
>> into
>> the input,
>> which is detected by the parser). I think that with Synopsis I'm able to
>> provide alternate
>> techniques to generate custom source-to-source translators, for
>> example by
>> providing external
>> mapper scripts (to generate language bindings, say), or even embedd
>> processing instructions
>> into comments, which are then recognized by the parser and associated
>> with
>> the respective
>> nodes.
> 
> 
>> From what I remember the OpenC++ parser, atleast when I looked at it last
> time, was not able
> to parse all of C++ (I think there was some problems with e.g templates). I
> must admit though that
> my knowledge of this is spotty. Correct me if I am wrong, but from what I
> understand from our
> conversation this is something you have worked on. Do you have a list of
> improvements that you
> have done to OpenC++?

Unfortunately, no. Synopsis has started with a fork of OpenC++ about seven
years ago, and I have been applying various patches both to the lexer as well
as the parser over the years to fix or work around multiple issues.

However, there are a number of issues that can't be worked around with the
OpenC++ parser, as it still uses heuristics to guess whether some token
sequence is a 'name' or an expression (this becomes apparent with more
recent versions of g++, i.e. I think >= 3.4).
This is why I started last summer to rewrite the C++ parser from scratch.
The new implementation uses a technique very similar to gcc's new C++ frontend,
where (non-dependent) symbol lookup is done during the parsing to resolve all
ambiguities upfront. This required a new symbol table implementation, and
a new type repository (which is still very incomplete right now).

Once this rewrite is complete synopsis will be able to analyze things as complex as
partial template specializations, and correctly implement overload resolution.
There is still quite some way to go, though. :-)

>> I really think that the python language provides an ideal ground for this
>> kind
>> of introspection.
> 
> 
> That is something I would be very interested in discussing. First I am
> curious about
> your definition of the term introspection. If I interpret the term
> "introspection" as a way to
> specify patterns in the AST, we are  researching if this can be done
> with  a
> GLR parser generator like Elkhound. Basically we want to look
> for patterns in source code, security patterns, bug patterns for
> multi-threaded codes, poor use of MPI,
> or even poor programming practice patterns. Our research into how we can
> use
> Elkhound to achieve
> this goal is still in it's infancy though. How are you imagining the use of
> python to specify search
> patterns in the AST? We think that having a tool to specify search patterns
> in the AST would help
> us to:
>   * easier identify places in the AST where a translation should be
> performed
>   * enable all sorts of source code analysis which is now difficult to
> specify
>   * help us with the macro rewrap work

I'm not sure I understand where the actual parser framework (e.g. GLR) comes
into play here. Are you suggesting that some patterns you are looking for
should have a direct representation in the GLR grammar ?

The way I use 'introspection' is very generic: A means to analyze source
code, i.e. a set / layers of representations that can be used to search
for patterns, perform some actions (such as translation), etc.

I'm arguing in favor of python here because introspection typically involves
a number of steps to be performed in a specific workflow (a 'processor pipeline',
as I call it in synopsis). While the individual processors may be written in C++
or python, the wiring into a specific pipeline is easily done in little python
scripts, by means of a domain-specific language (just a subset of python) that
makes it easy to fine-tune the behavior of the tool.

There are other tools written for a more specific task in the same domain,
such as pyste or pyplusplus, which use python scripting to define language
bindings for C++ APIs to python APIs (using boost.python).
While these are currently still using gccxml as C++ frontend, I hope that
once the new C++ frontend is sufficiently complete, synopsis can offer similar
facilities.

Another domain this is useful in is source-to-source translation as originally
done by OpenC++ (see http://citeseer.ist.psu.edu/chiba95metaobject.html), or
nowadays AspectC++ (see http://www.aspectc.org/). These tools operate on an
augmented C++ grammar, i.e. the processing instructions are embedded right
into the source code language.

I believe it is easier to keep the target language and the language processing
instructions are expressed in separate, both, for the developer of the code,
as well as for the developer of the tool that is to translate it.

I have hopes that here, too, Synopsis could become useful.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

[Opencxx-users] libtool error with gcc3.3

[<sa...@we...>]

Hello,

I could install opencxx-2.8 successfully on my computer using gcc-3.3, but=
 I still cannot run occ2. Trying the basic example:
occ2 VerboseClass.mc -o VerboseClass.exe

I get:
libtool: unrecognized option `--tag=3DCXX'
Try `libtool --help' for more information.
occ2: command failed: libtool --tag=3DCXX --mode=3Dcompile --silent g++-3.3 -c=
 VerboseClass.2.ii -o VerboseClass.lo


My environment variables are set in my .bashrc in the following way:=20
export CC=3Dgcc-3.3
export CPP=3D'gcc-3.3 -E'
export CXX=3Dg++-3.3
export CXXCPP=3D'g++-3.3 -E'

How can I solve this problem =3F It's important for me to have it work so an=
y clue and help would be appreciated...

Thanks a lot,
Sam

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F
Mit WEB.DE iNews werden Sie =FCber die Ergebnisse der wichtigsten WM-Begegnu=
ngen
per SMS informiert: http://freemail.web.de/features/inews.htm/=3Fmc=3D021202

Re: [Opencxx-users] include directory not found

[Scott D. F. <sd...@ms...>]

Hi Sam,
1. If you installed the OpenC++ 2.8 standard release, you will
probably need to replace it with the latest CVS snapshot:
http://opencxx.sourceforge.net/snapshots/opencxx-20050912.tar.gz
As I recall, the -I flag along with some other stuff is broken in the
standard release.

2. I also recall OpenC++ (any version) being broken for GCC versions
later than 3.4.x. If you get errors parsing the standard C++
libraries, it will be a clue that you need to either hack OpenC++ or
use an earlier version of GCC.

3. I usually compile by doing something like this:

<prefix>/bin/occ2 -Wc,-Wall  -I. -I<prefix>/include -c Metaclass1.mc
-o Metaclass1.o
<prefix>/bin/occ2 -Wc,-Wall  -I. -I<prefix>/include -c Metaclass2.mc
-o Metaclass2.o
<prefix>/bin/occ2 -Wc,-Wall  -I. -I<prefix>/include -c Metaclass3.mc
-o Metaclass3.o
g++ -Wall -o my-compiler Metaclass1.o Metaclass2.o Metaclass3.o
-L<prefix>/lib -locc -lltdl

./my-compiler -I. -c -- -Wall MyClass1.cc
./my-compiler -I. -c -- -Wall MyClass2.cc
./my-compiler -I. -c -- -Wall MyClass3.cc
g++ -Wall -o my-program MyClass1.o MyClass2.o MyClass3.o

I hope this helps.
Cheers, Scott

[Opencxx-users] include directory not found

[<sa...@we...>]

Hi again,

Still , I have another problem...
How should I include the header files in my .mc files ? I used the --prefix option with configure to change the standard directory but when I execute the example:
occ -m -- -g VerboseClass.mc
Then I always get the error that "mop.h" or "opencxx/mop.h" or whatever I try to include is not found. However, there is mop.h in "{prefix}/include" and all the other include files (and mop.h again) in "{prefix}/include/opencxx". 

What am I doing wrong ? 

Thanks,
Sam

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

Re: [Opencxx-users] libltdl not found

[Scott D. F. <sd...@ms...>]

Hi Sam,
I believe you need to install the libltdl3-dev package.
Cheers, Scott


On 6/13/06, sa...@we... <sa...@we...> wrote:
> Hello,
>
> I am totally newbie and trying to configure opencxx-2.8 on a debian sarge and I get after running ./configure:
> configure: error: libltdl not found; verify that libtool package is installed
>
> The debian package libltdl3 is installed. on my computer
>
> What should I do ?
>
> Thanks,
> Sam
> ______________________________________________________________
> Verschicken Sie romantische, coole und witzige Bilder per SMS!
> Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
>
>
>
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>

Re: [Opencxx-users] [OBORONA-SPAM] libltdl not found

[Dmitriy <pos...@na...>]

On Tue, 13 Jun 2006 17:23:52 +0200
sa...@we... wrote:

> The debian package libltdl3 is installed. on my computer
> What should I do ?
Try to install libltdl3-dev

[Opencxx-users] libltdl not found

[<sa...@we...>]

Hello,

I am totally newbie and trying to configure opencxx-2.8 on a debian sarge and I get after running ./configure:
configure: error: libltdl not found; verify that libtool package is installed

The debian package libltdl3 is installed. on my computer

What should I do ?

Thanks,
Sam
______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

Re: [Opencxx-users] libtool and glibtool for OpenC++ on Mac 10.4.2 (Tiger)

[<se...@in...>]

On Mon, 2006-03-20 at 13:16 -0800, garaf garaf wrote:
> Hi,
> 
> I am trying to install the latest CVS snapshot of
> OpenC++ on Mac 10.4.2 (Tiger). I am facing the
> following problem: in Mac 10.4.2, libtool is different
> than the gnu libtool -which is called glibtool- 
> 
> All installation files in OpenC++ assumes that libtool
> is glibtool, which causes installation problems and
> errors.

The libtool utility is there to resolve incompatibility across
architecture, something wrong there.

if glibtool package is equivalent, solutions are
1) symlink the the thing
2) provide a mechanism to identify your architecture, for example
$ uname
will give "Linux", does that thing work
so that we can put more intelligence in the script.

> I changed every occurence of "libtool" in the file
> bootstrap with "glibtool" and it worked, but later on,
> when I tried to run occ2 it caused segmentation fault
> because it is again calling libtool thinking it is
> glibtool. 
> 
> I tried to change every occurence of every "libtool"
> in all OpenC++ files with "glibtool" but again this
> didn't work.
> 
> Anyone can help? 
> 
> Please let me know if OpenC++ can be installed on Mac
> 10.4.2, I have spent over a month trying to install it
> on my Mac with no success.
> 
> Thank you
> garaf

Re: [Opencxx-users] libtool and glibtool for OpenC++ on Mac 10.4.2 (Tiger)

[Scott D. F. <sd...@cs...>]

Hi Garaf,
As part of the OpenC++ build process, a libtool script is generated in
the build directory. You can simply copy this file into the bin
directory that occ and occ2 were installed in (make sure it's in your
PATH), and everything should work (hopefully). I previously used this
technique to get occ working on a Solaris machine that lacked libtool.
Good luck, Scott


On 3/20/06, garaf garaf <garaf_garaf@...> wrote:
> Hi,
>
> I am trying to install the latest CVS snapshot of
> OpenC++ on Mac 10.4.2 (Tiger). I am facing the
> following problem: in Mac 10.4.2, libtool is different
> than the gnu libtool -which is called glibtool-
>
> All installation files in OpenC++ assumes that libtool
> is glibtool, which causes installation problems and
> errors.
>
> I changed every occurence of "libtool" in the file
> bootstrap with "glibtool" and it worked, but later on,
> when I tried to run occ2 it caused segmentation fault
> because it is again calling libtool thinking it is
> glibtool.
>
> I tried to change every occurence of every "libtool"
> in all OpenC++ files with "glibtool" but again this
> didn't work.
>
> Anyone can help?
>
> Please let me know if OpenC++ can be installed on Mac
> 10.4.2, I have spent over a month trying to install it
> on my Mac with no success.
>
> Thank you
> garaf
>

Re: [Opencxx-users] libtool and glibtool for OpenC++ on Mac 10.4.2 (Tiger)

[Stefan S. <se...@sy...>]

garaf garaf wrote:
> Hi,
> 
> I am trying to install the latest CVS snapshot of
> OpenC++ on Mac 10.4.2 (Tiger). I am facing the
> following problem: in Mac 10.4.2, libtool is different
> than the gnu libtool -which is called glibtool- 
> 
> All installation files in OpenC++ assumes that libtool
> is glibtool, which causes installation problems and
> errors.

AFAICT, 'libtool' is a generated script in the build tree,
so it shouldn't matter whether your /usr/bin/libtool (or
wherever it lives) is compatible with the GNU version.

> I changed every occurence of "libtool" in the file
> bootstrap with "glibtool" and it worked, but later on,
> when I tried to run occ2 it caused segmentation fault
> because it is again calling libtool thinking it is
> glibtool. 
> 
> I tried to change every occurence of every "libtool"
> in all OpenC++ files with "glibtool" but again this
> didn't work.

I'm not sure. libtool seems to be used both during
occ's own compilation, as well as during compilation
*with* occ. In the latter case, occ2 appears to accept
a --libtool option with which to specify which libtool
script to use.

HTH,
		Stefan