wxruby users - Jul 2011 - Enable input and Ruby true/false semantics

I''m working on enabling/disabling controls, and I keep getting
exceptions like the following:

mysource.rb:262:in `enable'': Expected argument 1 of type bool, but got
NilClass nil (TypeError)
        in SWIG method ''Enable''
        from mysource.rb:262
        from
C:/Ruby187/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-mingw32/lib/wx/classe
s/app.rb:16:in `call''
        from
C:/Ruby187/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-mingw32/lib/wx/classe
s/app.rb:16:in `process_event''
        from
C:/Ruby187/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-mingw32/lib/wx/classe
s/app.rb:16:in `on_run''
        from
C:/Ruby187/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-mingw32/lib/wx/classe
s/app.rb:16:in `main_loop''
        from
C:/Ruby187/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-mingw32/lib/wx/classe
s/app.rb:16:in `run''
        from app.rb:188

Is there an (easy) way to help WxRuby follow Ruby''s notion of truth,
i.e. everything but +nil+ and +false+ are true?

The current best workaround I have is 

  enable(... ? true : false)

but that''s clunky, and I obviously keep forgetting to use it. :-)

Thanks!

---
Ryan Hinton
L-3 Communications / Communication Systems West
ryan.w.hinton@L-3com.com

Hi Ryan

[list generally - I''ve had problems receiving wxruby-users posts in the
past month - apologies for any missed discussions]

On 02/07/2011 00:10, ryan.w.hinton at L-3com.com wrote:
> I''m working on enabling/disabling controls, and I keep getting
> exceptions like the following:
>
> mysource.rb:262:in `enable'': Expected argument 1 of type bool, but
got
> NilClass nil (TypeError)
>          in SWIG method ''Enable''
>          from mysource.rb:262
>          from
These exceptions come from SWIG''s default way of wrapping C/C++ methods
that require a C boolean type.
>
> Is there an (easy) way to help WxRuby follow Ruby''s notion of
truth,
> i.e. everything but +nil+ and +false+ are true?
>
> The current best workaround I have is
>
>    enable(... ? true : false)
>
> but that''s clunky, and I obviously keep forgetting to use it. :-)
Globally, it could be changed by altering the standard way that wxRuby 
SWIG translates methods that require a boolean. It is a pretty simple 
%typemap statement but obviously requires the whole SWIG+compiler 
set-up. However it''s a change I''d be open to adding for future
versions,
as I think SWIG''s approach is sometimes too class-strict for Ruby
style.

For the time being, the only way would be either to add your workaround 
to a subclass of the control, so that its enable method looked like 
super(input ? true : false). Or you could do some reflection and find 
methods called ''enable'' in all wxRuby classes at start-up and
redefine
them. But from experience (at least with Ruby 1.8) it does take a little 
time to cycle through all the 200+ classes.

best
alex

-----Original Message-----
Date: Mon, 04 Jul 2011 10:51:08 +0100
From: Alex Fenton <alex at pressure.to>
To: General discussion of wxRuby <wxruby-users at rubyforge.org>
Subject: Re: [wxruby-users] Enable input and Ruby true/false semantics
Message-ID: <4E118D0C.4020605 at pressure.to>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Hi Ryan
> 
> [list generally - I''ve had problems receiving wxruby-users posts
in
the 
> past month - apologies for any missed discussions]
> 
> On 02/07/2011 00:10, ryan.w.hinton at L-3com.com wrote:
> > I''m working on enabling/disabling controls, and I keep
getting
> > exceptions like the following:
> >
> > mysource.rb:262:in `enable'': Expected argument 1 of type
bool, but
got
> > NilClass nil (TypeError)
> >          in SWIG method ''Enable''
> >          from mysource.rb:262
> >          from
> 
> These exceptions come from SWIG''s default way of wrapping C/C++
methods 
> that require a C boolean type.
> 
> >
> > Is there an (easy) way to help WxRuby follow Ruby''s notion of
truth,
> > i.e. everything but +nil+ and +false+ are true?
> >
> > The current best workaround I have is
> >
> >    enable(... ? true : false)
> >
> > but that''s clunky, and I obviously keep forgetting to use it.
:-)
> 
> Globally, it could be changed by altering the standard way that wxRuby
> SWIG translates methods that require a boolean. It is a pretty simple 
> %typemap statement but obviously requires the whole SWIG+compiler 
> set-up. However it''s a change I''d be open to adding for
future
versions, 
> as I think SWIG''s approach is sometimes too class-strict for Ruby
style.

I''m already a bit over-budget; I won''t have time to set up the
full
environment now.  Is there a bug-tracking system I can enter this as an
enhancement request?
> For the time being, the only way would be either to add your
workaround 
> to a subclass of the control, so that its enable method looked like 
> super(input ? true : false). Or you could do some reflection and find 
> methods called ''enable'' in all wxRuby classes at start-up
and redefine
> them. But from experience (at least with Ruby 1.8) it does take a
little 
> time to cycle through all the 200+ classes.
That''s a good idea.  For now I''ll override Window#enable, and
that
should take care of it for my use.

Thanks!

- Ryan

> I''m already a bit over-budget; I won''t have time to set
up the full
> environment now.  Is there a bug-tracking system I can enter this as an
> enhancement request?
http://rubyforge.org/tracker/?atid=221&group_id=35&func=browse

cheers
alex

Alex:

Thanks for the RubyForge tracker pointer.  I''ll add this to the list.

FYI, I just squashed a related bug.  I was returning +nil+ when a
drag-drop operation failed, and it would crash my application.  I just
added the 

<expression> ? true : false

trick on my return value, and the crash is gone.  I assume the SWIG
solution would handle this case, too.

Thanks!

- Ryan

-----Original Message-----
Date: Mon, 04 Jul 2011 10:51:08 +0100
From: Alex Fenton <alex at pressure.to>
To: General discussion of wxRuby <wxruby-users at rubyforge.org>
Subject: Re: [wxruby-users] Enable input and Ruby true/false semantics
Message-ID: <4E118D0C.4020605 at pressure.to>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Hi Ryan
> 
> [list generally - I''ve had problems receiving wxruby-users posts
in
the 
> past month - apologies for any missed discussions]
> 
> On 02/07/2011 00:10, ryan.w.hinton at L-3com.com wrote:
> > I''m working on enabling/disabling controls, and I keep
getting
> > exceptions like the following:
> >
> > mysource.rb:262:in `enable'': Expected argument 1 of type
bool, but
got
> > NilClass nil (TypeError)
> >          in SWIG method ''Enable''
> >          from mysource.rb:262
> >          from
> 
> These exceptions come from SWIG''s default way of wrapping C/C++
methods 
> that require a C boolean type.
> 
> >
> > Is there an (easy) way to help WxRuby follow Ruby''s notion of
truth,
> > i.e. everything but +nil+ and +false+ are true?
> >
> > The current best workaround I have is
> >
> >    enable(... ? true : false)
> >
> > but that''s clunky, and I obviously keep forgetting to use it.
:-)
> 
> Globally, it could be changed by altering the standard way that wxRuby
> SWIG translates methods that require a boolean. It is a pretty simple 
> %typemap statement but obviously requires the whole SWIG+compiler 
> set-up. However it''s a change I''d be open to adding for
future
versions, 
> as I think SWIG''s approach is sometimes too class-strict for Ruby
style.

I''m already a bit over-budget; I won''t have time to set up the
full
environment now.  Is there a bug-tracking system I can enter this as an
enhancement request?
> For the time being, the only way would be either to add your
workaround 
> to a subclass of the control, so that its enable method looked like 
> super(input ? true : false). Or you could do some reflection and find 
> methods called ''enable'' in all wxRuby classes at start-up
and redefine
> them. But from experience (at least with Ruby 1.8) it does take a
little 
> time to cycle through all the 200+ classes.
That''s a good idea.  For now I''ll override Window#enable, and
that
should take care of it for my use.

Thanks!

- Ryan

On 05/07/11 22:18, ryan.w.hinton at L-3com.com wrote:
> FYI, I just squashed a related bug.  I was returning +nil+ when a
> drag-drop operation failed, and it would crash my application.  I just
> added the
>
> <expression>  ? true : false
>
> trick on my return value, and the crash is gone.  I assume the SWIG
> solution would handle this case, too.
Thanks for the info. Standard SWIG covers straightforward cases (e.g. 
Ruby arguments to C++ methods). Some stuff like drag-drop where C++ code 
calls Ruby then back to C++ is more tricky and there may be unsafe 
conversions. So it would be great if you could add a couple of details 
in a bug report.

alex

On Tue, Jul 5, 2011 at 5:18 PM, <ryan.w.hinton at l-3com.com> wrote:
> Alex:
>
> Thanks for the RubyForge tracker pointer.  I''ll add this to the
list.
>
> FYI, I just squashed a related bug.  I was returning +nil+ when a
> drag-drop operation failed, and it would crash my application.  I just
> added the
>
> <expression> ? true : false
>
> trick on my return value, and the crash is gone.  I assume the SWIG
> solution would handle this case, too.
>
> Thanks!
>
> - Ryan
>
> -----Original Message-----
> Date: Mon, 04 Jul 2011 10:51:08 +0100
> From: Alex Fenton <alex at pressure.to>
> To: General discussion of wxRuby <wxruby-users at rubyforge.org>
> Subject: Re: [wxruby-users] Enable input and Ruby true/false semantics
> Message-ID: <4E118D0C.4020605 at pressure.to>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> > Hi Ryan
> >
> > [list generally - I''ve had problems receiving wxruby-users
posts in
> the
> > past month - apologies for any missed discussions]
> >
> > On 02/07/2011 00:10, ryan.w.hinton at L-3com.com wrote:
> > > I''m working on enabling/disabling controls, and I keep
getting
> > > exceptions like the following:
> > >
> > > mysource.rb:262:in `enable'': Expected argument 1 of type
bool, but
> got
> > > NilClass nil (TypeError)
> > >          in SWIG method ''Enable''
> > >          from mysource.rb:262
> > >          from
> >
> > These exceptions come from SWIG''s default way of wrapping
C/C++
> methods
> > that require a C boolean type.
> >
> > >
> > > Is there an (easy) way to help WxRuby follow Ruby''s
notion of truth,
> > > i.e. everything but +nil+ and +false+ are true?
> > >
> > > The current best workaround I have is
> > >
> > >    enable(... ? true : false)
> > >
> > > but that''s clunky, and I obviously keep forgetting to
use it. :-)
> >
> > Globally, it could be changed by altering the standard way that wxRuby
>
> > SWIG translates methods that require a boolean. It is a pretty simple
> > %typemap statement but obviously requires the whole SWIG+compiler
> > set-up. However it''s a change I''d be open to adding
for future
> versions,
> > as I think SWIG''s approach is sometimes too class-strict for
Ruby
> style.
>
> I''m already a bit over-budget; I won''t have time to set
up the full
> environment now.  Is there a bug-tracking system I can enter this as an
> enhancement request?
>
> > For the time being, the only way would be either to add your
> workaround
> > to a subclass of the control, so that its enable method looked like
> > super(input ? true : false). Or you could do some reflection and find
> > methods called ''enable'' in all wxRuby classes at
start-up and redefine
>
> > them. But from experience (at least with Ruby 1.8) it does take a
> little
> > time to cycle through all the 200+ classes.
>
> That''s a good idea.  For now I''ll override Window#enable,
and that
> should take care of it for my use.
>
> Thanks!
>
> - Ryan
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>

I realize I''m a bit late and not really solving the core issue, but:
one of
the common ways to approach forcing a boolean datatype, in the rails world
at least, is to double up your boolean not operators: !!<expression>.
It''s a
little weird looking at first but gets the same results as (<expression> ?
true : false) with less typing.

--Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/wxruby-users/attachments/20110711/505a45de/attachment.html>