opencxx-users

Re: [Opencxx-users] Makefile.am showing 'make test' does not require reconfiguring

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

Hi,

Wow, if it runs also on Darwin also, then it is really cool and much 
cleaner. I was under impression that libtool library has to be installed 
to be linked agains, but now I reread docs and it looks that indeed it 
does not, providing libtool is used for linking. However, I rememeber 
that Alex Tolmos had some problems with thin on Darwin, so I will not 
shout urray unless I see it running on this system.

The only issue I can see is that with this set-up there is no way to 
check if all necessary headers are installed. However AFAIU this should 
not be difficult to fix by adding a test to 'make installcheck'.

Thanks!
Grzegorz

Gilles J. Seguin wrote:
> Steps required to make install from tar file.
> $ ./configure
> $ make
> $ su -
> # make install
> 
> If we want to add verifications.
> $ ./configure
> $ make
> $ make check
> $ su -
> # make install
> 
> On my linux platform, Fedora Core 2
> the attach compress file 'Makefile.am.gz'
> allow to verify that present reconfiguration step is not
> necessary.
> 
> steps perform are:
> $ cvs -z3 co -rrel_2_8 opencxx
> $ cd opencxx
> $ ./bootstrap
> $ cd ..
> $ mkdir build
> $ cd build
> $ ../opencxx/configure -C \
>  --prefix=/usr \
>  --srcdir=../opencxx \
>  --disable-gc
> $ make
> $ make test
> $ su -
> # make install
> 
> This, demonstrate the mechanism that I will like to have for
> my system.
> 
> Comments ?
> 

[Opencxx-users] opencxx/sample for rel_2_8

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

opencxx/sample $ make -f Makefile.occ2 person
../src/occ -I../src -I../gc/include -- -g -o VerboseClass.exe
../tmplib/libocc.a -ldl ../tmplib/libgc.a  VerboseClass.mc
make: ../src/occ: Command not found
make: *** [VerboseClass.exe] Error 127

../src/occ must be ../occ
-I../src ??
-I../gc/include ?? gc is disable
../tmplib/libgc.a ?? gc is disable
../tmplib/libocc.a -ldl is 
	../../build/.libs/libocc.a
	../../build/opencxx/.libs/libocc_mop.a
	../../build/opencxx/.libs/libocc_parser.a -lltdl

we want this directory in the build directory

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

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

Stefan Seefeld wrote:
> hi there,
> 
> The following valid code doesn't parse with opencxx:
> 
> ---
> 
> template <typename T> void Foo();
> 
> void (*bar)() = &Foo<int>;
> 
> ---
> 
> I'll look into it, but in case someone else (Grzegorz, Chiba ?)
> has an idea, I'll send it to the list.

A little follow-up: after '&Foo' has been parsed, 'Parser::isTemplateArgs'
is been called. However, as the comment above that method indicates:

/*
   template.args : '<' any* '>'

   template.args must be followed by '(' or '::'
*/

which obviously doesn't account for this case where a function pointer
is passed, i.e. no terminating '('. Now I'm a bit lost. I guess the '('
constraint is used to disambigate from a relational expression, i.e. if
we drop it, we'll misinterpret other expressions. Could I simply add ';'
and ',' to the list of symbols potentially following the template args ?
May be I should have a look into the new C++ parser used in gcc 3.4...

Any ideas ? Chiba ?

Kind regards,
		Stefan

[Opencxx-users] Makefile.am showing 'make test' does not require reconfiguring

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

Steps required to make install from tar file.
$ ./configure
$ make
$ su -
# make install

If we want to add verifications.
$ ./configure
$ make
$ make check
$ su -
# make install

On my linux platform, Fedora Core 2
the attach compress file 'Makefile.am.gz'
allow to verify that present reconfiguration step is not
necessary.

steps perform are:
$ cvs -z3 co -rrel_2_8 opencxx
$ cd opencxx
$ ./bootstrap
$ cd ..
$ mkdir build
$ cd build
$ ../opencxx/configure -C \
 --prefix=/usr \
 --srcdir=../opencxx \
 --disable-gc
$ make
$ make test
$ su -
# make install

This, demonstrate the mechanism that I will like to have for
my system.

Comments ?

[Opencxx-users] parse error on valid code

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

hi there,

The following valid code doesn't parse with opencxx:

---

template <typename T> void Foo();

void (*bar)() = &Foo<int>;

---

I'll look into it, but in case someone else (Grzegorz, Chiba ?)
has an idea, I'll send it to the list.

Here is the call graph:

rInitializeExpr
rExpression
rConditionalExpr
rLogicalOrExpr
rLogicalAndExpr
rInclusiveOrExpr
rExclusiveOrExpr
rAndExpr
rEqualityExpr
rRelationalExpr
rShiftExpr

and there it happens:

the parser just read the 'shift expression' ('[& Foo]'), and now
runs into the '<', which it wrongly interprets as a relational operator.

What can I do to resolve this conflict ?

Kind regards,
		Stefan

Re: [Opencxx-users] 'metaclass' keyword

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

Grzegorz Jakacki wrote:
 >
 >
 > Stefan Seefeld wrote:
 >
 >> hi there,
 >>
 >> I just got a bug report for synopsis from a user who
 >> reports that all input containing 'metaclass' generates
 >> parse errors.
 >> Looking into the Opencxx lexer, I see it's defined there
 >> as a keyword :-)
 >
 >
 > Why don't you put it under run-time flag?

right ! I didn't notice this capability, but now that I see it
it's indeed the best solution, in particular given the overal
goal to open up the frontend, so registering new keywords will
be trivial.

Thanks,
		Stefan

Re: [Opencxx-users] generated files in CVS branch rel_2_8

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

Done.

Gilles J. Seguin wrote:
> cvs update: Updating opencxx
> M opencxx/Makefile.in
> M opencxx/aclocal.m4
> M opencxx/config.h.in
> M opencxx/configure
> cvs update: Updating opencxx/gc
> M opencxx/gc/Makefile.in
> M opencxx/gc/aclocal.m4
> M opencxx/gc/configure
> cvs update: Updating opencxx/gc/doc
> M opencxx/gc/doc/Makefile.in
> cvs update: Updating opencxx/gc/include
> M opencxx/gc/include/Makefile.in
> cvs update: Updating opencxx/libltdl
> M opencxx/libltdl/config-h.in
> cvs update: Updating opencxx/scripts
> M opencxx/scripts/Makefile.in
> 
> directory opencxx may used an .cvsignore file
> add aclocal.m4 to opencxx/gc/.cvsignore
> add aclocal.m4 to opencxx/libltdl/.cvsignore
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] 'metaclass' keyword

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

Stefan Seefeld wrote:
> hi there,
> 
> I just got a bug report for synopsis from a user who
> reports that all input containing 'metaclass' generates
> parse errors.
> Looking into the Opencxx lexer, I see it's defined there
> as a keyword :-)

Why don't you put it under run-time flag?

BR
Grzegorz

> 
> Obviously I have to remove this for synopsis, though I'd
> like to preserve the possibility to insert opencxx markers
> into C++ code. What could become an alternative keyword ?
> What token is unlikely to be used by others, and yet a valid
> token ? (apparently words starting with two underscores are
> out, as they are reserved for the compiler / std library).
> What about '_opencxx' or similar ? (I know it's used as a macro
> now...)
> 
> Regards,
>         Stefan
> 
> 
> -------------------------------------------------------
> 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] Cygwin problem

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

On Wed, 2004-07-14 at 16:47, Grigorenko Dmitriy wrote:
> Hello
> 
> > As you see when occ.exe is loaded the dynamic linker will pick the
> > global cygltdl.dll;
> I`m sorry. The correct log is here:
> 
> H:\...ome\Dima\opencxx-2.7\testbed\bin>cygcheck occ.exe
> Found: .\occ.exe
> occ.exe
>   .\cygltdl-3.dll
>     h:\cygwin\bin\cygwin1.dll
>       H:\WINDOWS\System32\ADVAPI32.DLL
>         H:\WINDOWS\System32\ntdll.dll
>         H:\WINDOWS\System32\KERNEL32.dll
>         H:\WINDOWS\System32\RPCRT4.dll
> 
> The previos one described the case when all is correct.
> I`d like to call attention that sigsegv occurs whith the local (opencxx/)
> cygltdl-3.dll
> 
> > ./configure --with-ltdl=/my/path/libltdl
> > we need to verified that your build does it correctly.
> I tried
> ./configure --with-ltdl=/usr/bin
> becouse the correct cygltdl-3.dll is in the /usr/bin directory
> 
> 'make test' do not work properly. It steel uses local ltdl and crashes.

does the config.log is created, if yes
$ grep LIBLTDL config.log
LIBLTDL='-lltdl'
$ grep INCLTDL config.log
INCLTDL=''
what are the results

if LIBLTDL is not '-lltdl'
in opencxx/testsuite/tester2.in
we have line
LIBS="-locc @libgc@ -lltdl"
change to
LIBS="-locc @libgc@ @LIBLTDL@"
than do configure in your top_builddir
what is the result of this line

Have you try 'libtoolize --ltdl' before bootstrap script

when running configure, do you have somthing like
checking dependency style of gcc... gcc3
checking for lt_dlinit in -lltdl... yes
checking for gcc... (cached) gcc

Re: [Opencxx-users] add PtreeVisualizer.h to branch rel_2_8

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

That's correct.

Gilles J. Seguin wrote:
> required by opencxx/opencxx/parser-test.cc
> $ ./parser-test
> digraph Ptree {
>   node[shape=box,width=.1,height=.1];
>   _0x9374bf8[label="PtreeDeclaration",style=bold];
>   _0x9374bf8 -> _null0[taillabel="CAR"];
>   _null0[shape=point,label=""];
>   _0x9374bf8 ->  _0x9374c08[taillabel="CDR"];
>   _0x9374c08[label="NonLeaf",color=lightgray,fontcolor=lightgray];
>   _0x9374c08 ->  _0x93742e8[taillabel="CAR"];
>   _0x93742e8[label="NonLeaf",color=lightgray,fontcolor=lightgray];
>   _0x93742e8 ->  _0x93742d8[taillabel="CAR"];
>   _0x93742d8[label="LeafINT\nint",style=filled,fillcolor=lightgray];
>   _0x93742e8 -> _null1[taillabel="CDR"];
>   _null1[shape=point,label=""];
>   _0x9374c08 ->  _0x9374c18[taillabel="CDR"];
>   _0x9374c18[label="NonLeaf",color=lightgray,fontcolor=lightgray];
>   _0x9374c18 ->  _0x9374b58[taillabel="CAR"];
>   _0x9374b58[label="PtreeDeclarator",style=bold];
>   _0x9374b58 ->  _0x9374ae8[taillabel="CAR"];
>   _0x9374ae8[label="Leaf\nmain",style=filled,fillcolor=lightgray];
>   _0x9374b58 ->  _0x9374b28[taillabel="CDR"];
>   _0x9374b28[label="NonLeaf",color=lightgray,fontcolor=lightgray];
>   _0x9374b28 ->  _0x9374b18[taillabel="CAR"];
>   _0x9374b18[label="Leaf\n(",style=filled,fillcolor=lightgray];
>   _0x9374b28 ->  _0x9374b38[taillabel="CDR"];
>   _0x9374b38[label="NonLeaf",color=lightgray,fontcolor=lightgray];
>   _0x9374b38 -> _null2[taillabel="CAR"];
>   _null2[shape=point,label=""];
>   _0x9374b38 ->  _0x9374b48[taillabel="CDR"];
>   _0x9374b48[label="NonLeaf",color=lightgray,fontcolor=lightgray];
>   _0x9374b48 ->  _0x9374b08[taillabel="CAR"];
>   _0x9374b08[label="Leaf\n)",style=filled,fillcolor=lightgray];
>   _0x9374b48 -> _null3[taillabel="CDR"];
>   _null3[shape=point,label=""];
>   _0x9374c18 ->  _0x9374c28[taillabel="CDR"];
>   _0x9374c28[label="NonLeaf",color=lightgray,fontcolor=lightgray];
>   _0x9374c28 ->  _0x9374ba8[taillabel="CAR"];
>   _0x9374ba8[label="PtreeBlock",style=bold];
>   _0x9374ba8 ->  _0x9374bb8[taillabel="CAR"];
>   _0x9374bb8[label="Leaf\n{",style=filled,fillcolor=lightgray];
>   _0x9374ba8 ->  _0x9374bd8[taillabel="CDR"];
>   _0x9374bd8[label="NonLeaf",color=lightgray,fontcolor=lightgray];
>   _0x9374bd8 -> _null4[taillabel="CAR"];
>   _null4[shape=point,label=""];
>   _0x9374bd8 ->  _0x9374be8[taillabel="CDR"];
>   _0x9374be8[label="NonLeaf",color=lightgray,fontcolor=lightgray];
>   _0x9374be8 ->  _0x9374bc8[taillabel="CAR"];
>   _0x9374bc8[label="Leaf\n}",style=filled,fillcolor=lightgray];
>   _0x9374be8 -> _null5[taillabel="CDR"];
>   _null5[shape=point,label=""];
>   _0x9374c28 -> _null6[taillabel="CDR"];
>   _null6[shape=point,label=""];
> }
> $
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

[Opencxx-users] 'metaclass' keyword

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

hi there,

I just got a bug report for synopsis from a user who
reports that all input containing 'metaclass' generates
parse errors.
Looking into the Opencxx lexer, I see it's defined there
as a keyword :-)

Obviously I have to remove this for synopsis, though I'd
like to preserve the possibility to insert opencxx markers
into C++ code. What could become an alternative keyword ?
What token is unlikely to be used by others, and yet a valid
token ? (apparently words starting with two underscores are
out, as they are reserved for the compiler / std library).
What about '_opencxx' or similar ? (I know it's used as a macro
now...)

Regards,
		Stefan

Re: [Opencxx-users] Cygwin problem

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

Hello

> As you see when occ.exe is loaded the dynamic linker will pick the
> global cygltdl.dll;
I`m sorry. The coorect log is here:

H:\...ome\Dima\opencxx-2.7\testbed\bin>cygcheck occ.exe
Found: .\occ.exe
occ.exe
  .\cygltdl-3.dll
    h:\cygwin\bin\cygwin1.dll
      H:\WINDOWS\System32\ADVAPI32.DLL
        H:\WINDOWS\System32\ntdll.dll
        H:\WINDOWS\System32\KERNEL32.dll
        H:\WINDOWS\System32\RPCRT4.dll

The previos one described the case when all is correct.
I`d like to call attention that sigsegv occurs whith the local (opencxx/)
cygltdl-3.dll

> ./configure --with-ltdl=/my/path/libltdl
> we need to verified that your build does it correctly.
I tried
./configure --with-ltdl=/usr/bin
becouse the correct cygltdl-3.dll is in the /usr/bin directory

'make test' do not work properly. It steel uses local ltdl and crashes.

> > (2) Another solution would be to make OpenC++ by default use
> > system-wide cygltdl.dll on Cygwin, as anyway there is no Cygwin on
> > Compile Farm. This requires modifying configure.in/Makefile.am, so
> > that it does not use libltdl if it is installed. The key point that
> > needs to be changed is --enable-ltdl-install in Makefile.am,
> > because it forces installation of libltdl.so/cygltdl-3.dll
>
> This does not resolve the Compile farm problem,
> because you must not be authorized to replace system library.
As far as I understood, the idea is to use system-wide library if it
presents. You must not be authorized to do it.
Unfortunately I do not know autoconf  enough to modify configure.in. At
least once I did not investigate it enough. I`ll try later.

> > (3) Ultimate solution, which I think is the way to go in the long
> > term, would be to
> >
> >    - remove libltdl from OpenC++ at all
>
> we keep it, it is our development reference.
> Others mechanisms provided way around this.
I am agree.

Re: [Opencxx-users] Cygwin problem

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

On Wed, 2004-07-14 at 11:16, Grzegorz Jakacki wrote:
> Grigorenko Dmitriy wrote:
> > Hello
> > 
> > I checked which library is used by occ.
> > 
> > H:\cygwin\home\Dima\opencxx-2.7\src>cygcheck occ
> > Found: .\occ.exe
> > occ.exe
> >   h:\cygwin\bin\cygltdl-3.dll
> >     h:\cygwin\bin\cygwin1.dll
> >       H:\WINDOWS\System32\ADVAPI32.DLL
> >         H:\WINDOWS\System32\ntdll.dll
> >         H:\WINDOWS\System32\KERNEL32.dll
> >         H:\WINDOWS\System32\RPCRT4.dll
> > 
> 
> Yes, this is exactly the information that was needed.
> 
> As you see when occ.exe is loaded the dynamic linker will pick the 
> global cygltdl.dll;
> 
> > It couses sigsegv when cygltdl-3.dll builds from opencxx/libltdl.
> > In case of native cygltdl-3.dll using it`s ok.
> 
> I suppose that the version of ltdl in opencxx/libltdl is different
> from your system-wide version. The problem is that ld sets function
> offsets in occ.exe according to the layout of opencxx/cygltdl-3.dll,
> but at load-time /cygwin/bin/cygltdl-3.dll is linked dynamically
> and there is a mismatch between offsets and entries
> in /cygwin/bin/cygltdl-3.dll

I suspect two problems
- When libtool package is install, the make tool must not
  compile anything in the libltdl subdirectory.
  Even less, link to produce a static and/or shared libraries.
  a) Usely two packages are provided,
     that is libtool-lib and libtool.
     libtool-lib package provides  cygltdl-3.dll, that is for user
     libtool provide the Software Development Kit,
     that is for developer.

  b) the subdirectory libltdl in cvs is not for cygwin.
     neither the bootstrap script enough powerfull to detect
     your platform.  Present alternative is to
     - delete the libltdl subdirectory
     - in top_srcdir execute foolwing equivalent cli command,
       $ libtoolize --automake --copy --ltdl
       What is desired, option --ltdl ask to copy your
       platform ltdl.h and ltdl.c in libltdl subdirectory.

  c) step b) is *not* supposed to be required.
     but may be require to do test or check.
     We have hardwire dependency in the Makefile.
     Solution, removed them

diff -u -r1.7.2.1 Makefile.am
--- opencxx/Makefile.am 11 Jul 2004 02:07:32 -0000 1.7.2.1
+++ opencxx/Makefile.am 12 Jul 2004 19:28:08 -0000
@@ -44,13 +44,13 @@
 occ_SOURCES    = MetaclassPreregistration.cc
 occ_LDADD      = libocc.la
 occ_LDFLAGS    = -export-dynamic
-INCLUDES       = -I$(top_srcdir) -I$(top_srcdir)/libltdl
+INCLUDES       = -I$(top_srcdir) $(INCLTDL)
 
 lib_LTLIBRARIES        = libocc.la
 libocc_la_SOURCES = empty_libocc.cc
 libocc_la_LIBADD       = \
                opencxx/libocc_mop.la   \
-               libltdl/libltdl.la      \
+               $(LIBLTDL) \
                $(libgc)
 
 include_HEADERS        = mop.h

diff -u -r1.2.2.2 Makefile.am
--- opencxx/opencxx/Makefile.am 11 Jul 2004 02:07:32 -0000 1.2.2.2
+++ opencxx/opencxx/Makefile.am 12 Jul 2004 19:34:12 -0000
@@ -119,7 +119,7 @@
 EXTRA_DIST     = \
                parser/ptree-gen.in
 
-INCLUDES = -I$(builddir) -I$(top_srcdir) -I$(top_srcdir)/libltdl 
+INCLUDES = -I$(builddir) -I$(top_srcdir) $(INCLTDL)
 
 lib_LTLIBRARIES                = \
        libocc_mop.la   \
@@ -227,7 +227,7 @@
 parser_test_LDADD = \
        libparser-test.la       \
        libocc_parser.la        \
-       ../libltdl/libltdl.la
+       $(LIBLTDL)
 
 ###################################################################

> > Why does it make libltdl instead of using the native one?

see above

> I had problems on Compile Farm --- the version of libtool installed 
> there system-wide was too old and crashed with libgc. So I decided
> to force occ to use the libltdl bundled with OpenC++.

solutions, link static library libltdl.a

> > How can it be fixed?

./configure --with-ltdl=/my/path/libltdl
we need to verified that your build does it correctly.

> (1) On Linux you can tell the dynamic linker where to look for
> shared libraries by setting the environment variable LD_LIBRARY_PATH.
> There must be a way to tell this to cygwin dynamic linker also.
> This will instruct dynamic linker to pick
> opencxx/libltdl/cygltdl-3.dll, not the system-wide one.

this presuppose that both libraries even if not at the same
location are in fact identical.  You must prove me,
that they are(see above libtoolize -ltdl option).

> (2) Another solution would be to make OpenC++ by default use
> system-wide cygltdl.dll on Cygwin, as anyway there is no Cygwin on
> Compile Farm. This requires modifying configure.in/Makefile.am, so
> that it does not use libltdl if it is installed. The key point that
> needs to be changed is --enable-ltdl-install in Makefile.am,
> because it forces installation of libltdl.so/cygltdl-3.dll

This does not resolve the Compile farm problem,
because you must not be authorized to replace system library.

>  even if it is already present.

Means, the Compile Farm must ensure equivalence to
OCC=LD_PRELOAD=/my/path/libldlt.so.3 /my/path/occ

> (3) Ultimate solution, which I think is the way to go in the long
> term, would be to
> 
>    - remove libltdl from OpenC++ at all

we keep it, it is our development reference.
Others mechanisms provided way around this.

>    - add --with-libltdl=DIR to ./configure
> 
> Then OpenC++ will use system-wide libltdl by default.

Verified that libltdl provide a known working library.
if not, two choice used static or ensure that the ld utility
know how to find the shared library. That is,
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
  during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
  during linking
- use the `-Wl,--rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
- LD_PRELOAD mechanism.
where LIBDIR=/my/path/opencxx/libtool/.libs/libltdl.so

> On Compile Farm the tests build would be configured with
> 
>    ./configure --with-libltdl=PATH_TO_RECENT_VERSION_OF_LIBLTDL.
> 
> If you could help with implementing (2) or (3), please do.

Re: [Opencxx-users] Cygwin problem

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

Grigorenko Dmitriy wrote:
> Hello
> 
> I checked which library is used by occ.
> 
> H:\cygwin\home\Dima\opencxx-2.7\src>cygcheck occ
> Found: .\occ.exe
> occ.exe
>   h:\cygwin\bin\cygltdl-3.dll
>     h:\cygwin\bin\cygwin1.dll
>       H:\WINDOWS\System32\ADVAPI32.DLL
>         H:\WINDOWS\System32\ntdll.dll
>         H:\WINDOWS\System32\KERNEL32.dll
>         H:\WINDOWS\System32\RPCRT4.dll
> 

Yes, this is exactly the information that was needed.

As you see when occ.exe is loaded the dynamic linker will pick the 
global cygltdl.dll;

> It couses sigsegv when cygltdl-3.dll builds from opencxx/libltdl.
> In case of native cygltdl-3.dll using it`s ok.

I suppose that the version of ltdl in opencxx/libltdl is different from 
your system-wide version. The problem is that ld sets function offsets 
in occ.exe according to the layout of opencxx/cygltdl-3.dll, but at 
load-time /cygwin/bin/cygltdl-3.dll is linked dynamically and there is a 
mismatch between offsets and entries in /cygwin/bin/cygltdl-3.dll

> Why does it make libltdl instead of using the native one?

I had problems on Compile Farm --- the version of libtool installed 
there system-wide was too old and crashed with libgc. So I decided to 
force occ to use the libltdl bundled with OpenC++.

> How can it be fixed?

(1) On Linux you can tell the dynamic linker where to look for
shared libraries by setting the environment variable LD_LIBRARY_PATH. 
There must be a way to tell this to cygwin dynamic linker also. This 
will instruct dynamic linker to pick opencxx/libltdl/cygltdl-3.dll, not 
the system-wide one.

(2) Another solution would be to make OpenC++ by default use system-wide 
cygltdl.dll on Cygwin, as anyway there is no Cygwin on Compile Farm. 
This requires modifying configure.in/Makefile.am, so that it does not 
use libltdl if it is installed. The key point that needs to be changed 
is --enable-ltdl-install in Makefile.am, because it forces installation 
of libltdl.so/cygltdl-3.dll even if it is already present.

(3) Ultimate solution, which I think is the way to go in the long term, 
would be to

   - remove libltdl from OpenC++ at all
   - add --with-libltdl=DIR to ./configure

Then OpenC++ will use system-wide libltdl by default. On Compile Farm 
the tests build would be configured with

   ./configure --with-libltdl=PATH_TO_RECENT_VERSION_OF_LIBLTDL.

If you could help with implementing (2) or (3), please do.

> Thank you
> 
> P.S. Your last letter was only for me, not for the hole mail list. Is it
> right?

I am sorry, I make this mistake recently. I switched from Pine to 
Mozilla and they handle replies differently (when replying in Pine you 
have an option to reply to all, but in Mozilla it by default replies 
only to main recipient). As the thread came from the list, I intended to 
reply to the list. Sorry again, I am forwarding these e-mails.

BR
Grzegorz

Re: [Opencxx-users] Cygwin problem

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

Grigorenko Dmitriy wrote:
> Hi
> 
> 
>>Congratulations, very nice workaround.
> 
> Thank`s
> 
> 
>>That very well may be. However, I would also check if by any chance 
>>dynamic linker is not picking another version of libltdl installed 
>>somewhere else on your system. On my Linux there is 'ldd' utility for 
>>this purpose, I am not sure about Cygwin.
> 
> I checked that it does not compile without ltdt libs.

One think is if it compiles, another is how it is linked at runtime. In
most Linux distros libltdl package has dev and non-dev versions. If you
have non-dev version installed system-wide, then you have
/lib/libltdl.so, but not /include/ltdl.h . Thus OpenC++ will not compile
without bundled libltdl; when you point bundled libltdl to OpenC++ it
will pick opencxx/libltdl/ltdl.h at compilation time and at linking time
it will see opencxx/libltdl/libltdl.so and will be satisfied. However,
at loadtime, the dynamic loader may pick your system-wide
/lib/libltdl.so and if the versions do not match, your executable may
crash (at least I believe so; there may be some version control
mechanism built into libtool libraries that is supposed to prevent it,
but I am no expert).

Do you have (or can install) 'ldd' utility? On Linux it works like this:


$ ldd occ

         libltdl.so.3 =>
/home/jakacki/tmp/opencxx/libltdl/.libs/libltdl.so.3 (0x40018000)
         libdl.so.2 => /lib/libdl.so.2 (0x4002c000)
         libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4002f000)
         libm.so.6 => /lib/libm.so.6 (0x400e8000)
         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4010a000)
         libc.so.6 => /lib/libc.so.6 (0x40112000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

As you can see in this particular config dynamic linker will pick my
local version of libltdl.

And this is the output I am getting after linking libltdl statically by
hand:

$ ldd occ
         libdl.so.2 => /lib/libdl.so.2 (0x40024000)
         libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40028000)
         libm.so.6 => /lib/libm.so.6 (0x400e1000)
         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40103000)
         libc.so.6 => /lib/libc.so.6 (0x4010b000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

As you can see libltdl does not occur at all --- it is linked statically.

If you could run ldd in your setup we could see if the correct
libltdl.so is picked.

Best regards
Grzegorz



> 
> 

[Opencxx-users] generated files in CVS branch rel_2_8

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

cvs update: Updating opencxx
M opencxx/Makefile.in
M opencxx/aclocal.m4
M opencxx/config.h.in
M opencxx/configure
cvs update: Updating opencxx/gc
M opencxx/gc/Makefile.in
M opencxx/gc/aclocal.m4
M opencxx/gc/configure
cvs update: Updating opencxx/gc/doc
M opencxx/gc/doc/Makefile.in
cvs update: Updating opencxx/gc/include
M opencxx/gc/include/Makefile.in
cvs update: Updating opencxx/libltdl
M opencxx/libltdl/config-h.in
cvs update: Updating opencxx/scripts
M opencxx/scripts/Makefile.in

directory opencxx may used an .cvsignore file
add aclocal.m4 to opencxx/gc/.cvsignore
add aclocal.m4 to opencxx/libltdl/.cvsignore

[Opencxx-users] add PtreeVisualizer.h to branch rel_2_8

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

required by opencxx/opencxx/parser-test.cc
$ ./parser-test
digraph Ptree {
  node[shape=box,width=.1,height=.1];
  _0x9374bf8[label="PtreeDeclaration",style=bold];
  _0x9374bf8 -> _null0[taillabel="CAR"];
  _null0[shape=point,label=""];
  _0x9374bf8 ->  _0x9374c08[taillabel="CDR"];
  _0x9374c08[label="NonLeaf",color=lightgray,fontcolor=lightgray];
  _0x9374c08 ->  _0x93742e8[taillabel="CAR"];
  _0x93742e8[label="NonLeaf",color=lightgray,fontcolor=lightgray];
  _0x93742e8 ->  _0x93742d8[taillabel="CAR"];
  _0x93742d8[label="LeafINT\nint",style=filled,fillcolor=lightgray];
  _0x93742e8 -> _null1[taillabel="CDR"];
  _null1[shape=point,label=""];
  _0x9374c08 ->  _0x9374c18[taillabel="CDR"];
  _0x9374c18[label="NonLeaf",color=lightgray,fontcolor=lightgray];
  _0x9374c18 ->  _0x9374b58[taillabel="CAR"];
  _0x9374b58[label="PtreeDeclarator",style=bold];
  _0x9374b58 ->  _0x9374ae8[taillabel="CAR"];
  _0x9374ae8[label="Leaf\nmain",style=filled,fillcolor=lightgray];
  _0x9374b58 ->  _0x9374b28[taillabel="CDR"];
  _0x9374b28[label="NonLeaf",color=lightgray,fontcolor=lightgray];
  _0x9374b28 ->  _0x9374b18[taillabel="CAR"];
  _0x9374b18[label="Leaf\n(",style=filled,fillcolor=lightgray];
  _0x9374b28 ->  _0x9374b38[taillabel="CDR"];
  _0x9374b38[label="NonLeaf",color=lightgray,fontcolor=lightgray];
  _0x9374b38 -> _null2[taillabel="CAR"];
  _null2[shape=point,label=""];
  _0x9374b38 ->  _0x9374b48[taillabel="CDR"];
  _0x9374b48[label="NonLeaf",color=lightgray,fontcolor=lightgray];
  _0x9374b48 ->  _0x9374b08[taillabel="CAR"];
  _0x9374b08[label="Leaf\n)",style=filled,fillcolor=lightgray];
  _0x9374b48 -> _null3[taillabel="CDR"];
  _null3[shape=point,label=""];
  _0x9374c18 ->  _0x9374c28[taillabel="CDR"];
  _0x9374c28[label="NonLeaf",color=lightgray,fontcolor=lightgray];
  _0x9374c28 ->  _0x9374ba8[taillabel="CAR"];
  _0x9374ba8[label="PtreeBlock",style=bold];
  _0x9374ba8 ->  _0x9374bb8[taillabel="CAR"];
  _0x9374bb8[label="Leaf\n{",style=filled,fillcolor=lightgray];
  _0x9374ba8 ->  _0x9374bd8[taillabel="CDR"];
  _0x9374bd8[label="NonLeaf",color=lightgray,fontcolor=lightgray];
  _0x9374bd8 -> _null4[taillabel="CAR"];
  _null4[shape=point,label=""];
  _0x9374bd8 ->  _0x9374be8[taillabel="CDR"];
  _0x9374be8[label="NonLeaf",color=lightgray,fontcolor=lightgray];
  _0x9374be8 ->  _0x9374bc8[taillabel="CAR"];
  _0x9374bc8[label="Leaf\n}",style=filled,fillcolor=lightgray];
  _0x9374be8 -> _null5[taillabel="CDR"];
  _null5[shape=point,label=""];
  _0x9374c28 -> _null6[taillabel="CDR"];
  _null6[shape=point,label=""];
}
$

Re: [Opencxx-users] rel_2_8 branch

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

Gilles J. Seguin wrote:
> On Fri, 2004-07-09 at 06:30, Grzegorz Jakacki wrote:
> 
>>Hi Gilles!
>>
>>Thank you very much for your feedback.
>>
>>This is not clear to me,
> 
> 
> OK, it is not clear.
> Patches can be applied even if others behavior are not
> what I would like to be.  

Ok, I see.

 > But must not break the GC.
> 
> 
>>however, if the make output you gave is *before*
>>or *after* the patches have been applied.
> 
> 
> Patches are relative to branch rel_2_8.
> The ability to do 'make' in the build directory was lost.

I see.

> This is a nice option to test little patch or to keep
> multiple binary version.

Sure.

> $ cd /home1/opencxx
> $ ./bootstrap
> $ cd ..
> $ mkdir build
> $ cd build
> $ ../opencxx/configure --prefix=/usr --srcdir=../opencxx \
>  --datadir=/usr/share --disable-gc
> $ make
> was failing because option -I../opencxx is required in that
> situation.

I see.

>>Can you build now with your patches? 
> 
> 
> $ make
> succeed
> $ make unittests
> $ make check
> IIRC, also succeed. they are the same make target.

Right.

> $ make test
> 
>>Do gc tests pass?
> 
> not tested
> 
> 
>>If not, then could you send the 
>>complete output of bootstrap+configure+make ?
>>
>>Thanks again
>>Grzegorz
>>
>>
>>Gilles J. Seguin wrote:
>>
>>>On Wed, 2004-07-07 at 09:49, Grzegorz Jakacki wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>HEAD passed the following tests on CF:
>>>>
>>>>* powerpc-apple-darwin6.8/nogc/gcc-3.3
>>>>* i686-pc-linux-gnu/gc-6.2/gcc-2.95.2 (Debian)
>>>>
>>>>I am still waiting for RedHat host on Compile Farm to go up to
>>>>test on RedHat.
>>>>
>>>>I created a branch rel_2_8 and it eventually will be released
>>>>as 2.8;this is a beta release, with major restructurings
>>>>applied to the code. 
>>>
>>>On Fedora Core 2
>>>with rel_2_8
>>>make from a build directory fail.
>>>I have applied following patches
>>>
>>>make test
> 
> [...]
> 
>>>/bin/sh ../../opencxx/mkinstalldirs /usr/share/opencxx/html
>>>mkdir -p -- /usr/share/opencxx/html
>>>mkdir: cannot create directory
>>>`/usr/share/opencxx': Permission denied
>>>
>>>something is very wrong, here
> 
> 
> More extensively, my believe is that
> - we can install the opencxx build required libraries under the
>   testsuite subdirectory.

The intention was to install them in ${builddir}/testbed . If it does 
not happen, this is a bug.

> - it can be done without root privilege.

Yes, this was also my intention.

> - it can be done without reconfiguring.

Unfortunately, I don't think it can be easily avoided.

The libtool libraries (*.la files) should be "installed" before they are 
linked against. On some systems you cannot link against shared library 
unless it is installed in one specific directory, which is hardcoded in 
the shared library file.

This means, that when the *.la file is created the path at which it is 
going to be installed must be known.

In case of OpenC++ libtool is called from Makefile, and this Makefile is 
generated from Makefile.am by Automake and configure. Automake creates 
all the logic and configure only fills-in parameters like @builddir@, 
@libdir@ etc. This logic calls libtool in such a way, that the library 
installation path is $libdir, and I don't know about any easy way to 
force Automake to supply another installation path when calling libtool.

This means that in order to be able to run tests that do dynamic 
linking, we need to install shared libraries. I don't want to force 
users to install in /usr/lib or in system-wide location before they can 
test, so I came up with an idea, that for testing they will be 
provisionally installed in ${builddir}/testbed . As outlined above, due 
to Automake limitations it is difficult to do it without 
reconfiguration. So when you say 'make test' and $prefix is not 
`pwd`/testbed , the sources are reconfigured with --prefix=`pwd`/testbed
(and --enable-libltdl-install, more about it in a moment).

> What is missing,
> - the advance understanding of the aclocal, automake, libtool,
>   and autoconf tools.
> - And answers to other occult behaviors.
>   Why is the libltdl being built, don't we have specify
>   AC_LIBLTDL_INSTALLABLE, AC_LIB_LTDL
>   and I have obviously the libtools package.

I had a lots of problems with old libltdl installed on a system (this 
especially showed up on Compile Farm, where I cannot just upgrade it). 
Thus when OpenC++ is reconfigured for testing it forces building the 
bundled libltdl, no matter if libltdl is available system-wide.

> - the patches.

I applied patches from your previous e-mail. I will try to have a look 
builddir!=srcdir before 2.8 release. If you find any further facts that 
would help, please let me know.

Thanks!
Grzegorz

Re: [Opencxx-users] Cygwin problem

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

Hi

> Congratulations, very nice workaround.
Thank`s

> That very well may be. However, I would also check if by any chance 
> dynamic linker is not picking another version of libltdl installed 
> somewhere else on your system. On my Linux there is 'ldd' utility for 
> this purpose, I am not sure about Cygwin.
I checked that it does not compile without ltdt libs.

Re: [Opencxx-users] future directions

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

Hi Stefan,

Stefan Seefeld wrote:
> Grzegorz Jakacki wrote:
> 
>>> And I don't see a problem having two separate constructors, one 
>>> operating
>>> on Ptree pointers, the other on the typed counterpart.
>>
>>
>>
>> I am not sure if you get the exact picture. The "untyped" constructor 
>> does not construct the NonLeaf auxiliary nodes. It is just:
>>
>>
>>     PtreeIfStatement(Ptree* p, Ptree* q) : NonLeaf(p, q) {}
>>
>> If we have another, "typed" constructor like this one:
>>
>>     PtreeIfStatement(
>>         PtreeExprStatement* cond
>>       , PtreeExprStatement *th
>>       , PtreeExprStatement* el
>>     )
>>       : NonLeaf(cond, new NonLeaf(th, new NonLeaf(el, NULL)))
>>     {}
>>
>> Then, as you noticed, there is a question of who owns auxiliary
>> NonLeaf nodes (and, consequently, if ~PtreeIfStatement should delete 
>> them).
> 
> 
> right, but I didn't mean the 'typed constructor' to construct any nodes
> himself, but rather to take 'PtreeExprStatement' arguments instead of 
> 'Ptree'.
> The ownership semantics remains the same.

Stefan, look again at the picture: immediate "physical" children of 
PtreeIfStatement are not PtreeExprStatement nodes. They do not have any 
reasonable type in the sense of C++ grammar. They are only glue nodes.

Having said that, I don't understand how can PtreeIfStatement take 
PtreeExprStatement nodes and at the same time not construct any nodes 
itself.

> 
>>> That sounds indeed like a bad idea. Either Ptrees
>>> own their children, or they don't. 
>>
>>
>>
>> I agree. However I am not sure what you mean by "child". What is a 
>> "child" of PtreeIfStatement node? Do you consider "else-part" to be a 
>> "child" of PtreeIfStatement node?
> 
> 
> yes.
> 
>> It is also not clear to me if you would like to keep the existing 
>> representation of if-statement as three physical nodes or if you 
>> eventually would like to modify PtreeIfStatement so that it becomes
>>
>> struct PtreeIfStatement
>> {
>>     ...
>>     PtreeExprStatement *cond_, *then_, *else_;
>> };
> 
> 
> the latter.

Then, as I described in my last e-mail, there is huge amount of work 
involved in transforming all the legacy code that deals with "glue" 
nodes. Every single piece of code that accesses, say, "condition" of 
if-statement, will need to be changed from 'p->Cdr()->Car()' to
'p->GetCond()'.

Your solution is very clean, but it requires a huge investment. My 
suggestion is to leave the legacy code as it is and provide NodePtr<> 
atop of it. NodePtr<old_PtreeIfStatement> would very closely mimic 
behaviour of new_PtreeIfStatement*, so where is the gain?

Moreover, if you ever change parser or elaborator, you are free to mix 
the code that uses NodePtr<> with the legacy code. Even more --- if one 
day you discover, that you eradicated all occurences of PtreeXXX, Leaf 
and NonLeaf from parser, you can implement your clean classes a la the 
PtreeIfStatement above and just textually replace every NodePtr<Foo> 
with new_Foo* and you are done. My solution arrives exactly at the same 
point that you want to reach, but it seems to me that the landing is 
much softer.

Best regards
Grzegorz

--------------------------

WRAP-UP
=======

Instead of introducing

   class new_PtreeIfStatement {
       ...
       PtreeExprStatement* GetCond() { return cond_; }
       ...
       PtreeExprStatement* cond_;
   };

and fixing all the places in code that will get broken by replacing 
PtreeIfStatement by new_PtreeIfStatement, let's introduce

   template <>
   class NodePtr<PtreeIfStatement> {
       ...
       NodePtr<PtreeExprStatement> GetCond() const {
           return NodePtr<PtreeExprStatement>(
               (PtreeExprStatement*)(p_->Cdr()->Car));
       }
       ...
   private:
       PtreeIfStatement* p_;
   };

and leave the legacy code as it is.

NodePtr<PtreeIfStatement> works essentially as new_PtreeIfStatement*,
it can be further enhanced to mimic newPtreeIfStatement* very closesly, 
including pointer syntax.

All uses of Ptree* derivatives can be gradually replaced with NodePtr<>. 
Once all of them are eradicated, every NodePtr<Foo> can be replaced with 
new_Foo* (and that will not require any further code tweaking), which 
effectively provides smooth, evolutionary way of arriving at the first 
solution.

----- END OF WRAP-UP -----


> 
> Regards,
>         Stefan
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] Cygwin problem

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

Hi,

Grigorenko Dmitriy wrote:
> Hello.
> 
> 
>>This 77-th line of iostream looks like a bug in debugger or compiler
>>(invalid debugging information), I remember that I had similar problems
>>somewhere else.
> 
> Your are right. I found that problem is in the lt_dlinit() call (the first
> call of the ltdl function). You can find it in
> the InitDynamicLoader() function in driver2.cc. I checked that sigfault
> heppens befor the first line of lt_dlinit and befor the first line of the
> main function in ltdl. (We have to add an empty main funcion in ltdl.c).
> I  investigated that in case of static linking occ which ltdl.o (instead of
> using -lltdl) it is all right!

Congratulations, very nice workaround.

> So I think that problem is in the linking process. Namely, I think what the
> lt_dlinit() function address is incorrect.

That very well may be. However, I would also check if by any chance 
dynamic linker is not picking another version of libltdl installed 
somewhere else on your system. On my Linux there is 'ldd' utility for 
this purpose, I am not sure about Cygwin.

If this is a genuine bug on Cygwin (and this is likely, since I have 
heard about similar problems from three other persons), then I will fix 
it in HEAD by following your workaround.

Thanks
Grzegorz

>> From your description it is difficult to tell where the sigfault really
>>happens. As far as I understand line 75 is the first line of main().
>>Perhaps the segfault happens during initialization of static variables.
>>One way to find out would be to load core file to gdb ('gdb occ core')
>>and examine stack trace ('bt').
> 
> It does not work on cygwin stackdump file in this way.
> Error: "occ.exe.stackdump" is not a core dump: File
> format not recognized

Re: [Opencxx-users] AST visualizer

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

Horacio J. Peña wrote:
> On Thu, Jul 08, 2004 at 03:30:03PM -0300, Horacio J. Peña wrote:
> 
>>>I comitted AST visualizer to HEAD. To play with it
>>>'cd opencxx/opencxx && make show-ast'.
> 
> 
> The CVS problem seems to be working now, but opencxx/PtreeVisualizer.h
> is missing (and there is no mention of it on opencxx-commits archive)

Sorry, I forgot to add this file. Already added (some 8 hours ago, so 
should be already in anonymous CVS too).

Thanks for letting me know!!!

Grzegorz

> 
> Saludos,
> 					HoraPe
> ---
> Horacio J. Peña
> ho...@co...
> ho...@un...

Re: [Opencxx-users] Cygwin problem

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

Grigorenko Dmitriy wrote:

> Your are right. I found that problem is in the lt_dlinit() call (the first
> call of the ltdl function). You can find it in
> the InitDynamicLoader() function in driver2.cc. I checked that sigfault
> heppens befor the first line of lt_dlinit and befor the first line of the
> main function in ltdl. (We have to add an empty main funcion in ltdl.c).
> I  investigated that in case of static linking occ which ltdl.o (instead of
> using -lltdl) it is all right!
> So I think that problem is in the linking process. Namely, I think what the
> lt_dlinit() function address is incorrect.

This sounds strangely familiar. I had lots of trouble with initialization
code that was due to the undefined order of global variable initialization.
We eventually replaced all global variables (in synopsis) by alternatives
(singletons, explicit initialization, etc.) and the problem disappeared.

May be there are somewhere some global variables left in opencxx...

Regards,
		Stefan

Re: [Opencxx-users] future directions

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

Grzegorz Jakacki wrote:

>> And I don't see a problem having two separate constructors, one operating
>> on Ptree pointers, the other on the typed counterpart.
> 
> 
> I am not sure if you get the exact picture. The "untyped" constructor 
> does not construct the NonLeaf auxiliary nodes. It is just:
> 
> 
>     PtreeIfStatement(Ptree* p, Ptree* q) : NonLeaf(p, q) {}
> 
> If we have another, "typed" constructor like this one:
> 
>     PtreeIfStatement(
>         PtreeExprStatement* cond
>       , PtreeExprStatement *th
>       , PtreeExprStatement* el
>     )
>       : NonLeaf(cond, new NonLeaf(th, new NonLeaf(el, NULL)))
>     {}
> 
> Then, as you noticed, there is a question of who owns auxiliary
> NonLeaf nodes (and, consequently, if ~PtreeIfStatement should delete them).

right, but I didn't mean the 'typed constructor' to construct any nodes
himself, but rather to take 'PtreeExprStatement' arguments instead of 'Ptree'.
The ownership semantics remains the same.

>> That sounds indeed like a bad idea. Either Ptrees
>> own their children, or they don't. 
> 
> 
> I agree. However I am not sure what you mean by "child". What is a 
> "child" of PtreeIfStatement node? Do you consider "else-part" to be a 
> "child" of PtreeIfStatement node?

yes.

> It is also not clear to me if you would like to keep the existing 
> representation of if-statement as three physical nodes or if you 
> eventually would like to modify PtreeIfStatement so that it becomes
> 
> struct PtreeIfStatement
> {
>     ...
>     PtreeExprStatement *cond_, *then_, *else_;
> };

the latter.

Regards,
		Stefan

Re: [Opencxx-users] AST visualizer

[Horacio <ho...@ti...>]

On Thu, Jul 08, 2004 at 03:30:03PM -0300, Horacio J. Pe=F1a wrote:
> > I comitted AST visualizer to HEAD. To play with it
> > 'cd opencxx/opencxx && make show-ast'.

The CVS problem seems to be working now, but opencxx/PtreeVisualizer.h
is missing (and there is no mention of it on opencxx-commits archive)

Saludos,
					HoraPe
---
Horacio J. Pe=F1a
ho...@co...
ho...@un...