opencxx-users

Re: [Opencxx-users] Reverse-engineered architecture docs

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

Grzegorz Jakacki wrote:
> Hi,
> 
> I checked in my attempt at reverse-engineering docs of OpenC++ 
> architecture on the class level. The document is incomplete and most 
> likely in flux, since architecture is changing now, but at least it 
> describes status quo. Please review, fix, give feedback.
> 
> The docs are in opencxx/doc/architecture.html

wouldn't it be a good idea to publish these documents on the website ?

I'm working my way through the code as I'm cleaning up the 'synopsis branch'.
Also, our latest discussions with Chiba have helped me a lot to understand
the current approach...

Something that has to be discussed quite in detail for anybody to understand
the design of the parser (notably the Walker stuff) is the two-stage parsing
that is done, i.e. the Parser building up a preliminary parse tree and then
the Walker running over it creating the various 'Environments'. (Up to our
discussion a while ago I just couldn't figure out why the Walker modified
the ptree it was traversing. Now I see and understand that it needs to to
fill in the things the parser's first pass couldn't figure out yet.)

A simple example would help to illustrate this:

-----
struct Foo {};
void bar(const Foo &);
-----

creating a parse / syntax tree for this using occ is done in two steps:

* the first builds a preliminary ptree via Lexer -> Parser
* the second refines the ptree using the Walker to build an 'Environment'
   containing the declaration of 'Foo', which is needed to properly encode
   the name/type of 'bar' (in the first pass the parser has to *guess* some
   details about the function arguments, as no Environment object is available
   for it to inspect).

I hope this makes some sense...

Now, I believe it would be important to try to move this to a one-step
parse, i.e. integrate the Environment building into the parser such that
the parser can correctly deal with corner cases that used to be interpreted
incorrectly.

Regards,
		Stefan

[Opencxx-users] relationship between Encoding and Environment

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

hi there,

I see the 'Encoding' class using 'Environment'  in its
methods 'GetBaseName', 'GetBaseNameIfTemplate' and
'ResolveTypedefName'.

What do these methods do ? Why do they access the
Environment ?

Thanks,
		Stefan

PS: The signature of 'Encoding::GetBaseName' suggests
     that the Environment pointer is set to the environment
     containing the declaration of a given type. Is there
     any documentation I could look at to better understand
     what these methods really do ?

Re: [Opencxx-users] Re: [Synopsis-devel] The Array type

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

Gilles J. Seguin wrote:

> QMtest is a very god choice. QMtest is a general-purpose,
> cross-platform software testing tools. It also have a gui
> for creating, managing, and executing tests through a browser,
> provides support for parallel test execution.
> 
> The first goal will be to provide a 'make test' target, that
> is intended for developer, which increase the level of
> confidence that changes are not affecting others functionalities
> in an non intended way.  We will still provide a 'make check'
> target that is generally done after ./configure && 'make',
> to ensure functionality before performing 'make install'.
> 
> Stephan could you give me access to what you have already done.
> Or things, sorry for my English, that can be done now.

Have a look into synopsis. To run the tests just follow the
instructions in the toplevel README file (executing
'python setup.py test' will run qmtest underneath). The code
I wrote to customize qmtest to my needs is in the tests/classes

http://synopsis.fresco.org/viewsvn/synopsis-Synopsis/trunk/tests/classes/

I currently only test opencxx through its single python entry point
('occ.parse'). I'll add C++ API tests for the Buffer and Lexer classes
once I'v finished them.

> We need to discuss what needs to be part of opencxx or synopsis.
> And prioritization of work step.

The list in my last mail reflects my own priorities. Feel free to
help out.

Regards,
		Stefan

Re: [Opencxx-users] Re: [Synopsis-devel] The Array type

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

On Sun, 2004-08-01 at 14:17, Stefan Seefeld wrote:
> Hi Gilles,
> 
> Gilles J. Seguin wrote:

[...]

> > Next project in opencxx, increase test coverage.
> > Any idea are welcome.
> 
> I'm doing that inside synopsis right now, i.e. I'm adding
> tests to the opencxx backend inside synopsis. My tests are
> all organized using the qmtest framework (www.qmtest.com),
> and I offered Grzegorz to put something similar into place
> for his project.

QMtest is a very god choice. QMtest is a general-purpose,
cross-platform software testing tools. It also have a gui
for creating, managing, and executing tests through a browser,
provides support for parallel test execution.

The first goal will be to provide a 'make test' target, that
is intended for developer, which increase the level of
confidence that changes are not affecting others functionalities
in an non intended way.  We will still provide a 'make check'
target that is generally done after ./configure && 'make',
to ensure functionality before performing 'make install'.

Stephan could you give me access to what you have already done.
Or things, sorry for my English, that can be done now.

We need to discuss what needs to be part of opencxx or synopsis.
And prioritization of work step.

> That being said, I still hope (as you may know) that we can at some
> point merge both projects. Right now I'm doing most work on synopsis,
> offering from time to time to merge back fixes into the OpenC++ project.
> 
> > The main point of this email, how can I see the work that
> > you are doing on the C++ parser.
> > I have done 'svn checkout', so I have revision 1332.
> 
> I'm just starting my work on the backend. My plans are (in that order):
> 
> * rewrite some low level classes (Buffer, Lexer, basically)
> 
> * make the existing API more clean (const-correct, more typed, etc.)
> 
> * try to understand how the Parser needs to be changed in order to
>    correctly understand the tokens, i.e. build a correct parse tree / AST
>    (see recent posts on the opencxx list).
> 
> * build a true high-level AST API on top (no more Car() / Cdr() calls !)
> 
> * export that AST API publicly through C++ as well as python
> 
> * get rid of the occ executable, provide a python script instead (for
>    backward compatibility only)
> 
> * solidify the C++ / python APIs to let users build their domain-specific
>    applications either as python scripts or C++ programs
> 
> I realize this is a lot of work. I'm not sure what the timeframe is to get
> all of this done. I'v almost finished the first point (the Buffer is committed,
> the Lexer will follow one of these days).
> If you are interested in getting involved, let me know.
> 
> Kind regards,
> 		Stefan

[Opencxx-users] Re: [Synopsis-devel] The Array type

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

Hi Gilles,

Gilles J. Seguin wrote:
> On Fri, 2004-07-30 at 22:09, Stefan Seefeld wrote:
> 
>>Thanks. In fact, I'm working on the C++ parser right now,
>>to be able to expose a much more rich AST to python to allow
>>real code inspection and following that code generation.
>>Drop in if you have ideas or even want to help :-)
> 
> 
> Hello Stefan,
> 
> First a little introduction.
> I have offered Grzegorz Jakacki, from the opencxx project
> to update the configuration of opencxx.  That step is done.
> The change are visible on the branch rel_2_8.
> Grzegorz is targetting third week of august for releasing 2.8 .

yeah, I know :-)

> Next project in opencxx, increase test coverage.
> Any idea are welcome.

I'm doing that inside synopsis right now, i.e. I'm adding tests
to the opencxx backend inside synopsis. My tests are all organized
using the qmtest framework (www.qmtest.com), and I offered Grzegorz
to put something similar into place for his project.
That being said, I still hope (as you may know) that we can at some
point merge both projects. Right now I'm doing most work on synopsis,
offering from time to time to merge back fixes into the OpenC++ project.

> The main point of this email, how can I see the work that
> you are doing on the C++ parser.
> I have done 'svn checkout', so I have revision 1332.

I'm just starting my work on the backend. My plans are (in that order):

* rewrite some low level classes (Buffer, Lexer, basically)

* make the existing API more clean (const-correct, more typed, etc.)

* try to understand how the Parser needs to be changed in order to
   correctly understand the tokens, i.e. build a correct parse tree / AST
   (see recent posts on the opencxx list).

* build a true high-level AST API on top (no more Car() / Cdr() calls !)

* export that AST API publicly through C++ as well as python

* get rid of the occ executable, provide a python script instead (for
   backward compatibility only)

* solidify the C++ / python APIs to let users build their domain-specific
   applications either as python scripts or C++ programs

I realize this is a lot of work. I'm not sure what the timeframe is to get
all of this done. I'v almost finished the first point (the Buffer is committed,
the Lexer will follow one of these days).
If you are interested in getting involved, let me know.

Kind regards,
		Stefan

[Opencxx-users] little Lexer bug parsing __extension__ token

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

hi there,

I just run into a little bug in the Lexer:
the SkipExtensionToken pretends to ignore
'__extension__ (...)' statements. However,
it really ignores __extension__ if *not*
followed by '(', and else ignores the
parens (with everything in between) and
reports '__extension__' as an identifier !

However, I'm not exactly sure what to do about
it, as I have not found any specs on the gcc site
about where __extension__ tokens can be found.

Gaby ?

Regards,
		Stefan

[Opencxx-users] Absent on-line Jul 30th - Aug 9th

[Grzegorz J. <ja...@ac...>]

Hi,

I will not be accessing my e-mail from Jul 30th afternoon through Aug 9th.

Gilles works in rel_2_8 branch, if you want to commit there, please 
contact him. BTW: Gilles working with Dmitry made huge contribution 
towards getting Cygwin build to work and generally cleaned lots of small 
imprefections in the build system. Big thanks!

The (aggressive) target for 2.8 is mid-August.

Best regards
Grzegorz

Re: [Opencxx-users] parse error on valid code

[Shigeru C. <ch...@is...>]

From: Gabriel Dos Reis <gd...@in...>
Subject: Re: [Opencxx-users] parse error on valid code
Date: 27 Jul 2004 13:20:13 +0200

> | So my solution when I wrote OpenC++ was to write a LL(k) parser, which
> | is a LL parser that may perform backtracking.  Then, since LL(k)
> | parser is really powerful, a LL(k) parser does not need to maintain a
> | type-name table for parsing the C++ grammar at that time.  That's why
> | the OpenC++ parser does not maintain a type-name table.
> 
> Pardon my ignorance, but:  Did you really handle full C++ (at the
> time), or a specific subset.  The reason I'm asking is that if you do
> not know which names are type-names, e.g.
> 
>     f(a);
> 
> ?

The answer depends on what a parser should do. :)

The OpenC++ parser accepts the statement above as a correct program
but never gives the semantics of that statement since it does not
know whether or not f is a type name.  ClassWalker traverses on a syntax
tree to maintain a type-name table and give the semantics to statements.

So maybe I should say the OpenC++ parser is not a complete parser.  It
accepts not only correct C++ programs but also some wrong ones and
produces a syntax tree.  Error messages for the wrong programs are
reported by ClassWalker etc (at the next stage).

The grammar dealt with by the OpenC++ parser is a bit looser than the
correct(?) one.  But I think the border between syntax and semantics
is ambiguous at least from the implementation viewpoint.

Chiba

Re: [Opencxx-users] parse error on valid code

[Gabriel D. R. <gd...@in...>]

Shigeru Chiba <ch...@is...> writes:

| No, my point is not an issue of OO design.  It is of parsing algorithm.
| 
| Since the parser of OpenC++ is LL(k) --- a backtracking parser ---,
| the token analyzer allows the parser to look up several tokens in
| advance.  The parser can read several tokens and rewind back to
| several tokens before.  If the rewinding happens, maybe TypeResolver
| must also discard some recorded type names to distinguish duplicated
| type declarations from revisited type declarations.  Therefore,
| TypeResolver must work with not only Parser but also TokenAnalyzer.
| 
| I'm now remembering my desing decision.  GCC used a LR(1) parser,
| i.e. bison parser (I don't know whether or not gcc3 still uses bison).

All GCC-3.x.y, x < 4, do.  GCC-3.4.x use a handwirtten recursive
descent parser.

| However, I didn't think that LR(1) is appropriate for C++ or that C++
| grammar can be parsed by a pure LR(1) parser.  As we are talking now,

Agreed.  That is extensively discussed in "Design and Evolution of C++".

| a C++ parser based on LR(1) needs a table of type names.  However,

I think even a LL(k) parser needs such thing.

| writing a LR(1) grammar that can maintain such a type-name table is a
| really messy job.  So, as far as I remember, the parser of GCC does
| not do this job but the token analyzer of GCC does although the code
| of the token analyzer of GCC is still complicated.
| 
| So my solution when I wrote OpenC++ was to write a LL(k) parser, which
| is a LL parser that may perform backtracking.  Then, since LL(k)
| parser is really powerful, a LL(k) parser does not need to maintain a
| type-name table for parsing the C++ grammar at that time.  That's why
| the OpenC++ parser does not maintain a type-name table.

Pardon my ignorance, but:  Did you really handle full C++ (at the
time), or a specific subset.  The reason I'm asking is that if you do
not know which names are type-names, e.g.

    f(a);

?

| Now, almost 10 years have been passed.  Sure, a LL(k) parser needs a
| type-name table for parsing the current grammar of C++.  So I agree to
| implement a type-name table but please note that the OpenC++ parser
| may backtrack.  So the type-name table must be aware of that
| backtracking.

-- Gaby

Re: [Opencxx-users] parse error on valid code

[Shigeru C. <ch...@is...>]

From: Stefan Seefeld <se...@sy...>
Subject: Re: [Opencxx-users] parse error on valid code
Date: Mon, 26 Jul 2004 19:00:12 -0400

> > Since the parser of OpenC++ is LL(k) --- a backtracking parser ---,
> > the token analyzer allows the parser to look up several tokens in
> > advance.  The parser can read several tokens and rewind back to
> > several tokens before.  If the rewinding happens, maybe TypeResolver
> > must also discard some recorded type names to distinguish duplicated
> > type declarations from revisited type declarations.  Therefore,
> > TypeResolver must work with not only Parser but also TokenAnalyzer.
> 
> I thought that new types would only be registered to the TypeResolver
> when the parser can confirm that what it is looking at is indeed a type,
> and not an expression. That would mean that while arbitrary 'look ahead' is
> required, tokens wouldn't be consumed until all ambiguities are resolved
> for the current token sequence, and thus, all type instantiations are
> final.

Yes, in theory!  But due to the complexity of the C++ grammar, the
OpenC++ parser sometime backtracks in a complex way.  So please be
careful although I don't think it's difficult.

> By the way: what is a TokenAnalyzer ? How is it related to Lexer and Parser ?

Ah, I mean Lexer.

> > I'm now remembering my desing decision.  GCC used a LR(1) parser,
> > i.e. bison parser (I don't know whether or not gcc3 still uses bison).
> 
> no, gcc 3.4 has a completely (manually) rewritten parser for C++.

I see.  I don't know today's fashion but using a bison/yacc for
writing a compiler such as gcc 2 (not 3!) was a right decison untill
mid 1990s, in which the C++ grammar had been extended beyond LR(1).

Chiba

[Opencxx-users] ptree design question

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

hi there,

now that I freed my mind for some opencxx refactoring,
I'm looking more closely at the actual API(s).
I think a good start is to make the API a little more
const-correct, and generally work with as much type information
as is available at any given point.
Thusly I run into the following function:

Ptree* Nconc(Ptree* p, Ptree* q)
{
     if(p == 0)
	return q;
     else{
	Last(p)->SetCdr(q);
	return p;
     }
}

This is a merge of two ptrees into one, appending
'q' at the end of 'p'. That looks fine, until you
realize that a Ptree can be either a leaf or a non-leaf,
so the question is what the 'SetCdr' method will do to
a leaf. It can't just change the ptree's type, as that
is fixed in the C++ type.
Thus, is it a programmer mistake to call SetCdr on
a leaf ? Should the object assert its non-leaf-ness ?

Regards,
		Stefan

Re: [Opencxx-users] parse error on valid code

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

Shigeru Chiba wrote:
> No, my point is not an issue of OO design.  It is of parsing algorithm.
> 
> Since the parser of OpenC++ is LL(k) --- a backtracking parser ---,
> the token analyzer allows the parser to look up several tokens in
> advance.  The parser can read several tokens and rewind back to
> several tokens before.  If the rewinding happens, maybe TypeResolver
> must also discard some recorded type names to distinguish duplicated
> type declarations from revisited type declarations.  Therefore,
> TypeResolver must work with not only Parser but also TokenAnalyzer.

I thought that new types would only be registered to the TypeResolver
when the parser can confirm that what it is looking at is indeed a type,
and not an expression. That would mean that while arbitrary 'look ahead' is
required, tokens wouldn't be consumed until all ambiguities are resolved
for the current token sequence, and thus, all type instantiations are
final.

By the way: what is a TokenAnalyzer ? How is it related to Lexer and Parser ?

> I'm now remembering my desing decision.  GCC used a LR(1) parser,
> i.e. bison parser (I don't know whether or not gcc3 still uses bison).

no, gcc 3.4 has a completely (manually) rewritten parser for C++.

Regards,
		Stefan

Re: [OBORONA-SPAM] Re: [Opencxx-users] Cygwin problem

[Grzegorz J. <ja...@ac...>]

Hi,

Grigorenko Dmitriy wrote:
>>>>/bin/bash ./libtool --mode=link g++  -g -O2   -o libocc.la -rpath
>>>>/usr/local/lib  empty_libocc.lo opencxx/libocc_mop.la
> 
> libltdl/libltdl.la
> 
>>>>mkdir .libs
>>>>libtool: link: warning: undefined symbols not allowed in
> 
> i686-pc-cygwin
> 
>>>>shared libraries
>>>
>>>Is there a way to learn what undefined symbols are left??? (On Linux
>>>there is 'nm', I don't know how to do this on Cygwin.)
> 
> Here is the output:
> 
> Dima@home ~/opencxx.pch
> $ /bin/bash ./libtool  --mode=relink g++ -g -O2 -o libocc.la -rpath
> /home/Dima/
> opencxx.pch/testbed/lib empty_libocc.lo opencxx/libocc_mop.la
> libltdl/libltdl.la
> libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
> shared libraries
> ar cru .libs/libocc.a  empty_libocc.o
> ranlib .libs/libocc.a
> creating libocc.la
> (cd .libs && rm -f libocc.la && ln -s ../libocc.la libocc.la)
> 
> Dima@home ~/opencxx.pch
> $ ./libtool --help --mode=relink
> libtool: invalid operation mode `relink'
> Try `libtool --help' for more information.
> 
> Dima@home ~/opencxx.pch
> $ ./libtool --version
> ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.94 2004/04/10 16:27:27)
> 
> Copyright (C) 2003  Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> Which file do I have to check?
> As far as I understand, libocc.a is OK.

All .(l)o and .(l)a files on the linker command line.

> Dima@home ~/opencxx.pch
> $ cd .libs/
> 
> Dima@home ~/opencxx.pch/.libs
> $ nm libocc.a
> 
> empty_libocc.o:
> 00000000 b .bss
> 00000000 d .data
> 00000000 N .stab
> 00000000 N .stabstr
> 00000000 t .text
> 
> 
> 
>>>>Tests do not work :(. See tester2.log for more details.
>>>
>>>This I don't understand. Libtool says it cannot find configure.ac or
>>>configure.in. WHY??? Why on earth should it need these files???
>>>tester2.log shows the libtool command that failed. Could you check what
>>>happens if you just use this command on its own?
> 
> 
> I do not know why it is.
> 
> Dima@home ~/opencxx.pch/testsuite/testsuite.dir/comp/tnested/compilation
> $ libtool --tag=CXX --mode=compile --silent g++ -c tnested-class.2.ii -o
> tnested-class.lo
> libtool: Couldn't find configure.ac nor configure.in file

Looks like a bug in cygwin. Seemingly workaround is available, see:

     http://www.cygwin.com/ml/cygwin/2002-01/msg01040.html

BR
GJ

> 
> Dima@home ~/opencxx.pch/testsuite/testsuite.dir/comp/tnested/compilation
> $ libtool --version
> ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42)
> 
> Copyright (C) 2003  Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> --------------------------------------------------------
> ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54)
> --------------------------------------------------------
> This is libtool-wrapper, which will hand off execution
> to one of the two real versions listed above, depending
> on the contents of configure.in/configure.ac.  Since the
> wrapper was called from within a directory in which those
> files are not found, this generic 'version' message is
> displayed.
> 
> Dima@home ~/opencxx.pch/testsuite/testsuite.dir/comp/tnested/compilation
> $

Re: [Opencxx-users] parse error on valid code

[Shigeru C. <ch...@is...>]

No, my point is not an issue of OO design.  It is of parsing algorithm.

Since the parser of OpenC++ is LL(k) --- a backtracking parser ---,
the token analyzer allows the parser to look up several tokens in
advance.  The parser can read several tokens and rewind back to
several tokens before.  If the rewinding happens, maybe TypeResolver
must also discard some recorded type names to distinguish duplicated
type declarations from revisited type declarations.  Therefore,
TypeResolver must work with not only Parser but also TokenAnalyzer.

I'm now remembering my desing decision.  GCC used a LR(1) parser,
i.e. bison parser (I don't know whether or not gcc3 still uses bison).
However, I didn't think that LR(1) is appropriate for C++ or that C++
grammar can be parsed by a pure LR(1) parser.  As we are talking now,
a C++ parser based on LR(1) needs a table of type names.  However,
writing a LR(1) grammar that can maintain such a type-name table is a
really messy job.  So, as far as I remember, the parser of GCC does
not do this job but the token analyzer of GCC does although the code
of the token analyzer of GCC is still complicated.

So my solution when I wrote OpenC++ was to write a LL(k) parser, which
is a LL parser that may perform backtracking.  Then, since LL(k)
parser is really powerful, a LL(k) parser does not need to maintain a
type-name table for parsing the C++ grammar at that time.  That's why
the OpenC++ parser does not maintain a type-name table.

Now, almost 10 years have been passed.  Sure, a LL(k) parser needs a
type-name table for parsing the current grammar of C++.  So I agree to
implement a type-name table but please note that the OpenC++ parser
may backtrack.  So the type-name table must be aware of that
backtracking.

Chiba

From: Grzegorz Jakacki <ja...@ac...>
Subject: Re: [Opencxx-users] parse error on valid code
Date: Thu, 22 Jul 2004 07:41:13 +0800

> > So now I must say that I cannot remember why I chose the approach
> > currently used in OpenC++.  However, there should be some examples in
> > which the lexical analyzer must help the parser to record all the
> > declared type names etc.  Thus, as far as I remember, the code of the
> > lexical analyzer of gcc 2.x(?) was quite tangled with the code of the
> > parser.  I didn't like to make the OpenC++ code tangled.  Hope this info
> > helps you guys.  I think the parser needs to maintain the type name
> > table for completely supporting templates.
> 
> I think we can keep the OpenC++ parser clean with this design:
> 
>                  <<iface>>
> +--------+     +--------------+
> | Parser |---->| TypeResolver |
> +--------+     +--------------+
> 
> Where TypeResolver instance provides all the functionality requiring
> maintaining the type name table. Perhaps ClassWalker or Environment can
> be made an implementation of TypeResolver. That way code would stay not
> tangled (i.e. Parser still does not implement type name table, nor does
> it depend on concrete classes from the next layers, like Environment or
> ClassWalker).

Re: [OBORONA-SPAM] Re: [Opencxx-users] Cygwin problem

[Grigorenko D. <pos...@na...>]

Hi!

> > > /bin/bash ./libtool --mode=link g++  -g -O2   -o libocc.la -rpath
> > > /usr/local/lib  empty_libocc.lo opencxx/libocc_mop.la
libltdl/libltdl.la
> > > mkdir .libs
> > > libtool: link: warning: undefined symbols not allowed in
i686-pc-cygwin
> > > shared libraries
> >
> > Is there a way to learn what undefined symbols are left??? (On Linux
> > there is 'nm', I don't know how to do this on Cygwin.)
Here is the output:

Dima@home ~/opencxx.pch
$ /bin/bash ./libtool  --mode=relink g++ -g -O2 -o libocc.la -rpath
/home/Dima/
opencxx.pch/testbed/lib empty_libocc.lo opencxx/libocc_mop.la
libltdl/libltdl.la
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
shared libraries
ar cru .libs/libocc.a  empty_libocc.o
ranlib .libs/libocc.a
creating libocc.la
(cd .libs && rm -f libocc.la && ln -s ../libocc.la libocc.la)

Dima@home ~/opencxx.pch
$ ./libtool --help --mode=relink
libtool: invalid operation mode `relink'
Try `libtool --help' for more information.

Dima@home ~/opencxx.pch
$ ./libtool --version
ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.94 2004/04/10 16:27:27)

Copyright (C) 2003  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Which file do I have to check?
As far as I understand, libocc.a is OK.

Dima@home ~/opencxx.pch
$ cd .libs/

Dima@home ~/opencxx.pch/.libs
$ nm libocc.a

empty_libocc.o:
00000000 b .bss
00000000 d .data
00000000 N .stab
00000000 N .stabstr
00000000 t .text


> > > Tests do not work :(. See tester2.log for more details.
> >
> > This I don't understand. Libtool says it cannot find configure.ac or
> > configure.in. WHY??? Why on earth should it need these files???
> > tester2.log shows the libtool command that failed. Could you check what
> > happens if you just use this command on its own?

I do not know why it is.

Dima@home ~/opencxx.pch/testsuite/testsuite.dir/comp/tnested/compilation
$ libtool --tag=CXX --mode=compile --silent g++ -c tnested-class.2.ii -o
tnested-class.lo
libtool: Couldn't find configure.ac nor configure.in file

Dima@home ~/opencxx.pch/testsuite/testsuite.dir/comp/tnested/compilation
$ libtool --version
ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42)

Copyright (C) 2003  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--------------------------------------------------------
ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54)
--------------------------------------------------------
This is libtool-wrapper, which will hand off execution
to one of the two real versions listed above, depending
on the contents of configure.in/configure.ac.  Since the
wrapper was called from within a directory in which those
files are not found, this generic 'version' message is
displayed.

Dima@home ~/opencxx.pch/testsuite/testsuite.dir/comp/tnested/compilation
$

Re: [Opencxx-users] Cygwin problem

[Grigorenko D. <pos...@na...>]

Hi!

> Gilles renamed files in CVS already.
OK
I am waiting for anonymous CVS to see it.

> To avoid holding your changes/patches, could I add you to developers and
> ask that you commit this kind of changes to CVS yourself in the future?
> If you agree, please send me your SourceForge id.
I`m now sure I`ll do any changes in the future.
I think, it is useful in any case so my id is:
1090814

> > /bin/bash ./libtool --mode=link g++  -g -O2   -o libocc.la -rpath
> > /usr/local/lib  empty_libocc.lo opencxx/libocc_mop.la libltdl/libltdl.la
> > mkdir .libs
> > libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
> > shared libraries
>
> Is there a way to learn what undefined symbols are left??? (On Linux
> there is 'nm', I don't know how to do this on Cygwin.)
I`ll investigate.

>
> > Tests do not work :(. See tester2.log for more details.
>
> This I don't understand. Libtool says it cannot find configure.ac or
> configure.in. WHY??? Why on earth should it need these files???
> tester2.log shows the libtool command that failed. Could you check what
> happens if you just use this command on its own?
I`ll look for it after downloading the last CVS version.

>Are there any fixes that you introduced which are not in CVS yet?
No, there are not. I just renamed files.

Re: [Opencxx-users] Cygwin problem

[Grzegorz J. <ja...@ac...>]

Grigorenko Dmitriy wrote:
> Hi
> 
> 
>>the most stable thing is rel_2_8,
>>which is the next release.
> 
> OK
> I`ve investigated my cvs problems
> First of all, there is a problem with aux.* files. Some filenames (such are
> aux, com, prn, con) have the special meaning in DOS/Win OS, so they cannot
> be used for
> common files. Please, rename them.
> The second point is that Windows is not case sensitive. So ptree.h and
> Ptree.h are the same file. (member.h and Member.h have the same problem).

See my other reply (sent just a minute ago).

> The second problem is the following:
> $./bootstrap
> $./configure
> <..>
> configure: error: libgc not found; set up paths or --disable-gc

This is ok. Beginning with 2.8 libgc is not a part of OpenC++, it is an 
external library. If you want to use gc, you need to install it 
system-wide or in your home. In the latter case you have guarantee, that 
compiler/linker will be able to find libgc, one way is:

./configure CPPFLAGS=-I<dir_with_gc>/include LDFLAGS=-L<dir_with_gc>/lib

Alternatively, you can switch gc off:

./configure --disable-gc

> The logs of bootstrap (boot.log) and configure (cfg.log) are attached.
> The full configure log which --disable-gc option is attached (cfg2.log)
> 
> You can see that in all cases the configure gives the right answer about
> ltdl (as far as I understand).
> I cannot show you results of tests becouse I have to make a number of
> changes in the filenames.

That would be great to bring all the fixes into CVS.

> I`ll write about 'make tests' later.
> 
> There is no makefile.in in the script folder.
> http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/scripts/?only_with_tag
> =rel_2_8

Correct. Makefile is generated by ./configure, no need to keep it in CVS.

> There is no gc/Makefile
> http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/gc/?only_with_tag=rel_
> 2_8

gc directory should be all empty, which effectively means it does not 
exist any more. This is because libgc is no longer distributed as a part 
of OpenC++, starting from 2.8 it is an external dependency.

> 
> Is it correct?

Yes.

Best regards
Grzegorz

Re: [Opencxx-users] Cygwin problem

[Grzegorz J. <ja...@ac...>]

Hi!

Grigorenko Dmitriy wrote:
> Hello
> 
> I renamed ptree.h to ptree2.h and so on. 

Gilles renamed files in CVS already.

To avoid holding your changes/patches, could I add you to developers and 
ask that you commit this kind of changes to CVS yourself in the future? 
If you agree, please send me your SourceForge id.

> I cannot send you patch for it
> becouse I cannot represent the origin version on my FAT :-)

I see. AFAIK this is solved already (also 'aux').

> 
> I runned bootstrap. After this there is the configure params:
> ./configure --disable-gc --enable-ltdl-install --prefix=`pwd`/testbed 2>&1 |
> tee cfg.log
> 
> There were some warnings:
> In file included from /usr/include/c++/3.3.1/backward/strstream:51,
>                  from driver.cc:47:
> /usr/include/c++/3.3.1/backward/backward_warning.h:32:2: warning: #warning
> This
> file includes at least one deprecated or antiquated header. Please consider
> usin
> g one of the 32 headers found in section 17.4.1.2 of the C++ standard.
> Examples
> include substituting the <X> header for the <X.h> header for C++ includes,
> or <s
> stream> instead of the deprecated header <strstream.h>. To disable this
> warning
> use -Wno-deprecated.

This is just because of 'strstream'. Unfortunately, gcc-2.95  which is 
still widely used does not have 'sstream', so we either have to live 
with this warning, or provide our own, say, 'sstream-workaround.h' which 
will check if the compiler is gcc-2.95 and include 'strstream' or 
'sstream' respectively.

> 
> /bin/bash ./libtool --mode=link g++  -g -O2   -o libocc.la -rpath
> /usr/local/lib  empty_libocc.lo opencxx/libocc_mop.la libltdl/libltdl.la
> mkdir .libs
> libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
> shared libraries

Is there a way to learn what undefined symbols are left??? (On Linux 
there is 'nm', I don't know how to do this on Cygwin.)

> Tests do not work :(. See tester2.log for more details.

This I don't understand. Libtool says it cannot find configure.ac or 
configure.in. WHY??? Why on earth should it need these files??? 
tester2.log shows the libtool command that failed. Could you check what 
happens if you just use this command on its own?

> But occ does not crash with sigsegv signal!

This is definitely a progress!!!

Are there any fixes that you introduced which are not in CVS yet?

Thanks,

Grzegorz

Re: [Opencxx-users] Cygwin problem

[Grigorenko D. <pos...@na...>]

Hello

I renamed ptree.h to ptree2.h and so on. I cannot send you patch for it
becouse I cannot represent the origin version on my FAT :-)

I runned bootstrap. After this there is the configure params:
./configure --disable-gc --enable-ltdl-install --prefix=`pwd`/testbed 2>&1 |
tee cfg.log

There were some warnings:
In file included from /usr/include/c++/3.3.1/backward/strstream:51,
                 from driver.cc:47:
/usr/include/c++/3.3.1/backward/backward_warning.h:32:2: warning: #warning
This
file includes at least one deprecated or antiquated header. Please consider
usin
g one of the 32 headers found in section 17.4.1.2 of the C++ standard.
Examples
include substituting the <X> header for the <X.h> header for C++ includes,
or <s
stream> instead of the deprecated header <strstream.h>. To disable this
warning
use -Wno-deprecated.

/bin/bash ./libtool --mode=link g++  -g -O2   -o libocc.la -rpath
/usr/local/lib  empty_libocc.lo opencxx/libocc_mop.la libltdl/libltdl.la
mkdir .libs
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
shared libraries

Tests do not work :(. See tester2.log for more details.
But occ does not crash with sigsegv signal!

Re: [Opencxx-users] Cygwin problem

[Grigorenko D. <pos...@na...>]

Hi

> the most stable thing is rel_2_8,
> which is the next release.
OK
I`ve investigated my cvs problems
First of all, there is a problem with aux.* files. Some filenames (such are
aux, com, prn, con) have the special meaning in DOS/Win OS, so they cannot
be used for
common files. Please, rename them.
The second point is that Windows is not case sensitive. So ptree.h and
Ptree.h are the same file. (member.h and Member.h have the same problem).

The second problem is the following:
$./bootstrap
$./configure
<..>
configure: error: libgc not found; set up paths or --disable-gc

The logs of bootstrap (boot.log) and configure (cfg.log) are attached.
The full configure log which --disable-gc option is attached (cfg2.log)

You can see that in all cases the configure gives the right answer about
ltdl (as far as I understand).
I cannot show you results of tests becouse I have to make a number of
changes in the filenames.
I`ll write about 'make tests' later.

There is no makefile.in in the script folder.
http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/scripts/?only_with_tag
=rel_2_8
There is no gc/Makefile
http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/gc/?only_with_tag=rel_
2_8

Is it correct?

Re: [Opencxx-users] Cygwin problem

[Grzegorz J. <ja...@ac...>]

Grigorenko Dmitriy wrote:
> Hello
> 
> 
>>Dmitriy can you make some tests,
> 
> OK
> 
> 
>>in config.log, you have
>>configure:2886: checking for main in -lltdl
>>configure:2911: gcc -o conftest.exe -g -O2   conftest.c -lltdl   >&5
>>/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld:
>>cannot find -lltdl
>>collect2: ld returned 1 exit status
>>configure:2914: $? = 1
>>configure: failed program was:
>>
>>we want this to pass, saying 'yes'.
> 
> I`he downloaded the head of cvs and tried ./configure
> The result is in the simple_cfg.log.
> As you can see the answer is 'yes' now.
> When I type 'make', I get an error message becouse there is no Makefile in
> gc directory (so it does not know how to build target 'all'). Why is it so?

I suspect that you don't have exact copy of CVS. I am not sure which 
branch you are using (MAIN or rel_2_8), but neither of them contains 
directory 'gc' anymore. Perhaps you need to do 'cvs update -C -P'.

> 
> 
>>can you try to change configure.in, adding AC_LIBTOOL_WIN32_DLL,
>>you will have,
>>
>>AC_DISABLE_SHARED
>>AC_LIBTOOL_WIN32_DLL
>>AM_PROG_LIBTOOL
>>
>>then
>>
>>libtoolize --force --automake --copy
>>./bootstrap
>>./configure --disable-gc # save compile time
> 
> I`ve done it (and I`ve undated my libtool up to 1.5.6)
> As you can see,
> checking dependency style of gcc... gcc3
> checking for lt_dlinit in -lltdl... yes
> (no checking for main in -lltdl)

That's correct, since libltdl shouldn't normally contain main. (I know 
that you need main on cygwin, but this is workaround for a bug.)

> Also there two new warnings:
> configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: dlfcn.h: proceeding with the compiler's result
> 
> Next step I tried to run make tests and got:
> In file included from ../opencxx/parser/Ptree.h:37,
>                  from ../opencxx/Class.h:37,
>                  from ChangedMemberList.cc:36:
> ../opencxx/parser/PtreeUtil.h:34:32: opencxx/parser/aux.h: No such file or
> direc
> tory
> make[2]: *** [ChangedMemberList.lo] Error 1
> 
> It is right. There is no aux.h in the opencxx/parser. Why is it so?
> 

Again, I think you are not in sync with CVS. Viewcvs shows that both 
rel_2_8 and MAIN contain parser/aux.h

http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/opencxx/parser/aux.h?rev=1.2.2.1&only_with_tag=rel_2_8&view=log
http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/opencxx/parser/aux.h?rev=1.2&only_with_tag=MAIN&view=log

BR
Grzegorz

> The result of 'cvn up' command is following:
> cvs update: move away opencxx/member.h; it is in the way
> C opencxx/member.h
> cvs update: Updating opencxx/dll-off
> cvs update: Updating opencxx/gc-related-gc-no
> cvs update: Updating opencxx/gc-related-gc-yes
> cvs update: Updating opencxx/gc-related-gc-yes/dll-off
> cvs update: Updating opencxx/gc-related-gc-yes/dll-on
> cvs update: Updating opencxx/parser
> cvs update: move away opencxx/parser/aux.cc; it is in the way
> C opencxx/parser/aux.cc
> cvs update: move away opencxx/parser/aux.h; it is in the way
> C opencxx/parser/aux.h
> cvs update: move away opencxx/parser/ptree.h; it is in the way
> C opencxx/parser/ptree.h
> cvs update: Updating opencxx/ptree
> cvs update: Updating opencxx/ptree/src
> 
> How can I download these files?
> 
> Thank you

Re: [Opencxx-users] Cygwin problem

[Grigorenko D. <pos...@na...>]

Hello

> Dmitriy can you make some tests,
OK

> in config.log, you have
> configure:2886: checking for main in -lltdl
> configure:2911: gcc -o conftest.exe -g -O2   conftest.c -lltdl   >&5
> /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld:
> cannot find -lltdl
> collect2: ld returned 1 exit status
> configure:2914: $? = 1
> configure: failed program was:
>
> we want this to pass, saying 'yes'.
I`he downloaded the head of cvs and tried ./configure
The result is in the simple_cfg.log.
As you can see the answer is 'yes' now.
When I type 'make', I get an error message becouse there is no Makefile in
gc directory (so it does not know how to build target 'all'). Why is it so?

> can you try to change configure.in, adding AC_LIBTOOL_WIN32_DLL,
> you will have,
>
> AC_DISABLE_SHARED
> AC_LIBTOOL_WIN32_DLL
> AM_PROG_LIBTOOL
>
> then
>
> libtoolize --force --automake --copy
> ./bootstrap
> ./configure --disable-gc # save compile time
I`ve done it (and I`ve undated my libtool up to 1.5.6)
As you can see,
checking dependency style of gcc... gcc3
checking for lt_dlinit in -lltdl... yes
(no checking for main in -lltdl)
Also there two new warnings:
configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: dlfcn.h: proceeding with the compiler's result

Next step I tried to run make tests and got:
In file included from ../opencxx/parser/Ptree.h:37,
                 from ../opencxx/Class.h:37,
                 from ChangedMemberList.cc:36:
../opencxx/parser/PtreeUtil.h:34:32: opencxx/parser/aux.h: No such file or
direc
tory
make[2]: *** [ChangedMemberList.lo] Error 1

It is right. There is no aux.h in the opencxx/parser. Why is it so?

The result of 'cvn up' command is following:
cvs update: move away opencxx/member.h; it is in the way
C opencxx/member.h
cvs update: Updating opencxx/dll-off
cvs update: Updating opencxx/gc-related-gc-no
cvs update: Updating opencxx/gc-related-gc-yes
cvs update: Updating opencxx/gc-related-gc-yes/dll-off
cvs update: Updating opencxx/gc-related-gc-yes/dll-on
cvs update: Updating opencxx/parser
cvs update: move away opencxx/parser/aux.cc; it is in the way
C opencxx/parser/aux.cc
cvs update: move away opencxx/parser/aux.h; it is in the way
C opencxx/parser/aux.h
cvs update: move away opencxx/parser/ptree.h; it is in the way
C opencxx/parser/ptree.h
cvs update: Updating opencxx/ptree
cvs update: Updating opencxx/ptree/src

How can I download these files?

Thank you

Re: [Opencxx-users] Adding new function statatements

[Grzegorz J. <ja...@ac...>]

Hi,

It seems to me that when you only insert new code, then the original 
code should stay untouched. OpenC++ will also generate #line directives 
around the inserted code, so that line number information is correct.
They are missing in your sample. Could you post the code which you use 
to insert the statement?

BR
Grzegorz

Raphael Yokoingawa de Camargo wrote:
> Hi, 
> 
> I am writing a C++ precompiler to modify an application to automatically save
> its state periodically. For doing this, I need to insert new statements in
> function bodies. The problem i am encountering is how to insert these new
> statements. In the first version of this precompiler I am using the command
> Ptree::Make. The problem of using this command, is that all the original
> statements after the insert ones appear on the same line, and not on different
> lines as before. For example:
> 
> ckp_save_stack_data("temp.dat"); // Added by the precompiler
> printf ( "testInt    =   1: %d\n" , testInt ) ; printf ( "testDouble = 2.1:
> %f\n" , testDouble ) ; ckp_npop_data(5);
> 
> The modifications are being done at the function ClassWalker::TranslateBlock.
> Does anyone know how to solve this?
> 
> Thanks,
> Raphael
> 
> 
> Raphael Yokoingawa de Camargo <rca...@im...>
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] OpenCXX and Windows

[Grzegorz J. <ja...@ac...>]

Luke Petre wrote:
> Do any of the releases of opencxx build and run on windows?  I'm using 
> Windows XP with Visual C++ 7.1.  I also have the latest version of 
> cygwin installed.

Win+Cygwin has been reported to work after minor modifications. 
Moredetails you can find in mailing list archive, look for postings from 
Dmitri Grigorenko and Gilles Seguin. Gilles is currently applying his 
patches (Cygwin fixes) in rel_2_8 branch, they are going to be merged 
into trunk after 2.8 is out.

Win+MSVC perhaps requires a little bit more tweaking. Most likely your 
problems are either due to libgc or libltdl. My understanding is that to 
be able to run under MSVC you need to get rid of dependencies on 
libltdl. If you don't need plugins (and most likely you don't) it should 
be easy to do. Some time ago Asen Kovachev was struggling on XP+MSVC and 
he succeede as far as I remember. The changes have not been checked in, 
however.

> I've tried building opencxx-2.7 using cygwin.  I've added the main() to 
> lbtl.c to get lbtl to link but I can't run the occ.exe executable 
> without it crashing.

Yes, pls. refere to the archives, exactly the same symptoms.

> I've also tried building from the head of the CVS tree but configure 
> doesn't even run.

Could you post the output of configure and content of config.log ?

> 
> Suggestions?  Should I try an earlier release?

Not recommended. Let's move forward, not backward :-)

BR
Grzegorz

Re: [Opencxx-users] Reverse-engineered architecture docs

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

Grzegorz Jakacki wrote:
> Hi,
> 
> I checked in my attempt at reverse-engineering docs of OpenC++ 
> architecture on the class level. The document is incomplete and most 
> likely in flux, since architecture is changing now, but at least it 
> describes status quo. Please review, fix, give feedback.
> 
> The docs are in opencxx/doc/architecture.html

nice work, thanks a lot !

Stefan