pygccxml-development

Re: [pygccxml-development] Adding wrappers...

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
>> That's already the first problem. Currently, a class either has an
>> entire class wrapper or no wrapper at all. But often it would already be
>> enough to just provide wrappers for individual methods. It wouldn't be
>> necessary to create a new C++ wrapper class for that purpose.
> 
> If I understand you right: function can have wrapper, but it is not
> necessary that the wrapper belongs to the class. 

Exactly. This can be used to add new (Python) methods to a class that 
the corresponding C++ does not have or it can be used to replace 
methods. Currently, I'm using the "backdoor" cdef() decorator for this.

>>> decl_wrappers.class_t we have add_code/add_wrapper_code functionality.
>>> I propose to add similar functionality to decl_wrappers.calldef_t class:  two
>>> properties: replace_code and replace_wrapper_code. module_creator.creator_t
>>> class will check those properties and will create right code creators,
>>> that instead of
>>> generating default code will put user code as is.
>> But if we simply replace code then the new code must implement the
>> functionality of the previous code. But as a user I don't know what code
>> pyplusplus has already added to a wrapper so I can't provide its
>> functionality. And by simply replacing it we ignore the previous code
>> and the result might not work as expected anymore.
>> I think adding user wrapper code must not interfere with previously
>> added code by pyplusplus.
> 
> I have very different opinion. My rule is simple:user knows better that py++.

Oh, I see. But I disagree on this one. I'm using software tools so that 
I don't have to remember every detail myself. And it would be nice if 
the tool could also be used by non-experts.

>> I can add include_t creators to classes? ok, I'll keep that in mind and
>> will try it out eventually...
> 
> It is not implemented yet, I see it as one possible solution.

Ah, ok. But when the code has to be changed anyway I'm in favor of 
adding some sort of "File" objects that each has its own code creator 
tree (as was already brought up somewhen earlier)...
(or a similar, more flexible approach)

- Matthias -

Re: [pygccxml-development] Adding wrappers...

[Roman Y. <rom...@gm...>]

On 4/11/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Good. I knew that you plan next revolution in py++.
>
> Evolution! It's evolution, not Revolution... ;-)

:-)

> > every class has associated class wrapper with it. file writers
> > guarantee that class
> > will see definition of it's class wrapper, otherwise it will not compil=
e. On
>
> That's already the first problem. Currently, a class either has an
> entire class wrapper or no wrapper at all. But often it would already be
> enough to just provide wrappers for individual methods. It wouldn't be
> necessary to create a new C++ wrapper class for that purpose.

If I understand you right: function can have wrapper, but it is not
necessary that
the wrapper belongs to the class. May be good idea. I need to check whether=
 it
could be implemented with simple interface.

> > decl_wrappers.class_t we have add_code/add_wrapper_code functionality.
> > I propose to add similar functionality to decl_wrappers.calldef_t class=
:  two
> > properties: replace_code and replace_wrapper_code. module_creator.creat=
or_t
> > class will check those properties and will create right code creators,
> > that instead of
> > generating default code will put user code as is.
>
> But if we simply replace code then the new code must implement the
> functionality of the previous code. But as a user I don't know what code
> pyplusplus has already added to a wrapper so I can't provide its
> functionality. And by simply replacing it we ignore the previous code
> and the result might not work as expected anymore.
> I think adding user wrapper code must not interfere with previously
> added code by pyplusplus.

I have very different opinion. My rule is simple:user knows better that py+=
+.

> I'm currently experimenting with a model that is similar to the existing
> code creators, sort of special "micro code creators" that together
> create one wrapper method. I'll post more about that in a separate mail.

Good, I'd like to see it.

> >> but it seems that adding code to a generated file is not possible.
> >
> > You can always to derive from built-in file_writer and implement your o=
wn one.
> > This is was my original idea.
>
> I was already toying with that idea but haven't done so yet...

It should be simple.

> >> Alternatively, I could stick my new code in a separate file (.h/.cpp).
> >> Then the only problem is to include the header in the pyplusplus file.
> >> As far as I can tell this also cannot be done on a file-by-file basis,
> >> but I could add the header files to *all* generated files at once (not
> >> really a nice solution but at least it could work).
> >
> > No, the better solution is to add to code_creators.class_t list of
> > code_creators.include_t. Thus file writer will understand that user pro=
vided an
> > additional header files and will put them in a right place.
>
> I can add include_t creators to classes? ok, I'll keep that in mind and
> will try it out eventually...

It is not implemented yet, I see it as one possible solution.

> - Matthias -

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Adding wrappers...

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> Good. I knew that you plan next revolution in py++. 

Evolution! It's evolution, not Revolution... ;-)

> every class has associated class wrapper with it. file writers
> guarantee that class
> will see definition of it's class wrapper, otherwise it will not compile. On

That's already the first problem. Currently, a class either has an 
entire class wrapper or no wrapper at all. But often it would already be 
enough to just provide wrappers for individual methods. It wouldn't be 
necessary to create a new C++ wrapper class for that purpose.

> decl_wrappers.class_t we have add_code/add_wrapper_code functionality.
> I propose to add similar functionality to decl_wrappers.calldef_t class:  two
> properties: replace_code and replace_wrapper_code. module_creator.creator_t
> class will check those properties and will create right code creators,
> that instead of
> generating default code will put user code as is.

But if we simply replace code then the new code must implement the 
functionality of the previous code. But as a user I don't know what code 
pyplusplus has already added to a wrapper so I can't provide its 
functionality. And by simply replacing it we ignore the previous code 
and the result might not work as expected anymore.
I think adding user wrapper code must not interfere with previously 
added code by pyplusplus.

I'm currently experimenting with a model that is similar to the existing 
code creators, sort of special "micro code creators" that together 
create one wrapper method. I'll post more about that in a separate mail.

>> but it seems that adding code to a generated file is not possible.
> 
> You can always to derive from built-in file_writer and implement your own one.
> This is was my original idea.

I was already toying with that idea but haven't done so yet...

>> Alternatively, I could stick my new code in a separate file (.h/.cpp).
>> Then the only problem is to include the header in the pyplusplus file.
>> As far as I can tell this also cannot be done on a file-by-file basis,
>> but I could add the header files to *all* generated files at once (not
>> really a nice solution but at least it could work).
> 
> No, the better solution is to add to code_creators.class_t list of
> code_creators.include_t. Thus file writer will understand that user provided an
> additional header files and will put them in a right place.

I can add include_t creators to classes? ok, I'll keep that in mind and 
will try it out eventually...

- Matthias -

Re: [pygccxml-development] Installing from cvs doesn't work

[Roman Y. <rom...@gm...>]

On 4/11/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> ok, I'll give it a try...

Thank you. If you don't have time, we can do it for next release.

> Where do you want to keep the version number? Did you just put it into
> __init__.py so that it is available somewhere during creating the
> distribution or is this also meant as a way for the user to determine
> the version at runtime?

The first one. Until now I did not get requests to expose version as
public variable.
If it will be requested I will do that.

> Maybe the documentation should be packaged separately. It would be ok to
> add them to the sources but I'm not aware that there is a standard
> location to install them.

I did not add documentation to the sources. The structure I propose is next=
:

__next_release__ /
    package_name + version number /
        setup.py
        docs /
        examples /
        unittests /
        package /
            only sources needed to use package + scripts

So if you run setup.py it will install only the package, nothing more.
If you run release_builder.py you will see it.

> - Matthias -

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Installing from cvs doesn't work

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
>>> May be. I don't think/expect user/programmer to run
>>> setup_pyplusplus.py directly.
>>> I think he should run release_manager/release_builder.py and then to
>>> run setup.py
>>> from pyplusplusXXX directory.
>>>
>>> Is this wrong approach?
>> Well, in my opinion it is. ;) The main reason is that it is
>> non-standard. The standard way of dealing with an extension package is
>> by using the distutils. This includes not only building and installing
>> the package but also creating a source or binary distribution (see the
>> "sdist" and "bdist_*" commands (setup.py --help-commands)).
>> Some other reasons are that it takes much longer and is inconvenient
>> when I just want to update the sources and apply those updates.
> 
> Are you able to build something similar to release manager with distutils?
> If so, can you spend some time and implement this. I will be glad to drop
> the usage of release manager.

ok, I'll give it a try...

Where do you want to keep the version number? Did you just put it into 
__init__.py so that it is available somewhere during creating the 
distribution or is this also meant as a way for the user to determine 
the version at runtime?

Maybe the documentation should be packaged separately. It would be ok to 
add them to the sources but I'm not aware that there is a standard 
location to install them.

- Matthias -

Re: [pygccxml-development] Adding wrappers...

[Roman Y. <rom...@gm...>]

On 4/9/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> this mail is sort of a continuation of the thread "How to manage wrapper
> classes?"...

Good. I knew that you plan next revolution in py++. Now code_creators
are target.
Okay, lets do it :-)

> Meanwhile I have some code that can generate wrapper source code for
> individual member functions. The question now is how do I insert those
> into pyplusplus?
> What I would actually like to do is adding those generated functions to
> the appropriate *.cpp file that is generated by pyplusplus and then
> replace the original member function with this wrapper function.

It is possible to solve your problem using existing tools + adding
some new ones.
The general solution is next:

every class has associated class wrapper with it. file writers
guarantee that class
will see definition of it's class wrapper, otherwise it will not compile. O=
n
decl_wrappers.class_t we have add_code/add_wrapper_code functionality.
I propose to add similar functionality to decl_wrappers.calldef_t class:  t=
wo
properties: replace_code and replace_wrapper_code. module_creator.creator_t
class will check those properties and will create right code creators,
that instead of
generating default code will put user code as is.

I think, this is simple solution that is very easy to understand and implem=
ent.
( I estimate 2-3 days =3D=3D ( 6 - 8 hours including some testing )
User can use powerful query interface and don't need to be familiar with co=
de
creators.

What do you think?

> I had a
> look at the multi file writer (while doing so I also added some doc
> strings)
Many thanks!

> but it seems that adding code to a generated file is not possible.

You can always to derive from built-in file_writer and implement your own o=
ne.
This is was my original idea.

> Alternatively, I could stick my new code in a separate file (.h/.cpp).
> Then the only problem is to include the header in the pyplusplus file.
> As far as I can tell this also cannot be done on a file-by-file basis,
> but I could add the header files to *all* generated files at once (not
> really a nice solution but at least it could work).

No, the better solution is to add to code_creators.class_t list of
code_creators.include_t. Thus file writer will understand that user provide=
d an
additional header files and will put them in a right place.

> Are there any suggestions on how this could be improved? I think
> pyplusplus is in need of more flexibility in this area.

I agree :-). You can prepare "to do" list for next release.

> This all gets even more problematic if pyplusplus has already decided to
> generate wrappers and I want to add wrapper code as well. How can these
> two be combined? It might be that I have such examples as well in the
> Maya SDK, but I'm not really that far yet...

I prefer to solve main problematic scenario. After this we will see.

If we will release py++ this week, it is possible to implement all
your request next
week. We have some holidays ( passover ).

> - Matthias -

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Installing from cvs doesn't work

[Roman Y. <rom...@gm...>]

On 4/9/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > May be. I don't think/expect user/programmer to run
> > setup_pyplusplus.py directly.
> > I think he should run release_manager/release_builder.py and then to
> > run setup.py
> > from pyplusplusXXX directory.
> >
> > Is this wrong approach?
>
> Well, in my opinion it is. ;) The main reason is that it is
> non-standard. The standard way of dealing with an extension package is
> by using the distutils. This includes not only building and installing
> the package but also creating a source or binary distribution (see the
> "sdist" and "bdist_*" commands (setup.py --help-commands)).
> Some other reasons are that it takes much longer and is inconvenient
> when I just want to update the sources and apply those updates.

Are you able to build something similar to release manager with distutils?
If so, can you spend some time and implement this. I will be glad to drop
the usage of release manager.
If not, I think I will release this version using release manager.

> - Matthias -

Thanks

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] Adding wrappers...

[Matthias B. <ba...@ir...>]

Hi,

this mail is sort of a continuation of the thread "How to manage wrapper 
classes?"...
Meanwhile I have some code that can generate wrapper source code for 
individual member functions. The question now is how do I insert those 
into pyplusplus?
What I would actually like to do is adding those generated functions to 
the appropriate *.cpp file that is generated by pyplusplus and then 
replace the original member function with this wrapper function. I had a 
look at the multi file writer (while doing so I also added some doc 
strings) but it seems that adding code to a generated file is not possible.
Alternatively, I could stick my new code in a separate file (.h/.cpp). 
Then the only problem is to include the header in the pyplusplus file. 
As far as I can tell this also cannot be done on a file-by-file basis, 
but I could add the header files to *all* generated files at once (not 
really a nice solution but at least it could work).
Are there any suggestions on how this could be improved? I think 
pyplusplus is in need of more flexibility in this area.

This all gets even more problematic if pyplusplus has already decided to 
generate wrappers and I want to add wrapper code as well. How can these 
two be combined? It might be that I have such examples as well in the 
Maya SDK, but I'm not really that far yet...

- Matthias -

Re: [pygccxml-development] Installing from cvs doesn't work

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> May be. I don't think/expect user/programmer to run
> setup_pyplusplus.py directly.
> I think he should run release_manager/release_builder.py and then to
> run setup.py
> from pyplusplusXXX directory.
> 
> Is this wrong approach?

Well, in my opinion it is. ;) The main reason is that it is 
non-standard. The standard way of dealing with an extension package is 
by using the distutils. This includes not only building and installing 
the package but also creating a source or binary distribution (see the 
"sdist" and "bdist_*" commands (setup.py --help-commands)).
Some other reasons are that it takes much longer and is inconvenient 
when I just want to update the sources and apply those updates.

- Matthias -

Re: [pygccxml-development] Installing from cvs doesn't work

[Roman Y. <rom...@gm...>]

On 4/9/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> the latest version of pyplusplus cannot be built/installed when the
> sources are obtained from cvs.
> Running the setup script for pyplusplus results in the following error:
>
> error: pyplusplus\scripts\CVS: Permission denied
>
> The problem is that in the setup script the entire contents of the
> scripts directory is passed to the "scripts" argument:
>
>         , scripts=3D map( lambda script_name: os.path.join( 'pyplusplus',
> 'scripts', script_name )
>                         , os.listdir( os.path.join( 'pyplusplus',
> 'scripts' ) ) )
>
> This includes the directory "CVS" which leads to the above error.
> (My quick workaround was to remove the above two lines from the setup
> script. A proper fix would be to specify the files explicitly)

May be. I don't think/expect user/programmer to run
setup_pyplusplus.py directly.
I think he should run release_manager/release_builder.py and then to
run setup.py
from pyplusplusXXX directory.

Is this wrong approach?

> - Matthias -


--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] Installing from cvs doesn't work

[Matthias B. <ba...@ir...>]

Hi,

the latest version of pyplusplus cannot be built/installed when the 
sources are obtained from cvs.
Running the setup script for pyplusplus results in the following error:

error: pyplusplus\scripts\CVS: Permission denied

The problem is that in the setup script the entire contents of the 
scripts directory is passed to the "scripts" argument:

        , scripts= map( lambda script_name: os.path.join( 'pyplusplus', 
'scripts', script_name )
                        , os.listdir( os.path.join( 'pyplusplus', 
'scripts' ) ) )

This includes the directory "CVS" which leads to the above error.
(My quick workaround was to remove the above two lines from the setup 
script. A proper fix would be to specify the files explicitly)

- Matthias -

[pygccxml-development] Next release is almost ready

[Roman Y. <rom...@gm...>]

Hi. Today I uploaded 2 files to SourceForge: pygccxml0.7.1 and pyplusplus0.=
7.0.
You can find it here:
http://sourceforge.net/project/showfiles.php?group_id=3D118209

------------------------------------------
This is not an official release!
------------------------------------------

I ask you to try to install it and check.

Things that prevents me from releasing:
1. I need to write tutorial for high level API
2. More documentation strings on module_builder_t,
decl_wrappers.namespace_t and
    decl_wrappers.scopedef_t classes
3. I would like to get some fixes/review for documentation.
   ( You know my English could be much better)
4. Release notes - I should still write them.
5. Bug fixes in setup's
6. ...

Comments, suggestions and fixes are welcome.

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] Re: MJ: not sure about CVS - see just old versions

[Roman Y. <rom...@gm...>]

On 4/7/06, Janes, Matthias <mat...@si...> wrote:
>
>
>
>  hi roman,
>
> I noticed today that in the  CVS tree (Browse CVS  Repository) I see just=
 old > versions.

It could take few days before CVS is updated and every developer can see sa=
me
source code. Same is applied on CVS from web

Any way thanks




--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] How to use the readme() method?

[Roman Y. <rom...@gm...>]

On 4/7/06, Matthias Baas <ba...@ir...> wrote:
> ok, but I think those messages should never be silently ignored (unless
> the user wants it that way). Currently, the user has to be the "active
> part" and has to inspect the messages (by writing quite a bit of code),
> otherwise they get ignored. I'd like to see pyplusplus to take over the
> active part on this issue (as it would otherwise produce code that
> doesn't work). This can also be done in the "high level layer", that's
> why I wanted to check what the recommended way to obtain those messages
> efficiently is.

I understand what are you talking about. I think that module_creator.creato=
r_t
class should print into the logger those read messages. What do you think?
pyplusplus can do nothing before that point.

> - Matthias -

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] How to use the readme() method?

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
>> How can a user find out/iterate over all declarations that "have
>> something to say"? (other than iterating over all declarations and check
>> if readme() returns something else than an empty list)
> 
> This is the only way. And here is the reason: I don't expect users
> will actually investigate
> what is written there at run time and make some decision. I think they
> will print the content
> of readme and after this, they will go and add some treatment to
> problematic declarations.

ok, but I think those messages should never be silently ignored (unless 
the user wants it that way). Currently, the user has to be the "active 
part" and has to inspect the messages (by writing quite a bit of code), 
otherwise they get ignored. I'd like to see pyplusplus to take over the 
active part on this issue (as it would otherwise produce code that 
doesn't work). This can also be done in the "high level layer", that's 
why I wanted to check what the recommended way to obtain those messages 
efficiently is.

- Matthias -

Re: [pygccxml-development] How to use the readme() method?

[Roman Y. <rom...@gm...>]

On 4/6/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > For imlementation and usage, please take a look on calldef_wrapper.py a=
nd
> > decl_wrapper_printer.py modules.
>
> How can a user find out/iterate over all declarations that "have
> something to say"? (other than iterating over all declarations and check
> if readme() returns something else than an empty list)

This is the only way. And here is the reason: I don't expect users
will actually investigate
what is written there at run time and make some decision. I think they
will print the content
of readme and after this, they will go and add some treatment to
problematic declarations.

Obviously you have an other opinion, please share it :-)

> - Matthias -



--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] How to use the readme() method?

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> For imlementation and usage, please take a look on calldef_wrapper.py and
> decl_wrapper_printer.py modules.

How can a user find out/iterate over all declarations that "have 
something to say"? (other than iterating over all declarations and check 
if readme() returns something else than an empty list)

- Matthias -

Re: [pygccxml-development] How to use the readme() method?

[Roman Y. <rom...@gm...>]

On 4/6/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I've read in the cvs log about the new readme() method. Roman, can you
> please give some instructions on how this method is to be used?

Function readme should return list of strings. This list will contain
some hints/tips/warnings
to the user, that py++ has to say about the declaration.

> I
> noticed it returns a list, but what will the items be? The first
> argument to the method is called "calldef" instead of "self", so is this
> really supposed to be a "true" argument or is it self and you just gave
> it a different name?

Of course it should be self. In that moment I thought about adding
functionality to calldef
decl wrapper.

For imlementation and usage, please take a look on calldef_wrapper.py and
decl_wrapper_printer.py modules.

> - Matthias -

Thank you

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] How to use the readme() method?

[Matthias B. <ba...@ir...>]

Hi,

I've read in the cvs log about the new readme() method. Roman, can you 
please give some instructions on how this method is to be used? I 
noticed it returns a list, but what will the items be? The first 
argument to the method is called "calldef" instead of "self", so is this 
really supposed to be a "true" argument or is it self and you just gave 
it a different name? If it is a true argument, what is it supposed to be?

- Matthias -

Re: [pygccxml-development] epydoc stylesheet

[Roman Y. <rom...@gm...>]

On 4/6/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I checked out the new stuff and started by checking the documentation
> for pygccxml. I noticed that the stylesheet has changed and, well, in my
> opinion it's more difficult to read than before.
> For example, the "Method Details" doesn't contain any syntax
> highlighting and the individual methods aren't visually separated
> anymore (it's just one big gray box). Table backgrounds are now white
> just as the page background which makes the separation of the content
> from the background less noticeable.
>
> I suppose there has been a good reason for changing it, but would it be
> possible to provide a way for the user to configure the look of the manua=
l?

It is my fault. I played a little with css file. I did not like the
result too. I forgot
to remove my changes. Any way I fixed it. Thanks for reporting

> - Matthias -
>
>

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] epydoc stylesheet

[Matthias B. <ba...@ir...>]

Hi,

I checked out the new stuff and started by checking the documentation 
for pygccxml. I noticed that the stylesheet has changed and, well, in my 
opinion it's more difficult to read than before.
For example, the "Method Details" doesn't contain any syntax 
highlighting and the individual methods aren't visually separated 
anymore (it's just one big gray box). Table backgrounds are now white 
just as the page background which makes the separation of the content 
from the background less noticeable.

I suppose there has been a good reason for changing it, but would it be 
possible to provide a way for the user to configure the look of the manual?

- Matthias -

[pygccxml-development] pygccxml pyplusplus next release

[Roman Y. <rom...@gm...>]

Hi. This morning I committed almost final version of projects. I
think, that the only thing that
I will change, is documentation and files related to "build release" proces=
s.

I ask you to checkout and try this changes. Also, as you know,=20
English is not my native
language, so if I ask you to review and fix documentation or
documentation string.

Any way it worse to work with latest CVS version, cause it contains
few bug fixes and
improved logging functionality.

Enjoy

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] MJ: Update Gcc 4.1.0

[Roman Y. <rom...@gm...>]

On 4/4/06, Janes, Matthias <mat...@si...> wrote:
> I will definetly do the unittest from pygccxml.
>
> But one question: when do you plan to freez the CVS api - there are just =
to many changes at the moment.

Code is frozen.

The most of changes are cleanup. I prepare code for release. I suppose
api is not going to
change for this release.

SourceForge CVS servers does not work right now, so I can not commit
final version.

> Before I start with my actual python wrapping I decided to put some effor=
t in creating a more suitable ProjectFrontend for my problems (Java to pyth=
on wrapper via pyplusplus).
>
> If I manage something useful I will let you know.
>
> If I will not succeed at least partially in a few weeks time - I will hav=
e to look into an other option like swig or sip do to it.

:-). If you have some problem, I would like to hear about them.

Good luck!

> MJ
>
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] MJ: Update Gcc 4.1.0

[Roman Y. <rom...@gm...>]

On 4/4/06, Janes, Matthias <mat...@si...> wrote:
>
> hi roman,
>
> just a short info.
>
> as I told you I need for different reason the Gcc 4.1.0.
>
> as I upgraded there where a number of problems with GCC-XML.
>
> Since a few days the actual CVS version (Gcc-XML) has support for Gcc 4.1=
.0
> included.
>
> worked at least for the few small examples I tried.

Good news. Can you run unittest from pygccxml? If they pass you have fully
working environment.

> greetings

I hope you will start to enjoy from pyplusplus very soon

> MJ


--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] MJ: Update Gcc 4.1.0

[Janes, M. <mat...@si...>]

hi roman,
=20
just a short info.
=20
as I told you I need for different reason the Gcc 4.1.0.
=20
as I upgraded there where a number of problems with GCC-XML.
=20
Since a few days the actual CVS version (Gcc-XML) has support for Gcc
4.1.0 included.
=20
worked at least for the few small examples I tried.
=20
greetings
=20
MJ
=20



=20