[zypp-devel] Re: [zypp-commit] r8131 - in /trunk/sat-solver/bindings: ruby/CMakeLists.txt ruby/ruby.i ruby/satsolver.rb ruby/tests/ ruby/tests/loading.rb ruby/tests/pool.rb ruby/tests/repo.rb satsolver.i
On Thursday 20 December 2007 11:19:47 pm kkaempf@svn.opensuse.org wrote:
Author: kkaempf Date: Thu Dec 20 23:19:47 2007 New Revision: 8131
URL: http://svn.opensuse.org/viewcvs/zypp?rev=8131&view=rev Log: put some love into the bindings
great!
- dont generate everything from .h file, but selectively
Uhm, does that mean we will have to sync by hand?
whats actually needed
what is excluded now?
- add test cases for Ruby bindings
nice :-) Why did you change cxx to .c when the output is actually a C++ source (the OO layer is inlined) Cheers Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
* Duncan Mac-Vicar P.
On Thursday 20 December 2007 11:19:47 pm kkaempf@svn.opensuse.org wrote:
Author: kkaempf Date: Thu Dec 20 23:19:47 2007 New Revision: 8131
URL: http://svn.opensuse.org/viewcvs/zypp?rev=8131&view=rev Log: put some love into the bindings
great!
- dont generate everything from .h file, but selectively
Uhm, does that mean we will have to sync by hand?
Yes, in some parts. The problem with generating from sat-solvers .h files is the vast amount of internal data being exposed. Adapting all sat-solver .h files for 'public' and 'private' data structures might be another approach. But this also needs care, which I currently put into satsolver.i
whats actually needed
what is excluded now?
All the internal structure properties. And it also makes functions real instance methods.
- add test cases for Ruby bindings
nice :-)
Why did you change cxx to .c when the output is actually a C++ source (the OO layer is inlined)
Whats the value of having C++ here ? Please explain. Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Friday 21 December 2007 10:06:02 Klaus Kaempf wrote:
Yes, in some parts. The problem with generating from sat-solvers .h files is the vast amount of internal data being exposed.
We can include the .h files and then add ignore statements to the swig .i file. I guess the amount of things we expose is bgger than the amount of things we want to hide or?
Why did you change cxx to .c when the output is actually a C++ source (the OO layer is inlined) Whats the value of having C++ here ? Please explain.
Oh, SWIG does not generate OO libraries from C APIs for free. I define C++ classes in the .i file which wrap the C methods. Swig parses those classes and generate ruby classes on the fly. Otherwise I would need to have a swig generated C api in ruby and wrap them in ruby code (and have a hybrid extension). Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
* Duncan Mac-Vicar Prett
On Friday 21 December 2007 10:06:02 Klaus Kaempf wrote:
Yes, in some parts. The problem with generating from sat-solvers .h files is the vast amount of internal data being exposed.
We can include the .h files and then add ignore statements to the swig .i file. I guess the amount of things we expose is bgger than the amount of things we want to hide or?
No, its not. Just look at the amount of structure properties in a typical sat solver .h file. I'd rather add specific accessor methods instead of lots of %ignores ;-)
Why did you change cxx to .c when the output is actually a C++ source (the OO layer is inlined) Whats the value of having C++ here ? Please explain.
Oh, SWIG does not generate OO libraries from C APIs for free. I define C++ classes in the .i file which wrap the C methods. Swig parses those classes and generate ruby classes on the fly. Otherwise I would need to have a swig generated C api in ruby and wrap them in ruby code (and have a hybrid extension).
Huh ? I don't understand the part of wrapping in Ruby code. Have a look at the current satsolver.i file and the examples in ruby/tests. I think its pretty straightforward. Adding C++ classes seems more complex to me. But I'm open to any counterexamples ... :-P Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Huh ? I don't understand the part of wrapping in Ruby code. Have a look at the current satsolver.i file and the examples in ruby/tests. I think its pretty straightforward. Adding C++ classes seems more complex to me. But I'm open to any counterexamples ... :-P
C++ classes have been always there! since my first version. %extend Pool { Pool() { return pool_create(); } ~Pool() { pool_free($self); } That adds methods to the C struct. So SWIG is not parsing a C struct anymore but a C++ class. That is why the ruby pool class has member functions, constructors etc, otherwise you would get a plain C struct in Ruby (unless we wrap/extend them in pure ruby code). Where I am wrong is that even if SWIG is parsing C++, the output extension can be plain C I guess. I am not sure. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
* Duncan Mac-Vicar Prett
Huh ? I don't understand the part of wrapping in Ruby code. Have a look at the current satsolver.i file and the examples in ruby/tests. I think its pretty straightforward. Adding C++ classes seems more complex to me. But I'm open to any counterexamples ... :-P
C++ classes have been always there! since my first version.
%extend Pool { Pool() { return pool_create(); } ~Pool() { pool_free($self); }
That adds methods to the C struct. So SWIG is not parsing a C struct anymore but a C++ class. That is why the ruby pool class has member functions, constructors etc, otherwise you would get a plain C struct in Ruby (unless we wrap/extend them in pure ruby code).
Ahh, now I get it. Well, as you can see from the current .i file, this also works just fine with C. Actually, I stumbled over this too on my first tries yesterday. Then I learned about the difference between wrapper code (copied to the output wrapper) and interface description (parsed by swig to learn how to generate the wrapper). So the above Pool 'constructor' and 'destructor' are in fact not(!) C++ but the interface description for SWIG how to allocate and free instances of 'Pool'.
Where I am wrong is that even if SWIG is parsing C++, the output extension can be plain C I guess. I am not sure.
Just look at the currnet satsolver.i file. It has lots of %nodefault to suppress swig autogenerated alloc/free bindings. Instead, you can see pseudo-C++ to teach swig about instance allocation/deallocation. And its all pure C ;-) Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (3)
-
Duncan Mac-Vicar P. -
Duncan Mac-Vicar Prett
-
Klaus Kaempf