wxruby users - Aug 2006 - typemap.i patch

This patch adds %directorout typemaps for the GetTextExtent functions


_______________________________________________
wxruby-users mailing list
wxruby-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/wxruby-users

On Thu, 2006-08-24 at 17:51 -0400, Roy Sutton wrote:
> This patch adds %directorout typemaps for the GetTextExtent functions
Applied, thanks. 

I also uncommented the %ignore for DC#get_text_extent. That allows
bigdemo''s wxScrolledWindow page to get a bit farther, but now it chokes
because the first parameter to draw_lines is an array which needs to get
mapped to a wxList* in typemaps.i.


A couple questions/comments:
> +%typemap(directorargout) ( int * x , int * y , int * descent, int *
externalLeading ) {
> +  if((TYPE(result) == T_ARRAY) && (RARRAY(result)->len >=
2))
What if an array is not returned, or if the returned array length is
less than 2? Should we handle the case, by throwing or returning NULL or
something?
> +  {
> +    *$1 = ($*1_ltype)NUM2INT(rb_ary_entry(result,0));
I don''t remember seeing $*1_ltype before. It''s a bit jarring
seeing it
on the same line as *$1. I don''t know enough to suggest anything, but
if
you can think of a way to make those lines easier to understand, that
would be great.
> +    *$2 = ($*2_ltype)NUM2INT(rb_ary_entry(result,1));
> +    if(($3 != NULL) && RARRAY(result)->len >= 3)
> +      *$3 = ($*3_ltype)NUM2INT(rb_ary_entry(result,2));
> +    if(($4 != NULL) && RARRAY(result)->len >= 4)
> +      *$4 = ($*4_ltype)NUM2INT(rb_ary_entry(result,3));
> +  }
> +}
Kevin

Kevin Smith wrote:
> I also uncommented the %ignore for DC#get_text_extent. That allows
> bigdemo''s wxScrolledWindow page to get a bit farther, but now it
chokes
> because the first parameter to draw_lines is an array which needs to get
> mapped to a wxList* in typemaps.i.
>   
Excellent!  I didn''t even see that was missing.
>> +%typemap(directorargout) ( int * x , int * y , int * descent, int *
externalLeading ) {
>> +  if((TYPE(result) == T_ARRAY) && (RARRAY(result)->len
>= 2))
>>     
>
> What if an array is not returned, or if the returned array length is
> less than 2? Should we handle the case, by throwing or returning NULL or
> something?
>   
Well, it really -has- to return at least two items in an array or it''s 
not correct.  99.999% of the time no one will -ever- override this 
function so it''s really academic.  I don''t have a good
suggestion for
what to do.  Any value you pull out of thin air will be wrong.  Throwing 
is probably the correct thing to do.  I decided to just leave the old 
values untouched.
>> +  {
>> +    *$1 = ($*1_ltype)NUM2INT(rb_ary_entry(result,0));
>>     
>
> I don''t remember seeing $*1_ltype before. It''s a bit
jarring seeing it
> on the same line as *$1. I don''t know enough to suggest anything,
but if
> you can think of a way to make those lines easier to understand, that
> would be great.
>   
If there was something to make typemaps easier to read I''d be all over 
it.  Typemaps just drive me nuts.  I feel like they''re just black magic
sometimes.  I feel like a really hacker when I work on them.  I got this 
from looking through the docs and included files.  If you think a 
comment would be helpful I think that''s the only thing that would make 
these better.

Roy

On Fri, 2006-08-25 at 00:29 -0400, Roy Sutton wrote:
> If there was something to make typemaps easier to read I''d be all
over
> it.  Typemaps just drive me nuts.  I feel like they''re just black
magic
> sometimes.  I feel like a really hacker when I work on them.  I got this 
> from looking through the docs and included files.  If you think a 
> comment would be helpful I think that''s the only thing that would
make
> these better.
The whole API for typemaps is horribly flawed. I wonder if we could hide
at least some of it by auto-generating our typemap.i from ruby code. If
we could declaratively say something like "wxList is the same as a Ruby
Array", and "wxString is the same as a Ruby String", it could
build all
the necessary typemaps automatically. It could automatically handle all
the const, reference&, and other cases.

That would be another cool little pure ruby task for someone. If anyone
wants to volunteer, let us know and we can probably write up a little
spec.

To start with, we would want to have a mix of automated typemaps and
hand-coded. Over time, hopefully the hand-coded portion would approach,
if not reach, emptyness.

Kevin

That is a very good idea! I have always hatted the typemap voodoo, it
is too easy to mess it up with one or two changes of a single
character.

I hope someone has the time to pursue this task, I would if I had the time.

Sean

On 8/25/06, Kevin Smith <wxruby at qualitycode.com>
wrote:
> On Fri, 2006-08-25 at 00:29 -0400, Roy Sutton wrote:
> > If there was something to make typemaps easier to read I''d be
all over
> > it.  Typemaps just drive me nuts.  I feel like they''re just
black magic
> > sometimes.  I feel like a really hacker when I work on them.  I got
this
> > from looking through the docs and included files.  If you think a
> > comment would be helpful I think that''s the only thing that
would make
> > these better.
>
> The whole API for typemaps is horribly flawed. I wonder if we could hide
> at least some of it by auto-generating our typemap.i from ruby code. If
> we could declaratively say something like "wxList is the same as a
Ruby
> Array", and "wxString is the same as a Ruby String", it
could build all
> the necessary typemaps automatically. It could automatically handle all
> the const, reference&, and other cases.
>
> That would be another cool little pure ruby task for someone. If anyone
> wants to volunteer, let us know and we can probably write up a little
> spec.
>
> To start with, we would want to have a mix of automated typemaps and
> hand-coded. Over time, hopefully the hand-coded portion would approach,
> if not reach, emptyness.
>
> Kevin
>
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>