Hi
Have been looking again at SWIG output pointer parameters, as:
http://www.swig.org/Doc1.3/Ruby.html#Ruby_nn32
The problem is, whenever I tried to include the SWIG/Ruby
''typemaps.i''
file, it threw loads of errors.
A bit more investigation pinned the problem down to some secondary files
that typemaps.i includes to map ''special'' types like File.
So I tried just copying the section from SWIG''s ruby/typemaps.i that
deals with output, input and inout mapping of simple types like int,
long etc. It''s attached. I pasted this into our own swig/typemap.i file
and recompiled.
And it seems to work. For example, with Wx::Window#get_text_extent, I
added the directives
%apply int *OUTPUT { int* x , int* y , int* descent, int*
externalLeading};
%apply wxFont *INPUT { const wxFont* font };
And then the method correctly returns a four-element array containing
width, height, descent and leading. I also tried
Wx::TextCtrl#position_to_xy.
This could help us fix quite a few useful methods, but I''m not sure if
this is generally the right approach (block-copying from typemaps.i to
our typemap.i).
If it sounds right, let me know and I''ll generate proper patches and
send them in.
cheers
alex
_______________________________________________
wxruby-users mailing list
wxruby-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/wxruby-users
On Wed, 2006-04-12 at 14:17 +0100, Alex Fenton wrote:> Hi > > Have been looking again at SWIG output pointer parameters, as: > http://www.swig.org/Doc1.3/Ruby.html#Ruby_nn32Excellent! This is going to be really important for wxruby.> The problem is, whenever I tried to include the SWIG/Ruby ''typemaps.i'' > file, it threw loads of errors. > > A bit more investigation pinned the problem down to some secondary files > that typemaps.i includes to map ''special'' types like File. > > So I tried just copying the section from SWIG''s ruby/typemaps.i that > deals with output, input and inout mapping of simple types like int, > long etc. It''s attached. I pasted this into our own swig/typemap.i file > and recompiled.(snip)> This could help us fix quite a few useful methods, but I''m not sure if > this is generally the right approach (block-copying from typemaps.i to > our typemap.i). > > If it sounds right, let me know and I''ll generate proper patches and > send them in.I really don''t want copied code. Is there any hope of fixing the compile errors in ruby/typemaps.i? That seems like the "right" solution. If not, I wonder if we could have a little script that copies ruby/typemaps.i into our swig directory, and then comments out the offending includes? That way, at least, we would automatically gain the benefits of any improvements by the swig folks. Can you take a stab at those compile errors, and post any specific messages that you have trouble working around? Thanks, Kevin
Kevin Smith wrote:> I really don''t want copied code. Is there any hope of fixing the compile > errors in ruby/typemaps.i? That seems like the "right" solution.Fair enough, I agree with your rationale. There''s no chance I can fix it, but every chance someone else here can ;) If SWIG''s ''typemap.i''file'' is properly %included, it includes SWIG ''file.i'', which starts with #ifdef __cplusplus extern "C" { #endif #include "rubyio.h" #ifdef __cplusplus } #endif This turns up in App.cpp (for example), and causes the compile to fail with a lot of errors like: /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:30: error: parse error before `('' token In file included from src/App.cpp:1591: /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:30:46: pasting "L" and "(" does not give a valid preprocessing token /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:64: error: syntax error before `('' token /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:64:44: pasting "L" and "(" does not give a valid preprocessing token /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:65: error: syntax error before `('' token cheers alex
Sorry if any of the comments below are too obvious, but ... In message <443F6ECD.3040007 at pressure.to>, Alex Fenton <alex at pressure.to> writes>Kevin Smith wrote: >> I really don''t want copied code. Is there any hope of fixing the compile >> errors in ruby/typemaps.i? That seems like the "right" solution. >Fair enough, I agree with your rationale. There''s no chance I can fix >it, but every chance someone else here can ;) > >If SWIG''s ''typemap.i''file'' is properly %included, it includes SWIG >''file.i'', which starts with > >#ifdef __cplusplus >extern "C" { >#endif >#include "rubyio.h" >#ifdef __cplusplus >} >#endif >This is a fairly standard approach for being able to link C++ code to compiled C functions. Where it is embedded in C/C++ code, when the preprocessor detects that this source is being compiled as C++ (via the __cplusplus symbol0, the contents of rubio.h are bracketed by: extern "C" { ... } This allows functions declared in this .h file to be known as C functions, and callable from the C++.>This turns up in App.cpp (for example), and causes the compile to fail >with a lot of errors like: > >/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:30: error: parse error > before `('' token >In file included from src/App.cpp:1591: >/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:30:46: pasting "L" >and "(" does not give a valid preprocessing token >/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:64: error: syntax >error > before `('' token >/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:64:44: pasting "L" >and "(" does not give a valid preprocessing token >/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:65: error: syntax >error > before `('' token >The message about "L(" being an invalid token seems correct to me; and I don''t see how the extern "C" ... above could cause this, other than letting the build process continue until it hits this problem. (On the face of it, a macro token pasting one.) Not much, I know, but HTH. Regards, Alec -- Alec Ross
Alex Fenton wrote:> If SWIG''s ''typemap.i''file'' is properly %included, it includes SWIG > ''file.i'', which starts with > > #ifdef __cplusplus > extern "C" { > #endif > #include "rubyio.h" > #ifdef __cplusplus > } > #endif > > This turns up in App.cpp (for example), and causes the compile to fail > with a lot of errors like: > > /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:30: error: parse error > before `('' token > In file included from src/App.cpp:1591: > /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:30:46: pasting "L" > and "(" does not give a valid preprocessing token > /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:64: error: syntax > error > before `('' token > /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:64:44: pasting "L" > and "(" does not give a valid preprocessing token > /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:65: error: syntax > error > before `('' token > > cheers > alexMaybe the _ macro isn''t defined like it should be. Could you try a #include "defines.h" before #include "rubyio.h" in file.i? Robin Stocker
Robin, Alec, thanks for the suggestions - I don''t know c++ so no insight''s too obvious. Robin Stocker wrote:> Maybe the _ macro isn''t defined like it should be. Could you try a > #include "defines.h" before #include "rubyio.h" in file.i? >I just tried adding #include "defines.h" to file.i, but the compile still fails with the same error. I''ve posted a query to SWIG mailing list to see if this looks familiar to anyone there. alex
> Maybe the _ macro isn''t defined like it should be. >I don''t know if this has anything to do with it, but WxWidgets includes a _ macro for internationalisation http://www.wxwidgets.org/manuals/2.6.3/wx_stringfunctions.html#underscore alex