Thread: [pygccxml-development] Printing declarations...
Brought to you by:
mbaas,
roman_yakovenko
From: Matthias B. <ba...@ir...> - 2006-03-17 11:07:49
|
Hi, finally I can send a mail as a *user* of pyplusplus again and not as a developer... :) I was pleased to see that the optional<> stuff is in cvs and working! Should the fix for the copy constructor also be available yet? (they are still not wrapped automatically) The call operator also doesn't seem to get wrapped (hasn't that been already done by earlier versions)? Now to my main question for this mail: Is there already a way to obtain a "full" string representation of a declaration (for printing)? I'm only aware of the full_name() function but (as the name already implies) this only returns the name whereas for methods I'd like to see the full signature as well (to be able to distinguish between overloaded methods). - Matthias - |
From: Roman Y. <rom...@gm...> - 2006-03-17 18:09:58
|
On 3/17/06, Matthias Baas <ba...@ir...> wrote: > Hi, > > finally I can send a mail as a *user* of pyplusplus again and not as a > developer... :) Well, it took some time, but ... > I was pleased to see that the optional<> stuff is in cvs and working! :-). Enjoy. > Should the fix for the copy constructor also be available yet? (they are > still not wrapped automatically) I am doing something wrong with constructors. I do not know what :-(. In order to export constructors I need to take into account too many facts. So, until somebody will write comprehensive test case it will not be done i= n few weeks or may be months. :-( >The call operator also doesn't seem to > get wrapped (hasn't that been already done by earlier versions)? I think you find a bug. I just run special_operators_tester.py and it pass= . Can you reproduce it? Thanks > Now to my main question for this mail: Is there already a way to obtain > a "full" string representation of a declaration (for printing)? I'm only > aware of the full_name() function but (as the name already implies) this > only returns the name whereas for methods I'd like to see the full > signature as well (to be able to distinguish between overloaded methods). x.decl_string This should do it. > - Matthias - -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Matthias B. <ba...@ir...> - 2006-03-19 19:38:30
|
Roman Yakovenko wrote: >> Should the fix for the copy constructor also be available yet? (they are >> still not wrapped automatically) > > I am doing something wrong with constructors. I do not know what :-(. What's wrong with the other constructors? For me, it's only the copy constructor that doesn't get wrapped, all other constructors have been fine so far. >> The call operator also doesn't seem to >> get wrapped (hasn't that been already done by earlier versions)? > > I think you find a bug. I just run special_operators_tester.py and it pass. > Can you reproduce it? Thanks Ahem, I forgot that I was explicitly ignoring it..... The actual problem is that the generated code won't compile on Windows (using VC7.1). pyplusplus generates the following code: MVector_exposer.def( "__call__" , (double ( ::MVector::* )( unsigned int ) const)(&MVector::operator()) , ( bp::arg("i") ) , bp::default_call_policies() ); When I try to compile this I get a syntax error because of the "operator()" (VC7.1 gets confused by the brackets). Whereas when I create the following typedef typedef double (::MVector::*bracket_op)(unsigned int i) const; and then rewrite the above as MVector_exposer.def( "__call__" , (bracket_op)(&MVector::operator()) , ( bp::arg("i") ) , bp::default_call_policies() ); then it compiles fine. Could this scheme be incorporated in pyplusplus? >> Now to my main question for this mail: Is there already a way to obtain >> a "full" string representation of a declaration (for printing)? I'm only >> aware of the full_name() function but (as the name already implies) this >> only returns the name whereas for methods I'd like to see the full >> signature as well (to be able to distinguish between overloaded methods). > > x.decl_string > > This should do it. Almost, the signature is there but the actual method name is missing. - Matthias - |
From: Roman Y. <rom...@gm...> - 2006-03-19 19:50:54
|
On 3/19/06, Matthias Baas <ba...@ir...> wrote: > Roman Yakovenko wrote: > >> Should the fix for the copy constructor also be available yet? (they a= re > >> still not wrapped automatically) > > > > I am doing something wrong with constructors. I do not know what :-(. > > What's wrong with the other constructors? For me, it's only the copy > constructor that doesn't get wrapped, all other constructors have been > fine so far. I don't know exactly. I have take into account constructor for wrapper, artificial constructors, private and protected and ... . > Ahem, I forgot that I was explicitly ignoring it..... > The actual problem is that the generated code won't compile on Windows > (using VC7.1). pyplusplus generates the following code: > > MVector_exposer.def( "__call__" > , (double ( ::MVector::* )( unsigned int ) > const)(&MVector::operator()) > , ( bp::arg("i") ) > , bp::default_call_policies() ); > > When I try to compile this I get a syntax error because of the > "operator()" (VC7.1 gets confused by the brackets). Whereas when I > create the following typedef > > typedef double (::MVector::*bracket_op)(unsigned int i) const; > > and then rewrite the above as > > MVector_exposer.def( "__call__" > , (bracket_op)(&MVector::operator()) > , ( bp::arg("i") ) > , bp::default_call_policies() ); > > then it compiles fine. Could this scheme be incorporated in pyplusplus? Yes. I need it also for template functions too. Do you think we need to implement this before release or after? > Almost, the signature is there but the actual method name is missing. Okay, I give up :-). I understand what you want, but I don't understand the format. Also, why do you need this from framework. You have all tools to create almost any format by your own? > - Matthias - -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Roman Y. <rom...@gm...> - 2006-03-20 05:58:26
|
On 3/19/06, Roman Yakovenko <rom...@gm...> wrote: > On 3/19/06, Matthias Baas <ba...@ir...> wrote: > > Roman Yakovenko wrote: > > >> Should the fix for the copy constructor also be available yet? (they= are > > >> still not wrapped automatically) > > > > > > I am doing something wrong with constructors. I do not know what :-(. > > > > What's wrong with the other constructors? For me, it's only the copy > > constructor that doesn't get wrapped, all other constructors have been > > fine so far. > > I don't know exactly. I have take into account constructor for > wrapper, artificial > constructors, private and protected and ... . > > > Ahem, I forgot that I was explicitly ignoring it..... > > The actual problem is that the generated code won't compile on Windows > > (using VC7.1). pyplusplus generates the following code: > > > > MVector_exposer.def( "__call__" > > , (double ( ::MVector::* )( unsigned int ) > > const)(&MVector::operator()) > > , ( bp::arg("i") ) > > , bp::default_call_policies() ); > > > > When I try to compile this I get a syntax error because of the > > "operator()" (VC7.1 gets confused by the brackets). Whereas when I > > create the following typedef > > > > typedef double (::MVector::*bracket_op)(unsigned int i) const; > > > > and then rewrite the above as > > > > MVector_exposer.def( "__call__" > > , (bracket_op)(&MVector::operator()) > > , ( bp::arg("i") ) > > , bp::default_call_policies() ); > > > > then it compiles fine. Could this scheme be incorporated in pyplusplus? Also, untill I add this code to pyplusplus and you don't have an other operator () on MVector you can set create_with_signature to false. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Matthias B. <ba...@ir...> - 2006-03-20 10:09:14
|
Roman Yakovenko wrote: >> typedef double (::MVector::*bracket_op)(unsigned int i) const; >> >> and then rewrite the above as >> >> MVector_exposer.def( "__call__" >> , (bracket_op)(&MVector::operator()) >> , ( bp::arg("i") ) >> , bp::default_call_policies() ); >> >> then it compiles fine. Could this scheme be incorporated in pyplusplus? > > Yes. I need it also for template functions too. Do you think we need to > implement this before release or after? Whenever you have some time you can spend on it. In the above case, the call operator is not that important, so I can wait. > Also, untill I add this code to pyplusplus and you don't have an other > operator () > on MVector you can set create_with_signature to false. I didn't notice a difference in the generated code....? >> Almost, the signature is there but the actual method name is missing. > > Okay, I give up :-). I understand what you want, but I don't > understand the format. The more it resembles the original source code the better. I'm dumping the declarations into a log file that the user can inspect. For example, he could just grep for a particular function name to find out what decorations have been applied to that function. > Also, why do you need this from framework. You have all tools to > create almost any format by your own? Well, yes, but it seems that recreating the source code doesn't look that easy to me (and I don't know how much of the original source code (which could be reused here) has survived in the output from gccxml). When I have some time left I can have a look at it. Would you like the idea to add __str__() methods to the declaration_t classes? (then a user could just print a declaration and see exactly what it is) - Matthias - |
From: Roman Y. <rom...@gm...> - 2006-03-20 10:24:10
|
On 3/20/06, Matthias Baas <ba...@ir...> wrote: > Roman Yakovenko wrote: > >> typedef double (::MVector::*bracket_op)(unsigned int i) const; > >> > >> and then rewrite the above as > >> > >> MVector_exposer.def( "__call__" > >> , (bracket_op)(&MVector::operator()) > >> , ( bp::arg("i") ) > >> , bp::default_call_policies() ); > >> > >> then it compiles fine. Could this scheme be incorporated in pyplusplus= ? > > > > Yes. I need it also for template functions too. Do you think we need to > > implement this before release or after? > > Whenever you have some time you can spend on it. In the above case, the > call operator is not that important, so I can wait. I took a look and it seems, that I need 3 - 4 hours to fix the problem, may be less. So, I will wait with this a little. > > Also, untill I add this code to pyplusplus and you don't have an other > > operator () > > on MVector you can set create_with_signature to false. > > I didn't notice a difference in the generated code....? I think this is because you have an other overload, right? > >> Almost, the signature is there but the actual method name is missing. > > > > Okay, I give up :-). I understand what you want, but I don't > > understand the format. > > The more it resembles the original source code the better. I'm dumping > the declarations into a log file that the user can inspect. For example, > he could just grep for a particular function name to find out what > decorations have been applied to that function. > > Also, why do you need this from framework. You have all tools to > > create almost any format by your own? > > Well, yes, but it seems that recreating the source code doesn't look > that easy to me (and I don't know how much of the original source code > (which could be reused here) has survived in the output from gccxml). > When I have some time left I can have a look at it. Would you like the > idea to add __str__() methods to the declaration_t classes? (then a user > could just print a declaration and see exactly what it is) Before you do it, please ask your self next questions: 1. What is the difference between output of decl_printer_t? 2. Why we need 2 implementation of __str__ methods 3. is decl_printer_t should be implemented in terms of __str__ method, or m= ay be __str__ method should be implemented in terms of decl_printer_t 4. How you configure the a amount of printed information. I would like to see the answers to those question, after this, I think we will have better understanding of what you are actually want. I think we do add __str__ method to declarations, but I need to know the rule. Thanks -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Matthias B. <ba...@ir...> - 2006-03-21 17:03:26
|
Roman Yakovenko wrote: >>>> Almost, the signature is there but the actual method name is missing. >>> Okay, I give up :-). I understand what you want, but I don't >>> understand the format. >> The more it resembles the original source code the better. I'm dumping >> the declarations into a log file that the user can inspect. For example, >> he could just grep for a particular function name to find out what >> decorations have been applied to that function. > >>> Also, why do you need this from framework. You have all tools to >>> create almost any format by your own? >> Well, yes, but it seems that recreating the source code doesn't look >> that easy to me (and I don't know how much of the original source code >> (which could be reused here) has survived in the output from gccxml). >> When I have some time left I can have a look at it. Would you like the >> idea to add __str__() methods to the declaration_t classes? (then a user >> could just print a declaration and see exactly what it is) > > Before you do it, please ask your self next questions: > 1. What is the difference between output of decl_printer_t? decl_printer_t is a more advanced way to output a declaration (or an entire tree) whereas I'd expect the __str__ method to return a concise version of the declaration (preferably in one line) so that it can be uniquely identified by the user. For example, I have a method that the decl_printer_t outputs like this: member_function_t: 'selectByName' Signature: [u'::MStatus', [u'::MString const &', u'::MGlobal::ListAdjustment']] The __str__ method could instead return something like: MStatus MGlobal::selectByName(MString const &, MGlobal::ListAdjustment) [member_function] That is, it is almost C++ source code. The advantage of having only one line is that you can use 'grep' to find a particular declaration in a log file. By the way, in the case of a class, I don't expect the entire class to be printed (including members) but only the class name. If I really want to inspect the contents of the class I can still use the decl_printer. > 2. Why we need 2 implementation of __str__ methods I don't understand. So far, there is no __str__ method. When I print a declaration I get something like: <pyplusplus.decl_wrappers.calldef_wrapper.member_function_t object at 0xb75b826c> > 3. is decl_printer_t should be implemented in terms of __str__ method, or may be > __str__ method should be implemented in terms of decl_printer_t I think they serve different purposes. __str__ should yield a short but unique human-readable representation of the object (like an id so that the user knows where to find this declaration in his source code) whereas decl_printer_t can be used to inspect an entire declaration tree. The decl_printer can be used by a new user to find out how pyplusplus works and how it stores its data. > 4. How you configure the a amount of printed information. It's ok to be able to configure decl_printer_t, but in my opinion __str__ doesn't need to be configured. - Matthias - |
From: Roman Y. <rom...@gm...> - 2006-03-21 18:49:17
|
On 3/21/06, Matthias Baas <ba...@ir...> wrote: > > Before you do it, please ask your self next questions: > > 1. What is the difference between output of decl_printer_t? > > decl_printer_t is a more advanced way to output a declaration (or an > entire tree) whereas I'd expect the __str__ method to return a concise > version of the declaration (preferably in one line) so that it can be > uniquely identified by the user. > > For example, I have a method that the decl_printer_t outputs like this: > > member_function_t: 'selectByName' > Signature: [u'::MStatus', [u'::MString const &', > u'::MGlobal::ListAdjustment']] > > The __str__ method could instead return something like: > > MStatus MGlobal::selectByName(MString const &, MGlobal::ListAdjustment) > [member_function] Okay > That is, it is almost C++ source code. > The advantage of having only one line is that you can use 'grep' to find > a particular declaration in a log file. > > By the way, in the case of a class, I don't expect the entire class to > be printed (including members) but only the class name. > If I really want to inspect the contents of the class I can still use > the decl_printer. Okay > > 2. Why we need 2 implementation of __str__ methods > > I don't understand. So far, there is no __str__ method. When I print a > declaration I get something like: > > <pyplusplus.decl_wrappers.calldef_wrapper.member_function_t object at > 0xb75b826c> I meant why we need decl_printer_t and __str__. In answer to first question you explained this. > > 3. is decl_printer_t should be implemented in terms of __str__ method, = or may be > > __str__ method should be implemented in terms of decl_printer_t > > I think they serve different purposes. __str__ should yield a short but > unique human-readable representation of the object (like an id so that > the user knows where to find this declaration in his source code) > whereas decl_printer_t can be used to inspect an entire declaration > tree. The decl_printer can be used by a new user to find out how > pyplusplus works and how it stores its data. Clear. Can you put this paragraph somewhere in documentation? > > 4. How you configure the a amount of printed information. > > It's ok to be able to configure decl_printer_t, but in my opinion > __str__ doesn't need to be configured. Right Thanks. I understand what you want/need. I think that this is a good functionality. Can you add it to pygccxml.declarations class hierarchy? I will add some te= st code for it. Thanks. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Matthias B. <ba...@ir...> - 2006-03-22 10:57:33
|
Roman Yakovenko wrote: >>> 3. is decl_printer_t should be implemented in terms of __str__ method, or may be >>> __str__ method should be implemented in terms of decl_printer_t >> I think they serve different purposes. __str__ should yield a short but >> unique human-readable representation of the object (like an id so that >> the user knows where to find this declaration in his source code) >> whereas decl_printer_t can be used to inspect an entire declaration >> tree. The decl_printer can be used by a new user to find out how >> pyplusplus works and how it stores its data. > > Clear. Can you put this paragraph somewhere in documentation? I added some notes to the doc string of the decl_printer and the default __str__ method in declaration_t. >>> 4. How you configure the a amount of printed information. >> It's ok to be able to configure decl_printer_t, but in my opinion >> __str__ doesn't need to be configured. > > Right > > Thanks. I understand what you want/need. I think that this is a good > functionality. > Can you add it to pygccxml.declarations class hierarchy? I will add some test > code for it. I've just committed the changes. I hope I didn't miss any declaration. With those changes my query log file has become much more readable. For example, a line like the following in my pyplusplus script: mod.Methods("operator()", retval=["float &", "double &"]).exclude() will produce the following snippet in the log file: ---------------------------------------------------------------------- pypp_setup.py, 417: mod.Methods("operator()", retval=["float &", "double &"]).exclude() Filter: (name=='operator()') & ((retval==float &) | (retval==double &)) & (type==METHOD|FUNCTION|CONSTRUCTOR) & (anyparent=='::') -> float & MFloatPoint::operator()(unsigned int i) [member_operator] -> float & MFloatMatrix::operator()(unsigned int row, unsigned int col) [member_operator] -> float & MFloatVector::operator()(unsigned int i) [member_operator] -> float & MColor::operator()(unsigned int i) [member_operator] -> double & MMatrix::operator()(unsigned int row, unsigned int col) [member_operator] -> double & MVector::operator()(unsigned int i) [member_operator] -> double & MPoint::operator()(unsigned int i) [member_operator] (7 declarations) ---------------------------------------------------------------------- Here the user can exactly see how pyplusplus has interpreted a particular query. The first line is a reference to the user's source script. The second line is the generated filter expression and the remaining lines show the result of the query. I'm still planning on adding another similar log file that is not based on queries but on decoration operations. Each such operation will then output a line for each declaration it was applied to. Then you can just grep for a particular declaration to obtain a "history" on what has happened to that declaration. - Matthias - |
From: Roman Y. <rom...@gm...> - 2006-03-22 11:21:14
|
On 3/22/06, Matthias Baas <ba...@ir...> wrote: > I added some notes to the doc string of the decl_printer and the default > __str__ method in declaration_t. Thanks > >>> 4. How you configure the a amount of printed information. > >> It's ok to be able to configure decl_printer_t, but in my opinion > >> __str__ doesn't need to be configured. > > > > Right > > > > Thanks. I understand what you want/need. I think that this is a good > > functionality. > > Can you add it to pygccxml.declarations class hierarchy? I will add som= e test > > code for it. > > I've just committed the changes. I hope I didn't miss any declaration. I just run 113 pygccxml test cases. All works as expected > With those changes my query log file has become much more readable. For > example, a line like the following in my pyplusplus script: > > mod.Methods("operator()", retval=3D["float &", "double &"]).exclude() > > will produce the following snippet in the log file: > > ---------------------------------------------------------------------- > pypp_setup.py, 417: mod.Methods("operator()", retval=3D["float &", "doubl= e > &"]).exclude() > Filter: (name=3D=3D'operator()') & ((retval=3D=3Dfloat &) | (retval=3D=3D= double &)) > & (type=3D=3DMETHOD|FUNCTION|CONSTRUCTOR) & (anyparent=3D=3D'::') > -> float & MFloatPoint::operator()(unsigned int i) [member_operator] > -> float & MFloatMatrix::operator()(unsigned int row, unsigned int > col) [member_operator] > -> float & MFloatVector::operator()(unsigned int i) [member_operator] > -> float & MColor::operator()(unsigned int i) [member_operator] > -> double & MMatrix::operator()(unsigned int row, unsigned int col) > [member_operator] > -> double & MVector::operator()(unsigned int i) [member_operator] > -> double & MPoint::operator()(unsigned int i) [member_operator] > (7 declarations) > ---------------------------------------------------------------------- > Here the user can exactly see how pyplusplus has interpreted a > particular query. The first line is a reference to the user's source > script. The second line is the generated filter expression and the > remaining lines show the result of the query. I am envy you a little :-). Do you want to port that code to matchers? > I'm still planning on adding another similar log file that is not based > on queries but on decoration operations. Each such operation will then > output a line for each declaration it was applied to. Then you can just > grep for a particular declaration to obtain a "history" on what has > happened to that declaration. Can you switch to new API ( =3D=3D module builder ) and improve/add/update = it? I think that now pyplusplus has all functionality you need. What do you thi= nk? What is the stopper? -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Matthias B. <ba...@ir...> - 2006-03-22 17:32:24
|
Roman Yakovenko wrote: > Can you switch to new API ( == module builder ) and improve/add/update it? > I think that now pyplusplus has all functionality you need. What do you think? > What is the stopper? Well, I'm hesitating because I would still like to be able to experiment with the API. If I give up that extra layer between the "official" pyplusplus code and my driver script then I cannot do quick changes to the API anymore. In the experimental folder I can mess around without being afraid of breaking something in the official code. That's what I meant in a previous mail when I said I'm in favor of waiting with moving the high level API to the official code until it's more or less stable and all areas have been addressed. Currently, the API is usable and can produce code, but I'm still not entirely satisfied with the results and still like to improve my module. And there are still quite a few things that could be added to the API... - Matthias - |
From: Roman Y. <rom...@gm...> - 2006-03-22 19:48:17
|
On 3/22/06, Matthias Baas <ba...@ir...> wrote: > That's what I meant in a previous mail when I said I'm in favor of > waiting with moving the high level API to the official code until it's > more or less stable and all areas have been addressed. I don't agree with you on this point. I think that you and Allen did such great job, really. You designed completely new interface to pyplusplus. I think that select api is stable. It is not going to be changed, only in a few places we will add a functionality users missing/need. Don't you agree with me? Please, take a look on py_date= _time example. You will see the whole power of select interface :-). I have to give some lecture about Python next week, after this I think we w= ill release "technology preview" version. There is only one point that open - how to treat overloaded function. ( By the way, I hope I will implement tomorrow solution that will satisfy you ). You are adding great functionality ( =3D=3D logging ) to filters/matchers. Why not to add it to the main source code? > Currently, the > API is usable and can produce code, but I'm still not entirely satisfied > with the results and still like to improve my module. And there are > still quite a few things that could be added to the API... I think that you have great ideas and you can implement them directly on main source code. There are some ideas, that we don't agree or I need some = time to understand you. Those ideas should be implemented on experimental branch= . Although your implementation is so different from my. I fill a little bit uncomfortable with this. Can you try module_builder_t class on your project? I think you will like the result. decl_wrappers are still missing some functionality ( cdef ), but I don't think this will be a problem. What do you think? > - Matthias - P.S.1. Until end of the next week I will be busy, very busy. I will try to response as quick as I can. P.S.2 Can you start writing some introduction/tutorial for high level API? Thanks -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Matthias B. <ba...@ir...> - 2006-03-23 10:31:11
|
Roman Yakovenko wrote: > On 3/22/06, Matthias Baas <ba...@ir...> wrote: >> That's what I meant in a previous mail when I said I'm in favor of >> waiting with moving the high level API to the official code until it's >> more or less stable and all areas have been addressed. > > I don't agree with you on this point. I think that you and Allen did > such great job, > really. You designed completely new interface to pyplusplus. I think > that select api is > stable. It is not going to be changed, only in a few places we will > add a functionality > users missing/need. Don't you agree with me? Please, take a look on py_date_time > example. You will see the whole power of select interface :-). I noticed that the selection works differently in your version compared to the experimental version. I would have only called it "stable" when the interface in both versions would have been identical as in this case, it would have shown that we all agree on one common scheme. Obviously this is not yet the case. I just tried to write a driver script for the Maya module that only uses the "official" module_builder_t class. I thought I could mainly use my existing script and only inject aliases for the method names in module_builder and decl_wrapper. But it's not only the naming convention but also the interface itself that differs. So switching entirely to your version would take quite a bit of time and even with my current partial script I've noticed things that could be improved in my opinion. But at least it provides a basis for further discussion (as I just see it as another proposal for an API) and hopefully we can objectively balance the pros and cons of each version once they're in a state that the respective supporters are happy with. :) > Although your implementation is so different from my. > I fill a little bit uncomfortable with this. Yes, we seem to have different ways of thinking and programming... ;-) But anyway, the focus is still on the *interface*, isn't it? This means, the actual implementation of a prototype interface is not important at all (as long as it works and can be used to test the interface). For a final implementation (once the interface is stable!), we should find better algorithms anyway. For example, querying for declarations could be a lot faster (now that the parsing time is no issue anymore, querying for declarations has become the new bottleneck for me). Currently, we use a rather naive approach of iterating through all declarations and applying a filter function which is O(n) for a single query. It would be great if a final version could reduce this complexity to O(log(n)) or even O(1) by doing some preprocessing. By the way, such a thing might also have an effect on the interface itself. If you base selections solely on user-provided functions then there's little you can do to get any better than O(n). But if you provide a set of predefined filter functions then we know in advance how this filters work and can exploit that knowledge to speed up the queries. > P.S.2 Can you start writing some introduction/tutorial for high level API? I'll see that I gradually update the documentation of the experimental module. You can then take the parts that are identical and use them for your version as well. But I'm afraid I'm not yet able to write a tutorial for your version as I'm not entirely familiar with the way it's supposed to work and I even think that a couple of things need improvement. - Matthias - |
From: Roman Y. <rom...@gm...> - 2006-03-23 11:59:41
|
On 3/23/06, Matthias Baas <ba...@ir...> wrote: > I noticed that the selection works differently in your version compared > to the experimental version. I would have only called it "stable" when > the interface in both versions would have been identical as in this > case, it would have shown that we all agree on one common scheme. > Obviously this is not yet the case. Why? In my opinion our "select" interfaces are very very similar. What I am missing. I do aware about differences in regex filter/matcher, bu= t that's all. > I just tried to write a driver script for the Maya module that only uses > the "official" module_builder_t class. I thought I could mainly use my > existing script and only inject aliases for the method names in > module_builder and decl_wrapper. But it's not only the naming convention > but also the interface itself that differs. You right, there are differences, but not the conceptual ones. I can be fle= xible ( At least I believe so :-) ) > So switching entirely to > your version would take quite a bit of time and even with my current > partial script I've noticed things that could be improved in my opinion. What are they? We can discuss them in few mails and I think we could implem= ent them on main branch. > But at least it provides a basis for further discussion > (as I just see it as another proposal for an API) And you are right. > and hopefully we can objectively > balance the pros and cons of each version once they're in a state that > the respective supporters are happy with. :) That is exactly what I want. I think you and I developed enough. It is a ti= me to move on. I think we should sit and merge our sources/ideas. Do you think that there are some major features that is still missing in my/your selection code base? > > Although your implementation is so different from my. > > I fill a little bit uncomfortable with this. > > Yes, we seem to have different ways of thinking and programming... ;-) Yes we are :-) > But anyway, the focus is still on the *interface*, isn't it? This means, > the actual implementation of a prototype interface is not important at > all (as long as it works and can be used to test the interface). Yes. So may we close at least select interface? > For a final implementation (once the interface is stable!), we should > find better algorithms anyway. For example, querying for declarations > could be a lot faster (now that the parsing time is no issue anymore, > querying for declarations has become the new bottleneck for me). > Currently, we use a rather naive approach of iterating through all > declarations and applying a filter function which is O(n) for a single > query. It would be great if a final version could reduce this complexity > to O(log(n)) or even O(1) by doing some preprocessing. By the way, such > a thing might also have an effect on the interface itself. If you base > selections solely on user-provided functions then there's little you can > do to get any better than O(n). But if you provide a set of predefined > filter functions then we know in advance how this filters work and can > exploit that knowledge to speed up the queries. I also saw performance problems and I think I can fix them without changing select interface > > P.S.2 Can you start writing some introduction/tutorial for high level A= PI? > > I'll see that I gradually update the documentation of the experimental > module. You can then take the parts that are identical and use them for > your version as well. But I'm afraid I'm not yet able to write a > tutorial for your version as I'm not entirely familiar with the way it's > supposed to work and I even think that a couple of things need improvemen= t. Please say what are they? As I already said, I am going to be pretty busy next week, but at the end of the week we can chat a little, what do you think? Matthias, I want people to start using pyplusplus. So I think that we should stop "code creation" and start merging. Almost all your ideas found the way into pyplusplus code. What do you think about next plan: this and next week you are going to develop missing functionality.From the 1/04 we close experimental branch and start merging almost all functionality to main branch. Thanks -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Matthias B. <ba...@ir...> - 2006-03-23 17:19:24
|
Roman Yakovenko wrote: >> I noticed that the selection works differently in your version compared >> to the experimental version. I would have only called it "stable" when >> the interface in both versions would have been identical as in this >> case, it would have shown that we all agree on one common scheme. >> Obviously this is not yet the case. > > Why? In my opinion our "select" interfaces are very very similar. > What I am missing. I do aware about differences in regex filter/matcher, but > that's all. In the date_time example you're very often using lambda functions to do selections. The function is passed as first argument (without using keyword arguments), but sometimes you also just pass a string with the declaration name as first argument. So obviously there is some builtin rule about what the argument types may look like in your version. The experimental version doesn't have that. So far, it is only guaranteed that the first argument is the name filter, all other filters must be specified by keyword arguments. Actually, I haven't found out yet what arguments your selection functions do provide (the source code is not that easy to read)... >> So switching entirely to >> your version would take quite a bit of time and even with my current >> partial script I've noticed things that could be improved in my opinion. > > What are they? From the top of my head: - There's no single module from which the user can import all the required stuff but instead he has to know where everything is located. - The module builder still requires the config object (which I would rather regard as an internal pyplusplus object). - The selection functions accept *any* keyword argument even when that argument is not used/valid at all. - I think making the step to create code creators explicit is not necessary. To me, code creators are rather an implementation detail a user doesn't really have to know about (maybe this will change with more advanced features...?). Apart from that, the error message that appears when a user forgets to do this step (as happened with me :) is confusing: "self.module is equal to None. Did you forget to call create_module function?" The first sentence refers to an internal variable the user does not know about and the second sentence refers to a function that does not exist. - When I wrote the source files without doing any decorations I got an empty module. So far, so good, this has been the test to check whether declarations are ignored or exposed by default. But when I added include() calls for some particular classes, I actually got many more classes in the output (that I didn't want). - There are no doc strings... ;-) > We can discuss them in few mails and I think we could implement > them on main branch. But if you would now implement everything so that it conforms to my opinion, then you would basically end up with the experimental module. So what's the point of doing that? We have that already. Instead we should try to get the core of pyplusplus stable and flexible enough (one area which I still think is a weak point in pyplusplus is the ability to customize the individual output files. I still don't know how/if I could add source code at the declaration level in a particular output file or modify the include files from one particular file). >> and hopefully we can objectively >> balance the pros and cons of each version once they're in a state that >> the respective supporters are happy with. :) > > That is exactly what I want. I think you and I developed enough. It is a time > to move on. I think we should sit and merge our sources/ideas. > Do you think that there are some major features that is still missing > in my/your selection code base? So far, I have been fine with the selection in the experimental module. But I guess some more filters could be useful eventually. And the performance could be better, of course. :) But there are certainly features missing in the API. See for example, the section "What capabilites are not supported by the current API that we should have?" in the wiki. > Matthias, I want people to start using pyplusplus. I see that you're eager to get out a new release, and this is fine with me. :) But what's the problem with releasing pyplusplus and referring to the experimental module which the people can try out and provide feedback? This is not going to be the 1.0 release, is it? ;) > code. What do you think about next plan: this and next week you are > going to develop > missing functionality.From the 1/04 we close experimental branch and > start merging almost all functionality to main branch. I cannot guarantee that in a week or two the experimental API will be finished. Actually, I'm pretty much sure that it won't be finished by then as there are still a lot of areas we haven't addressed yet. For me, one of the next things I'd like to see would be automated wrapper generation.... but this is an entirely new thing that I don't know yet how this could be done (and if it could be done at all). It's just an area that needs some experimentation... :) So how about the following instead as the next milestone for pyplusplus: "Get the core of pyplusplus stable and flexible so that *any* high level API could be implemented on top of that without having to modify pygccxml/pyplusplus" - Matthias - |
From: Roman Y. <rom...@gm...> - 2006-03-23 19:48:01
|
On 3/23/06, Matthias Baas <ba...@ir...> wrote: > Roman Yakovenko wrote: > >> I noticed that the selection works differently in your version compare= d > >> to the experimental version. I would have only called it "stable" when > >> the interface in both versions would have been identical as in this > >> case, it would have shown that we all agree on one common scheme. > >> Obviously this is not yet the case. > > > > Why? In my opinion our "select" interfaces are very very similar. > > What I am missing. I do aware about differences in regex filter/matcher= , but > > that's all. > > In the date_time example you're very often using lambda functions to do > selections. The function is passed as first argument (without using > keyword arguments), but sometimes you also just pass a string with the > declaration name as first argument. So obviously there is some builtin > rule about what the argument types may look like in your version. The > experimental version doesn't have that. So far, it is only guaranteed > that the first argument is the name filter, all other filters must be > specified by keyword arguments. Actually, I haven't found out yet what > arguments your selection functions do provide (the source code is not > that easy to read)... :-) Now you are talking. Remember, I like when you critic me. So lets start= . The rule is next ( decl_wrappers/scopedef_wrapper.py relevant functions: __create_matcher, _find_single, _find_multiple ) def __create_matcher( self, match_class, *args, **keywds ): if len( args ) =3D=3D 1 and callable( args[0] ): matcher =3D match_class( [], **keywds) return lambda decl: matcher( decl ) and args[0](decl) else: if 1 =3D=3D len( args ) and isinstance( args[0], str ): keywds['name'] =3D args[0] args =3D [] return match_class(*args, **keywds) If user pass one callable argument then I construct instance of concrete ma= tcher class and join it with user function. Else, I just construct matcher with user arguments, if he passes only one argument then I say that this argument represents the name of decl(s) he wants to fi= nd. Here, there is an other difference: user don't have to specify whether name= is full name or object name only. declarations.declaration_matcher_t can find = it by itself What can you pass as arguments? You have to see declaration matchers class hierarchy. > >> So switching entirely to > >> your version would take quite a bit of time and even with my current > >> partial script I've noticed things that could be improved in my opinio= n. > > > > What are they? > > From the top of my head: > > - There's no single module from which the user can import all the > required stuff but instead he has to know where everything is located. I did not want to polish my implementation. I think it is very easy to add aliases to relevant classes in module_builder/__init__.py file. I think it should take 1 hour. Am I wrong? > - The module builder still requires the config object (which I would > rather regard as an internal pyplusplus object). There are few ways to go: 1. You can pass all arguments needed for parsing to module_builder_t.__init= __ method. I prefer this method 2. You can create some class that will aggregate all needed settings and us= er will pass it to module_builder_t.__init__ If you like this approach, we will implement it. 3. Your approach is going here I am sure you have an other idea. So we can discuss it also. 4. module_builder_t.__init__ don't take any arguments or it could take it does not matter, because module_builder_t will expose set of variables that user= can configure and only after that to call parse function. I am strongly against this approach. Class interface should guide user. Although for almost every function in this class there is a precondition: declarations tree has been extracted from sources. So lets force it in __in= it__. I am almost sure user don't need such flexibility. > - The selection functions accept *any* keyword argument even when that > argument is not used/valid at all. Well, all you say is that my implementation has not been polished and you a= re right. It is just a concept. > - I think making the step to create code creators explicit is not > necessary. To me, code creators are rather an implementation detail a > user doesn't really have to know about (maybe this will change with more > advanced features...?). Here I am semi agree with you. I understand your point, but access to power= ful features of pyplusplus( code creators ) should be also easy. When user call= this function the only parameter he should give is module name. Also we talk wit= h you that every step after parsing should be done explicitly, don't we? May be I've got you wrong? I choose bad name. I thought about: create_in_memory_module, but it is too long. So you can suggest something better. pypp_api.py also has this function. >Apart from that, the error message that appears > when a user forgets to do this step (as happened with me :) is confusing: > > "self.module is equal to None. Did you forget to call create_module > function?" If we could agree on previous item, I am sure we can provide better error message. > The first sentence refers to an internal variable the user does not know > about and the second sentence refers to a function that does not exist. Fixed. > - When I wrote the source files without doing any decorations I got an > empty module. So far, so good, this has been the test to check whether > declarations are ignored or exposed by default. But when I added > include() calls for some particular classes, I actually got many more > classes in the output (that I didn't want). The default behaviour is next: export all declarations from file and files that belongs to the same directory as included file. You can suggest an other default behaviour. This is not the point I will argue with you. > - There are no doc strings... ;-) Guilty, guilty an guilty :-) > > We can discuss them in few mails and I think we could implement > > them on main branch. > > But if you would now implement everything so that it conforms to my > opinion, then you would basically end up with the experimental module. > So what's the point of doing that? Implementation details. If you are going to implement experimental branch using functionality provided by pyplusplus I am sure your code will find th= e way into main branch in few hours. > We have that already. > Instead we should try to get the core of pyplusplus stable and flexible > enough (one area which I still think is a weak point in pyplusplus is > the ability to customize the individual output files. I still don't know > how/if I could add source code at the declaration level in a particular > output file or modify the include files from one particular file). Until now, no one requested this functionality. In general I have one rule: I don't write code if no one needs it. If you need such functionality, then please start an other discussion with detailed description of your use case. I am almost sure we can find good solution to the problem. > So far, I have been fine with the selection in the experimental module. > But I guess some more filters could be useful eventually. And the > performance could be better, of course. :) Please don't be greedy :-). I am sure when people will start using pyplusplus, they will contribute a lot of filters and suggestions to improve performance. > But there are certainly features missing in the API. See for example, > the section "What capabilites are not supported by the current API that > we should have?" in the wiki. May be I am looking in a wrong place, can you post the link? Thanks Also, there are always so many things that we could implement. I have so many crazy ideas. I prefer to release something very usable, in order to get users opinion > > Matthias, I want people to start using pyplusplus. > > I see that you're eager to get out a new release, and this is fine with > me. :) But what's the problem with releasing pyplusplus and referring to > the experimental module which the people can try out and provide > feedback? This is not going to be the 1.0 release, is it? ;) There is one problem:I think people will not start to use it, until you can= say explicitly: only small parts of this API could be change. And we can not say this on experimental branch :-( Also if you re implement your high level API in terms of matchers and decl_wrappers, I think we can release even 2 interface. They will peek what= ever they like. It could be fun, don't you think so :-) ? > > code. What do you think about next plan: this and next week you are > > going to develop > > missing functionality.From the 1/04 we close experimental branch and > > start merging almost all functionality to main branch. > > I cannot guarantee that in a week or two the experimental API will be > finished. Actually, I'm pretty much sure that it won't be finished by > then as there are still a lot of areas we haven't addressed yet. Matthias, I think that this is okay, really. You started to use pyplusplus = when it was a pain. If I would wait, while I have "perfect" API, I wouldn't get your and Allen help. So lets go for release. Please concentrate on major feature and functionality. We always can add functionality here and there. Or to fix couple of bugs. > For me, one of the next things I'd like to see would be automated > wrapper generation.... but this is an entirely new thing that I don't > know yet how this could be done (and if it could be done at all). It's > just an area that needs some experimentation... :) Do you know what I am thinking about? GUI. Just imagine you have tree with = all declarations at the left. On the top you have Python interpreter or an othe= r window, that will help you to select declarations set. On the center you wi= ll have a list of properties and explanation. Nice, ha? Almost fully automated solution. But ... > So how about the following instead as the next milestone for pyplusplus: > > "Get the core of pyplusplus stable and flexible so that *any* high level > API could be implemented on top of that without having to modify > pygccxml/pyplusplus" First of all you need to define a core. Do declaration_matcher_t class hier= archy and decl_wrappers are core or not. ( Pay attention select interface impleme= nted on decl_wrappers ) After this I think that I am agree with you. Although there is only one way to prove that core is stable enough - to implement module_builder class. So please make a review on your and my code, decide and at the end of next week I hope we could talk few hours on IRC in order to close issues. I will try to create a list of concrete open questions. I hope we will be able to produce something until 20/04. > - Matthias - -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Matthias B. <ba...@ir...> - 2006-03-24 15:41:28
|
Roman Yakovenko wrote: >> - There's no single module from which the user can import all the >> required stuff but instead he has to know where everything is located. > > I did not want to polish my implementation. I think it is very easy to > add aliases > to relevant classes in module_builder/__init__.py file. I think it > should take 1 hour. > Am I wrong? I even think it only takes a couple of minutes. But I think this would have been an important thing as it affects the user's script. In my view there are three "layers" of software involved in the process of creating bindings. Here's some ASCII art that shows the layers (make sure to use a fixed pitch font for viewing): +------------------------------+ | The user's "driver" script | +---------------------------+ | | High level API | | +---------------------------+--+ | pygccxml/pyplusplus "core" | +------------------------------+ On top there's the script written by the user that controls pyplusplus and creates the final bindings. It should be "easy" (whatever that means) for the user to write and maintain this script. The script will most likely stick to the high level API but it can also use the "core" directly if this is of any advantage. The second layer is the high level API that handles all the internals of pyplusplus and provides the main interface for the driver script so that the user's script can concentrate on tailoring the bindings to the user's needs. Internally, the high level API uses the "core" just as if it was another user script. The bottom layer is the actual "core" of pyplusplus. It does all the work and contains everything that is required to write the final C++ source code. It also provides an API but at a lower level (basically this is what pyplusplus has already been a month ago). A few noteworthy points: - The purpose of the high level API is to make the user's life easier and his script more "manageable". The API is not vital for the results. The script could produce the very same extension module by using the core directly. - The core is entirely independent of the high level API. From the core's point of view the high level API is just another "user script". As a consequence, for every piece of code in pyplusplus it should be clear whether this code conceptually belongs to the core or to the high level API. - The high level API may still contain "logic" and functionality that is not part of the core if this functionality is not strictly required for writing extension source code. Now, in my opinion, when we talk about the interface our main focus should be the topmost layer, that is, how should the user's script look like? Whereas it seems to me that this thread currently rather focuses on the implementation of the middle and bottom layer (which is not that relevant at this point). Above you say that sticking the relevant stuff into one module is just "polishing" the implementation. Here I disagree! This "polishing" directly affects the user's script on the very top of those layers and as such, I consider it to be a very important issue. Whereas if you modify something in the pyplusplus core or within the implementation of the high level API, but this modification is not "visible" in the user's script then there's actually nothing that needs discussion anyway. >> - The module builder still requires the config object (which I would >> rather regard as an internal pyplusplus object). > > There are few ways to go: > 1. You can pass all arguments needed for parsing to module_builder_t.__init__ > method. > > I prefer this method > > 2. You can create some class that will aggregate all needed settings and user > will pass it to module_builder_t.__init__ > > If you like this approach, we will implement it. I prefer 1 as well (maybe in addition to some specific config methods) and this is already how the experimental ModuleBuilder works. Your version uses method 2 which is why I was complaining. >> - The selection functions accept *any* keyword argument even when that >> argument is not used/valid at all. > > Well, all you say is that my implementation has not been polished and you are > right. It is just a concept. Yes, but missing documentation and missing warning/error message make it rather difficult to use. You can neither read how it works nor can you apply "trial and error" attempts. >> - I think making the step to create code creators explicit is not >> necessary. To me, code creators are rather an implementation detail a >> user doesn't really have to know about (maybe this will change with more >> advanced features...?). > > Here I am semi agree with you. I understand your point, but access to powerful > features of pyplusplus( code creators ) should be also easy. When the user needs it he can of course call the function, I'm only arguing that it is not necessary to enforce such a call when it is not required by the user (which I think is the common case). > When user call this > function the only parameter he should give is module name. Also we talk with > you that every step after parsing should be done explicitly, don't we? Uhm, I don't remember having said that every step should be explicit. Maybe this was just a misunderstanding then... >>> We can discuss them in few mails and I think we could implement >>> them on main branch. >> But if you would now implement everything so that it conforms to my >> opinion, then you would basically end up with the experimental module. >> So what's the point of doing that? > > Implementation details. If you are going to implement experimental branch > using functionality provided by pyplusplus I *am* implementing the experimental module by using the functionality provided by pyplusplus. This has always been the case. I'm not planning on implementing my own code generation tool... :) > I am sure your code will find the way into main branch in few hours. But I never said I wanted the high level API to be part of the main branch *as quickly as possible*. It has always been my point in the previous mails that I actually like it to be independent and separate from the core (as long as the API is still under heavy construction). >> We have that already. >> Instead we should try to get the core of pyplusplus stable and flexible >> enough (one area which I still think is a weak point in pyplusplus is >> the ability to customize the individual output files. I still don't know >> how/if I could add source code at the declaration level in a particular >> output file or modify the include files from one particular file). > > Until now, no one requested this functionality. Didn't I mention that in a mail once? (hm, maybe I wanted to mention it but there were more important things at that time...) Anyway, after the introduction of the decl_wrappers it took me a while to get the basics working again, so during that period of time the more advanced features haven't been that important. That's going to change now... ;) >> But there are certainly features missing in the API. See for example, >> the section "What capabilites are not supported by the current API that >> we should have?" in the wiki. > > May be I am looking in a wrong place, can you post the link? Thanks https://realityforge.vrsource.org/view/PyOpenSG/PyppApiDiscussion >>> Matthias, I want people to start using pyplusplus. >> I see that you're eager to get out a new release, and this is fine with >> me. :) But what's the problem with releasing pyplusplus and referring to >> the experimental module which the people can try out and provide >> feedback? This is not going to be the 1.0 release, is it? ;) > > There is one problem:I think people will not start to use it, until you can say > explicitly: only small parts of this API could be change. And we can > not say this on experimental branch :-( But just because a piece of code is located in another directory doesn't mean it is more stable, does it? Wouldn't that be kind of a "false security" to think that this API couldn't change anymore? >>> code. What do you think about next plan: this and next week you are >>> going to develop >>> missing functionality.From the 1/04 we close experimental branch and >>> start merging almost all functionality to main branch. >> I cannot guarantee that in a week or two the experimental API will be >> finished. Actually, I'm pretty much sure that it won't be finished by >> then as there are still a lot of areas we haven't addressed yet. > > Matthias, I think that this is okay, really. You started to use pyplusplus when > it was a pain. :) > If I would wait, while I have "perfect" API, I > wouldn't get your and > Allen help. So lets go for release. I never said you should not do a release. I'm in favor of a new release! I'm only arguing that a new release shouldn't mean the end of the experimental module. >> For me, one of the next things I'd like to see would be automated >> wrapper generation.... but this is an entirely new thing that I don't >> know yet how this could be done (and if it could be done at all). It's >> just an area that needs some experimentation... :) > > Do you know what I am thinking about? GUI. Just imagine you have tree with all > declarations at the left. On the top you have Python interpreter or an other > window, that will help you to select declarations set. On the center you will > have a list of properties and explanation. Nice, ha? Almost fully automated > solution. But ... This might be a handy tool. But it will also take quite a bit of time to implement that properly... >> So how about the following instead as the next milestone for pyplusplus: >> >> "Get the core of pyplusplus stable and flexible so that *any* high level >> API could be implemented on top of that without having to modify >> pygccxml/pyplusplus" > > First of all you need to define a core. Do declaration_matcher_t class hierarchy > and decl_wrappers are core or not. ( Pay attention select interface implemented > on decl_wrappers ) By default, I consider everything in pyplusplus as being part of the core and everything beneath experimental as high level. :) The decl_wrapper classes are core classes to me and they are actually used already in the experimental module, even though they are only used as "decorators" whereas the selection interface is not used. By the way, that's an example where the (builtin) high level API is intermingled with the core which I do not like. As I said above, I would prefer a modular approach where these things are strictly kept separate and where the core is independent from the high level API. - Matthias - |
From: Roman Y. <rom...@gm...> - 2006-03-29 08:04:36
|
On 3/24/06, Matthias Baas <ba...@ir...> wrote: > I even think it only takes a couple of minutes. But I think this would > have been an important thing as it affects the user's script. module_builder/__init__.py module now imports all necessary functionality. > In my view there are three "layers" of software involved in the process > of creating bindings. Here's some ASCII art that shows the layers (make > sure to use a fixed pitch font for viewing): > > +------------------------------+ > | The user's "driver" script | > +---------------------------+ | > | High level API | | > +---------------------------+--+ > | pygccxml/pyplusplus "core" | > +------------------------------+ Matthias, I don't want to start theoretical discussion, really. In general I agree with you. > Above you say that sticking the relevant stuff into one module is just > "polishing" the implementation. Here I disagree! This "polishing" > directly affects the user's script on the very top of those layers and > as such, I consider it to be a very important issue. I agree with you, but for me very important issue is something that will ta= ke few days to implement. Documentation is one of them, for example. >Whereas if you > modify something in the pyplusplus core or within the implementation of > the high level API, but this modification is not "visible" in the user's > script then there's actually nothing that needs discussion anyway. I think you should understand that high level script and user api is tightly coupled. Second, sometimes implementation details important - for example performanc= e. > > There are few ways to go: > > 1. You can pass all arguments needed for parsing to module_builder_t.__= init__ > > method. Done. > >> - The selection functions accept *any* keyword argument even when that > >> argument is not used/valid at all. > > > > Well, all you say is that my implementation has not been polished and y= ou are > > right. It is just a concept. > > Yes, but missing documentation and missing warning/error message make it > rather difficult to use. You can neither read how it works nor can you > apply "trial and error" attempts. Work in progress > >> - I think making the step to create code creators explicit is not > >> necessary. To me, code creators are rather an implementation detail a > >> user doesn't really have to know about (maybe this will change with mo= re > >> advanced features...?). > > > > Here I am semi agree with you. I understand your point, but access to p= owerful > > features of pyplusplus( code creators ) should be also easy. > > When the user needs it he can of course call the function, I'm only > arguing that it is not necessary to enforce such a call when it is not > required by the user (which I think is the common case). Where you will setup module name? > I *am* implementing the experimental module by using the functionality > provided by pyplusplus. This has always been the case. I'm not planning > on implementing my own code generation tool... :) Honestly, I don't see reuse of functionality except code creators. > > I am sure your code will find the way into main branch in few hours. > > But I never said I wanted the high level API to be part of the main > branch *as quickly as possible*. It has always been my point in the > previous mails that I actually like it to be independent and separate > from the core (as long as the API is still under heavy construction). I consider API found in pyplusplus as stable. So I would like to insert you= r functionality inside. I would like to talk with you and explain every corne= r of pyplusplus. > Didn't I mention that in a mail once? (hm, maybe I wanted to mention it > but there were more important things at that time...) Anyway, after the > introduction of the decl_wrappers it took me a while to get the basics > working again, so during that period of time the more advanced features > haven't been that important. That's going to change now... ;) :-). Yes we will merge our efforts. > >> But there are certainly features missing in the API. See for example, > >> the section "What capabilites are not supported by the current API tha= t > >> we should have?" in the wiki. > > > > May be I am looking in a wrong place, can you post the link? Thanks > > https://realityforge.vrsource.org/view/PyOpenSG/PyppApiDiscussion Yes, we will add missing features in next releases. > But just because a piece of code is located in another directory doesn't > mean it is more stable, does it? Yes it does. I have more then 40 unit testers + 3 projects ( EasyBMP, boost.date_time and TnFOX ). >Wouldn't that be kind of a "false > security" to think that this API couldn't change anymore? This is not the message I pass to an user. Even API in main branch could be changed. The main message is that API in main branch has been tested and it= is useful. > > > If I would wait, while I have "perfect" API, I > > wouldn't get your and > > Allen help. So lets go for release. > > I never said you should not do a release. I'm in favor of a new release! > I'm only arguing that a new release shouldn't mean the end of the > experimental module. Do you plan another revolution in pyplusplus :-)? If no I see no point in experimental module. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Matthias B. <ba...@ir...> - 2006-03-29 20:24:18
|
Roman Yakovenko wrote: >>>> - I think making the step to create code creators explicit is not >>>> necessary. To me, code creators are rather an implementation detail a >>>> user doesn't really have to know about (maybe this will change with more >>>> advanced features...?). >>> Here I am semi agree with you. I understand your point, but access to powerful >>> features of pyplusplus( code creators ) should be also easy. >> When the user needs it he can of course call the function, I'm only >> arguing that it is not necessary to enforce such a call when it is not >> required by the user (which I think is the common case). > > Where you will setup module name? In the constructor of the module builder (and probably with an appropriate "configuration method", but such a thing is still missing in the experimental module). >> I *am* implementing the experimental module by using the functionality >> provided by pyplusplus. This has always been the case. I'm not planning >> on implementing my own code generation tool... :) > > Honestly, I don't see reuse of functionality except code creators. Decorating the declarations is done using the corresponding methods in the decl_wrappers. >> But just because a piece of code is located in another directory doesn't >> mean it is more stable, does it? > > Yes it does. I have more then 40 unit testers + 3 projects ( EasyBMP, > boost.date_time and TnFOX ). Well, yes, the unit tests are quite impressive and already a sign of the quality of the software, but: the unit tests can only test an implementation, but not the "usability" or how intuitive an interface is. >> I never said you should not do a release. I'm in favor of a new release! >> I'm only arguing that a new release shouldn't mean the end of the >> experimental module. > > Do you plan another revolution in pyplusplus :-)? Oh, I wasn't aware there has been a revolution... :) > If no I see no point in experimental module. Well, it's for experimenting (and sharing that)... ;-) - Matthias - |
From: Roman Y. <rom...@gm...> - 2006-03-29 20:37:14
|
On 3/29/06, Matthias Baas <ba...@ir...> wrote: > Roman Yakovenko wrote: > > Where you will setup module name? > > In the constructor of the module builder (and probably with an > appropriate "configuration method", but such a thing is still missing in > the experimental module). There are few reasons I want user to call method "create code creators tree= ". One of them is that I think an user should be aware of code creators tree, at least to the fact that after this call he can not change decl wrapper properties. Second reason I want to guide user through the process: step 1: parse step 2: configure declarations step 3: create code creators step 4: configure them step 5: write module to files. I think every step is important > >> I *am* implementing the experimental module by using the functionality > >> provided by pyplusplus. This has always been the case. I'm not plannin= g > >> on implementing my own code generation tool... :) > > > > Honestly, I don't see reuse of functionality except code creators. > > Decorating the declarations is done using the corresponding methods in > the decl_wrappers. :-), code creators and small part of decl_wrappers, this is not enough. > >> But just because a piece of code is located in another directory doesn= 't > >> mean it is more stable, does it? > > > > Yes it does. I have more then 40 unit testers + 3 projects ( EasyBMP, > > boost.date_time and TnFOX ). > > Well, yes, the unit tests are quite impressive and already a sign of the > quality of the software, but: the unit tests can only test an > implementation, but not the "usability" or how intuitive an interface is. Tomorrow I will commit "select" interface that has been updated according t= o your suggestions. So there will be not much difference in interface. I hope= we will have same level of usability. > >> I never said you should not do a release. I'm in favor of a new releas= e! > >> I'm only arguing that a new release shouldn't mean the end of the > >> experimental module. > > > > Do you plan another revolution in pyplusplus :-)? > > Oh, I wasn't aware there has been a revolution... :) Common, you did it! :-) > > If no I see no point in experimental module. > > Well, it's for experimenting (and sharing that)... ;-) :-) > - Matthias - -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |