opencxx-users

[Opencxx-users] Another stupid question...

[RodZilla <rod...@fr...>]

Hello,

I have another stupid question. Now I would like to
get (and write into a file) the full declaration of
a member in a class.
I do this using Member::Signature and TypeInfo::MakePtree,
but if the member is an array, its size is omitted.
Is it possible to get the full declaration, and how ?
Thanks a lot in advance.

Best regards,

Rod.

Re: [Opencxx-users] OpenC++ Core Lib -- prototype

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

Hi,

On Mon, 13 Sep 2004, Stefan Seefeld wrote:

> Grzegorz Jakacki wrote:
>
>  >> I'd generally much prefer to start with an assessment (i.e. documentation
>  >> in terms of actual text, unit tests, and examples) of the existing design.
>  >
>  >
>  > I think it is suboptimal in this case for two reasons. First, there is
>  > very little documentation of existing system, so almost all documentation
>  > would need to be reverse engineered (I already did some of it, as you may
>  > remember).
>
> Yes. But don't we need to reverse engineer if we want to apply changes in a
> controlled manner ?
>
> I can tell you how much head-aches I have these days trying to understand
> why a given method is implemented the way it is. The fact that the old code
> wasn't const-correct obviously doesn't help, i.e. I have to guess whether a
> given argument is going to be modified in-place or whether it's only
> an 'in' parameter.
>
> So reverse-engineering is what takes 90% of my time. Once I understand a
> given design it's quite easy to see whether it can be enhanced.

My take is that 100% understanding in these circumstances is not
precondition to introducing changes. But this is MHO.

>  > Second, we cannot provide accurate unit tests post factum, because we are
>  > not sure what the code should really do.
>
> granted. Though they would serve as regression tests, i.e. we could measure
> what kind of changes we incure to the data handling while we work on the
> redesign.

I was trying to take this patch for the past 3 years and for me it did not
work out with OpenC++. Writting reasonable regression tests is lots of
hard work and is not very exciting for prospective developers. I took such
road at work where I inherited undocumented system without tests, but with
open-source volunteers-based project things look differently.

Thus my proposal to focus on the core functionality and put "Greater
OpenC++" aside for some time. In particular I no longer think that it
makes sense to add regression tests to "Greater OpenC++" now.

> In fact, there are, as we discussed, a couple of cases that are known
> to fail. Those known failures should be accompagnied by (annotated) unit
> tests, if only to document that we know about them.

Agreed, but I vote for mounting those unit tests as low as possible ---
not on top of 'occ' interface, but e.g. on top of parser library.

>  > I think that the way to go is to read and clean the code step by step,
>  > adding unit tests as the knowledge about the code grows.
>  >
>  >> Some months ago I proposed a rigorous separation between 'parser'
>  >> (including ptree API) and higher level classes (Environment, TypeInfo,
>  >> Class, etc.).
>  >
>  >
>  > In fact parser separation started several months before you joined in April.
>  > (http://sourceforge.net/mailarchive/message.php?msg_id=6971830)
>  >
>  >> Now that my understanding of occ internals is a little better, I would
>  >> revise my suggestions I then made.
>  >
>  >
>  > Go ahead.
>
> nothing dramatic :-) I simply concluded that the boundary between 'low' and
> 'high' level is a little blury, or not where I originally expected it to be.
> That's mainly because I didn't realize at the time that what we called 'parsing'
> was only the first half, the second half including the use of 'ClassWalker' and co.
>
> As we now agree to redesign the parser such that it does the declarator
> recording (Environment...) itself instead of letting it done by a Walker, it
> could mean that the Walker could be part of the high level.
> Right now it can't because parsing isn't complete (i.e. self-contained)
> without ClassWalker.

Wait a moment. I don't think it is *that* easy with C++. As I already
mentioned here several weeks ago, I don't see a way to perform type
elaboration in one pass. This is because

    The potential scope of a name declared in a class consists not only of
    the declarative region following the name s declarator, but also of all
    function bodies, default arguments, and constructor ctor-initializers in
    that class. [3.6.6p1]

which in particular makes this code legal:

    class A
    {
        void f() { g(); };
        void g() {};
    };

The more tricky example:

    class A
    {
        void f() { B < 1 > ( 2 ) ; }
        template <int n> void B(int);
    };

Here we just cannot rely just on one pass. It seems to me that a reasonable
solution is that parser stores the function bodies, default arguments and
ctor-initializers and parses them after the class is parsed. At that
time the symbol table can meaningfully answer if a given name represents
a template.

>  >> and so I believe in order to be able
>  >> to make 'educated suggestions' we should start by discussing the existing
>  >> design.
>  >> In particular, how does parsing work in detail ?
>  >
>  >
>  > More detailed question solicited.
>
> details follow:
>
>  >> What is the Walker's role ?
>  >
>  >
>  > I believe that:
>  >
>  > Walker -- does preety nothing, just traverses the subtrees. It is a
>  > "skeletal implementation".
>  >
>  > ClassWalker --- traverses the AST and creates metaobjects (objects
>  > representing semantic entities of C++, e.g. objects of classes Class, Member
>  > etc.)
>
> not quite. That's precisely one of the spots I have problems with: the
> ClassWalker plays a role as well in the low level (parsing) as well as the
> high level (mop).
> It records declarations to the Environments, and these are then necessary to
> complete the parsing, no ?

I don't think OpenC++ does it now in such manner. AFAIK parser does not use
type information to resolve any syntax ambiguities (ie. at template
instantiations).

> Remember when we discussed ambiguous C++ statements, i.e.
> statements that are ambiguous as long as you can't check whether a given
> symbol refers to a type or not...
>
>  > ClassBodyWalekr --- traverses the AST of classes and also creates
>  > metaobjects (perhaps difference between ClassWalker and ClassBodyWalker
>  > stems from the fact that in C++ binding in class scopes works differently
>  > than in other scopes).
>  >
>  >> How are Encoding and TypeInfo related ?
>  >
>  >
>  > It seems to me that Encoding is always an "expanded" type, while TypeInfo
>  > is "lazy" type, e.g. it can buffer referencing/dereferencing
>  > and also it can keep typedefs unexpanded (that's why it needs to have a
>  > link to Environment).
>  >
>  > There also another point to it: if I am not mistaken Encoding can encode
>  > not only type, but also scoped identifier.
>
> yes, it encodes names (function names, in particular, which include the
> signature, i.e. parameter types !), as well as types.
> I think that your separation of Encoding and EncodingUtil is a good start.

It is original design, I have not touched it.

> 'Encoding' is a 'passive' data holder (similar to std::string). In this role
> I placed it into PTree nodes, to make them more type safe.

Personally I don't like it, because it forces clients data structure on
parser library.

> All the active parts (name lookup, code generation, etc.) should be kept
> outside. By the way, why isn't the EncodingUtil part of Environment or TypeInfo ?
> Wouldn't that make things slightly simpler ?

Putting functions from EncodingUtil into Encoding makes parser library
depend on Environment, and Walker, and Bind, and TypeInfo, and Class,
so all the parser isolation collapses.

Putting functions from EncodingUtil into Environment makes sense only if
they need private access to Environment. They don't.

If you feel that 4 functions in EncodingUtil namespace does not warrant its
existence, then I would suggest putting them in Environment.h (but not as
member functions), according to Sutter's "interface principle".

>  >> PS: I consider the redesign I'm doing in Synopsis as an iterative
>  >>     process.
>  >>     I work my way up starting from the lowest layers, and while I get a
>  >>     better understanding on the individual classes I'm able to improve their
>  >>     design.
>  >
>  >
>  > How does it relate to OpenC++? What would you suggest for OpenC++?
>
> oh, the process is simply the only way for me to understand OpenC++. The
> design itself is what I would suggest OpenC++ to use for its core. But as I said,
> it's an iterative process, so I'm far from done with it, so I expect more structural
> changes to the repository (thank svn this is easy ;-)

I think that your contributions to original OpenC++ that currently
constitute C++ submodule of Synopsis are very valuable and I would be glad
to leverage them in OpenC++ Core. As I understand the only changes that were
made under LGPL to OpenC++ 2.5.12 under Synopsis are yours, right? If so,
would you consider donating them to OpenC++ under OpenC++ license?

BR
Grzegorz

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

Re: [Opencxx-users] OpenC++ Core Lib - MANIFESTO

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

Yann Dirson wrote:
> On Wed, Sep 01, 2004 at 10:40:46PM -0400, Stefan Seefeld wrote:
> 
>>I anticipate to move to scons (http://www.scons.org) in the not-so-distant
>>future. That will simplify matters even further, especially concerning
>>portability.
> 
> 
> I don't know what scons is up to, but it seems to require python.

indeed. Is that practically a problem for you ?

> That would add a quite big build-dependency.  OTOH, Jam

Well, I was talking for Synopsis. As Synopsis provides scripting access
to OpenC++ I'm already depending on python. I don't think this is an issue
for anybody wanting to use Synopsis / OpenC++. Please convince me from
the contrary.

> (http://www.perforce.com/jam/jam.html) is a very powerful portable
> replacement for make+automake as well, and does not have any large
> dependencies.  You may want to have a look at it (if you don't already
> know about it, that is ;)

Yes, I know about it. In fact, I'm watching the boost build system which
is based on a modified version of jam ('bjam'). The boost developers,
and notably David Abrahams, are considering to switch to scons these days...

Regards,
		Stefan

Re: [Opencxx-users] OpenC++ Core Lib -- prototype

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

Grzegorz Jakacki wrote:

 >> I'd generally much prefer to start with an assessment (i.e. documentation
 >> in terms of actual text, unit tests, and examples) of the existing design.
 >
 >
 > I think it is suboptimal in this case for two reasons. First, there is
 > very little documentation of existing system, so almost all documentation
 > would need to be reverse engineered (I already did some of it, as you may
 > remember).

Yes. But don't we need to reverse engineer if we want to apply changes in a
controlled manner ?
I can tell you how much head-aches I have these days trying to understand
why a given method is implemented the way it is. The fact that the old code
wasn't const-correct obviously doesn't help, i.e. I have to guess whether a
given argument is going to be modified in-place or whether it's only
an 'in' parameter.

So reverse-engineering is what takes 90% of my time. Once I understand a
given design it's quite easy to see whether it can be enhanced.

 > Second, we cannot provide accurate unit tests post factum, because we are
 > not sure what the code should really do.

granted. Though they would serve as regression tests, i.e. we could measure
what kind of changes we incure to the data handling while we work on the
redesign. In fact, there are, as we discussed, a couple of cases that are known
to fail. Those known failures should be accompagnied by (annotated) unit
tests, if only to document that we know about them.

 > I think that the way to go is to read and clean the code step by step,
 > adding unit tests as the knowledge about the code grows.
 >
 >> Some months ago I proposed a rigorous separation between 'parser'
 >> (including ptree API) and higher level classes (Environment, TypeInfo,
 >> Class, etc.).
 >
 >
 > In fact parser separation started several months before you joined in April.
 > (http://sourceforge.net/mailarchive/message.php?msg_id=6971830)
 >
 >> Now that my understanding of occ internals is a little better, I would
 >> revise my suggestions I then made.
 >
 >
 > Go ahead.

nothing dramatic :-) I simply concluded that the boundary between 'low' and
'high' level is a little blury, or not where I originally expected it to be.
That's mainly because I didn't realize at the time that what we called 'parsing'
was only the first half, the second half including the use of 'ClassWalker' and co.

As we now agree to redesign the parser such that it does the declarator
recording (Environment...) itself instead of letting it done by a Walker, it
could mean that the Walker could be part of the high level.
Right now it can't because parsing isn't complete (i.e. self-contained)
without ClassWalker.

 >> and so I believe in order to be able
 >> to make 'educated suggestions' we should start by discussing the existing
 >> design.
 >> In particular, how does parsing work in detail ?
 >
 >
 > More detailed question solicited.

details follow:

 >> What is the Walker's role ?
 >
 >
 > I believe that:
 >
 > Walker -- does preety nothing, just traverses the subtrees. It is a
 > "skeletal implementation".
 >
 > ClassWalker --- traverses the AST and creates metaobjects (objects
 > representing semantic entities of C++, e.g. objects of classes Class, Member
 > etc.)

not quite. That's precisely one of the spots I have problems with: the
ClassWalker plays a role as well in the low level (parsing) as well as the
high level (mop).
It records declarations to the Environments, and these are then necessary to
complete the parsing, no ? Remember when we discussed ambiguous C++ statements, i.e.
statements that are ambiguous as long as you can't check whether a given
symbol refers to a type or not...

 > ClassBodyWalekr --- traverses the AST of classes and also creates
 > metaobjects (perhaps difference between ClassWalker and ClassBodyWalker
 > stems from the fact that in C++ binding in class scopes works differently
 > than in other scopes).
 >
 >> How are Encoding and TypeInfo related ?
 >
 >
 > It seems to me that Encoding is always an "expanded" type, while TypeInfo
 > is "lazy" type, e.g. it can buffer referencing/dereferencing
 > and also it can keep typedefs unexpanded (that's why it needs to have a
 > link to Environment).
 >
 > There also another point to it: if I am not mistaken Encoding can encode
 > not only type, but also scoped identifier.

yes, it encodes names (function names, in particular, which include the
signature, i.e. parameter types !), as well as types.
I think that your separation of Encoding and EncodingUtil is a good start.
'Encoding' is a 'passive' data holder (similar to std::string). In this role
I placed it into PTree nodes, to make them more type safe.
All the active parts (name lookup, code generation, etc.) should be kept
outside. By the way, why isn't the EncodingUtil part of Environment or TypeInfo ?
Wouldn't that make things slightly simpler ?

 >> PS: I consider the redesign I'm doing in Synopsis as an iterative
 >>     process.
 >>     I work my way up starting from the lowest layers, and while I get a
 >>     better understanding on the individual classes I'm able to improve their
 >>     design.
 >
 >
 > How does it relate to OpenC++? What would you suggest for OpenC++?

oh, the process is simply the only way for me to understand OpenC++. The
design itself is what I would suggest OpenC++ to use for its core. But as I said,
it's an iterative process, so I'm far from done with it, so I expect more structural
changes to the repository (thank svn this is easy ;-)

Regards,
		Stefan

Re: [Opencxx-users] OpenC++ Core Lib - MANIFESTO

[Yann D. <yd...@al...>]

On Wed, Sep 01, 2004 at 10:40:46PM -0400, Stefan Seefeld wrote:
> I anticipate to move to scons (http://www.scons.org) in the not-so-distant
> future. That will simplify matters even further, especially concerning
> portability.

I don't know what scons is up to, but it seems to require python.
That would add a quite big build-dependency.  OTOH, Jam
(http://www.perforce.com/jam/jam.html) is a very powerful portable
replacement for make+automake as well, and does not have any large
dependencies.  You may want to have a look at it (if you don't already
know about it, that is ;)

Best regards,
-- 
Yann Dirson    <yd...@al...> |
Debian-related: <di...@de...> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Re: [Opencxx-users] OpenC++ Core Lib -- prototype

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

Hi!

Stefan Seefeld wrote:
> Did you have a look at the redesign I did inside Synopsis ? How does
> your occ-core compare to that ?

Yes I have. I have not got down to visitors, so this is one difference. 
I got rid of metaclass- and translation-related stuff, as I think this 
is the domain of a client (Greater OpenC++) not the OpenC++ Core. I have 
also seen that you have done some renaming in Ptree hierarchy; I kept it 
as it was, so this is yet another difference. That's it for the quick 
glimpse.

In fact I contemplated starting from your files, however it would force 
LGPL on OpenC++ and I am not sure if this is the right thing to do.

> I'd generally much prefer to start with an assessment (i.e. documentation
> in terms of actual text, unit tests, and examples) of the existing design.

I think it is suboptimal in this case for two reasons. First, there is 
very little documentation of existing system, so almost all 
documentation would need to be reverse engineered (I already did some of 
it, as you may remember). Second, we cannot provide accurate unit tests 
post factum, because we are not sure what the code should really do.

I think that the way to go is to read and clean the code step by step, 
adding unit tests as the knowledge about the code grows.

> Some months ago I proposed a rigorous separation between 'parser' 
> (including
> ptree API) and higher level classes (Environment, TypeInfo, Class, etc.).

In fact parser separation started several months before you joined in 
April. (http://sourceforge.net/mailarchive/message.php?msg_id=6971830)

> Now that my understanding of occ internals is a little better, I would
> revise my suggestions I then made. 

Go ahead.

> Still, I believe that I'm not the only
> one whose understanding is limitted, 

You are not the only one. Count myself.

> and so I believe in order to be able
> to make 'educated suggestions' we should start by discussing the existing
> design.
> In particular, how does parsing work in detail ? 

More detailed question solicited.

> What is the Walker's role ?

I believe that:

Walker -- does preety nothing, just traverses the subtrees. It is a 
"skeletal implementation".

ClassWalker --- traverses the AST and creates metaobjects (objects 
representing semantic entities of C++, e.g. objects of classes Class, 
Member etc.)

ClassBodyWalekr --- traverses the AST of classes and also creates 
metaobjects (perhaps difference between ClassWalker and ClassBodyWalker 
stems from the fact that in C++ binding in class scopes works 
differently than in other scopes).

> How are Encoding and TypeInfo related ?

It seems to me that Encoding is always an "expanded" type, while 
TypeInfo is "lazy" type, e.g. it can buffer referencing/dereferencing
and also it can keep typedefs unexpanded (that's why it needs to have a 
link to Environment).

There also another point to it: if I am not mistaken Encoding can encode 
not only type, but also scoped identifier.

> Without better understanding these and other questions I'm unable to 
> suggest where to draw the line between low level and high level.

I am afraid there is no single person who understand (or remembers :-) 
this all clearly today.

> Regards,
>         Stefan
> 
> PS: I consider the redesign I'm doing in Synopsis as an iterative process.
>     I work my way up starting from the lowest layers, and while I get a 
> better
>     understanding on the individual classes I'm able to improve their 
> design.

How does it relate to OpenC++? What would you suggest for OpenC++?

BR
Grzegorz

Re: [Opencxx-users] Next tasks

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

Stefan Seefeld wrote:
> Grzegorz Jakacki wrote:
> 
>>> yes, '-s' is already there. My proposal is to change the semantics such
>>> that it will behave as it always did when '-p' is specified, and else
>>> display the ptree after the translation instead of before.
>>
>>
>>
>> Yes, that makes sense to me, pls. go ahead.
> 
> 
> ...
> 
>>> I honestly strongly doubt anybody would ever notice, as '-s' seems to
>>> me to be a debugging / testing / learning tool only.
>>
>>
>>
>>>
>>> The change I'd like to make is thus trivial and involves only three 
>>> lines
>>> of code that are moved down a bit :-)
> 
> 
> ok, The change is checked in.
> I'v tried it out and I'm a bit surprized, as I expected to find the 
> translation
> to modify the ptree in almost all cases, but a little test I ran didn't 
> appear
> to do anything in the translation, i.e. the resulting ptree was 
> identical to
> the original one. Why is that ?

Could you post an example?

BR
Grzegorz

> AFAIK translation includes the second stage of the parsing (i.e. resolving
> any ambiguities that only exist because to resolve them one needs a 
> symbol lookup
> table which didn't exist in the first pass), and it also includes 
> anything related
> to metaprogramming, i.e. metaclass tokens that were part of the original 
> source,
> and are now expanded.
> 
> Anyways, that's precisely one of the reasons I want to put this testing 
> stuff
> in the original code: to be able to study occ systematically on a broad 
> sample
> of existing input files.
> 
> Regards,
>         Stefan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM. 
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] OpenC++ Core Lib -- prototype

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

Grzegorz Jakacki wrote:
> Hi,
> 
> The new module in CVS called 'occ-core' contains my first attempt at
> launching the "OpenC++ Core" initiative. Throughout the last week
> Stefan Seefeld and myself were discussing the possibilities of having
> a common repo for the core part of OpenC++ reused by Synopsis, but some
> unsolved issues still remain, thus I decided to demo my idea in an actual
> code.
> 
> As outlined in "OpenC++ Core Lib MANIFESTO", OpenC++ has problems with
> advancing the quality of code analysis (templates and overloading),
> because along with advancement in this areas, other parts of the system 
> need to be accordingly maintained, which distracts the resources. Thus 
> the idea to take out the core functionality pertaining to code analysis
> and make it into compact, self-contained and self-testable library.
> The division would separated code into "OpenC++ Core" (lexer, parser,
> code object model ("Class", "Member"), type elaboration) and
> "Greater OpenC++" (translation, metaclasses).
> 
> 'occ-core' is a first attempt to group the "OpenC++ Core" and make it
> self-contained. To checkout (non-developers):
> 
>   export CVSROOT=:pserver:ano...@cv...:/cvsroot/opencxx
>   cvs login
>   cvs -z3 co occ-core

'no such module' is all I get. That's probably because the anonymous
access is seeing changes with some hours of delay. Using my developer
login works.

Did you have a look at the redesign I did inside Synopsis ? How does
your occ-core compare to that ?

I'd generally much prefer to start with an assessment (i.e. documentation
in terms of actual text, unit tests, and examples) of the existing design.
Some months ago I proposed a rigorous separation between 'parser' (including
ptree API) and higher level classes (Environment, TypeInfo, Class, etc.).

Now that my understanding of occ internals is a little better, I would
revise my suggestions I then made. Still, I believe that I'm not the only
one whose understanding is limitted, and so I believe in order to be able
to make 'educated suggestions' we should start by discussing the existing
design.
In particular, how does parsing work in detail ? What is the Walker's role ?
How are Encoding and TypeInfo related ?
Without better understanding these and other questions I'm unable to suggest
where to draw the line between low level and high level.

Regards,
		Stefan

PS: I consider the redesign I'm doing in Synopsis as an iterative process.
     I work my way up starting from the lowest layers, and while I get a better
     understanding on the individual classes I'm able to improve their design.

[Opencxx-users] OpenC++ Core Lib -- prototype

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

Hi,

The new module in CVS called 'occ-core' contains my first attempt at
launching the "OpenC++ Core" initiative. Throughout the last week
Stefan Seefeld and myself were discussing the possibilities of having
a common repo for the core part of OpenC++ reused by Synopsis, but some
unsolved issues still remain, thus I decided to demo my idea in an actual
code.

As outlined in "OpenC++ Core Lib MANIFESTO", OpenC++ has problems with
advancing the quality of code analysis (templates and overloading),
because along with advancement in this areas, other parts of the system 
need to be accordingly maintained, which distracts the resources. Thus 
the idea to take out the core functionality pertaining to code analysis
and make it into compact, self-contained and self-testable library.
The division would separated code into "OpenC++ Core" (lexer, parser,
code object model ("Class", "Member"), type elaboration) and
"Greater OpenC++" (translation, metaclasses).

'occ-core' is a first attempt to group the "OpenC++ Core" and make it
self-contained. To checkout (non-developers):

   export CVSROOT=:pserver:ano...@cv...:/cvsroot/opencxx
   cvs login
   cvs -z3 co occ-core

To build and run exemplary tests:

   make test

Makefile will require some tweaking if you are not using g++. However
build process is very straighforward, so that should not be an issue.

All developers interested in advancing templates and overloading
functionality are invited to have a look and comment. Please remember, 
that this is by no means a ready product, but rather a workplace for the 
actual work.

Best regards
Grzegorz

Re: [Opencxx-users] Next tasks

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

Grzegorz Jakacki wrote:

>> yes, '-s' is already there. My proposal is to change the semantics such
>> that it will behave as it always did when '-p' is specified, and else
>> display the ptree after the translation instead of before.
> 
> 
> Yes, that makes sense to me, pls. go ahead.

...

>> I honestly strongly doubt anybody would ever notice, as '-s' seems to
>> me to be a debugging / testing / learning tool only.
> 
> 
>>
>> The change I'd like to make is thus trivial and involves only three lines
>> of code that are moved down a bit :-)

ok, The change is checked in.
I'v tried it out and I'm a bit surprized, as I expected to find the translation
to modify the ptree in almost all cases, but a little test I ran didn't appear
to do anything in the translation, i.e. the resulting ptree was identical to
the original one. Why is that ?

AFAIK translation includes the second stage of the parsing (i.e. resolving
any ambiguities that only exist because to resolve them one needs a symbol lookup
table which didn't exist in the first pass), and it also includes anything related
to metaprogramming, i.e. metaclass tokens that were part of the original source,
and are now expanded.

Anyways, that's precisely one of the reasons I want to put this testing stuff
in the original code: to be able to study occ systematically on a broad sample
of existing input files.

Regards,
		Stefan

Re: [Opencxx-users] Next tasks

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

Stefan Seefeld wrote:
[...]

>>> Grzegorz, what about my other mail ? Do you agree to make the change 
>>> I propose, i.e. let 'occ' display the translated
>>> ptree if no '-p' option is given ?
>>
>>
>>
>> Sorry for the delay.
>>
>> First, occ already has '-s' option. I assume the output you 
>> implemented is better suited for e.g. testing. If so, please go ahead, 
>> just put it under an option, preferably a long one ('--...'), that way 
>> we minimize chances to accidentally hit some "well-known" one-letter 
>> option.
> 
> 
> yes, '-s' is already there. My proposal is to change the semantics such
> that it will behave as it always did when '-p' is specified, and else
> display the ptree after the translation instead of before.

Yes, that makes sense to me, pls. go ahead.

BR
Grzegorz


> 
> I honestly strongly doubt anybody would ever notice, as '-s' seems to
> me to be a debugging / testing / learning tool only.

> 
> The change I'd like to make is thus trivial and involves only three lines
> of code that are moved down a bit :-)
> 
> Regards,
>         Stefan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM. 
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

[Opencxx-users] rel_2_8 merged

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

Hi,

I merged the changes from rel_2_8 to MAIN.

BR
Grzegorz

Re: [Opencxx-users] Next tasks

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

Grzegorz Jakacki wrote:

> Ideally we could set up one common repo for the core part of opencxx 
> (nicknamed "OpenC++ Core) to be used by both OpenC++ and Synopsis.

ideally, yes. But no matter what we end up doing, I strongly believe
the opencxx code as it exists today should get this added, too, so
we can use it as a reference. Whenever we are unsure whether the
results we are seing elsewhere are correct, we can at least check
with the old occ tests whether it's a regression or whether it has
always been there.

>> Grzegorz, what about my other mail ? Do you agree to make the change I 
>> propose, i.e. let 'occ' display the translated
>> ptree if no '-p' option is given ?
> 
> 
> Sorry for the delay.
> 
> First, occ already has '-s' option. I assume the output you implemented 
> is better suited for e.g. testing. If so, please go ahead, just put it 
> under an option, preferably a long one ('--...'), that way we minimize 
> chances to accidentally hit some "well-known" one-letter option.

yes, '-s' is already there. My proposal is to change the semantics such
that it will behave as it always did when '-p' is specified, and else
display the ptree after the translation instead of before.

I honestly strongly doubt anybody would ever notice, as '-s' seems to
me to be a debugging / testing / learning tool only.

The change I'd like to make is thus trivial and involves only three lines
of code that are moved down a bit :-)

Regards,
		Stefan

Re: [Opencxx-users] Next tasks

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

Stefan Seefeld wrote:
> Hi Gilles,
> 
> Gilles J. Seguin wrote:
> 
>> Those language constructs are the one of OpenC++, right.
>> Do you have an idea/suggestion of the structure of the test directory.
>> For example,
>> here following ISO/IEC 14882

If I can comment on this: I think that directory layout is not that much 
important. What is important is to have most cases covered by tests, and 
for that purpose your list of features is a perfect reference. However 
if the tests go into one directory or into several ones, it is much up 
to the implementor (however personally I always try to restrain myself 
from overengineering).

> [...]
> 
> did you have a look into these ? I'd be interested in putting them
> into synopsis' testing framework and, if it's ok with everybody here
> into opencxx, too. 

Ideally we could set up one common repo for the core part of opencxx 
(nicknamed "OpenC++ Core) to be used by both OpenC++ and Synopsis.

For the information of everybody: Stefan and myself are discussing now 
how we can join efforts of OpenC++ and Synopsis projects to advance the 
functionality of the code that is shared by both projects.

> Grzegorz, what about my other mail ? 
> Do you agree to make the change I propose, i.e. let 'occ' display the translated
> ptree if no '-p' option is given ?

Sorry for the delay.

First, occ already has '-s' option. I assume the output you implemented 
is better suited for e.g. testing. If so, please go ahead, just put it 
under an option, preferably a long one ('--...'), that way we minimize 
chances to accidentally hit some "well-known" one-letter option.

BR
Grzegorz

Re: [Opencxx-users] Next tasks

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

Hi Gilles,

Gilles J. Seguin wrote:

> Those language constructs are the one of OpenC++, right.
> Do you have an idea/suggestion of the structure of the test directory.
> For example,
> here following ISO/IEC 14882

[...]

did you have a look into these ? I'd be interested in putting them
into synopsis' testing framework and, if it's ok with everybody here
into opencxx, too. Grzegorz, what about my other mail ? Do you agree
to make the change I propose, i.e. let 'occ' display the translated
ptree if no '-p' option is given ?
Gilles, did you have a look into the qmtest harness I put into synopsis ?
What do you think about it ? Should we put a copy of it (the part that
concerns opencxx) into the opencxx repository ?

Regards,
		Stefan

Re: [Opencxx-users] New user and stupid question...

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

Hi,

This should work (not tested, no error handling):

  void TranslateMemberFunction(Environment* e, Member& m)
  {
    int line;
    Ptree* tmp = e->GetLineNumber(m->GetName(), line);
    string filename(tmp->ToString());
    ...
  }

Let me know if it does not.

BR
Grzegorz

On Thu, 9 Sep 2004, RodZilla wrote:

> Hello,
>
> I've been using OpenC++ for a bit more than a week now
> and I have a *really* stupid question : is it possible
> in a TranslateMemberFunction method to obtain the name
> of the source file (in which the member function is
> defined) ?
> I looked into the doc, examples and source code and
> didn't find anything (but it's likely I missed
> something).
>
> Thanks a lot in advance.
>
> Best regards,
>
> Rod.
>
>
> -------------------------------------------------------
> 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=5047&alloc_id=10808&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
>

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

[Opencxx-users] New user and stupid question...

[RodZilla <rod...@fr...>]

Hello,

I've been using OpenC++ for a bit more than a week now
and I have a *really* stupid question : is it possible
in a TranslateMemberFunction method to obtain the name
of the source file (in which the member function is
defined) ?
I looked into the doc, examples and source code and
didn't find anything (but it's likely I missed
something).

Thanks a lot in advance.

Best regards,

Rod.

Re: [Opencxx-users] How to change global functions ?

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

Hi,

Have a look at 'Class::SetMetaclassForFunctions()' (described in appendix
to documentation). Please let me know if you any further assistance.

BR
Grzegorz

On Thu, 9 Sep 2004, Gyun Woo wrote:

> Dear OpenC++ Users:
>
> I am pretty new to OpenC++. I have just read the tutorial
> and found that OpenC++ may be used for program transformation.
> However, currently it seems to support only the class structures.
> Can I change the global functions of the source code using OpenC++ ?
> Thanks in advance!
>
> Gyun Woo
>
> --
> wo...@pu...
> +82-51-510-3518
> Pusan National University
>
>
> -------------------------------------------------------
> 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=5047&alloc_id=10808&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
>

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

[Opencxx-users] How to change global functions ?

[Gyun W. <wo...@gm...>]

Dear OpenC++ Users:

I am pretty new to OpenC++. I have just read the tutorial
and found that OpenC++ may be used for program transformation.
However, currently it seems to support only the class structures.
Can I change the global functions of the source code using OpenC++ ?
Thanks in advance!

Gyun Woo

-- 
wo...@pu...
+82-51-510-3518
Pusan National University

Re: [Opencxx-users] Next tasks

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

Hi Gilles & Stefan,

You may want to reuse the solution that is in place at opencxx.sf.net,
this is a Python script, it always sends links. Very easy to modify (but I
am not sure what changes are required to hook it up to svn). You can find
it in CVSROOT module of opencxx.sf.net

BR
Grzegorz

On Tue, 7 Sep 2004, Stefan Seefeld wrote:

> Gilles J. Seguin wrote:
>
> > Well, watcher that watch half the time is no fun.
>
> you can always look at http://synopsis.fresco.org/changelog.html
> to see all the checkins. The same data exist as an rss feed, too.
>
> > If we look at mailing list like
> > <http://gcc.gnu.org/ml/libstdc++-cvs/2004-q3/>
> > choosing
> > <http://gcc.gnu.org/ml/libstdc++-cvs/2004-q3/msg00576.html>
> >
> > We have:
> > - Modified files:
> > - Added files:
> > - Log message:
> > - Patches:
> >   Here is the interesting modification.
> >   * * Do not send the patch, but a reference to the patch(es). * *
> >
> >   They succeed to mystified my again.
>
> well, if the data are too big to be included in the mail, just
> send a reference. That's another possibility: just mail an URL
> to the revision view via viewcvs. However, some people don't like
> that either because it's another indirection. It's always a trade-off...
>
> If you want to fix the commit-email.pl script to ommit diffs
> that are too big, here is the code:
> http://svn.collab.net/viewcvs/svn/trunk/tools/hook-scripts/commit-email.pl.in?rev=10787&view=auto
>
> 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=5047&alloc_id=10808&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
>

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

Re: [Opencxx-users] Next tasks

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

Gilles J. Seguin wrote:

> Well, watcher that watch half the time is no fun.

you can always look at http://synopsis.fresco.org/changelog.html
to see all the checkins. The same data exist as an rss feed, too.

> If we look at mailing list like
> <http://gcc.gnu.org/ml/libstdc++-cvs/2004-q3/>
> choosing
> <http://gcc.gnu.org/ml/libstdc++-cvs/2004-q3/msg00576.html>
> 
> We have:
> - Modified files:
> - Added files:
> - Log message:
> - Patches:
>   Here is the interesting modification.
>   * * Do not send the patch, but a reference to the patch(es). * *
> 
>   They succeed to mystified my again.

well, if the data are too big to be included in the mail, just
send a reference. That's another possibility: just mail an URL
to the revision view via viewcvs. However, some people don't like
that either because it's another indirection. It's always a trade-off...

If you want to fix the commit-email.pl script to ommit diffs
that are too big, here is the code:
http://svn.collab.net/viewcvs/svn/trunk/tools/hook-scripts/commit-email.pl.in?rev=10787&view=auto

Regards,
		Stefan

Re: [Opencxx-users] Next tasks

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

On Tue, 2004-08-31 at 20:13, Stefan Seefeld wrote:
> Gilles J. Seguin wrote:
> 
> > About 'my branch', I am puzzle.
> > Does this branch is in opencxx or synopsis.
> > If in opencxx, I was under the impression that modification in CVS
> > where sending email to ope...@li....
> > What is the name of the branch.  I may not be aware of a lot of
> > work you have been doing.
> > I am tracking through syn...@fr...
> 
> yeah, I'm talking about synopsis. Sorry if that wasn't clear.
> And again, half of my checkins don't show up on the synopsis-changes
> list as the diffs are so big that it wouldn't make sense to mail
> them. I'll patch the commit-email.pl script some day to skip the
> diffs if they exceed some size...

Well, watcher that watch half the time is no fun.

If we look at mailing list like
<http://gcc.gnu.org/ml/libstdc++-cvs/2004-q3/>
choosing
<http://gcc.gnu.org/ml/libstdc++-cvs/2004-q3/msg00576.html>

We have:
- Modified files:
- Added files:
- Log message:
- Patches:
  Here is the interesting modification.
  * * Do not send the patch, but a reference to the patch(es). * *

  They succeed to mystified my again.

The loginfo file, contains the filter log_accum that they have
replace with log_accum_bugzillafied,  which I can not found
the source/reference to it, sorry.

That email was for saying, they have a mechanism for sending huge
"reference" to patch.

have fun,
gilles

[Opencxx-users] displaying the parse tree

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

hi there,

in my work on synopsis I just checked in a tiny applet that
prints out the parse tree, either before or after
translating it with 'ClassWalker', depending on a switch.

I'd be very interested in adding support to the 'occ'
application to do the same (right now the ptree can only
be printed before the translation stage).

What do you think ? What would be the best way to do it ?
I imagine something simple such as printing after parsing
when '-p' ('stop after parsing') is given, else print after
translation.

Comments ?

Regards,
		Stefan

Re: [Opencxx-users] Throw Clause Fix

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

jal...@st... wrote:
> Hello Everyone again,
> 
> I have fixed the throw clause problem that was in my previous email by 
> changing the body of the method bool Parser::optThrowDecl(Ptree*& throw_decl) 
> in the parser.cc file (for OpenC++ 2.5.12 but each version of OpenC++ has the 
> same implementation for this method).  Here is what I changed this method to:

[...]

Thanks for the bug report, and thanks for trying to fix it !
I don't think your code really solves the problem, though.
Here is my understanding of the problem:

First note that the ptree fragment that results from parsing the declaration
is never used as of now. (Grzegorz: we should add new ptree nodes for this,
shouldn't we ?)
optThrowDecl uses 'rName' in a loop, i.e. it assumes the throw specifier
contains a list of identifiers. That is probably so because in most cases
what you throw is a class, and as non-builtin types are not looked up during
this stage of the parsing, optThrowDecl simply has to look for identifiers.
Now you put a builtin type there, which the lexer reports as a special token,
which the parser doesn't expect (it expects identifiers !). Boom !!

You have replaced the loop involving 'rName' with 'rTempArgList'.
That's a method that parses template arguments, which is probably not what
you thought what it does :-)

Anyways I believe as this wasn't really a problem until now we should just
keep a record of this bug (a good case for a unit test to remind us until
we fix it !) and fix it when we can. That is, I believe, as soon as we
have a symbol lookup mechanism integrated into the parser, and thus we can
look for a 'list of types'.

Makes sense ?

Thanks for your your help !

Stefan

Re: [Opencxx-users] opencxx refactoring

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

Grzegorz Jakacki wrote:
> 
> Stefan Seefeld wrote:
> 
>>   Finally, I cleaned up the Encoding class such that PTree::Nodes now 
>> hold
>>   PTree::Encoding instances instead of 'char *'.
> 
> 
> Does PTree now need to know about Encoding?

yes. In my view Encoding is nothing but a type-safe version of
the 'unsigned char *' that already was there before. The stuff that
the PTree shouldn't care about should eventually be factored out,
possibly into TypeInfo. One of the issues we should address next...

Regards,
		Stefan