opencxx-users

[Opencxx-users] Re: parsing, manipulating, regenerating c++ code

[Bing-Chang L. <op...@bc...>]

Perhaps you can have a look are the PUMA library from

http://wwwivs.cs.uni-magdeburg.de/~puma/

It's packaged with Aspect C++ now.

http://www.aspectc.org

It seems to allow you to search syntax trees and to perform manipulations on 
them. The User Manual's tutorial shows how it can be used to rename all 
instances of a private member variable in C++ source files.

Cheers
Bing-Chang Lai

Re: [Opencxx-users] Re: parsing, manipulating, regenerating c++ code

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

Stefan Seefeld wrote:

> * finally, when regenerating the code, you through out everything

--------------------------------------------^^^^

oh my, that should read 'throw', in case anybody wondered.
/me blushes...

>   in between the markers and replace it by the stored include
>   directive

Regards,
		Stefan

Re: [Opencxx-users] Re: parsing, manipulating, regenerating c++ code

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

Andrew Delong wrote:

> If OpenC++ still cannot provide this ability, I'd be happy to
> contribute as long as it's a relatively small thing to do (I only have
> two weeks to finish my project :~)

While I believe it is quite substantial work, you may want to look
into it anyways :-) Note that I don't think 'include etc.' can work
in general. You may be able to reintroduce the includes, but definitely
not the macros.

Here is how 'ctool' / 'synopsis' do it:

* the parser receives preprocessed code

* the parser generates special parse tree nodes as markers where
   the header is entered and where it is left (use '#line' directives
   to figure out the exact place).

* you need a way to find out what the header name was that was
   originally used, and whether it used <> or "" (synopsis has some
   special logic to interact with the preprocessor to get at that data)

* finally, when regenerating the code, you through out everything
   in between the markers and replace it by the stored include
   directive

HTH,
		Stefan

[Opencxx-users] Re: parsing, manipulating, regenerating c++ code

[Andrew D. <and...@gm...>]

Regarding the message from Maarten de Boer:

> I am looking for an application that can parse c++, store it in a AST,
> and regenerate the original c++ code.

I also could use this exact functionality. I want to use OpenC++ as a
source-to-source translation tool that operates on both hpp and cpp
files, but it must preserve #include etc in the final output. In the
end, the final headers will be used by other source files without occ.

If OpenC++ still cannot provide this ability, I'd be happy to
contribute as long as it's a relatively small thing to do (I only have
two weeks to finish my project :~)

This is a great project by the way, nice work Volunteers...

    Andrew

Re: [Opencxx-users] Re: Environment::Lookup Question/Problem

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

Scott D. Fleming wrote:
> 
> Hi Grzegorz,
> Thank you very much for your prompt response. Your advice was very 
> helpful; as you said, I was looking in the wrong environment. 
> Unfortunately, my problem has not been completely solved. If the 
> function that I want to lookup is overloaded, then Environment::Lookup 
> will always report the same version regardless of the arguments to the 
> call. I suppose this is because Environment::Lookup simply returns the 
> first symbol it finds with a name matching that of the function.
> 
> For example, if I have a class with an overloaded member function, like 
> this:
[...]
> 
> The obvious solution that I see here is to lookup all the possible 
> versions of the member function using Class::LookupMember, lookup the 
> types of the arguments using Environment::Lookup, and use the gathered 
> information to determine which version of the member function was 
> called.  Unfortunately, this solution is rather complex as there are a 
> lot of special cases to worry about (e.g., automatic type conversion in 
> C++, arguments that are expressions, etc.).
> 
> Again, any advice you offer towards a better solution would be most 
> appreciated.

I am afraid I don't see any easier solution. OpenC++ is missing the 
functionality you describe. Would like to implement this piece? (Perhaps 
not with all corner cases at first, e.g. omitting conversions simplifies 
a lot.)

BR
Grzegorz

> Thanks, Scott
> 
> 
> Grzegorz Jakacki wrote:
> 
>>
>> Hi,
>>
>> sdflemin wrote:
>>
>>>
>>> Hi,
>>> I have been using OpenC++ for about a year now, and recently ran into 
>>> a problem. I am doing member call translations (using 
>>> MemberCallTranslate), and I need to know if the member function that 
>>> the call is being made on returns void. I find that when the call is 
>>> made outside the member's class, the Environment does not contain the 
>>> member function's symbol. A stripped-down sample that illustrates the 
>>> problem follows.
>>
>>
>>
>> I don't have much time to look into it now, but it seems to me that 
>> you are looking in wrong environment. Given
>>
>>     C x;
>>     x->f();
>>
>> you should be looking for 'f()' in environment of class C, not in the 
>> environment of the call site.
>>
>> Given the fact that you are in a metaclass of C, you should be able to 
>> get hold on the right environment by calling 'this->GetEnvironment()'.
>>
>> Let me know if this does not work, I will have a deeper look.
>>
>>> I have used the Environment::Dump function before the Lookup to help 
>>> debug this, and sure enough, none of the Foo member functions appear 
>>> in the dump. The Foo class does, however...
>>
>>
>>
>> Seems right.
>>
>>> My question to you: is this behavior a feature that I don't 
>>> understand or a bug?
>>>
>>> If it's a feature, can you suggest a way for me to determine the 
>>> return type of foo_do_it() in the TranslateMemberCall() function?
>>>
>>> If it's a bug, can you suggest a patch? I am happy to patch the 
>>> OpenC++ source myself, but it will take me awhile to understand it. 
>>
>>
>>
>> It seems that no patch is needed here, but if you would consider 
>> contributing your work to OpenC++ there are always bigger and smaller 
>> jobs to do in OpenC++, OpenC++Core or OpenC++ website, just contact me 
>> for arrangements.
>>
>>> Any pointers you can give me would be great, and also, is there a 
>>> document that describes the OpenC++ source design?
>>
>>
>>
>> See opencxx/doc/architecture.html in CVS.
>>
>> BR
>> Grzegorz
>>
>>
>>
>>> Many Thanks, Scott
>>>
>>> PS: My thanks to the OpenC++ maintainers. It has been an extremely 
>>> useful tool for me, and I am glad that the project is alive and well.
>>>
>>>
>>> -------------------------------------------------------
>>> The SF.Net email is sponsored by: Beat the post-holiday blues
>>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>>> _______________________________________________
>>> Opencxx-users mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>>
>>
>>
>>
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

[Opencxx-users] Re: Environment::Lookup Question/Problem

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

Hi Grzegorz,
Thank you very much for your prompt response. Your advice was very 
helpful; as you said, I was looking in the wrong environment. 
Unfortunately, my problem has not been completely solved. If the 
function that I want to lookup is overloaded, then Environment::Lookup 
will always report the same version regardless of the arguments to the 
call. I suppose this is because Environment::Lookup simply returns the 
first symbol it finds with a name matching that of the function.

For example, if I have a class with an overloaded member function, like 
this:

   my_meta class Foo {
   public:
     void foo_do_it()      { return; }
     int  foo_do_it(int i) { return i; }
   };

And two calls like:

   Foo f;
   f.foo_do_it();
   f.foo_do_it(99);

Then when the calls are translated, Environment::Lookup always reports 
foo_do_it having a return type of void. Environment::Dump shows two 
versions of foo_do_it, though.

The obvious solution that I see here is to lookup all the possible 
versions of the member function using Class::LookupMember, lookup the 
types of the arguments using Environment::Lookup, and use the gathered 
information to determine which version of the member function was 
called.  Unfortunately, this solution is rather complex as there are a 
lot of special cases to worry about (e.g., automatic type conversion in 
C++, arguments that are expressions, etc.).

Again, any advice you offer towards a better solution would be most 
appreciated.
Thanks, Scott


Grzegorz Jakacki wrote:
> 
> Hi,
> 
> sdflemin wrote:
> 
>>
>> Hi,
>> I have been using OpenC++ for about a year now, and recently ran into 
>> a problem. I am doing member call translations (using 
>> MemberCallTranslate), and I need to know if the member function that 
>> the call is being made on returns void. I find that when the call is 
>> made outside the member's class, the Environment does not contain the 
>> member function's symbol. A stripped-down sample that illustrates the 
>> problem follows.
> 
> 
> I don't have much time to look into it now, but it seems to me that you 
> are looking in wrong environment. Given
> 
>     C x;
>     x->f();
> 
> you should be looking for 'f()' in environment of class C, not in the 
> environment of the call site.
> 
> Given the fact that you are in a metaclass of C, you should be able to 
> get hold on the right environment by calling 'this->GetEnvironment()'.
> 
> Let me know if this does not work, I will have a deeper look.
> 
>> I have used the Environment::Dump function before the Lookup to help 
>> debug this, and sure enough, none of the Foo member functions appear 
>> in the dump. The Foo class does, however...
> 
> 
> Seems right.
> 
>> My question to you: is this behavior a feature that I don't understand 
>> or a bug?
>>
>> If it's a feature, can you suggest a way for me to determine the 
>> return type of foo_do_it() in the TranslateMemberCall() function?
>>
>> If it's a bug, can you suggest a patch? I am happy to patch the 
>> OpenC++ source myself, but it will take me awhile to understand it. 
> 
> 
> It seems that no patch is needed here, but if you would consider 
> contributing your work to OpenC++ there are always bigger and smaller 
> jobs to do in OpenC++, OpenC++Core or OpenC++ website, just contact me 
> for arrangements.
> 
>> Any pointers you can give me would be great, and also, is there a 
>> document that describes the OpenC++ source design?
> 
> 
> See opencxx/doc/architecture.html in CVS.
> 
> BR
> Grzegorz
> 
> 
> 
>> Many Thanks, Scott
>>
>> PS: My thanks to the OpenC++ maintainers. It has been an extremely 
>> useful tool for me, and I am glad that the project is alive and well.
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> Opencxx-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opencxx-users
> 
> 
> 

Re: [Opencxx-users] Environment::Lookup Question/Problem

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

Hi,

sdflemin wrote:
> 
> Hi,
> I have been using OpenC++ for about a year now, and recently ran into a 
> problem. I am doing member call translations (using 
> MemberCallTranslate), and I need to know if the member function that the 
> call is being made on returns void. I find that when the call is made 
> outside the member's class, the Environment does not contain the member 
> function's symbol. A stripped-down sample that illustrates the problem 
> follows.

I don't have much time to look into it now, but it seems to me that you 
are looking in wrong environment. Given

     C x;
     x->f();

you should be looking for 'f()' in environment of class C, not in the 
environment of the call site.

Given the fact that you are in a metaclass of C, you should be able to 
get hold on the right environment by calling 'this->GetEnvironment()'.

Let me know if this does not work, I will have a deeper look.

> I have used the Environment::Dump function before the Lookup to help 
> debug this, and sure enough, none of the Foo member functions appear in 
> the dump. The Foo class does, however...

Seems right.

> My question to you: is this behavior a feature that I don't understand 
> or a bug?
> 
> If it's a feature, can you suggest a way for me to determine the return 
> type of foo_do_it() in the TranslateMemberCall() function?
> 
> If it's a bug, can you suggest a patch? I am happy to patch the OpenC++ 
> source myself, but it will take me awhile to understand it. 

It seems that no patch is needed here, but if you would consider 
contributing your work to OpenC++ there are always bigger and smaller 
jobs to do in OpenC++, OpenC++Core or OpenC++ website, just contact me 
for arrangements.

> Any pointers 
> you can give me would be great, and also, is there a document that 
> describes the OpenC++ source design?

See opencxx/doc/architecture.html in CVS.

BR
Grzegorz



> Many Thanks, Scott
> 
> PS: My thanks to the OpenC++ maintainers. It has been an extremely 
> useful tool for me, and I am glad that the project is alive and well.
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

[Opencxx-users] Environment::Lookup Question/Problem

[sdflemin <sdf...@cs...>]

Hi,
I have been using OpenC++ for about a year now, and recently ran into a problem. 
I am doing member call translations (using MemberCallTranslate), and I need to 
know if the member function that the call is being made on returns void. I find 
that when the call is made outside the member's class, the Environment does not 
contain the member function's symbol. A stripped-down sample that illustrates 
the problem follows.

// THE METAPROGRAM /////////////////////////////////////////////////////////////
// File: My_Meta.mc

#include <iostream>
#include <mop.h>
using namespace std;

char* const SYNC_CMOD = "my_meta";

class My_Meta : public Class {
public:
   My_Meta() : Class() {}
   My_Meta(Environment* e, char* name) : Class(e, name) {}
   My_Meta(Environment* e, Ptree* name) : Class(e, name) {}
   static bool Initialize()
   { RegisterMetaclass(SYNC_CMOD, "My_Meta"); return true; }
   Ptree* TranslateMemberCall(Environment* env, Ptree* object, Ptree* op,
			     Ptree* member, Ptree* arglist);
};

Ptree* My_Meta::TranslateMemberCall(Environment* env, Ptree* object,
					    Ptree* op, Ptree* member,
					    Ptree* arglist)
{
   TypeInfo member_type;
   if (!env->Lookup(member, member_type)) { // <---- LOOKUP ATTEMPTED HERE!!!!!!!
     ErrorMessage(env, "environment cannot find member: ", member, member);
     exit(1);
   }
   member_type.Dereference();
   ...
}

// THE BASE-LEVEL PROGRAM //////////////////////////////////////////////////////
// File: base_level.cpp

#include <iostream>
using namespace std;

my_meta class Foo {
public:
   Foo() {}
   void foo_do_it() { return; }
};

class Bar {
public:
   Bar(Foo* a_foo) : my_foo(a_foo) {}
   void bar_do_it();
private:
   Foo* my_foo;
};

void Bar::bar_do_it()
{
   my_foo->foo_do_it(); // <----LOOKUP FAILS ON THIS LINE!!!!!!!!!!!!!!!!!!!!!!!!
}

int main()
{
   Foo* a_foo = new Foo;
   Bar* a_bar = new Bar(a_foo);
   a_bar->bar_do_it();
   ...
}

// COMPILATION OUTPUT //////////////////////////////////////////////////////////
      occ2 -c My_Meta.mc -o My_Meta.o
      In file included from My_Meta.mc:5:
      /.../include/mop.h:19:2: warning: #warning "header <mop.h> is deprecated,
      use <opencxx/mop.h>"
      g++ -o my_occ My_Meta.o -L/.../lib -locc -lltdl

      ./my_occ -c base_level.cpp
      [MetaclassRegistration(My_Meta)]
      [Class::RegisterMetaclass(my_meta,My_Meta]
      EXECUTING: g++ g++ -D__opencxx -E -o base_level.occ -x c++ base_level.cpp 
---> base_level.cpp:34: environment cannot find member: foo_do_it

////////////////////////////////////////////////////////////////////////////////

I have used the Environment::Dump function before the Lookup to help debug this, 
and sure enough, none of the Foo member functions appear in the dump. The Foo 
class does, however...

My question to you: is this behavior a feature that I don't understand or a bug?

If it's a feature, can you suggest a way for me to determine the return type of 
foo_do_it() in the TranslateMemberCall() function?

If it's a bug, can you suggest a patch? I am happy to patch the OpenC++ source 
myself, but it will take me awhile to understand it. Any pointers you can give 
me would be great, and also, is there a document that describes the OpenC++ 
source design?
Many Thanks, Scott

PS: My thanks to the OpenC++ maintainers. It has been an extremely useful tool 
for me, and I am glad that the project is alive and well.

Re: [Opencxx-users] InsertBeforeStatement doesn't work when called from the context of a ClassBodyWalker...

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

Scott Shumaker wrote:
> I've been writing some code with OpenC++, and have run into the
> following problem:
> 
> testClass class A
> {
>    int mData;
>    void Foo()
>    {
>       mData = 7;
>    }
> };
> 
> I've written a TranslateMemberWrite for testClass, which gets called
> when mData = 7 is referenced.  However, when I call
> InsertBeforeStatement with some additional code, nothing gets
> inserted.
> 
> On the other hand, this DOES work:
> 
> class A
> {
>    int mData;
>    void Foo();
> };
> 
> 
> void A::Foo()
> {
>    mData = 7;
> }
> 
> Looking through the code, the problem arises in ClassWalker.cc, line
> 757 (your line #s may be slightly different.  The code in question is
> as follows:
> 
> 	metaobject = GetClassMetaobject(type);
> 	if(metaobject != 0){
> 	    exp2 = metaobject->TranslateMemberWrite(env, object, op,
> 						    member, assign_op, right);
> 	    return CheckMemberEquiv(exp, exp2);
> 	}
>     }
>     else if((scope = env->IsMember(left)) != 0){
> 	metaobject = scope->IsClassEnvironment();
> 	if(metaobject != 0){
> 	    exp2 = metaobject->TranslateMemberWrite(env, left, Second(exp),
> 						    right);       
> 
> 	    return CheckEquiv(exp, exp2);
> 	}
> 
> The code has dropped into the else if case.  Looking at the variables,
> the environment variable env has a ClassBodyWalker, while the current
> context of the function is in a ClassWalker.  The
> InsertBeforeStatement thus inserts the code into the ClassBodyWalker's
> before_function list, which is never applied or copied over to the
> ClassWalker's before_function list, so it never gets inserted.
> 
> This probably would happen with any other code you write inside of an
> inlined function body - InsertBeforeStatement, etc wouldn't work.
> 
> Any suggestions for a fix?  

Sorry, I don't have much time to look into it now. Can you get hold on 
the right walker at the point where TranslateMemberWrite is called?

BR
Grzegorz

[Opencxx-users] Encoding ambiguities

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

hi there,

while trying to enhance the Encoding API I'm looking
at examples of encoded names I'll have to deal with.
Doing that I find that

::A::B<A::Int, 2>::type

maps to

Q[4][0][1]AT[1]B[9]Q[2][1]A[3]Int*[4]type

The point that worries me is the '*', which, according
to the docs refers to a 'non-type template parameter'.

That means types aren't represented unambiguously, as
'A<1>' will generate the same symbol as 'A<2>'. However,
when doing symbol lookup, I obviously have to distinguish the
two.

Was that an oversight in OpenCxx ? Or was that deliberately
left out as full symbol lookup wasn't done anyways ?
Any ideas as to how to fix this ? Chiba ?

Speaking of ambiguities in the Encoding class, I earlier
this year reported the missing array dimensions, but didn't
get feedback on this. Is there any interest into a fix ?

Regards,
		Stefan

RE: [Opencxx-users] update on symbol lookup

[Stefan S. <sse...@ar...>]

> From: Grzegorz Jakacki 

> However your decision about licensing the work derived from 
> OpenC++ in 
> Synopsis is far from what I call collaboration and does not 
> help OpenC++ 
> project.

Allright. Is there anything we could / should do such that we don't
go over this again and again ? Is there some level of communication
we can use for further technical discussion ? I understand that you
don't want me to discuss the evolution of the synopsis *code* here,
but what about high level design ?
What are your own plans for openc++ ? It seemed we agreed on the general
directions of integrating symbol lookup into the parsing, i.e. not
doing it in a second pass (Walker). Is there not a lot of potential
for discussion ? I'v been trying to get discussions going, but
there wasn't much feedback. Are these attempts to collaborate
unsolicited, too ?

What do other people on the list think about this ? As it stands,
confining the discussions to the synopsis list wouldn't make a big
difference for me (sadly), though I'v not given up hope yet. ;-)

Regards,
		Stefan

Re: [Opencxx-users] update on symbol lookup

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

Stefan Seefeld wrote:
> Hi Grzegorz,
 >
>>From: Grzegorz Jakacki [mailto:jakacki(at)acm.org]
 >>
>>This list is for OpenC++ related issues, while your e-mail is about 
>>Synopsis. You refused to share your contributions under 
>>OpenC++ license 
>>and prefer to keep them under GPL in Synopsis.
 >
> As we discussed licensing issues quite a bit I have to correct this:
> you ought to be very aware that the above is false ! Synopsis is *not*
> distributed under GPL, but LGPL. It is an important difference and
> you should know that !
> Please don't make any misrepresentations like this.

I am sorry about that. I meant LGPL.

>>Fine. However in this 
>>situation I hope it is clear to you that contributions that go to 
>>Synopsis are lost for OpenC++ (although not the other way around).
> 
> 
> No, that is not clear. Anybody who contributes code to either side
> is free to contribute it to the other, too.

You know that this is unlikely.

> And, there is much more than code that can be shared. As you know
> I'd be very happy to discuss the underlaying design. I once posted
> my ideas here and got some feedback (though not much, unfortunately).
> As I have now fleshed out some more of the high level design, I'd like
> to follow up.
> This is not meant to attract people away from OpenC++ ! It's an
> attempt to exchange ideas. After all we agreed about the general
> direction to take half a year ago.
 >
> If you don't want me to discuss such stuff with you I'll keep it 
> to the synopsis list. But please stop accusing me from not 
> collaborating.

I admit that you contributed a lot to OpenC++ and I appreciate it.

However your decision about licensing the work derived from OpenC++ in 
Synopsis is far from what I call collaboration and does not help OpenC++ 
project.

BR
Grzegorz

PS: I would appreciate if you could obfuscate my e-mail address when 
posting to public forums.

RE: [Opencxx-users] update on symbol lookup

[Stefan S. <sse...@ar...>]

Hi Grzegorz,

> From: Grzegorz Jakacki [mailto:ja...@ac...]

> This list is for OpenC++ related issues, while your e-mail is about 
> Synopsis. You refused to share your contributions under 
> OpenC++ license 
> and prefer to keep them under GPL in Synopsis.

As we discussed licensing issues quite a bit I have to correct this:
you ought to be very aware that the above is false ! Synopsis is *not*
distributed under GPL, but LGPL. It is an important difference and
you should know that !
Please don't make any misrepresentations like this.

> Fine. However in this 
> situation I hope it is clear to you that contributions that go to 
> Synopsis are lost for OpenC++ (although not the other way around).

No, that is not clear. Anybody who contributes code to either side
is free to contribute it to the other, too.
And, there is much more than code that can be shared. As you know
I'd be very happy to discuss the underlaying design. I once posted
my ideas here and got some feedback (though not much, unfortunately).
As I have now fleshed out some more of the high level design, I'd like
to follow up.
This is not meant to attract people away from OpenC++ ! It's an
attempt to exchange ideas. After all we agreed about the general
direction to take half a year ago.
If you don't want me to discuss such stuff with you I'll keep it 
to the synopsis list. But please stop accusing me from not 
collaborating.

Good luck,
		Stefan

Re: [Opencxx-users] update on symbol lookup

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

Dear Stefan,

This list is for OpenC++ related issues, while your e-mail is about 
Synopsis. You refused to share your contributions under OpenC++ license 
and prefer to keep them under GPL in Synopsis. Fine. However in this 
situation I hope it is clear to you that contributions that go to 
Synopsis are lost for OpenC++ (although not the other way around). In 
such circumstances please show a bit of consideration and do not use 
this forum to attract people from OpenC++ to Synopsis. I hope you 
understand it, since I would hate to use moderator privledges as you did 
to my e-mail on Synopsis mailing list.

Having said that, OpenC++ is always open to any form of cooperation, 
promotion and exchange, provided the benefits are mutual.

Thanks
Grzegorz

Stefan Seefeld wrote:
> hi there,
> 
> Here is some status update on the work currently done on the symbol lookup.
> The basic classes for symbol lookup are in place, and the parser class has
> been modified to declare symbols as they are parsed. Specifically, the
> SymbolLookup module provides a set of 'Symbol' types and a set of 'Scope'
> classes [*]. The details are encapsulated behind a 'SymbolLookup::Table' 
> facade,
> which allows some polymorphism for example to support a variety of dialects
> (at least C as well as C++ symbol lookup).
> 
> The 'dump-symbols' applet that is compiled within the build tree on request
> can be used to test the current state of affairs. Note that no analysis is
> performed yet as to whether a symbol is just declared or really defined.
> That will be the next step. Also, the lookup isn't implemented yet.
> 
> However, the basic design is shaped out and so the next steps are 
> relatively
> straight forward.
> 
> As always, any help is very much appreciated. For details please visit the
> synopsis task manager at http://synopsis.fresco.org/issues/task , in 
> particular
> http://synopsis.fresco.org/issues/task25 .
> 
> Regards,
>         Stefan
> 
> [*] The diagram at http://synopsis.fresco.org/cxx-parser.png may serve to
>     illustrate the high level design
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

[Opencxx-users] update on symbol lookup

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

hi there,

Here is some status update on the work currently done on the symbol lookup.
The basic classes for symbol lookup are in place, and the parser class has
been modified to declare symbols as they are parsed. Specifically, the
SymbolLookup module provides a set of 'Symbol' types and a set of 'Scope'
classes [*]. The details are encapsulated behind a 'SymbolLookup::Table' facade,
which allows some polymorphism for example to support a variety of dialects
(at least C as well as C++ symbol lookup).

The 'dump-symbols' applet that is compiled within the build tree on request
can be used to test the current state of affairs. Note that no analysis is
performed yet as to whether a symbol is just declared or really defined.
That will be the next step. Also, the lookup isn't implemented yet.

However, the basic design is shaped out and so the next steps are relatively
straight forward.

As always, any help is very much appreciated. For details please visit the
synopsis task manager at http://synopsis.fresco.org/issues/task , in particular
http://synopsis.fresco.org/issues/task25 .

Regards,
		Stefan

[*] The diagram at http://synopsis.fresco.org/cxx-parser.png may serve to
     illustrate the high level design

[Opencxx-users] InsertBeforeStatement doesn't work when called from the context of a ClassBodyWalker...

[Scott S. <ssh...@gm...>]

I've been writing some code with OpenC++, and have run into the
following problem:

testClass class A
{
   int mData;
   void Foo()
   {
      mData = 7;
   }
};

I've written a TranslateMemberWrite for testClass, which gets called
when mData = 7 is referenced.  However, when I call
InsertBeforeStatement with some additional code, nothing gets
inserted.

On the other hand, this DOES work:

class A
{
   int mData;
   void Foo();
};


void A::Foo()
{
   mData = 7;
}

Looking through the code, the problem arises in ClassWalker.cc, line
757 (your line #s may be slightly different.  The code in question is
as follows:

	metaobject = GetClassMetaobject(type);
	if(metaobject != 0){
	    exp2 = metaobject->TranslateMemberWrite(env, object, op,
						    member, assign_op, right);
	    return CheckMemberEquiv(exp, exp2);
	}
    }
    else if((scope = env->IsMember(left)) != 0){
	metaobject = scope->IsClassEnvironment();
	if(metaobject != 0){
	    exp2 = metaobject->TranslateMemberWrite(env, left, Second(exp),
						    right);       

	    return CheckEquiv(exp, exp2);
	}

The code has dropped into the else if case.  Looking at the variables,
the environment variable env has a ClassBodyWalker, while the current
context of the function is in a ClassWalker.  The
InsertBeforeStatement thus inserts the code into the ClassBodyWalker's
before_function list, which is never applied or copied over to the
ClassWalker's before_function list, so it never gets inserted.

This probably would happen with any other code you write inside of an
inlined function body - InsertBeforeStatement, etc wouldn't work.

Any suggestions for a fix?  

Thanks,
Scott

[Opencxx-users] Glory to Volunteers!

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

Hi all!

Today is an International Vounteers' Day and I would like to take this 
opportunity to thank all past and present contributors who comitted 
their time and skills to move OpenC++ forward.

Thanks and keep the contributions comming!

Best regards
Grzegorz
[project administrator]

Re: [Opencxx-users] Errorlog compilation problem - occ-core

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

Alberto Paro wrote:
> Compiling test of occ-core cvs version I have a problem with gconv.
> I attach the full error log. And full info version of my gcc.

Try to remove '-fprofile-arcs' and '-ftest-coverage' from CXXFLAGS in 
Makefile. Let me know if you need any further assistance.

BR
Grzegorz

>  
> Hi,
> 	Alberto
> 
> 
> gcc -v
> Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
> Configured with: /var/tmp/portage/gcc-3.4.3/work/gcc-3.4.3/configure
> --enable-version-specific-runtime-libs --prefix=/usr
> --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4
> --includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include
> --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4
> --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4/man
> --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4/info
> --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/g
> ++-v3 --host=i686-pc-linux-gnu --disable-altivec --enable-nls
> --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu
> --with-system-zlib --disable-checking --disable-werror
> --disable-libunwind-exceptions --enable-shared --enable-threads=posix
> --disable-multilib --disable-libgcj --enable-languages=c,c++,f77
> Thread model: posix
> gcc version 3.4.3  (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> occ-core/parser/ParserTestGlue.o(.text+0x4dd): In function `global constructors keyed to main_GCOV':
> occ-core/parser/ParserTestGlue.cc:45: undefined reference to `__gcov_init'
> occ-core/parser/ParserTestGlue.o(.data+0x164): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(Lex.o)(.text+0x3293): In function `global constructors keyed to _ZN7Opencxx3Lex13user_keywordsE_GCOV':
> occ-core/parser/Lex.cc:1025: undefined reference to `__gcov_init'
> bin/libocc_parser.a(Lex.o)(.data+0x824): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(Parser.o)(.text+0x204c9): In function `global constructors keyed to _ZN7Opencxx6Parser10LineNumberEPcRS1_Ri_GCOV':
> occ-core/parser/Parser.cc:4636: undefined reference to `__gcov_init'
> bin/libocc_parser.a(Parser.o)(.data+0xdc4): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(Program.o)(.text+0x1c35): In function `global constructors keyed to _ZN7Opencxx7Program3GetEv_GCOV':
> occ-core/parser/Program.cc:413: undefined reference to `__gcov_init'
> bin/libocc_parser.a(Program.o)(.data+0x164): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(ProgramFromStdin.o)(.text+0x72b): In function `global constructors keyed to _ZN7Opencxx16ProgramFromStdinC2Ev_GCOV':
> occ-core/parser/ProgramFromStdin.cc:98: undefined reference to `__gcov_init'
> bin/libocc_parser.a(ProgramFromStdin.o)(.data+0xe4): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(Ptree.o)(.text+0x2735): In function `global constructors keyed to _ZN7Opencxx5Ptree8Display2ERSo_GCOV':
> occ-core/parser/Ptree.cc:555: undefined reference to `__gcov_init'
> bin/libocc_parser.a(Ptree.o)(.data+0x3e4): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeAccessDecl.o)(.text+0xf1): In function `global constructors keyed to _ZN7Opencxx15PtreeAccessDeclC2EPNS_5PtreeES2__GCOV':
> occ-core/parser/PtreeAccessDecl.cc:67: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeAccessDecl.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeAccessSpec.o)(.text+0xf1): In function `global constructors keyed to _ZN7Opencxx15PtreeAccessSpecC2EPNS_5PtreeES2__GCOV':
> occ-core/parser/PtreeAccessSpec.cc:67: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeAccessSpec.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeBlock.o)(.text+0x4d): In function `global constructors keyed to _ZN7Opencxx10PtreeBlock9TranslateEPNS_25AbstractTranslatingWalkerE_GCOV':
> occ-core/parser/PtreeBlock.cc:56: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeBlock.o)(.data+0x44): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeBrace.o)(.text+0x9b7): In function `global constructors keyed to _ZN7Opencxx10PtreeBrace5PrintERSoii_GCOV':
> occ-core/parser/PtreeBrace.cc:126: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeBrace.o)(.data+0x124): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeClassBody.o)(.text+0x5d): In function `global constructors keyed to _ZN7Opencxx14PtreeClassBody9TranslateEPNS_25AbstractTranslatingWalkerE_GCOV':
> occ-core/parser/PtreeClassBody.cc:56: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeClassBody.o)(.data+0x44): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeClassSpec.o)(.text+0x1fd): In function `global constructors keyed to _ZN7Opencxx14PtreeClassSpecC2EPNS_5PtreeES2_S2__GCOV':
> occ-core/parser/PtreeClassSpec.cc:86: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeClassSpec.o)(.data+0xa4): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeDeclaration.o)(.text+0x65): In function `global constructors keyed to _ZN7Opencxx16PtreeDeclaration4WhatEv_GCOV':
> occ-core/parser/PtreeDeclaration.cc:62: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeDeclaration.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeDeclarator.o)(.text+0xe73): In function `global constructors keyed to _ZN7Opencxx15PtreeDeclaratorC2EPNS_5PtreeERNS_8EncodingES4_S2__GCOV':
> occ-core/parser/PtreeDeclarator.cc:186: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeDeclarator.o)(.data+0x184): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeDumper.o)(.text+0x669): In function `global constructors keyed to _ZN7Opencxx11PtreeDumper4DumpERSoPKNS_5PtreeE_GCOV':
> occ-core/parser/PtreeDumper.cc:39: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeDumper.o)(.data+0x124): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeEnumSpec.o)(.text+0x123): In function `global constructors keyed to _ZN7Opencxx13PtreeEnumSpecC2EPNS_5PtreeE_GCOV':
> occ-core/parser/PtreeEnumSpec.cc:73: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeEnumSpec.o)(.data+0x84): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeExprStatement.o)(.text+0x4f): In function `global constructors keyed to _ZN7Opencxx18PtreeExprStatement9TranslateEPNS_25AbstractTranslatingWalkerE_GCOV':
> occ-core/parser/PtreeExprStatement.cc:56: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeExprStatement.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeExternTemplate.o)(.text+0x65): In function `global constructors keyed to _ZN7Opencxx19PtreeExternTemplate4WhatEv_GCOV':
> occ-core/parser/PtreeExternTemplate.cc:62: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeExternTemplate.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeFstyleCastExpr.o)(.text+0x2c1): In function `global constructors keyed to _ZN7Opencxx19PtreeFstyleCastExprC2ERNS_8EncodingEPNS_5PtreeES4__GCOV':
> occ-core/parser/PtreeFstyleCastExpr.cc:94: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeFstyleCastExpr.o)(.data+0xa4): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeLinkageSpec.o)(.text+0x65): In function `global constructors keyed to _ZN7Opencxx16PtreeLinkageSpec4WhatEv_GCOV':
> occ-core/parser/PtreeLinkageSpec.cc:62: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeLinkageSpec.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeMetaclassDecl.o)(.text+0x65): In function `global constructors keyed to _ZN7Opencxx18PtreeMetaclassDecl4WhatEv_GCOV':
> occ-core/parser/PtreeMetaclassDecl.cc:62: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeMetaclassDecl.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeName.o)(.text+0x381): In function `global constructors keyed to _ZN7Opencxx9PtreeNameC2EPNS_5PtreeERNS_8EncodingE_GCOV':
> occ-core/parser/PtreeName.cc:93: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeName.o)(.data+0xc4): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeNamespaceAlias.o)(.text+0x65): In function `global constructors keyed to _ZN7Opencxx19PtreeNamespaceAlias4WhatEv_GCOV':
> occ-core/parser/PtreeNamespaceAlias.cc:49: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeNamespaceAlias.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeNamespaceSpec.o)(.text+0x65): In function `global constructors keyed to _ZN7Opencxx18PtreeNamespaceSpec4WhatEv_GCOV':
> occ-core/parser/PtreeNamespaceSpec.cc:62: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeNamespaceSpec.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeTemplateDecl.o)(.text+0x65): In function `global constructors keyed to _ZN7Opencxx17PtreeTemplateDecl4WhatEv_GCOV':
> occ-core/parser/PtreeTemplateDecl.cc:62: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeTemplateDecl.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeTemplateInstantiation.o)(.text+0x65): In function `global constructors keyed to _ZN7Opencxx26PtreeTemplateInstantiation4WhatEv_GCOV':
> occ-core/parser/PtreeTemplateInstantiation.cc:62: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeTemplateInstantiation.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeTypedef.o)(.text+0x65): In function `global constructors keyed to _ZN7Opencxx12PtreeTypedef4WhatEv_GCOV':
> occ-core/parser/PtreeTypedef.cc:62: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeTypedef.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeUserAccessSpec.o)(.text+0xf1): In function `global constructors keyed to _ZN7Opencxx19PtreeUserAccessSpecC2EPNS_5PtreeES2__GCOV':
> occ-core/parser/PtreeUserAccessSpec.cc:67: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeUserAccessSpec.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeUserdefKeyword.o)(.text+0xb3): In function `global constructors keyed to _ZN7Opencxx19PtreeUserdefKeywordC2EPNS_5PtreeES2__GCOV':
> occ-core/parser/PtreeUserdefKeyword.cc:62: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeUserdefKeyword.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeUsing.o)(.text+0x7b7): In function `global constructors keyed to _ZN7Opencxx10PtreeUsingC2EPNS_5PtreeES2_S2_RNS_8EncodingES2__GCOV':
> occ-core/parser/PtreeUsing.cc:83: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeUsing.o)(.data+0x84): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeUtil.o)(.text+0x436f): In function `global constructors keyed to _ZN7Opencxx9PtreeUtil21SetDeclaratorCommentsEPNS_5PtreeES2__GCOV':
> occ-core/parser/PtreeUtil.cc:969: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeUtil.o)(.data+0x3a4): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(TheErrorLog.o)(.text+0x345): In function `global constructors keyed to _ZN7Opencxx11TheErrorLogEv_GCOV':
> occ-core/parser/TheErrorLog.cc:30: undefined reference to `__gcov_init'
> bin/libocc_parser.a(TheErrorLog.o)(.data+0xc4): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(auxil.o)(.text+0x1e5): In function `global constructors keyed to _ZN7Opencxx15gc_aware_strdupEPKc_GCOV':
> occ-core/parser/auxil.cc:67: undefined reference to `__gcov_init'
> bin/libocc_parser.a(auxil.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(deprecated.o)(.text+0x5e1): In function `global constructors keyed to _ZN7Opencxx10DeprecatedEPKcS1__GCOV':
> occ-core/parser/deprecated.cc:44: undefined reference to `__gcov_init'
> bin/libocc_parser.a(deprecated.o)(.data+0x344): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(ptree-generated.o)(.text+0xe1f): In function `global constructors keyed to _ZN7Opencxx14PtreeCommaExpr9TranslateEPNS_25AbstractTranslatingWalkerE_GCOV':
> occ-core/parser/ptree-generated.cc:482: undefined reference to `__gcov_init'
> bin/libocc_parser.a(ptree-generated.o)(.data+0x564): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(CerrErrorLog.o)(.text+0x3c9): In function `global constructors keyed to _ZN7Opencxx12CerrErrorLog6ReportERKNS_3MsgE_GCOV':
> occ-core/parser/CerrErrorLog.cc:50: undefined reference to `__gcov_init'
> bin/libocc_parser.a(CerrErrorLog.o)(.data+0xc4): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(DupLeaf.o)(.text+0x6c5): In function `global constructors keyed to _ZN7Opencxx7DupLeafC2EPci_GCOV':
> occ-core/parser/DupLeaf.cc:96: undefined reference to `__gcov_init'
> bin/libocc_parser.a(DupLeaf.o)(.data+0xc4): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(Encoding.o)(.text+0x3165): In function `global constructors keyed to _ZN7Opencxx8Encoding5ResetERS0__GCOV':
> occ-core/parser/Encoding.cc:539: undefined reference to `__gcov_init'
> bin/libocc_parser.a(Encoding.o)(.data+0x244): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(HashTable.o)(.text+0x1749): In function `global constructors keyed to _ZN7Opencxx9HashTableC2Ev_GCOV':
> occ-core/parser/HashTable.cc:401: undefined reference to `__gcov_init'
> bin/libocc_parser.a(HashTable.o)(.data+0x1a4): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(Leaf.o)(.text+0x6e1): In function `global constructors keyed to _ZN7Opencxx4LeafC2EPci_GCOV':
> occ-core/parser/Leaf.cc:102: undefined reference to `__gcov_init'
> bin/libocc_parser.a(Leaf.o)(.data+0x104): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(LeafName.o)(.text+0x113): In function `global constructors keyed to _ZN7Opencxx8LeafNameC2ERNS_5TokenE_GCOV':
> occ-core/parser/LeafName.cc:67: undefined reference to `__gcov_init'
> bin/libocc_parser.a(LeafName.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(LeafThis.o)(.text+0xab): In function `global constructors keyed to _ZN7Opencxx8LeafThis4WhatEv_GCOV':
> occ-core/parser/LeafThis.cc:69: undefined reference to `__gcov_init'
> bin/libocc_parser.a(LeafThis.o)(.data+0x64): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(NonLeaf.o)(.text+0xdbb): In function `global constructors keyed to _ZN7Opencxx7NonLeafC2EPNS_5PtreeES2__GCOV':
> occ-core/parser/NonLeaf.cc:171: undefined reference to `__gcov_init'
> bin/libocc_parser.a(NonLeaf.o)(.data+0x184): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeArray.o)(.text+0x833): In function `global constructors keyed to _ZN7Opencxx10PtreeArrayC2Ei_GCOV':
> occ-core/parser/PtreeArray.cc:89: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeArray.o)(.data+0x124): undefined reference to `__gcov_merge_add'
> bin/libocc_parser.a(PtreeConstants.o)(.text+0x1509): In function `global constructors keyed to _ZN7Opencxx14PtreeConstants6bool_tE_GCOV':
> occ-core/parser/PtreeConstants.cc:64: undefined reference to `__gcov_init'
> bin/libocc_parser.a(PtreeConstants.o)(.data+0x224): undefined reference to `__gcov_merge_add'
> collect2: ld returned 1 exit status
> make: *** [bin/parser-test-glue] Error 1

Re: [Opencxx-users] OpenC++ gets funding

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

Stefan Seefeld wrote:
> From: Grzegorz Jakacki [mailto:ja...@ac...]
> 
> 
>>See http://www.linuxonpower.com/faq.php
> 
> 
> right, that's where I found:
> 
> "Why are only US contestants elligible?
> 
>  Regretfully, because of time constraints for obtaining legal clearances 
>  internationally, we are able to launch this  first effort as a
> U.S.-contestant-only 
>  event. In future, we will plan for a worldwide event."
> 
> Anyways, I'm glad it worked out for you. 

AFAIU it worked because in this contest I am a judge, not a contestant.

> May be the above was why I didn't
> follow up when I received the initial mail, because it appeared to be
> 'unreachable'.

Seems to me that we should move this conversation off the list, it is no 
longer relevant to OpenC++...

BR
Grzegorz

RE: [Opencxx-users] Errorlog compilation problem - occ-core

[Stefan S. <sse...@ar...>]

> From: Alberto Paro [mailto:al...@pa...]

> Compiling test of occ-core cvs version I have a problem with gconv.
> I attach the full error log. And full info version of my gcc.

this looks like you have a problem with your gcc installation.
Can you successfully compile & link other C++ applications with
that compiler ?

Regards,
		Stefan

[Opencxx-users] Errorlog compilation problem - occ-core

[Alberto P. <al...@pa...>]

Compiling test of occ-core cvs version I have a problem with gconv.
I attach the full error log. And full info version of my gcc.
 
Hi,
	Alberto


gcc -v
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: /var/tmp/portage/gcc-3.4.3/work/gcc-3.4.3/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/g
++-v3 --host=i686-pc-linux-gnu --disable-altivec --enable-nls
--without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu
--with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --enable-shared --enable-threads=posix
--disable-multilib --disable-libgcj --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.3  (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)

RE: [Opencxx-users] OpenC++ gets funding

[Stefan S. <sse...@ar...>]

From: Grzegorz Jakacki [mailto:ja...@ac...]

> See http://www.linuxonpower.com/faq.php

right, that's where I found:

"Why are only US contestants elligible?

 Regretfully, because of time constraints for obtaining legal clearances 
 internationally, we are able to launch this  first effort as a
U.S.-contestant-only 
 event. In future, we will plan for a worldwide event."


Anyways, I'm glad it worked out for you. May be the above was why I didn't
follow up when I received the initial mail, because it appeared to be
'unreachable'.

Regards,
		Stefan

Re: [Opencxx-users] OpenC++ gets funding

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

Stefan Seefeld wrote:
>>From: Grzegorz Jakacki [mailto:ja...@ac...]
> 
> 
>>It was meant as an incentive for project admins so that they 
>>sign up for 
>>judging the ports. You have a project on SF, so you also must have 
>>gotten an invitation to this contest, haven't you?
> 
> yeah, I remember vaguely. It probably got burried under heavy loads 
> of other mail :-/
> 
>>PS: Succesful ports are awarded from another pool and can win $1000
>>     (http://www.linuxonpower.com/rules.php).
> 
> interesting. However, how do you interpret the first paragraph on that
> page, i.e. "The following contest is intended for viewing in the United
> States only..." ?

See http://www.linuxonpower.com/faq.php

BR
Grzegorz

RE: [Opencxx-users] OpenC++ gets funding

[Stefan S. <sse...@ar...>]

> From: Grzegorz Jakacki [mailto:ja...@ac...]

> It was meant as an incentive for project admins so that they 
> sign up for 
> judging the ports. You have a project on SF, so you also must have 
> gotten an invitation to this contest, haven't you?

yeah, I remember vaguely. It probably got burried under heavy loads 
of other mail :-/


> PS: Succesful ports are awarded from another pool and can win $1000
>      (http://www.linuxonpower.com/rules.php).

interesting. However, how do you interpret the first paragraph on that
page, i.e. "The following contest is intended for viewing in the United
States only..." ?


Regards,
		Stefan

Re: [Opencxx-users] OpenC++ gets funding

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

>>From: Grzegorz Jakacki [mailto:ja...@ac...]
> 
>>If you have any suggestions on how this money can be used to advance 
>>OpenC++, please post them on this forum.
> 
> was the award being granted because OpenC++ already was ported to the PPC ?
> Or as an incentive to port it ? If the latter, shouldn't the money be spent
> to help do the port ?

It was meant as an incentive for project admins so that they sign up for 
judging the ports. You have a project on SF, so you also must have 
gotten an invitation to this contest, haven't you?

BR
Grzegorz

PS: Succesful ports are awarded from another pool and can win $1000
     (http://www.linuxonpower.com/rules.php).