pygccxml-development

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [434] pyplusplus_dev/contrib/__init__.py

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

Allen Bierbaum wrote:
>> I don't know if this is such a good idea. It won't work with pypp_api 
>> and arrayinfo anyway. The latter is no package and the former has its 
>> package in pypp_api/pypp_api and not directly in pypp_api because I 
>> wanted to be able to add additional files such as the doc generation 
>> script, readme, etc. which do not belong right inside the package 
>> directory.
> 
> Wouldn't you now be able to do import contrib.pypp_api.pypp_api or 
> something like that?

No, because there is no file contrib/pypp_api/__init__.py
(besides that you would still have to update PYTHONPATH to point to 
contrib, so there's not much gained)

> Any other ideas on how to make this easier?

The "correct" way would be to provide a setup script so that users can 
install the package just like every other Python package.
If there's someone out there who would like me to add such a script I 
will happily do so, but as long as I'm the only user I think I can do 
without that script. :)

- Matthias -

Re: [pygccxml-development] crash on hello world in PyppTutorial

[Neal B. <ndb...@gm...>]

On Wednesday 23 August 2006 9:54 am, Matthias Baas wrote:
> Neal Becker wrote:
> > I just tried the hello world example from
> > https://realityforge.vrsource.org/view/PyppApi/PyppTutorial and got a
> > crash: [...]
> > running GCC-XML: world.h:5: error: `string' undeclared in namespace `std'
>
> The include file was missing in the example.
> You have to add the following line at the top of world.h:
>
> #include <string>
>
>
> - Matthias -

Yes, thanks.  I knew that.  I wanted to report the crash, though.

Re: [pygccxml-development] crash on hello world in PyppTutorial

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

Neal Becker wrote:
> I just tried the hello world example from  
> https://realityforge.vrsource.org/view/PyppApi/PyppTutorial and got a crash:
> [...]
> running GCC-XML: world.h:5: error: `string' undeclared in namespace `std'

The include file was missing in the example.
You have to add the following line at the top of world.h:

#include <string>


- Matthias -

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [434] pyplusplus_dev/contrib/__init__.py

[Allen B. <al...@vr...>]

Matthias Baas wrote:

> al...@us... wrote:
>
>> Revision: 434
>> Author:   allenb
>> Date:     2006-08-22 14:56:24 -0700 (Tue, 22 Aug 2006)
>> ViewCVS:  http://svn.sourceforge.net/pygccxml/?rev=434&view=rev
>>
>> Log Message:
>> -----------
>> Make contrib look a little like a package to python.
>>
>> This will allow a user to just add the contrib directory to their 
>> python path and then "import contrib.package_name".  This is much 
>> easier to deal with then having to add a bunch of paths.
>
>
> I don't know if this is such a good idea. It won't work with pypp_api 
> and arrayinfo anyway. The latter is no package and the former has its 
> package in pypp_api/pypp_api and not directly in pypp_api because I 
> wanted to be able to add additional files such as the doc generation 
> script, readme, etc. which do not belong right inside the package 
> directory.

Wouldn't you now be able to do import contrib.pypp_api.pypp_api or 
something like that?

>
> I think it's misleading if people think the entire contrib directory 
> is one single package.

I definitely don't want to mislead people.  I just want to make it easy 
to use the contribs. 

Any other ideas on how to make this easier?

-Allen

>
> - Matthias -
>

Re: [pygccxml-development] [release] setup.py need to be updated

[Allen B. <al...@vr...>]

Roman Yakovenko wrote:

>Hi. Matthias and Allen, I hope I will be ready to release Py++ next week.
>I would like to distribute contrib package too. There is small amount
>of work that should
>be done:
>
>1. To update setup.py script: to add your packages and generate documentation.
>2. License. Not all files/directories contains license.
>
>Can you fix those issues?
>
>Thanks.
>
>  
>
I don't think I have anything in there right now.  (goodies is 
definitely *not* ready for release but it does have licenses in the files)

-Allen

[pygccxml-development] crash on hello world in PyppTutorial

[Neal B. <ndb...@gm...>]

I just tried the hello world example from  
https://realityforge.vrsource.org/view/PyppApi/PyppTutorial and got a crash:
(just updated gccxml from cvs)

INFO gccxml 
cmd: /usr/bin/gccxml  -I"/home/nbecker/tmp"   "world.h" -fxml="/tmp/tmpQfJLT9.xml"
Traceback (most recent call last):
  File "pypp_setup.py", line 10, in ?
    root = mod.parse()
  
File "/usr/local/src/pygccxml/pyplusplus_dev/contrib/pypp_api/pypp_api/modulebuilder.py", 
line 230, in parse
    parser.project_reader.COMPILATION_MODE.FILE_BY_FILE)
  File "/usr/lib/python2.4/site-packages/pygccxml/parser/project_reader.py", 
line 225, in read_files
    return self.__parse_file_by_file(files)
  File "/usr/lib/python2.4/site-packages/pygccxml/parser/project_reader.py", 
line 250, in __parse_file_by_file
    decls = reader.read_file( header )
  File "/usr/lib/python2.4/site-packages/pygccxml/parser/source_reader.py", 
line 245, in read_file
    raise error
pygccxml.parser.source_reader.gccxml_runtime_error_t: Error occured while 
running GCC-XML: world.h:5: error: `string' undeclared in namespace `std'
world.h:5: error: syntax error before `)' token
world.h:6: error: syntax error before `(' token
world.h:7: error: semicolon missing after declaration of `World'
world.h: In member function `void World::set(...)':
world.h:5: error: 'struct World' has no member named 'msg'
world.h:5: error: `msg' undeclared (first use this function)
world.h:5: error: (Each undeclared identifier is reported only once for each 
   function it appears in.)
world.h: At global scope:
world.h:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

Re: [pygccxml-development] [release] setup.py need to be updated

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

Oops, I hit the send button too early...

> "Activities other than copying, distribution and modification are not 
> covered by this License; they are outside its scope."

Maybe I should also have quoted the subsequent sentence:

"The act of running the Program is not restricted, [...]"

Now I wonder if it would have been restricted if that sentence was 
missing...?

- Matthias -

Re: [pygccxml-development] [release] setup.py need to be updated

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

Roman Yakovenko wrote:
> I see, what about documentation? Don't you want to integrate to
> setup.py script to build pypp_api documentation?

Actually, I'm against this as I think Py++ shouldn't be dependent on 
code in "contrib". After all, these are "only" user contributions that 
are not officially supported. And if something proves to be useful for 
every Py++ user it should be moved out of contrib and made part of the 
official Py++ package.
But as long as something has the "contrib" status it's the contributor 
who's responsible for the code and who has to provide enough information 
so that others can use the package (having said that I've just added a 
readme to pypp_api ;) And the main documentation for pypp_api is now in 
the wiki anyway...

>> > 2. License. Not all files/directories contains license.
>>
>> I added a short license information to pypp_api (but I don't think we
>> have to be too picky here. I'm sure that every contributor who adds
>> something to contrib doesn't have any objections when you redistribute
>> that code with the Py++ sources. I couldn't imagine that someone is just
>> adding code so that he can sue you as soon as you release that code... ;)
> 
> I thought about different situation: there are people and\or
> organization, that just can
> not use the code, if license is not clear or it is not XYZ. This is
> the only reason.

It depends on what exactly you mean with "use the code". Note that a lot 
of Open Source licenses only deal with the distribution and modification 
of software and not its mere usage. The following sentence is taken from 
the GPL:

"Activities other than copying, distribution and modification are not 
covered by this License; they are outside its scope."

So if a company only wants to make use of a GPL licensed software (e.g. 
a 3D modeler to create models for a commercial game) and do not have to 
distribute this software with their own commercial product, then it is 
my understanding that they may certainly do so without infringing anything.

In our case it means that it doesn't matter whether some code in contrib 
has a license like the GPL or not if a particular user only wants to 
"use" that code and only wants to distribute the output of Py++ and not 
Py++ itself.

(but of course, I'm no lawyer so don't count on the above if you're in 
court... ;)

- Matthias -

Re: [pygccxml-development] [release] setup.py need to be updated

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

On 8/23/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Hi. Matthias and Allen, I hope I will be ready to release Py++ next week.
> > I would like to distribute contrib package too. There is small amount
> > of work that should
> > be done:
> >
> > 1. To update setup.py script: to add your packages and generate documentation.
>
> I did that already when I was adding the contrib directory to the
> repository (actually it's not the setup.py script that I had to modify
> but the MANIFEST.in file).
> So when you create a source distribution the contrib directory should
> already be part of it.

I see, what about documentation? Don't you want to integrate to
setup.py script to build
pypp_api documentation?

> > 2. License. Not all files/directories contains license.
>
> I added a short license information to pypp_api (but I don't think we
> have to be too picky here. I'm sure that every contributor who adds
> something to contrib doesn't have any objections when you redistribute
> that code with the Py++ sources. I couldn't imagine that someone is just
> adding code so that he can sue you as soon as you release that code... ;)

I thought about different situation: there are people and\or
organization, that just can
not use the code, if license is not clear or it is not XYZ. This is
the only reason.

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

Re: [pygccxml-development] [release] setup.py need to be updated

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

Roman Yakovenko wrote:
> Hi. Matthias and Allen, I hope I will be ready to release Py++ next week.
> I would like to distribute contrib package too. There is small amount
> of work that should
> be done:
> 
> 1. To update setup.py script: to add your packages and generate documentation.

I did that already when I was adding the contrib directory to the 
repository (actually it's not the setup.py script that I had to modify 
but the MANIFEST.in file).
So when you create a source distribution the contrib directory should 
already be part of it.

> 2. License. Not all files/directories contains license.

I added a short license information to pypp_api (but I don't think we 
have to be too picky here. I'm sure that every contributor who adds 
something to contrib doesn't have any objections when you redistribute 
that code with the Py++ sources. I couldn't imagine that someone is just 
adding code so that he can sue you as soon as you release that code... ;)

- Matthias -

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [434] pyplusplus_dev/contrib/__init__.py

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

al...@us... wrote:
> Revision: 434
> Author:   allenb
> Date:     2006-08-22 14:56:24 -0700 (Tue, 22 Aug 2006)
> ViewCVS:  http://svn.sourceforge.net/pygccxml/?rev=434&view=rev
> 
> Log Message:
> -----------
> Make contrib look a little like a package to python.
> 
> This will allow a user to just add the contrib directory to their python path and then "import contrib.package_name".  This is much easier to 
> deal with then having to add a bunch of paths.

I don't know if this is such a good idea. It won't work with pypp_api 
and arrayinfo anyway. The latter is no package and the former has its 
package in pypp_api/pypp_api and not directly in pypp_api because I 
wanted to be able to add additional files such as the doc generation 
script, readme, etc. which do not belong right inside the package directory.

I think it's misleading if people think the entire contrib directory is 
one single package.

- Matthias -

[pygccxml-development] bug fix in code generator engine code

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

Hi. I just committed a fix for few bugs in "class_organizer_t" class.
This class is responsible
for order of generated classes. I tested it on all my projects and it
works fine.

Can you test these fix and report whether the generated code works or not?

Thank you very much!

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

[pygccxml-development] [release] setup.py need to be updated

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

Hi. Matthias and Allen, I hope I will be ready to release Py++ next week.
I would like to distribute contrib package too. There is small amount
of work that should
be done:

1. To update setup.py script: to add your packages and generate documentation.
2. License. Not all files/directories contains license.

Can you fix those issues?

Thanks.

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

Re: [pygccxml-development] DSL challenge

[Allen B. <al...@vr...>]

Roman Yakovenko wrote:

> On 8/22/06, Allen Bierbaum <al...@vr...> wrote:
>
>> No problem.  I will take on the DSL design and discussion.  Can I assume
>> that means that you aren't going to introduce a new DSL and surprise us
>> all?  :)
>
>
> Don't you like surprises :-)? No. I am pretty happy with current API.
> I am not in
> a harry to "fix" the situation. I just hope that we will be able to
> solve this issue
> and implement it before next release.

Okay.

>
>> > The only API I introduced was Py++ one. I did not say anything about
>> > how DSL
>> > API looks like.
>>
>> The BUI that you proposed was what I was thinking about.
>
>
> It is not an API, but usage example

I guess so.  It just seemed that the "usage example" ended up defining a 
proposed API as part of the usage. :)

>
>> > Lets talk use cases. I introduced the problematic ones. I expect 
>> from you
>> > to prove me being wrong or to provide good solution.
>>
>> Yes, I have some ideas here.  I will try them out on my current project
>> with the method I suggested of extending and overriding the py++ api.
>
>
> :-( wrong answer. Please don't write single line of code before we 
> solve the
> problematic use cases "on paper". I would like to see definitions, before
> any implementation.

Well I think we are too late now.  I have already started implementing 
because I have to get something working ASAP.  I need to get my project 
done that I am working on with pyplusplus.  As much as I may like the 
idea of pyplusplus and contributing to it, right now I need to get work 
done to pay the bills.

Nothing in the API will be fixed or anything but it will let me give a 
concrete example of how some of the issues could be fixed.

That said, at the same time I am interested in talking through the 
issues using the wiki.


>> > This paper I still have to write :-). But in general you are right, I
>> > don't like two
>> > phased approach, but it is possible to implement it.
>>
>> By "paper" can I assume you mean comment on the wiki page about
>> templates?  That would be much more helpful IMHO then a .rest document
>> or mailing list posting.
>
>
> No, I mean  rest document. I will write an initial paper and then we 
> will take
> the discussion to the wiki.

Why write it as a .rest document at all?  That really just makes it 
harder for us to get access to it and comment on the contents.

-Allen

Re: [pygccxml-development] Future of pypp_api...

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

On 8/22/06, Matthias Baas <ba...@ir...> wrote:
>
> Just to clarify, compared to the Py++ high-level API pypp_api is not a
> *new* API. pypp_api was created by Allen and me because we were not
> satisfied with the way py++ had to be used at that time (there hasn't
> been any high-level API at all). Obviously the general concepts from our
> experimental prototype did convince Roman and so he implemented his own
> version of a high-level API which is based on the ideas from pypp_api
> but which does some things differently. To me it was just another
> "prototype" to try out alternative ways. But as it is integrated into
> the pyplusplus code base it has become the official API.
> Anyway, this explains why there are a lot of similarities between the
> two APIs.

Matthias is right. The pypp_api is not new. The main problem is that it takes
time to learn to work in "open source" team.

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

Re: [pygccxml-development] DSL challenge

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

On 8/22/06, Matthias Baas <ba...@ir...> wrote:
> > The second comment I would have is it seems strange to me that you
> > dismiss the idea of a DSL by introducing a proposed API with
> > deficiencies that you don't like and they saying "see it is bad".
>
> That was also my impression.... ;)

Not every day I can quote myself :-):
"...I don't argue, that the second way is better. ..."

It will take few hours to implement this feature. I see my role in
this feature as a
"bad guy" :-), sorry. I will bring difficult use cases and you will
have to solve them.
Thus we will better understand the problem and implement best solution.

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

Re: [pygccxml-development] DSL challenge

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

On 8/22/06, Allen Bierbaum <al...@vr...> wrote:
> No problem.  I will take on the DSL design and discussion.  Can I assume
> that means that you aren't going to introduce a new DSL and surprise us
> all?  :)

Don't you like surprises :-)? No. I am pretty happy with current API.
I am not in
a harry to "fix" the situation. I just hope that we will be able to
solve this issue
and implement it before next release.

> > The only API I introduced was Py++ one. I did not say anything about
> > how DSL
> > API looks like.
>
> The BUI that you proposed was what I was thinking about.

It is not an API, but usage example

> > Lets talk use cases. I introduced the problematic ones. I expect from you
> > to prove me being wrong or to provide good solution.
>
> Yes, I have some ideas here.  I will try them out on my current project
> with the method I suggested of extending and overriding the py++ api.

:-( wrong answer. Please don't write single line of code before we solve the
problematic use cases "on paper". I would like to see definitions, before
any implementation.

> > This paper I still have to write :-). But in general you are right, I
> > don't like two
> > phased approach, but it is possible to implement it.
>
> By "paper" can I assume you mean comment on the wiki page about
> templates?  That would be much more helpful IMHO then a .rest document
> or mailing list posting.

No, I mean  rest document. I will write an initial paper and then we will take
the discussion to the wiki.

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

Re: [pygccxml-development] DSL challenge

[Allen B. <al...@vr...>]

Allen Bierbaum wrote:

>Roman Yakovenko wrote:
>
>  
>
>>On 8/22/06, Allen Bierbaum <al...@vr...> wrote:
>>
>>    
>>
>>>My first comment would be to put this on the wiki so we can all comment
>>>on it and discuss it.
>>>      
>>>
>>Please become a leader of this effort :-).
>>    
>>
>
>No problem.  I will take on the DSL design and discussion.  Can I assume 
>that means that you aren't going to introduce a new DSL and surprise us 
>all?  :)
>  
>
The current discussion page is here: 
https://realityforge.vrsource.org/view/PyppApi/DslDiscussion

-Allen

Re: [pygccxml-development] Future of pypp_api...

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

Lakin Wecker wrote:
> I've had a look at the pypp wiki a few times now, although I have not 
> read through it in great detail.   From looking at the wiki, I still 
> don't understand what it is that pypp does. 
> 
> If you want to convince me that pypp is an easier better api to use, 
> then you're going to have to create some concrete examples of how this 
> new API saves me time.

Just to clarify, compared to the Py++ high-level API pypp_api is not a 
*new* API. pypp_api was created by Allen and me because we were not 
satisfied with the way py++ had to be used at that time (there hasn't 
been any high-level API at all). Obviously the general concepts from our 
experimental prototype did convince Roman and so he implemented his own 
version of a high-level API which is based on the ideas from pypp_api 
but which does some things differently. To me it was just another 
"prototype" to try out alternative ways. But as it is integrated into 
the pyplusplus code base it has become the official API.
Anyway, this explains why there are a lot of similarities between the 
two APIs.

Meanwhile I'm the only one who is using pypp_api and who's keeping it 
alive. But instead of sticking it into the repository for my own project 
I decided to put it into the pyplusplus contrib directory so that 1) 
others who are interested have the chance to try it out as well and 2) I 
don't have to duplicate code when I want to use the API for another project.

As for documentation/examples, now that we have a wiki I did write a 
short quick start tutorial and I've just started some user guide 
documentation. So if anyone is interested in giving pypp_api a try then 
keep an eye on the following pages:

https://realityforge.vrsource.org/view/PyppApi/PyppTutorial
https://realityforge.vrsource.org/view/PyppApi/PyppUserGuide

and run the script contrib/pypp_api/generate_docs.py to create an epydoc 
reference manual.

If you want a full example you could have a look at pypp_setup.py in 
here: http://svn.sourceforge.net/viewvc/cgkit/maya/trunk/maya_wrapper/
This is how I create Python bindings for the Maya SDK (Maya is a 
commercial 3D application from Autodesk (formerly from Alias)).

But on the other hand, if you're entirely happy with the current Py++ 
API and you already have the bindings you wanted to have, then there's 
absolutely no reason to waste your time with pypp_api.

- Matthias -

Re: [pygccxml-development] DSL challenge

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

Allen Bierbaum wrote:
>> Erm, I still cannot access the wiki....
>>
> Fixed.  Let me know if it happens again.  

It works again, thanks!

> I think you probably got hit 
> by editing a page quite a few times within a short window.  

That can happen. I like to preview the page rather often to see if the 
markup is correct.

- Matthias -

Re: [pygccxml-development] DSL challenge

[Allen B. <al...@vr...>]

Roman Yakovenko wrote:

> On 8/22/06, Allen Bierbaum <al...@vr...> wrote:
>
>> My first comment would be to put this on the wiki so we can all comment
>> on it and discuss it.
>
>
> Please become a leader of this effort :-).

No problem.  I will take on the DSL design and discussion.  Can I assume 
that means that you aren't going to introduce a new DSL and surprise us 
all?  :)

>
>> The second comment I would have is it seems strange to me that you
>> dismiss the idea of a DSL by introducing a proposed API with
>> deficiencies that you don't like and they saying "see it is bad".
>
>
> The only API I introduced was Py++ one. I did not say anything about 
> how DSL
> API looks like.

The BUI that you proposed was what I was thinking about.

>
>>  I
>> think there is a way around each of these issues and from what I see of
>> the interface you created I already submitted a ~5 line patch that you
>> rejected that would add this ability to the existing interface.
>
>
> Lets talk use cases. I introduced the problematic ones. I expect from you
> to prove me being wrong or to provide good solution.

Yes, I have some ideas here.  I will try them out on my current project 
with the method I suggested of extending and overriding the py++ api.

>> The last comment is that I still don't see how you think the template
>> support could be done this way with gccxml and pygccxml in the mix.  I
>> don't see a  way around the two phased approach.
>
>
> This paper I still have to write :-). But in general you are right, I
> don't like two
> phased approach, but it is possible to implement it.

By "paper" can I assume you mean comment on the wiki page about 
templates?  That would be much more helpful IMHO then a .rest document 
or mailing list posting.

-Allen

>
>

Re: [pygccxml-development] DSL challenge

[Allen B. <al...@vr...>]

Matthias Baas wrote:

>Allen Bierbaum wrote:
>  
>
>>Roman Yakovenko wrote:
>>
>>    
>>
>>>Hi. I created document that describes the problems( challenges )  I
>>>have with adding
>>>DSL to Py++.
>>>
>>>http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/docs/peps/dsl_challenge.rest?view=markup
>>>
>>>Obviously I need a help, to solve them. Comments, thought and
>>>suggestions are welcome.
>>> 
>>>      
>>>
>>My first comment would be to put this on the wiki so we can all comment 
>>on it and discuss it.
>>    
>>
>
>Erm, I still cannot access the wiki....
>  
>
Fixed.  Let me know if it happens again.  I think you probably got hit 
by editing a page quite a few times within a short window.  The system 
thought you were a bot spamming the wiki. :)

-Allen

>  
>
>>The second comment I would have is it seems strange to me that you 
>>dismiss the idea of a DSL by introducing a proposed API with 
>>deficiencies that you don't like and they saying "see it is bad".  
>>    
>>
>
>That was also my impression.... ;)
>
>- Matthias -
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>pygccxml-development mailing list
>pyg...@li...
>https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>
>  
>

[pygccxml-development] Wiki and FAQ

[Allen B. <al...@vr...>]

It looks like the faq on the wiki is out of date.  
https://realityforge.vrsource.org/view/PyppApi/PyPlusPlusFaq

For example the "finalize" method does not exist anymore. 
https://realityforge.vrsource.org/view/PyppApi/PyPlusPlusFaq#How_do_I_finalize_a_virtual_clas

What is the status of the wiki documentation effort.  Are we going to 
work together on creating documentation and improving the existing docs 
by editing them on the wiki?

Before someone suggests just editng the .rest documents and submitting 
patches, let reiterate why I think this is a bad idea and how it will 
not help me.
  - It is not live so there is actually very little in the way of 
collaboration
  - It requires building documentation and updating from sources (many 
more steps then just pointing a web browser at a webpage)
  - I read HMTL better then rest and find it much nicer to just have 
live documentation

Anyway, what are the plans for the wiki.  Will it be used for 
documentation or not?

-Allen

Re: [pygccxml-development] DSL challenge

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

Allen Bierbaum wrote:
> Roman Yakovenko wrote:
> 
>> Hi. I created document that describes the problems( challenges )  I
>> have with adding
>> DSL to Py++.
>>
>> http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/docs/peps/dsl_challenge.rest?view=markup
>>
>> Obviously I need a help, to solve them. Comments, thought and
>> suggestions are welcome.
>>  
> My first comment would be to put this on the wiki so we can all comment 
> on it and discuss it.

Erm, I still cannot access the wiki....

> The second comment I would have is it seems strange to me that you 
> dismiss the idea of a DSL by introducing a proposed API with 
> deficiencies that you don't like and they saying "see it is bad".  

That was also my impression.... ;)

- Matthias -

Re: [pygccxml-development] DSL challenge

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

On 8/22/06, Allen Bierbaum <al...@vr...> wrote:
> My first comment would be to put this on the wiki so we can all comment
> on it and discuss it.

Please become a leader of this effort :-).

> The second comment I would have is it seems strange to me that you
> dismiss the idea of a DSL by introducing a proposed API with
> deficiencies that you don't like and they saying "see it is bad".

The only API I introduced was Py++ one. I did not say anything about how DSL
API looks like.

>  I
> think there is a way around each of these issues and from what I see of
> the interface you created I already submitted a ~5 line patch that you
> rejected that would add this ability to the existing interface.

Lets talk use cases. I introduced the problematic ones. I expect from you
to prove me being wrong or to provide good solution.

> The last comment is that I still don't see how you think the template
> support could be done this way with gccxml and pygccxml in the mix.  I
> don't see a  way around the two phased approach.

This paper I still have to write :-). But in general you are right, I
don't like two
phased approach, but it is possible to implement it.


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