opencxx-users

[Opencxx-users] Re: [opencxx] Beta version of a website

[Alexandre T. <kt...@fr...>]

Le mardi, 18 mar 2003, =E0 01:57 Europe/Paris, Grzegorz Jakacki a =E9crit=
 :

>
> Hi,
>
> As you may have noticed, the current contents of =20
> opencxx.sourceforge.net
> is not very encouraging to prospective users or developers. Moreover, =20
> we
> are lacking a portal with developers resources like CVS procedures =20
> (e.g.
> merging sandbox into head, rollback etc.) or coding guidelines.
>
> I prepared a new website and after consultation with Chiba, who =20
> currently
> maintains OpenC++ portal at his webpage, I am putting it for the weekly
> review at:
>
>     http://opencxx.sourceforge.net/testdrive/website/index.shtml
>
> The site is not fully functional yet and I need help with testing it.
>
> The source of the website is available as module 'website' in the CVS.
>
> The design goals were:
>
>   * simple HTML on the client side, viewable also with text browsers
>     (e.g. Lynx)
>   * low maintenance requirements (e.g. I want as much content as =20
> possible
>     to be generated automatically from CVS development tree; currently
>     documentation pages and credit pages are implemented in this =20
> fashion);
>
> Please review the website and let me know:
>
>   * what is buggy
>   * what is missing

The "Check-in procedure" link leads to a buggy page (text: [an error =20
occurred while processing this directive]).

Alex

------------------------------------------------------------------------=20
-
Alexandre Tolmos
E-mail:=A0...@fr...
ICQ: 92964905
------------------------------------------------------------------------=20
-
"Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
------------------------------------------------------------------------=20
-

[Opencxx-users] Re: [opencxx] Let's break OpenC++ up

[Stefan R. <sr...@ma...>]

Hello,

On Mon, Mar 17, 2003 at 04:43:53PM +0800, Grzegorz Jakacki wrote:
> On Fri, 14 Mar 2003, Stefan Reuther wrote:
> > I think, there are two problems, at least with the parser. The
> > interface consists of two parts, namely the Ptree descendants
> > and their contents.
> >
> > 1) Every Ptree descendant has a method "Translate" which calls
> >    a method of Walker. Adding a new Ptree class means adding a
> >    method to Walker.
> 
> This is the first sign of too little isolation between visitor (Walker)
> and visited class hierarchy (Ptree and derived classes) --- you cannot
> extend Ptree hierarchy without modifying Walker code.

I don't think it can be done much different. Ptree and Walker
have to "know each other". What needs to be improved is that it
can be detected at compile-time that a Walker descendant does no
longer match our tree.

> >    User code must override that method, or
> >    they'll (accidentially, maybe) run into the default behaviour
> >    which just recurses into the subtrees.
> 
> I am not sure if I understand you here. When the user adds the method of
> Walke, he/she is free to define the default behavious as he/she wants,
> right? Or maybe you mean, that *some* default behavious has to be
> defined, since the member function cannot be just left abstract, because
> otherwise user would make Walker class abstract?

Right now, the default behaviour for every Walker::TranslateXYZ
method is to recurse into the subtrees, and return the changed
tree. I'm trying to say that this behaviour is not optimal,
because it might break user code's expectations. Say, I write a
Walker where each TranslateXYZ method returns a particular node,
like this:
   Ptree* MyWalker::TranslateIfStatement(Ptree* p) {
       return new MyFunkyPtreeDescendant(p, 0);
   }
To be sure, I take walker.h and override all methods of Walker.
So I can now rightfully assume that this
  dynamic_cast<MyFunkyPtreeDescendant*>(walker.Translate(p)) != 0
holds.

If a new TranslateXYZ method is added to Walker, my code still
compiles but does no longer fulfill the above assertion. The
wired-in default behaviour doesn't match my use-case. I can't
say what to do with nodes I don't know about.

Solutions I propose:

- add a AbstractWalker class, where all methods are pure
  virtual. People concerned with the above problem (like me) can
  use that as a base class. Code using that class breaks when we
  add new productions, and forces people to update their code
  (or stay with the old version). Walker would be derived from
  that class.
- add a DefaultWalker class, where all TranslateXYZ methods
  call another function, like this:
     Ptree* DefaultWalker::TranslateIfStatement(Ptree* p) {
         return DefaultHandler(p);
     }
  This would let people choose their default behaviour. Having a
  Ptree::Clone would come in handy for this one.

Another nice thing to have would be a Walker returning other
things than Ptrees. I'm still unsure how that could work. We
have such a thing in the VFiasco project, but (Michael, please
look away) it's not perfect. We also have that which I called
"DefaultWalker" here.

> >    This problem can be
> >    solved with an abstract base class, so people who want to be
> >    paranoid can derive from that.
> 
> Right, but then they have to define traversals in all 'Translate()'
> overloads by themselves.

A good thing, in my opinion. When I want to generate code, I
want to be sure not to miss any node. For example, the recent
addition of the "typeid" operator caused our code to silently
translate
   typeinfo ti = typeid(p);
as
   typeinfo ti = p;

> >    Their code will automatically
> >    fail to compile when we add a new node type, which is a Good
> >    Thing(tm), IMHO.
> 
> It depends. When I am adding new node to store '__attribute__' GNU
> extension, I do not want old code to fail. I would prefere a design,
> in which I can do it so that new code can see '__attribute__' node,
> while old code does not see it.

That's what I meant with "node contents" below.

> > 2) The bigger problem is with the content of the nodes. For
> >    example, the new wide-char constants turn into Leafs. Old
> >    programs might assume that all Leafs are either numeric, char
> >    or string literals, and break now. Or, my "if(decl)" patch[1]
> >    would add the new property that the third child of "if" can
> >    be a declaration instead of an expression. I don't see a good
> >    solution for that problem. Okay, one could go away from the
> >    Lispy data structure towards a more "explicit" syntax, i.e.
> >      class PtreeIfStatement {
> >        Ptree *if_keyword, *left_paren, *right_paren;
> >        PtreeExpressionOrDeclaration *condition;
> >        PtreeStatement *controlled_statement;
> >      };
> 
> Precisely. In fact OpenC++ does not use the "Lispy data structure"
> (I really like this term!). The abstract datatypes that you envision
> are already present --- look at the names of Metaclass methods ---
> they are candidates for the new syntax hierarchy. Such hierarchy
> would be much safer to play with: instead of
> "ifthenelse->Car()->Car()->Cdr()", which potentially can coredump
> at each arrow, one would conveniently write "ifthenelse->GetThen()".

Sir, where do I sign? :-)

Still, in the *current* code, TranslateIfStatement takes a
Ptree* and not a PtreeIfStatement*, although the latter would be
a safe assumption for most cases.

> Also if sometime in the future the representation of "PtreeIfStatement"
> node changes, then client using "ifthenelse->GetThen()" would feel good,
> while the client using "ifthenelse->Car()->Car()->Cdr()" would have
> to fix his/her Car()s and Cdr()s.

Far future, because nowadays everyone uses Car() and Cdr().

One problem we'd still have to solve is that people can still
construct invalid trees. For example, if I have a Ptree
representing "if (cond) statement;", someone could Snoc a "&" at
the end, although that'd yield invalid syntax, and nothing could
prevent it (although adding an "else" and another statement
still must be valid). That's what I meant with "Lispy" data
structure: in Lisp, you have structured lists, too, but no-one
can prevent you from mangling them somehow.

> >    but that would need an enormous amount of work and break
> >    everything.
> 
> If you just throw away Ptree's and introduce new hierarchy, then yes.
> 
> But there is much better way: one can wrap raw tree implementation (like
> Ptree) into better-structured one using wrapper types (which are
> implementation of Proxy pattern). The technique I am trying to come up with
> for it is mainly based on so-called traits (classes similar to e.g.
> numeric_limits<> from Standard Library) and type-safe visitation (similar to
> technique used in boost::visitor).
> 
> Introduction of wrappers does not break any existing code, but makes the new
> code much better isolated from the actual tree representation, so changes
> in the tree representation (even adding new nodes) does not break the new
> code.

I think adding those accessor functions ("GetCondition",
"GetThen", "GetIf") would be a good start, although it doesn't
work nicely for everything: for example, PtreeDeleteExpr can
have the following forms:
         [:: delete expr]
         [:: delete \[ \] expr]
         [delete expr]
         [delete \[ \] expr]
I'm unsure whether we should "regularize" that, for example, as
         [::  delete nil     expr]
         [::  delete [\[ \]] expr]
         [nil delete nil     expr]
         [nil delete [\[ \]] expr]
Still, this would break a lot of stuff. There are quite a number
of places like this in the parse tree. I could (try to) make up
a complete list. In my original posting, I mentioned only
"un-regular" places in Declarators.

Another nice thing to have would be a "better" class hierarchy.
Improvements I see so far are:
- all PtreeFooExpr should share a common base class,
  PtreeExpression
- all PtreeFooStatement should share a common base class,
  PtreeStatement. Hmmm, this seems to collide with PtreeBrace
  and PtreeDeclaration, so maybe leave it out.
- PtreeDeclaration and PtreeExpression should have a common base
  class (needed for my if(condition) thing)
Anything else? This should not break anything.

> > [1] Since the CVS code currently can't be built, I'll wait with
> > checking it in.
> 
> Ok.

It's in now.

Change in the parse tree: the third child of if/while/switch may
now be a PtreeDeclaration instead of an expression :-)

By the way, I get a strange message I can't interpret:
# Mailing ope...@li......
# Generating notification message...
# Generating notification message... done.
# Mailing ope...@li......
# Generating notification message...
# Traceback (innermost last):
#   File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 322, in ?
#     main()
#   File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 315, in main
#     blast_mail(subject, people, specs[1:], contextlines, fromhost)
#   File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 240, in blast_mail
#     print calculate_diff(file, contextlines)
#   File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 139, in calculate_diff
#     file, oldrev, newrev = string.split(filespec, ',')
# ValueError: unpack list of wrong size

Doesn't look like any interpreter I know :-)

> > > But now comes the problem: when we just extend Frontend itself, without
> > > proper support in Translator (e.g. your patches will make 'if ({...}) '
> > > parse, but Translator will choke on it), we do not have way to add tests
> > > that make sure the new Frontend functionality works.
> >
> > My 1) is a partial solution.
> 
> But this requires adding *some* support of new nodes to the translator
> anyway, right?

Yes, but I can't seem to find a way around that, because there
is no universal fallback. Some want just to recurse into the new
nodes, some do not want to miss them.

> > > BTW: Over a year ago there was a resolution on this forum to factor out the
> > > Driver subsystem and make it a shell script (for easier maintenance
> > > and to make underlying compiler/preproc/linker settable with Autoconf).
> >
> > Personally, I don't care whether the driver is in C, Perl, Shell
> > or Intercal.
> 
> I do, because I am responding to bug reports :-)
> (Seriously: shell is the only solution that does not have to duplicate
> libtool functionality, e.g. to know how to install shared library on the
> given platform).

Okay, I overlooked that shared library thing.

> > What about generating a ".h" file and including that in the
> > driver? In another project of mine, I have this in "configure.in":
[...]
> > This creates a file ("arch/platform.h") which contains the
> > specified code, with shell variables expanded (Disclaimer: I'm
> > not an Autoconf expert, maybe what I did can be done much
> > easier).
> 
> AC_DEFINE is the solution you are looking for.

Whoops? I wonder how I could have missed that :-P

> What you suggest is reasonable for e.g. setting compiler or setting the
> proper shared lib extension (.so, .dynlib etc.), but apart of those there is
> *functionality* which is necessary in driver. How will you pass the
> knowledge about the correct way of installing shared library? On some
> platforms you just do 'cp'. On some you also have to set up dynamic linker
> somehow. [snip]

I was mainly thinking about configuring compiler names etc. into
occ. I have "g++-2.95" and "g++-3.2", and to select one I
install a symlink in $HOME/bin. I'd like to be able to choose
that when I compile or - even better - run occ. For shared
libraries, you're absolutely right.


  Stefan

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

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

On Tue, 18 Mar 2003, Alexandre Tolmos wrote:

>
> Please disregard previous message; rollback procedure successfully
> completed. Back to normal operation.

Thanks much for fixing this.

Also thanks for testing the rollback procedure. I will try to make it int=
o
a script to make it less tedious.

Best regards
Grzegorz


> Sorry for the inconvenience.
>
> >
> > Le samedi, 15 mar 2003, =E0 14:25 Europe/Paris, Grzegorz Jakacki a =E9=
crit
> > :
> >
> >> Alexandre Tolmos writes:
> >>
> >>> I'm not expert at using Cvs and I see no command to do a rollback;
> >>> can  you help?
> >>
> >> Wow, it is harder that I thougt (or maybe I am missing something).
> >> This is what I came up with:
> >> (1) Check out working copy
> >>    cvs co opencxx
> >>    cd opencxx
> >>    [sticky tag: none, sticky date: none]
> >> (2) Use 'cvs log' on one of files that need rollback to
> >>    find out to what date you want to roll back.
> >>    [sticky tag: none, sticky date: none]
> >> (3) Go back to the rollback date, e.g.
> >>    cvs update -D'2003/03/15 12:07:26 UTC'
> >>    WARNING: Remember to specify "UTC". 'cvs status' give you times i=
n
> >> UTC,
> >>    but other commands accept date in your local time, unless you
> >> specify
> >>    UTC.
> >>    [sticky tag: none, sticky date: 2003.03.15.12.07.26]
> >> (3) Tag the rollback point:
> >>    cvs tag sandbox_USERID_rollback_point
> >>    [sticky tag: none, sticky date: 2003.03.15.12.07.26]
> >> (4) Get head revision in your working dir
> >>    cvs update -A
> >>    [sticky tag: none, sticky date: none]
> >> (5) Branch out a sandbox
> >>    cvs tag -b sandbox_USERID_rollback_result
> >>    [sticky tag: none, sticky date: none]
> >> (6) Switch to sandbox
> >>    cvs update -r sandbox_USERID_rollback_result
> >>    [sticky tag: sandbox_USERID_rollback_result, sticky date: none]
> >> (7) Merge reversed changes from rollback point
> >>    to rollback result into rollback_result branch
> >>    cvs update \
> >>        -jsandbox_USERID_rollback_result \
> >>        -jsandbox_USERID_rollback_point
> >>    WARNING: Order of '-j' options is essential!
> >>    [sticky tag: sandbox_USERID_rollback_result, sticky date: none]
> >
> > The merging does not work:
> >
> > bash-2.05a$ cvs update -jsandbox_kthulhu_rollback_result
> > -jsandbox_kthulhu_rollback_point
> > kt...@cv...'s password:
> > cvs [server aborted]: no such tag sandbox_kthulhu_rollback_point
> >
> > Alex
> >
> > ---------------------------------------------------------------------=
--
> > --
> > Alexandre Tolmos
> > E-mail:=A0...@fr...
> > ICQ: 92964905
> > ---------------------------------------------------------------------=
--
> > --
> > "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
> > ---------------------------------------------------------------------=
--
> > --
> >
> >
> >
> >
> >
> -----------------------------------------------------------------------=
-
> -
> Alexandre Tolmos
> E-mail:=A0...@fr...
> ICQ: 92964905
> -----------------------------------------------------------------------=
-
> -
> "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
> -----------------------------------------------------------------------=
-
> -
>
>
>
>
>

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

[Michael H. <ho...@sa...>]

I wrote:

> The head branch has been broken for almost a week now.  Would anyone
> mind if I'd just go ahead an fix it?

I just noticed that Alexandre fixed it 40 minutes ago.  Never mind!
;-)

Michael
-- 
ho...@sa..., ho...@in...
http://www.sax.de/~hohmuth/

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

[Alexandre T. <kt...@fr...>]

Please disregard previous message; rollback procedure successfully =20
completed. Back to normal operation. Sorry for the inconvenience.

>
> Le samedi, 15 mar 2003, =E0 14:25 Europe/Paris, Grzegorz Jakacki a =E9c=
rit =20
> :
>
>> Alexandre Tolmos writes:
>>
>>> I'm not expert at using Cvs and I see no command to do a rollback; =20
>>> can  you help?
>>
>> Wow, it is harder that I thougt (or maybe I am missing something).
>> This is what I came up with:
>> (1) Check out working copy
>>    cvs co opencxx
>>    cd opencxx
>>    [sticky tag: none, sticky date: none]
>> (2) Use 'cvs log' on one of files that need rollback to
>>    find out to what date you want to roll back.
>>    [sticky tag: none, sticky date: none]
>> (3) Go back to the rollback date, e.g.
>>    cvs update -D'2003/03/15 12:07:26 UTC'
>>    WARNING: Remember to specify "UTC". 'cvs status' give you times in =
=20
>> UTC,
>>    but other commands accept date in your local time, unless you =20
>> specify
>>    UTC.
>>    [sticky tag: none, sticky date: 2003.03.15.12.07.26]
>> (3) Tag the rollback point:
>>    cvs tag sandbox_USERID_rollback_point
>>    [sticky tag: none, sticky date: 2003.03.15.12.07.26]
>> (4) Get head revision in your working dir
>>    cvs update -A
>>    [sticky tag: none, sticky date: none]
>> (5) Branch out a sandbox
>>    cvs tag -b sandbox_USERID_rollback_result
>>    [sticky tag: none, sticky date: none]
>> (6) Switch to sandbox
>>    cvs update -r sandbox_USERID_rollback_result
>>    [sticky tag: sandbox_USERID_rollback_result, sticky date: none]
>> (7) Merge reversed changes from rollback point
>>    to rollback result into rollback_result branch
>>    cvs update \
>>        -jsandbox_USERID_rollback_result \
>>        -jsandbox_USERID_rollback_point
>>    WARNING: Order of '-j' options is essential!
>>    [sticky tag: sandbox_USERID_rollback_result, sticky date: none]
>
> The merging does not work:
>
> bash-2.05a$ cvs update -jsandbox_kthulhu_rollback_result =20
> -jsandbox_kthulhu_rollback_point
> kt...@cv...'s password:
> cvs [server aborted]: no such tag sandbox_kthulhu_rollback_point
>
> Alex
>
> -----------------------------------------------------------------------=
=20
> --
> Alexandre Tolmos
> E-mail:=A0...@fr...
> ICQ: 92964905
> -----------------------------------------------------------------------=
=20
> --
> "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
> -----------------------------------------------------------------------=
=20
> --
>
>
>
>
>
------------------------------------------------------------------------=20
-
Alexandre Tolmos
E-mail:=A0...@fr...
ICQ: 92964905
------------------------------------------------------------------------=20
-
"Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
------------------------------------------------------------------------=20
-

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

[Michael H. <ho...@sa...>]

Grzegorz Jakacki <ja...@he...> writes:

> [ long explanation of how to undo CVS breakage ]

The head branch has been broken for almost a week now.  Would anyone
mind if I'd just go ahead an fix it?

Thanks,
Michael
-- 
ho...@sa..., ho...@in...
http://www.sax.de/~hohmuth/

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

[Alexandre T. <kt...@fr...>]

Le samedi, 15 mar 2003, =E0 14:25 Europe/Paris, Grzegorz Jakacki a =E9cri=
t :

> Alexandre Tolmos writes:
>
>> I'm not expert at using Cvs and I see no command to do a rollback; =20
>> can  you help?
>
> Wow, it is harder that I thougt (or maybe I am missing something).
> This is what I came up with:
> (1) Check out working copy
>    cvs co opencxx
>    cd opencxx
>    [sticky tag: none, sticky date: none]
> (2) Use 'cvs log' on one of files that need rollback to
>    find out to what date you want to roll back.
>    [sticky tag: none, sticky date: none]
> (3) Go back to the rollback date, e.g.
>    cvs update -D'2003/03/15 12:07:26 UTC'
>    WARNING: Remember to specify "UTC". 'cvs status' give you times in =20
> UTC,
>    but other commands accept date in your local time, unless you =20
> specify
>    UTC.
>    [sticky tag: none, sticky date: 2003.03.15.12.07.26]
> (3) Tag the rollback point:
>    cvs tag sandbox_USERID_rollback_point
>    [sticky tag: none, sticky date: 2003.03.15.12.07.26]
> (4) Get head revision in your working dir
>    cvs update -A
>    [sticky tag: none, sticky date: none]
> (5) Branch out a sandbox
>    cvs tag -b sandbox_USERID_rollback_result
>    [sticky tag: none, sticky date: none]
> (6) Switch to sandbox
>    cvs update -r sandbox_USERID_rollback_result
>    [sticky tag: sandbox_USERID_rollback_result, sticky date: none]
> (7) Merge reversed changes from rollback point
>    to rollback result into rollback_result branch
>    cvs update \
>        -jsandbox_USERID_rollback_result \
>        -jsandbox_USERID_rollback_point
>    WARNING: Order of '-j' options is essential!
>    [sticky tag: sandbox_USERID_rollback_result, sticky date: none]

The merging does not work:

bash-2.05a$ cvs update -jsandbox_kthulhu_rollback_result =20
-jsandbox_kthulhu_rollback_point
kt...@cv...'s password:
cvs [server aborted]: no such tag sandbox_kthulhu_rollback_point

Alex

------------------------------------------------------------------------=20
-
Alexandre Tolmos
E-mail:=A0...@fr...
ICQ: 92964905
------------------------------------------------------------------------=20
-
"Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
------------------------------------------------------------------------=20
-

[Opencxx-users] [opencxx] Beta version of a website

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

Hi,

As you may have noticed, the current contents of opencxx.sourceforge.net
is not very encouraging to prospective users or developers. Moreover, we
are lacking a portal with developers resources like CVS procedures (e.g.
merging sandbox into head, rollback etc.) or coding guidelines.

I prepared a new website and after consultation with Chiba, who currently
maintains OpenC++ portal at his webpage, I am putting it for the weekly
review at:

    http://opencxx.sourceforge.net/testdrive/website/index.shtml

The site is not fully functional yet and I need help with testing it.

The source of the website is available as module 'website' in the CVS.

The design goals were:

  * simple HTML on the client side, viewable also with text browsers
    (e.g. Lynx)
  * low maintenance requirements (e.g. I want as much content as possible
    to be generated automatically from CVS development tree; currently
    documentation pages and credit pages are implemented in this fashion);

Please review the website and let me know:

  * what is buggy
  * what is missing

Best regards
Grzegorz

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

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

On Mon, 17 Mar 2003, Alexandre Tolmos wrote:

>
> Le samedi, 15 mar 2003, =E0 14:25 Europe/Paris, Grzegorz Jakacki a =E9c=
rit :
>
> > Alexandre Tolmos writes:
> >
> >> I'm not expert at using Cvs and I see no command to do a rollback;
> >> can  you help?
> >
> > Wow, it is harder that I thougt (or maybe I am missing something).
> > This is what I came up with:
> > (1) Check out working copy
> >    cvs co opencxx
> >    cd opencxx
> >    [sticky tag: none, sticky date: none]
> > (2) Use 'cvs log' on one of files that need rollback to
> >    find out to what date you want to roll back.
> >    [sticky tag: none, sticky date: none]
> > (3) Go back to the rollback date, e.g.
> >    cvs update -D'2003/03/15 12:07:26 UTC'
> >    WARNING: Remember to specify "UTC". 'cvs status' give you times in
> > UTC,
> >    but other commands accept date in your local time, unless you
> > specify
> >    UTC.
> >    [sticky tag: none, sticky date: 2003.03.15.12.07.26]
> > (3) Tag the rollback point:
> >    cvs tag sandbox_USERID_rollback_point
> >    [sticky tag: none, sticky date: 2003.03.15.12.07.26]
> > (4) Get head revision in your working dir
> >    cvs update -A
> >    [sticky tag: none, sticky date: none]
>
> Do I need to change the working directory? If the rollback point tag is
> created locally then it might be erased.

No. You do everything in the same directory. Tags in CVS are always
global (that's why we try to use "sandbox_USER" prefix to resolve
potential tag names conflicts).

If in doubt, set up a small repository with one file just on your machine
and run the procedure on it first (this is what I did):

    $ mkdir repo
    $ mkdir test
    $ export CVSROOT=3D`pwd`/repo
    $ cvs init
    $ cd test
    $ cat >test.cc <<END
    > line1
    > line2
    > line3
    END
    $ test
    $ cvs -d import -m '' test start kthulu
    N test/file.txt

    No conflicts created by this import

    $ cd ..
    $ rm -r test
    $ cvs -d co test
    cvs checkout: Updating test
    U test/file.txt
    $ cd test
    $ # edit file.txt
    $ commit
    cvs commit: Examining .
    Checking in file.txt;
    .../repo/test/file.txt,v  <--  file.txt
    new revision: 1.2; previous revision: 1.1
    done
    $ cd ..
    $ rm -r test

Now you have a repository with two revisions of the file. You may try the
procedure to revert the file to the first revision.

Hope this helps.

Best regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] Re: [opencxx] Let's break OpenC++ up

[James M. D. <mdu...@ya...>]

--- Stefan Reuther <sr...@ma...> wrote:
> whether it fits into its imagination. For example, my "if"
> handling code starts with (the equivalent of)
>    assert(p->First()->Eq("if"));
>    assert(p->Second()->Eq('('));
>    assert(p->Nth(3)->Eq(')'));

This is exactly the interface that needs to be rethought to make
openc++ more valuable. The current usage of the positions, and the
exposure of makes OpenC++ not very reusable.

If we have an If object, this should read like  
this is just a simple class model :
class BaseNode
{};// the base class of the tree
class Token
{
public :
  int Eq(const char * pstr){
  };
}; // the base class of the leaves 

class BaseNodeRef
{
  BaseNode * _p;
public:
  BaseNodeRef(BaseNode * p) : 
     _p(p)
  {
  };
  void assert(int x){
    
  }
  BaseNode * p()
  {
    return _p;
  }

  Token * Nth(int p)
  {
    return 0;// todo
  }
  
};

class IfNode  : public BaseNodeRef
{
  enum IfValues {
    OPENCXX_IF_NAME        = 1,
    OPENCXX_IF_OPENPAREN   = 2,
    OPENCXX_IF_CLOSEPAREN  = 3
  } ;
public : 
   IfNode(BaseNode * p)
      : BaseNodeRef (p)
   {

   }
   void assert()
   {
      BaseNodeRef::assert(GetToken()->Eq("if"));
      BaseNodeRef::assert(GetOpenP()->Eq("("));
      BaseNodeRef::assert(GetCloseP()->Eq(")"));
   }
   Token * GetToken()
   {
     return Nth(OPENCXX_IF_NAME);
   }
   Token * GetOpenP()
   {
     return Nth(OPENCXX_IF_OPENPAREN);
   } 
   Token * GetCloseP()
   {
     return Nth(OPENCXX_IF_CLOSEPAREN);
   } 
};


=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

[Alexandre T. <kt...@fr...>]

Le samedi, 15 mar 2003, =E0 14:25 Europe/Paris, Grzegorz Jakacki a =E9cri=
t :

> Alexandre Tolmos writes:
>
>> I'm not expert at using Cvs and I see no command to do a rollback; =20
>> can  you help?
>
> Wow, it is harder that I thougt (or maybe I am missing something).
> This is what I came up with:
> (1) Check out working copy
>    cvs co opencxx
>    cd opencxx
>    [sticky tag: none, sticky date: none]
> (2) Use 'cvs log' on one of files that need rollback to
>    find out to what date you want to roll back.
>    [sticky tag: none, sticky date: none]
> (3) Go back to the rollback date, e.g.
>    cvs update -D'2003/03/15 12:07:26 UTC'
>    WARNING: Remember to specify "UTC". 'cvs status' give you times in =20
> UTC,
>    but other commands accept date in your local time, unless you =20
> specify
>    UTC.
>    [sticky tag: none, sticky date: 2003.03.15.12.07.26]
> (3) Tag the rollback point:
>    cvs tag sandbox_USERID_rollback_point
>    [sticky tag: none, sticky date: 2003.03.15.12.07.26]
> (4) Get head revision in your working dir
>    cvs update -A
>    [sticky tag: none, sticky date: none]

Do I need to change the working directory? If the rollback point tag is =20
created locally then it might be erased.

Alex

------------------------------------------------------------------------=20
-
Alexandre Tolmos
E-mail:=A0...@fr...
ICQ: 92964905
------------------------------------------------------------------------=20
-
"Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
------------------------------------------------------------------------=20
-

[Opencxx-users] Re: [opencxx] Let's break OpenC++ up

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

On Fri, 14 Mar 2003, Stefan Reuther wrote:

> Hello,
>
> On Thu, Mar 13, 2003 at 01:52:52PM +0800, Grzegorz Jakacki wrote:
> > This is very important, as this allows somebody who is not a guru to come
> > and commit some fixes without fear that he/she breaks some distant parts
> > of the package. Our testsuite is pathetically small at the moment, but
> > it already helps and I believe that it can grow.
>
> I think, there are two problems, at least with the parser. The
> interface consists of two parts, namely the Ptree descendants
> and their contents.
>
> 1) Every Ptree descendant has a method "Translate" which calls
>    a method of Walker. Adding a new Ptree class means adding a
>    method to Walker.

This is the first sign of too little isolation between visitor (Walker)
and visited class hierarchy (Ptree and derived classes) --- you cannot
extend Ptree hierarchy without modifying Walker code.

>    User code must override that method, or
>    they'll (accidentially, maybe) run into the default behaviour
>    which just recurses into the subtrees.

I am not sure if I understand you here. When the user adds the method of
Walke, he/she is free to define the default behavious as he/she wants,
right? Or maybe you mean, that *some* default behavious has to be
defined, since the member function cannot be just left abstract, because
otherwise user would make Walker class abstract?

>    This problem can be
>    solved with an abstract base class, so people who want to be
>    paranoid can derive from that.

Right, but then they have to define traversals in all 'Translate()'
overloads by themselves.

>    Their code will automatically
>    fail to compile when we add a new node type, which is a Good
>    Thing(tm), IMHO.

It depends. When I am adding new node to store '__attribute__' GNU
extension, I do not want old code to fail. I would prefere a design,
in which I can do it so that new code can see '__attribute__' node,
while old code does not see it.

>
>    So far, everything nice.
>
> 2) The bigger problem is with the content of the nodes. For
>    example, the new wide-char constants turn into Leafs. Old
>    programs might assume that all Leafs are either numeric, char
>    or string literals, and break now. Or, my "if(decl)" patch[1]
>    would add the new property that the third child of "if" can
>    be a declaration instead of an expression. I don't see a good
>    solution for that problem. Okay, one could go away from the
>    Lispy data structure towards a more "explicit" syntax, i.e.
>      class PtreeIfStatement {
>        Ptree *if_keyword, *left_paren, *right_paren;
>        PtreeExpressionOrDeclaration *condition;
>        PtreeStatement *controlled_statement;
>      };

Precisely. In fact OpenC++ does not use the "Lispy data structure"
(I really like this term!). The abstract datatypes that you envision
are already present --- look at the names of Metaclass methods ---
they are candidates for the new syntax hierarchy. Such hierarchy
would be much safer to play with: instead of
"ifthenelse->Car()->Car()->Cdr()", which potentially can coredump
at each arrow, one would conveniently write "ifthenelse->GetThen()".
Also if sometime in the future the representation of "PtreeIfStatement"
node changes, then client using "ifthenelse->GetThen()" would feel good,
while the client using "ifthenelse->Car()->Car()->Cdr()" would have
to fix his/her Car()s and Cdr()s.

>    but that would need an enormous amount of work and break
>    everything.

If you just throw away Ptree's and introduce new hierarchy, then yes.

But there is much better way: one can wrap raw tree implementation (like
Ptree) into better-structured one using wrapper types (which are
implementation of Proxy pattern). The technique I am trying to come up with
for it is mainly based on so-called traits (classes similar to e.g.
numeric_limits<> from Standard Library) and type-safe visitation (similar to
technique used in boost::visitor).

Introduction of wrappers does not break any existing code, but makes the new
code much better isolated from the actual tree representation, so changes
in the tree representation (even adding new nodes) does not break the new
code.

>    Plus, OpenC++ started as a meta-object protocol
>    and not as a parser library, so I'm perfectly happy when it
>    fulfills its primary purpose best :-)

As C++ changes the meta-object protocol has to change also. Apart of that,
OpenC++ is the most reasonable non-GPL'd C++ frontend approximation
I know of.

> [1] Since the CVS code currently can't be built, I'll wait with
> checking it in.

Ok.

> > But now comes the problem: when we just extend Frontend itself, without
> > proper support in Translator (e.g. your patches will make 'if ({...}) '
> > parse, but Translator will choke on it), we do not have way to add tests
> > that make sure the new Frontend functionality works.
>
> My 1) is a partial solution.

But this requires adding *some* support of new nodes to the translator
anyway, right?

> 2) can be solved by very defensive
> programming.

Which is a maintenance nightmare and I would like to avoid it.

> My code checks every Ptree node it encounters
> whether it fits into its imagination. For example, my "if"
> handling code starts with (the equivalent of)
>    assert(p->First()->Eq("if"));
>    assert(p->Second()->Eq('('));
>    assert(p->Nth(3)->Eq(')'));
> so if someone now adds an "unless" statement which also
> generates a PtreeIfStatement ("it's almost the same"), my code
> will see that it can't handle it. I think we can't get much
> better.

Not with the design in place.

> > BTW: Over a year ago there was a resolution on this forum to factor out the
> > Driver subsystem and make it a shell script (for easier maintenance
> > and to make underlying compiler/preproc/linker settable with Autoconf).
>
> Personally, I don't care whether the driver is in C, Perl, Shell
> or Intercal.

I do, because I am responding to bug reports :-)
(Seriously: shell is the only solution that does not have to duplicate
libtool functionality, e.g. to know how to install shared library on the
given platform).

> What about generating a ".h" file and including that in the
> driver? In another project of mine, I have this in "configure.in":
> ----8<----
> define(CREATE1, [AC_OUTPUT_COMMANDS([echo "creating $1..."
> cat >conftest.tmp <<_EOF
> $2
> _EOF
> if cmp -s $1 conftest.tmp; then
>   echo $1 is unchanged
>   rm -f conftest.tmp
> else
>   rm -f $1
>   mv conftest.tmp $1
> fi])])dnl
>
> CREATE1(arch/platform.h, [#ifndef PCC_V2_ARCH_PLATFORM_H
> #define PCC_V2_ARCH_PLATFORM_H
> #define PCC2_SRCDIR "`cd "$srcdir" && pwd`"
> #define PCC2_DATADIR "$pdatadir"
> #include "arch/unix/platform.h"
> #endif
> ])
> ----8<----
> This creates a file ("arch/platform.h") which contains the
> specified code, with shell variables expanded (Disclaimer: I'm
> not an Autoconf expert, maybe what I did can be done much
> easier).

AC_DEFINE is the solution you are looking for.

What you suggest is reasonable for e.g. setting compiler or setting the
proper shared lib extension (.so, .dynlib etc.), but apart of those there is
*functionality* which is necessary in driver. How will you pass the
knowledge about the correct way of installing shared library? On some
platforms you just do 'cp'. On some you also have to set up dynamic linker
somehow. On yet other platforms you have to run special program on the new
shared library to activate it. On some you have to make appropriate
symlinks. I do not want to maintain code that takes care of all this,
especially that this code has already been written and is called libtool.

> In addition, setting these variables with options to the driver
> is a nice thing to have. Shouldn't be too hard. I'm currently
> fiddling around with symlinks in $HOME/bin.

I do not quite understand. What do you use symlinks for?

> Not too great :-P
> On the other hand, there's always the option to just translate
> the source (-E) and compile manually.

And that was basically what I would like occ executable to do. No more, no
less.

Best regards
Grzegorz

PS: I promised to prepare a write-up on the solution I have in mind, but
although I was trying hard thorughout the weekend, I still do not have it in
satisfactory form. Hopefully I will be able to mail it tomorrow. G.


##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] Re: [opencxx] Let's break OpenC++ up

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

On Sun, 16 Mar 2003, James Michael DuPont wrote:

>
> --- Grzegorz Jakacki <ja...@he...> wrote:
> > On Thu, 13 Mar 2003, Michael Hohmuth wrote:
> > > (Just as an aside: Would you mind posting a list of the projects
> > you
> > > know that use OpenC++ to this list or the project's homepage?  I
> > would
> > > like to have a look at them, and I really learned a lot from
> > looking
> > > at the Synopsis source code, for example.)
> >
> > * Introspector
>
> I have not gotten up to using OpenC++ just yet. However I do see
> OpenC++ as an inspiriation.

Sorry, I was under impression that you are using OpenC++ as code base.

Best regards
Grzegorz

> Hopefully I can help, and am ashamed that I
> have only been making empty promises.
>
> Currently I am working on www.dotgnu.org and www.Swig.org, when that
> work is completed, I will be able to propose some interfaces into
> openc++ that will preserve the openc++, but also tie it into the global
> metadata exchange that I envision.
>
> mike
>
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Web Hosting - establish your business online
> http://webhosting.yahoo.com
>
>

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] [opencxx] Re: [Opencxx-commits] =?gb2312?B?YSBxdWVzdGlvbg==?=

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

Hi,

I am sorry, I abused 'opencxx-commits'.

Let's stick to the rule that we do not mail to this list manually (just b=
y
the CVS script).

Regards
GJ

On Mon, 17 Mar 2003, Grzegorz Jakacki wrote:

> On Sun, 16 Mar 2003, pillarsun wrote:
>
> > Dear OpenC++ maintainers:
> >      I wonder if openC++ can be compiled under  Sco unix open server =
5.06
> > or  Linux Redhat 7.0 ?
> >      I tried both openc++ 2.5 and openc++2.6, but failed.
> >      Can you  help me in these questions ?
>
> Hopefully yes. Please:
>
> (1) Untar 2.6.1
> (2) ./configure >configure.log 2>&1
> (3) ./make test >make.log 2>&1
> (4) Send files 'config.log', 'configure.log' and 'make.log'
>
> Best regards
> Grzegorz
>
>
> >      Thank you!
> >
> >                     SunQingyan
> >
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > =CD=F8=D2=D7VIP=CA=D5=B7=D1=D3=CA=CF=E4 =B3=C9=B9=A6=C8=CB=CA=BF=B5=C4=
=D7=EE=BC=D1=D1=A1=D4=F1=A3=A1          http://vip.163.com/
> > =C3=B5=B9=E5=A1=A2=C7=C9=BF=CB=C1=A6=A1=A2=BA=CD=C7=E9=C2=C2=B2=AC=BD=
=F0=D7=EA=BD=E4=A3=A1                  http://vip.163.com/lover/new_love.=
jsp
> > =B4=BA=CC=EC=B5=BD=C1=CB=B9=C2=B6=C0=B5=C4=C4=E3=BB=B9=B2=BB=D4=BC=BB=
=E1 =D4=BC=BB=E1=C6=E4=CA=B5=BA=DC=BC=F2=B5=A5            http://dating.1=
63.com/
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:Crypto Challenge is now open!
> > Get cracking and register here for some mind boggling fun and
> > the chance of winning an Apple iPod:
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> > _______________________________________________
> > Opencxx-commits mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opencxx-commits
> >
> >
>
> ##################################################################
> # Grzegorz Jakacki                       Huada Electronic Design #
> # Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
> # tel. +86-10-64365577 x2074               Beijing 100015, China #
> # Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
> ##################################################################
>
>

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] Re: [opencxx] Let's break OpenC++ up

[James M. D. <mdu...@ya...>]

--- Grzegorz Jakacki <ja...@he...> wrote:
> On Thu, 13 Mar 2003, Michael Hohmuth wrote:
> > (Just as an aside: Would you mind posting a list of the projects
> you
> > know that use OpenC++ to this list or the project's homepage?  I
> would
> > like to have a look at them, and I really learned a lot from
> looking
> > at the Synopsis source code, for example.)
> 
> * Introspector

I have not gotten up to using OpenC++ just yet. However I do see
OpenC++ as an inspiriation. Hopefully I can help, and am ashamed that I
have only been making empty promises. 

Currently I am working on www.dotgnu.org and www.Swig.org, when that
work is completed, I will be able to propose some interfaces into
openc++ that will preserve the openc++, but also tie it into the global
metadata exchange that I envision.

mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

[Opencxx-users] [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

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

Alexandre Tolmos writes:=20

>=20
> Le samedi, 15 mar 2003, =E0 14:25 Europe/Paris, Grzegorz Jakacki a =E9c=
rit :=20
>=20
>>> I'm not expert at using Cvs and I see no command to do a rollback;  c=
an =20
>>> you help?
>>=20
>> Wow, it is harder that I thougt (or maybe I am missing something).
>> This is what I came up with:
>> (1) Check out working copy
>>    cvs co opencxx
>>    cd opencxx
>>    [sticky tag: none, sticky date: none]
>> (2) Use 'cvs log' on one of files that need rollback to
>>    find out to what date you want to roll back.
>>    [sticky tag: none, sticky date: none]
>> (3) Go back to the rollback date, e.g.
>>    cvs update -D'2003/03/15 12:07:26 UTC'
>>    WARNING: Remember to specify "UTC". 'cvs status' give you times in =
=20
>> UTC,
>>    but other commands accept date in your local time, unless you  spec=
ify
>>    UTC.
>>    [sticky tag: none, sticky date: 2003.03.15.12.07.26]
>> (3) Tag the rollback point:
>>    cvs tag sandbox_USERID_rollback_point
>=20
> Heck, does not work:
> verifytag: authorization of tag `sandbox_kthulhu_rollback_point' for  u=
ser=20
> `kthulhu' failed
> verifytag: please stick to these tag formats:
> verifytag:     sandbox_kthulhu
> verifytag:     sandbox_kthulhu_*
> verifytag: contact ja...@us... for more info
> verifytag: to change authorizations modify CVSROOT/verifytag
> cvs server: Pre-tag check failed

Fixed. Sorry, my bug (in verifytag).=20

Regards
Grzegorz=20

>>    [sticky tag: none, sticky date: 2003.03.15.12.07.26]
>> (4) Get head revision in your working dir
>>    cvs update -A
>>    [sticky tag: none, sticky date: none]
>> (5) Branch out a sandbox
>>    cvs tag -b sandbox_USERID_rollback_result
>>    [sticky tag: none, sticky date: none]
>> (6) Switch to sandbox
>>    cvs update -r sandbox_USERID_rollback_result
>>    [sticky tag: sandbox_USERID_rollback_result, sticky date: none]
>> (7) Merge reversed changes from rollback point
>>    to rollback result into rollback_result branch
>>    cvs update \
>>        -jsandbox_USERID_rollback_result \
>>        -jsandbox_USERID_rollback_point
>>    WARNING: Order of '-j' options is essential!
>>    [sticky tag: sandbox_USERID_rollback_result, sticky date: none]=20
>>=20
>> (8) Commit rolled-back version to your sandbox branch
>>    cvs commit
>>    [sticky tag: sandbox_USERID_rollback_result, sticky date: none]
>> (9) Test branch 'sandbox_USERID_rollback_result'
>>    or verify by other means, that you have
>>    correct, compilable version in working dir
>>    If you discover, that you rolled back to
>>    wrong date:
>>    (9.1) remove tags
>>        cvs tag -d sandbox_USERID_rollback_point
>>        cvs tag -d sandbox_USERID_rollback_result
>>    (9.2) goto (1) and figure out proper date
>> (10) Update your working directory to head revision
>>    cvs update -A
>>    [sticky tag: none, sticky date: none]
>> (11) Merge the difference between rolled-back
>>    revision and head into head
>>    cvs update -jsandbox_USERID_rollback_result
>>    [sticky tag: none, sticky date: none]
>> (12) Commit your changes
>>    cvs commit -m 'rollback to 2003/03/15 12:07:26'
>>    If you get "up-do-date check failed" it means
>>    that someone is checking something at the same
>>    time. Use webcvs or 'cvs status' to find out who
>>    is it and contact him/her, because your rollback
>>    will rollback his/her changes.
>>    [sticky tag: none, sticky date: none]
>> (13) Rollback is complete, clean up (remove tags):
>>    cvs rtag -d sandbox_USERID_rollback_point opencxx
>>    cvs rtag -d sandbox_USERID_rollback_result opencxx
>=20
> Alex=20
>=20
> -----------------------------------------------------------------------=
- -
> Alexandre Tolmos
> E-mail: kt...@fr...
> ICQ: 92964905
> -----------------------------------------------------------------------=
- -
> "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
> -----------------------------------------------------------------------=
- -=20
>=20
> =20
>=20
=20

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

[Alexandre T. <kt...@fr...>]

Le samedi, 15 mar 2003, =E0 14:25 Europe/Paris, Grzegorz Jakacki a =E9cri=
t :

>> I'm not expert at using Cvs and I see no command to do a rollback; =20
>> can  you help?
>
> Wow, it is harder that I thougt (or maybe I am missing something).
> This is what I came up with:
> (1) Check out working copy
>    cvs co opencxx
>    cd opencxx
>    [sticky tag: none, sticky date: none]
> (2) Use 'cvs log' on one of files that need rollback to
>    find out to what date you want to roll back.
>    [sticky tag: none, sticky date: none]
> (3) Go back to the rollback date, e.g.
>    cvs update -D'2003/03/15 12:07:26 UTC'
>    WARNING: Remember to specify "UTC". 'cvs status' give you times in =20
> UTC,
>    but other commands accept date in your local time, unless you =20
> specify
>    UTC.
>    [sticky tag: none, sticky date: 2003.03.15.12.07.26]
> (3) Tag the rollback point:
>    cvs tag sandbox_USERID_rollback_point

Heck, does not work:
verifytag: authorization of tag `sandbox_kthulhu_rollback_point' for =20
user `kthulhu' failed
verifytag: please stick to these tag formats:
verifytag:     sandbox_kthulhu
verifytag:     sandbox_kthulhu_*
verifytag: contact ja...@us... for more info
verifytag: to change authorizations modify CVSROOT/verifytag
cvs server: Pre-tag check failed

>    [sticky tag: none, sticky date: 2003.03.15.12.07.26]
> (4) Get head revision in your working dir
>    cvs update -A
>    [sticky tag: none, sticky date: none]
> (5) Branch out a sandbox
>    cvs tag -b sandbox_USERID_rollback_result
>    [sticky tag: none, sticky date: none]
> (6) Switch to sandbox
>    cvs update -r sandbox_USERID_rollback_result
>    [sticky tag: sandbox_USERID_rollback_result, sticky date: none]
> (7) Merge reversed changes from rollback point
>    to rollback result into rollback_result branch
>    cvs update \
>        -jsandbox_USERID_rollback_result \
>        -jsandbox_USERID_rollback_point
>    WARNING: Order of '-j' options is essential!
>    [sticky tag: sandbox_USERID_rollback_result, sticky date: none]
>
> (8) Commit rolled-back version to your sandbox branch
>    cvs commit
>    [sticky tag: sandbox_USERID_rollback_result, sticky date: none]
> (9) Test branch 'sandbox_USERID_rollback_result'
>    or verify by other means, that you have
>    correct, compilable version in working dir
>    If you discover, that you rolled back to
>    wrong date:
>    (9.1) remove tags
>        cvs tag -d sandbox_USERID_rollback_point
>        cvs tag -d sandbox_USERID_rollback_result
>    (9.2) goto (1) and figure out proper date
> (10) Update your working directory to head revision
>    cvs update -A
>    [sticky tag: none, sticky date: none]
> (11) Merge the difference between rolled-back
>    revision and head into head
>    cvs update -jsandbox_USERID_rollback_result
>    [sticky tag: none, sticky date: none]
> (12) Commit your changes
>    cvs commit -m 'rollback to 2003/03/15 12:07:26'
>    If you get "up-do-date check failed" it means
>    that someone is checking something at the same
>    time. Use webcvs or 'cvs status' to find out who
>    is it and contact him/her, because your rollback
>    will rollback his/her changes.
>    [sticky tag: none, sticky date: none]
> (13) Rollback is complete, clean up (remove tags):
>    cvs rtag -d sandbox_USERID_rollback_point opencxx
>    cvs rtag -d sandbox_USERID_rollback_result opencxx

Alex

------------------------------------------------------------------------=20
-
Alexandre Tolmos
E-mail:=A0...@fr...
ICQ: 92964905
------------------------------------------------------------------------=20
-
"Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
------------------------------------------------------------------------=20
-

[Opencxx-users] [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

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

Alexandre Tolmos writes: 


> I'm not expert at using Cvs and I see no command to do a rollback; can  
> you help?

Wow, it is harder that I thougt (or maybe I am missing something).
This is what I came up with: 

(1) Check out working copy 

    cvs co opencxx
    cd opencxx 

    [sticky tag: none, sticky date: none] 

(2) Use 'cvs log' on one of files that need rollback to
    find out to what date you want to roll back.
    [sticky tag: none, sticky date: none] 

(3) Go back to the rollback date, e.g. 

    cvs update -D'2003/03/15 12:07:26 UTC' 

    WARNING: Remember to specify "UTC". 'cvs status' give you times in UTC,
    but other commands accept date in your local time, unless you specify
    UTC. 

    [sticky tag: none, sticky date: 2003.03.15.12.07.26] 

(3) Tag the rollback point: 

    cvs tag sandbox_USERID_rollback_point
    [sticky tag: none, sticky date: 2003.03.15.12.07.26] 

(4) Get head revision in your working dir 

    cvs update -A 

    [sticky tag: none, sticky date: none] 

(5) Branch out a sandbox 

    cvs tag -b sandbox_USERID_rollback_result 

    [sticky tag: none, sticky date: none] 

(6) Switch to sandbox 

    cvs update -r sandbox_USERID_rollback_result 

    [sticky tag: sandbox_USERID_rollback_result, sticky date: none] 

(7) Merge reversed changes from rollback point
    to rollback result into rollback_result branch 

    cvs update \
        -jsandbox_USERID_rollback_result \
        -jsandbox_USERID_rollback_point 

    WARNING: Order of '-j' options is essential! 

    [sticky tag: sandbox_USERID_rollback_result, sticky date: none]

(8) Commit rolled-back version to your sandbox branch 

    cvs commit 

    [sticky tag: sandbox_USERID_rollback_result, sticky date: none] 

(9) Test branch 'sandbox_USERID_rollback_result'
    or verify by other means, that you have
    correct, compilable version in working dir 

    If you discover, that you rolled back to
    wrong date: 

    (9.1) remove tags 

        cvs tag -d sandbox_USERID_rollback_point
        cvs tag -d sandbox_USERID_rollback_result 

    (9.2) goto (1) and figure out proper date 

(10) Update your working directory to head revision 

    cvs update -A 

    [sticky tag: none, sticky date: none] 

(11) Merge the difference between rolled-back
    revision and head into head 

    cvs update -jsandbox_USERID_rollback_result 

    [sticky tag: none, sticky date: none] 

(12) Commit your changes 

    cvs commit -m 'rollback to 2003/03/15 12:07:26' 

    If you get "up-do-date check failed" it means
    that someone is checking something at the same
    time. Use webcvs or 'cvs status' to find out who
    is it and contact him/her, because your rollback
    will rollback his/her changes. 

    [sticky tag: none, sticky date: none] 

(13) Rollback is complete, clean up (remove tags): 

    cvs rtag -d sandbox_USERID_rollback_point opencxx
    cvs rtag -d sandbox_USERID_rollback_result opencxx 

 

REMARKS: It is possible to add a script to CVS which after
    each commit tries to build and test in order to tag
    the last correct revision. Then rollback procedure
    can be made into a script, because one does not have
    to figure out the date and later verify if the rollback
    point is correct. 

Best regards
Grzegorz 

PS: I will put the above procedure on the website, once we have one
   (hopefully soon). 

PPS: As for STL --- I know that there are problems, but
    this can be eventually worked out. Possibly some code
    in 'exp_templates' branch can be merged into main trunk
    to fix it. I would suggest that we focus on MacOS X port first,
    and once it works, we can move to your problems with STL, step
    by step (as we already succesfully did with gcc-3.1 compatibility).
    G. 

[Opencxx-users] Re: [opencxx] Let's break OpenC++ up

[Stefan R. <sr...@ma...>]

Hello,

On Thu, Mar 13, 2003 at 01:52:52PM +0800, Grzegorz Jakacki wrote:
> This is very important, as this allows somebody who is not a guru to come
> and commit some fixes without fear that he/she breaks some distant parts
> of the package. Our testsuite is pathetically small at the moment, but
> it already helps and I believe that it can grow.

I think, there are two problems, at least with the parser. The
interface consists of two parts, namely the Ptree descendants
and their contents.

1) Every Ptree descendant has a method "Translate" which calls
   a method of Walker. Adding a new Ptree class means adding a
   method to Walker. User code must override that method, or
   they'll (accidentially, maybe) run into the default behaviour
   which just recurses into the subtrees. This problem can be
   solved with an abstract base class, so people who want to be
   paranoid can derive from that. Their code will automatically
   fail to compile when we add a new node type, which is a Good
   Thing(tm), IMHO.

   So far, everything nice.

2) The bigger problem is with the content of the nodes. For
   example, the new wide-char constants turn into Leafs. Old
   programs might assume that all Leafs are either numeric, char
   or string literals, and break now. Or, my "if(decl)" patch[1]
   would add the new property that the third child of "if" can
   be a declaration instead of an expression. I don't see a good
   solution for that problem. Okay, one could go away from the
   Lispy data structure towards a more "explicit" syntax, i.e.
     class PtreeIfStatement {
       Ptree *if_keyword, *left_paren, *right_paren;
       PtreeExpressionOrDeclaration *condition;
       PtreeStatement *controlled_statement;
     };
   but that would need an enormous amount of work and break
   everything. Plus, OpenC++ started as a meta-object protocol
   and not as a parser library, so I'm perfectly happy when it
   fulfills its primary purpose best :-)

[1] Since the CVS code currently can't be built, I'll wait with
checking it in.

> But now comes the problem: when we just extend Frontend itself, without
> proper support in Translator (e.g. your patches will make 'if ({...}) '
> parse, but Translator will choke on it), we do not have way to add tests
> that make sure the new Frontend functionality works.

My 1) is a partial solution. 2) can be solved by very defensive
programming. My code checks every Ptree node it encounters
whether it fits into its imagination. For example, my "if"
handling code starts with (the equivalent of)
   assert(p->First()->Eq("if"));
   assert(p->Second()->Eq('('));
   assert(p->Nth(3)->Eq(')'));
so if someone now adds an "unless" statement which also
generates a PtreeIfStatement ("it's almost the same"), my code
will see that it can't handle it. I think we can't get much
better.

> BTW: Over a year ago there was a resolution on this forum to factor out the
> Driver subsystem and make it a shell script (for easier maintenance
> and to make underlying compiler/preproc/linker settable with Autoconf).

Personally, I don't care whether the driver is in C, Perl, Shell
or Intercal.

What about generating a ".h" file and including that in the
driver? In another project of mine, I have this in "configure.in":
----8<----
define(CREATE1, [AC_OUTPUT_COMMANDS([echo "creating $1..."
cat >conftest.tmp <<_EOF
$2
_EOF
if cmp -s $1 conftest.tmp; then
  echo $1 is unchanged
  rm -f conftest.tmp
else
  rm -f $1
  mv conftest.tmp $1
fi])])dnl

CREATE1(arch/platform.h, [#ifndef PCC_V2_ARCH_PLATFORM_H
#define PCC_V2_ARCH_PLATFORM_H
#define PCC2_SRCDIR "`cd "$srcdir" && pwd`"
#define PCC2_DATADIR "$pdatadir"
#include "arch/unix/platform.h"
#endif
])
----8<----
This creates a file ("arch/platform.h") which contains the
specified code, with shell variables expanded (Disclaimer: I'm
not an Autoconf expert, maybe what I did can be done much
easier).

In addition, setting these variables with options to the driver
is a nice thing to have. Shouldn't be too hard. I'm currently
fiddling around with symlinks in $HOME/bin. Not too great :-P
On the other hand, there's always the option to just translate
the source (-E) and compile manually.


  Stefan

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

[Alexandre T. <kt...@fr...>]

Le vendredi, 14 mar 2003, =E0 01:40 Europe/Paris, Grzegorz Jakacki a =20
=E9crit :

> On Thu, 13 Mar 2003, Alexandre Tolmos wrote:
>
>>
>> Le jeudi, 13 mar 2003, =E0 17:28 Europe/Paris, Michael Hohmuth a =E9cr=
it :
>>
>>> Grzegorz Jakacki <ja...@he...> writes:
>>>
>>>> When you wrote, that you checked in patch for gcc-3.2 I just checked
>>>> out
>>>> and it did not compile. Thus I assumed that you forgot to checkin
>>>> the new version of gc. I thought that you send the patch just for my
>>>> convinience, while CVS already contains the correct version of gc.
>>>
>>> I see -- sorry for the confusion.  As I wrote in another email, I use
>>> the new GC only privately, and I have to expertise for merging
>>> `libtool'd projects.
>>>
>>> I noticed that Alexandre has checked in parts of GC 6.2.alpha4.  The
>>> CVS tree currently is in an unbuildable state; I assume he is
>>> currently working on merging the new GC?
>>
>> Ooops sorry, my bad. I wanted to checkin in my own branch. I made a
>> mistake somewhere.
>
> This happens once in a while. Just if you can rollback to the version =20
> from
> before you checkin and test. "-D" option may help.

I'm not expert at using Cvs and I see no command to do a rollback; can =20
you help?

Thanks.

Alex
------------------------------------------------------------------------=20
-
Alexandre Tolmos
E-mail:=A0...@fr...
ICQ: 92964905
------------------------------------------------------------------------=20
-
"Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
------------------------------------------------------------------------=20
-

[Opencxx-users] Re: [opencxx] Let's break OpenC++ up

[Walter C. <ca...@di...>]

On Fri, 14 Mar 2003, Grzegorz Jakacki wrote:

> > (Just as an aside: Would you mind posting a list of the projects you
> > know that use OpenC++ to this list or the project's homepage?  I woul=
d
> > like to have a look at them, and I really learned a lot from looking
> > at the Synopsis source code, for example.)

[CUT]

> * Walter Cazzola (should be on this list) once used
>   OpenC++ in his project

Yep, but I have suspended my experiments (almost a year ago) because the
OpenC++'s (reflective) template support was not as I need and I had not
the time to work on its extension. Now (i.e., when the template supports
has been improved) the project is still suspended because new projects
are started and I don't have the time to complete my old work.

Walter

--=20
Walter Cazzola, PhD - Assistant Professor, DICo, University of Milano
E-mail ca...@di... Ph.: +39 010 353 6637  Fax: +39 010 353 6699
=B7 =B7 =B7 --------------------------- =B7 =B7 =B7 ---------------------=
------ =B7 =B7 =B7
               ... recursive: adjective, see recursive ...
=B7 =B7 =B7 --------------------------- =B7 =B7 =B7 ---------------------=
------ =B7 =B7 =B7

[Opencxx-users] Re: [opencxx] Member::Name()

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

On Thu, 13 Mar 2003, Stanislav Kaushanskiy wrote:

> when calling Member::Name() on a member function object
> I get a ptree with the name of the method, but when I try to
> call Environment::GetLineNumber on this ptree, I get a:
> file: unknown
>
> // code:
> // m is a Member object representing a method
> env -> GetLineNumber(m.Name())->Display();
>
> Output:
> unknown
>
>
> If I call Environment::GetLineNumber on a member.FunctionBody()
> I get a valid file and line number.
>
> any ideas?

I think this was addressed on this forum several weeks ago. Try searching
the archive at SF. In a few words: you have descend through the leftmost
path in Ptree to the first Leaf node and call GetLineNumber() on it.

Best regards
Grzegorz

> thanks
>
> I am using:
> OpenC++ 2.5.12
> gcc 2.96
>
>
>

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

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

On Thu, 13 Mar 2003, Michael Hohmuth wrote:

> Grzegorz Jakacki <ja...@he...> writes:
>
> > When you wrote, that you checked in patch for gcc-3.2 I just checked out
> > and it did not compile. Thus I assumed that you forgot to checkin
> > the new version of gc. I thought that you send the patch just for my
> > convinience, while CVS already contains the correct version of gc.
>
> I see -- sorry for the confusion.  As I wrote in another email, I use
> the new GC only privately, and I have to expertise for merging
> `libtool'd projects.

OK, no problem.

Thanks
Grzegorz

>
> I noticed that Alexandre has checked in parts of GC 6.2.alpha4.  The
> CVS tree currently is in an unbuildable state; I assume he is
> currently working on merging the new GC?
>
> Kind regards,
> Michael
> --
> ho...@sa..., ho...@in...
> http://www.sax.de/~hohmuth/
>
>

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] Re: [opencxx] Let's break OpenC++ up

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

On Thu, 13 Mar 2003, Michael Hohmuth wrote:

> Grzegorz Jakacki <ja...@he...> writes:
>
> > Conceptually OpenC++ consists of three sybsystems:
> >
> >     Frontend --- reads preprocessed sources, makes parse tree
> >         out of them; possibly OpenC++ static analyzer also belongs
> >         in this subsystem
> >
> >     Translator --- traverses syntax tree and transforms it
> >         according to rules described by metaclasses
> >
> >     Driver --- runs preprocessor, Frontend, Translator,
> >         native compiler and linker.
> >
> > As I understand Michael and Stefan work with Frontend and are not interested
> > in the rest of the system. I believe, that this is the most frequently
> > reused part of OpenC++ and I know of at least three more projects that
> > reuse just this part.
>
> (Just as an aside: Would you mind posting a list of the projects you
> know that use OpenC++ to this list or the project's homepage?  I would
> like to have a look at them, and I really learned a lot from looking
> at the Synopsis source code, for example.)

* Introspector
* Synopsis
* the commercial project I used to work on (non-open)
* I was told that 'Sds' projects also uses OpenC++, but I never contacted
  them
* Juan Carlos Arevalo-Baeza (should be on this list) once used
  OpenC++ in his project
* Walter Cazzola (should be on this list) once used
  OpenC++ in his project

> > Thus I suggest that we take it out and make it a separate library.
>
> There is a fourth part that lives somewhere in the middle between
> Frontend and Translator (maybe that's what you mean by ``static
> analyzer''): OpenC++'s symbol-table implementation, encapsulated in
> classes Environment, Encoding and friends.  We had trouble
> understanding and reusing particularly this part, and in the end
> decided not to use it, so it should be separable as well.

Right.

> > Otherwise I can see serious problems with testing.
> [...]
> > With separate Frontend library, we can test the library on its own, and
> > this is what we need at the moment, because we somehow have to add tests
> > for the new features implemented by patches from Fiasco project.
>
> I think what you are proposing can be achieved by some
> build-infrastructure (and maybe some terminology and documentation)
> changes, plus very little.  You actually do not need complete
> separation of the four parts comprising OpenC++ in order to facilitate
> testing -- separation would just be convenient for reuse.
>
> In my opinion, what's needed is just:
>
> 1. An abstract base class for Walker, which just provides the
>    interface for visiting a Ptree hierarchy and is completely
>    independent from the Translator and symbol-table parts.  (As an
>    added bonus, its visit functions should support return types other
>    than Ptree*, so it probably should be a template.)

But perhaps not called 'Walker', unfortunately, due to code base.

> 2. A simple unit-testing framework, to which tests for new
>    functionality (on a per-module level) can be added easily
>
> For our VFiasco project <http://www.vfiasco.org>, we use a wrapper
> around Walker which provides (1), and (2) consists of a set of
> unit-test programs that output test data and a simple Makefile (for
> GNU Make) that tests for regressions.

Could you part of your infrastructure to OpenC++? If so, can you put it
somewhere on the web so that we can review it and see what can OpenC++ get
from you?

> All in all, I think that the changes I proposed should be gradually
> added to the source base, but nothing more.  Frequent changes to the
> build system and library interface actually make reuse harder, not
> easier, and besides the points I mentioned, there isn't really that
> much of an itch to scratch.

I think that separation of Parser as a module should be done sooner or
later. In many applications you do not need the rest, why should it be
bundled? Moreover, I do not think that this separation *requires* much
of interface change (BTW: OpenC++ interface is a subjest for another
story).

> > BTW: Over a year ago there was a resolution on this forum to factor out the
> > Driver subsystem and make it a shell script (for easier maintenance
> > and to make underlying compiler/preproc/linker settable with Autoconf).
>
> I don't really care about the driver, but I don't understand how
> completely replacing a perfectly-well-working part makes anything more
> maintainable.

It is not working perfectly, see e.g. my problems with running regression
on gcc-3.2, originating from the fact that underlying compiler is
hardcoded and selected with system-specific defines. We hit this problem
a year ago, when Pavel Krusina was working on Irix port.

Another issue are shared libraries, which are currently not trurly
supported. libtool has all we need to make shared or dlopenable library,
while at the same time driver.cc/driver2.cc duplicates this functionality,
and is far less perfect than libtool (the fact is it was created much
earlier than libtool).

> It certainly is no problem to make the underlying tools
> configurable for the existing C++ driver, is it?

It is possible, but it is more work than it is worth (especially for
shared libs).

Best regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] Re: [opencxx] some OpenC++ experience

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

On Thu, 13 Mar 2003, Stefan Reuther wrote:

> > You are working on Fiasco project, right? Are your sources open?
>
> VFiasco, right. Sources are not yet open, because we did not yet
> package them up nicely, and because the project is far from
> complete. Other than that, there's no problem.
>
> > > OpenC++ also does not recognize di- and trigraphs, nor does it
> > > support replacement keywords (i.e. "and_eq" instead of "&="). I
> > > think these are better in a preprocessor.
> >
> > I do not quite understand where is the problem here. OpenC++ works on
> > preproc output, so it has no chance to see trigraps&co, right?
>
> gcc's preprocessor doesn't do digraphs ("<%" instead of "{"). It
> also doesn't do replacement keywords, but at least these can be
> worked around using some #defines, like C99 does it. I think
> there are some subtle gotchas in these, but I would just declare
> that these things are out of OpenC++'s scope (I don't care
> whether "<%" stringifies as "<%" or "{"). And, honestly, I've
> never seen anyone use them.

There is brand new preprocessor based on Spirit parser, you may want to
have a look at:

    http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&group=comp.compilers&selm=03-03-046%40comp.compilers

however I am not sure if it handles trigraphs.

> > > Another problem which I found quite hard to solve: take an
> > > expression like this: "(name) + x * y". Depending upon whether
> > > the "name" is a type or a variable, this either means
> > >    ((name) +x) * y
> > > (cast +x, then multiply) or
> > >    (name) + (x * y)
> > > (multply, then add).
> [...]
> > The honest solution would be to have node type that makes it
> > obvious, that parser does not know what it is. Further analysis
> > would change the node to one or another form, based on the
> > relevant identifiers bindings. I am not sure if this scheme
> > is currently implementable without seriously compromising backward
> > compatibility.
>
> Okay, I had some similar things in mind. For compatibility, the
> "Walker" could have a routine "TranslateAmbiguousCast" or
> somesuch, whose default implementation calls
> "TranslateCastExpr", "TranslatePrefixExpr" and
> "TranslateInfixExpr".

The problem is that occ client should be isolated from this detail.
Somebody using Walker should not care about it, it should be taken care of
by the framework.

I think there is a problem now, since there is no islation between syntax
tree that OpenC++ is working on and syntax three that is exposed to the
clients.

I have been working on this for some time and I think I have a couple of
idas on how to provide isolation here without runtime overhead, but I have
not run those ideas through too many persons yet. Perhaps this is a good
time and good place to do it. I will try to prepare a write-up on weekend
and post it here. I am not sure, if it will be immediately applicable and
what are exact backward compatibility issues on that, but maybe people
here will help figuring this out.

> Other than that, my (implicit) question was how many people
> would cry when I change the parse tree somehow :-)

Just wait for a week to see.

> At least, the
> addition of "typeid" broke one of our regression tests.

This is precisely why I would like the isolation.

> I think,
> static_cast & co should have their own PtreeCxxStyleCast node,
> which would probably change someone else's tests. Addition of
> new productions wouldn't break immediately, but someone who
> implements their own Walker might accidentially miss some nodes.
> That problem could at least be solved by making an abstract
> Walker base class where all the TranslateFooBar functions are
> pure virtual.

Right. However this involves problems with all the code that instantiates
Walker --- it has to be fixed by hand, better yet switched to
Factory-based solution.

> Maybe this can be solved more generally, as a parameterized user
> keyword.

Why not.

> If I recall correctly, such a thing is on the wishlist?
> (haven't yet digged through all of Michael's archive)

Unfortunately I do not maintain wishlist, so I cannot verify.

Best regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################