FXRuby issue

Lyle_Johnson4 · 14 November 2002 00:35

I had to patch responder2.rb and responder.rb to make Fox work on my
machine:

responder2.rb:

36. @pseudoTarget = Fox::FXPseudoTarget.new

Yes, this one I'm OK with.

responder.rb:

7. include Fox

No; doing this would pollute the global namespace (more on that in a
moment). A better solution is to use the fully-qualified names for the
various Fox module-level methods and constants that the Responder module
methods need, e.g. this code:

  # Define range of function types
  def FXMAPTYPES(typelo, typehi, func)
    addMapEntry(MKUINT(MINKEY, typelo),
                MKUINT(MAXKEY, typehi),
                func)
  end

becomes:

  # Define range of function types
  def FXMAPTYPES(typelo, typehi, func)
    addMapEntry(Fox::MKUINT(Fox::MINKEY, typelo),
                Fox::MKUINT(Fox::MAXKEY, typehi),
                func)
  end

I did a little digging to try to understand why FXRuby worked the way it did
in version 1.0.13 and what changed in version 1.0.14, and I think it all
boils down to some changes made to 'responder2.rb'. For some time (i.e. at
least in version 1.0.13 and perhaps earlier) it has been true that when you
require the 'fox' feature:

require 'fox'

it was also requiring some of the FXRuby library modules, and in particular
it was doing:

require 'fox/responder2'

Now for FXRuby-1.0.13, the beginning of 'responder2.rb' looked like this:

    require 'fox'
    require 'fox/responder'

    include Fox

and that last line was the culprit: it was dumping *everything* from the Fox
module into the global namespace, which kinda defeats the purpose of having
put those things into their own module in the first place. This code was
changed in version 1.0.14, where 'responder2.rb' no longer "include"-s the
Fox module into the global namespace.

So the behavior in FXRuby versions 1.0.14 (and later) is "safer" in the
sense that none of the stuff from the Fox module should ever escape into the
global namespace unless you explicitly make it so (i.e. by doing an 'include
Fox' at the top level). Since this is the behavior you were relying on, is
it possible to just modify the affected FreeRIDE file(s) to do an 'include
Fox' immediately after they require 'fox'? [I realize that I am asking this
question without knowing how many source files we're talking about.] Making
this change to the FreeRIDE sources would have the consequence that
everything from the Fox module will get dumped into the global namespace --
but that's what was happening *anyways* when you were running with FXRuby
1.0.13

···

On Wed, 13 Nov 2002 15:07:41 -0500, "Rich Kilmer" <rich@infoether.com> wrote :

Rich_Kilmer · 14 November 2002 01:43

Lyle,

I already made this change to FreeRIDE this afternoon. Every class that
uses Fox constants now specifically includes Fox. I agree that this is
better/safer from a namespace perspective. Are you going to patch
FXRuby with the changes I/you list here (explicit reference to Fox:: in
responder.rb and responder2.rb)?

Thanks for always being so supportive!

Regards,

Rich

···

-----Original Message-----
From: lyle@knology.net [mailto:lyle@knology.net]
Sent: Wednesday, November 13, 2002 7:35 PM
To: rich@infoether.com
Cc: ruby-talk@ruby-lang.org
Subject: Re: FXRuby issue

On Wed, 13 Nov 2002 15:07:41 -0500, "Rich Kilmer" > <rich@infoether.com> wrote :

> I had to patch responder2.rb and responder.rb to make Fox work on my
> machine:
>
> responder2.rb:
>
> 36. @pseudoTarget = Fox::FXPseudoTarget.new

Yes, this one I'm OK with.

> responder.rb:
>
> 7. include Fox

No; doing this would pollute the global namespace (more on
that in a moment). A better solution is to use the
fully-qualified names for the various Fox module-level
methods and constants that the Responder module methods need,
e.g. this code:

  # Define range of function types
  def FXMAPTYPES(typelo, typehi, func)
    addMapEntry(MKUINT(MINKEY, typelo),
                MKUINT(MAXKEY, typehi),
                func)
  end

becomes:

  # Define range of function types
  def FXMAPTYPES(typelo, typehi, func)
    addMapEntry(Fox::MKUINT(Fox::MINKEY, typelo),
                Fox::MKUINT(Fox::MAXKEY, typehi),
                func)
  end

I did a little digging to try to understand why FXRuby worked
the way it did in version 1.0.13 and what changed in version
1.0.14, and I think it all boils down to some changes made to
'responder2.rb'. For some time (i.e. at least in version
1.0.13 and perhaps earlier) it has been true that when you
require the 'fox' feature:

    require 'fox'

it was also requiring some of the FXRuby library modules, and
in particular it was doing:

    require 'fox/responder2'

Now for FXRuby-1.0.13, the beginning of 'responder2.rb'
looked like this:

    require 'fox'
    require 'fox/responder'

    include Fox

and that last line was the culprit: it was dumping
*everything* from the Fox module into the global namespace,
which kinda defeats the purpose of having put those things
into their own module in the first place. This code was
changed in version 1.0.14, where 'responder2.rb' no longer
"include"-s the Fox module into the global namespace.

So the behavior in FXRuby versions 1.0.14 (and later) is
"safer" in the sense that none of the stuff from the Fox
module should ever escape into the global namespace unless
you explicitly make it so (i.e. by doing an 'include Fox' at
the top level). Since this is the behavior you were relying
on, is it possible to just modify the affected FreeRIDE
file(s) to do an 'include Fox' immediately after they require
'fox'? [I realize that I am asking this question without
knowing how many source files we're talking about.] Making
this change to the FreeRIDE sources would have the
consequence that everything from the Fox module will get
dumped into the global namespace -- but that's what was
happening *anyways* when you were running with FXRuby 1.0.13

Rich_Kilmer · 14 November 2002 01:49

One other one in responder2.rb:

SELTYPE(sel) needs to be Fox::SELTYPE(sel)

-rich

···

-----Original Message-----
From: Rich Kilmer [mailto:rich@infoether.com]
Sent: Wednesday, November 13, 2002 8:43 PM
To: ruby-talk ML; lyle@knology.net
Cc: ruby-talk@ruby-lang.org
Subject: Re: FXRuby issue

Lyle,

I already made this change to FreeRIDE this afternoon. Every
class that uses Fox constants now specifically includes Fox.
I agree that this is better/safer from a namespace
perspective. Are you going to patch FXRuby with the changes
I/you list here (explicit reference to Fox:: in responder.rb
and responder2.rb)?

Thanks for always being so supportive!

Regards,

Rich
-----Original Message-----
From: lyle@knology.net [mailto:lyle@knology.net]
Sent: Wednesday, November 13, 2002 7:35 PM
To: rich@infoether.com
Cc: ruby-talk@ruby-lang.org
Subject: Re: FXRuby issue

On Wed, 13 Nov 2002 15:07:41 -0500, “Rich Kilmer” > > rich@infoether.com wrote :

I had to patch responder2.rb and responder.rb to make Fox
work on my
machine:

responder2.rb:

@pseudoTarget = Fox::FXPseudoTarget.new

Yes, this one I’m OK with.

responder.rb:

include Fox

No; doing this would pollute the global namespace (more on
that in a moment). A better solution is to use the
fully-qualified names for the various Fox module-level
methods and constants that the Responder module methods need,
e.g. this code:

Define range of function types

def FXMAPTYPES(typelo, typehi, func)
addMapEntry(MKUINT(MINKEY, typelo),
MKUINT(MAXKEY, typehi),
func)
end

becomes:

Define range of function types

def FXMAPTYPES(typelo, typehi, func)
addMapEntry(Fox::MKUINT(Fox::MINKEY, typelo),
Fox::MKUINT(Fox::MAXKEY, typehi),
func)
end

I did a little digging to try to understand why FXRuby worked
the way it did in version 1.0.13 and what changed in version
1.0.14, and I think it all boils down to some changes made to
‘responder2.rb’. For some time (i.e. at least in version
1.0.13 and perhaps earlier) it has been true that when you
require the ‘fox’ feature:
require 'fox'
it was also requiring some of the FXRuby library modules, and
in particular it was doing:
require 'fox/responder2'
Now for FXRuby-1.0.13, the beginning of ‘responder2.rb’
looked like this:
require 'fox'
require 'fox/responder'

include Fox
and that last line was the culprit: it was dumping
everything from the Fox module into the global namespace,
which kinda defeats the purpose of having put those things
into their own module in the first place. This code was
changed in version 1.0.14, where ‘responder2.rb’ no longer
“include”-s the Fox module into the global namespace.

So the behavior in FXRuby versions 1.0.14 (and later) is
“safer” in the sense that none of the stuff from the Fox
module should ever escape into the global namespace unless
you explicitly make it so (i.e. by doing an ‘include Fox’ at
the top level). Since this is the behavior you were relying
on, is it possible to just modify the affected FreeRIDE
file(s) to do an ‘include Fox’ immediately after they require
‘fox’? [I realize that I am asking this question without knowing how many source files we’re talking about.] Making
this change to the FreeRIDE sources would have the
consequence that everything from the Fox module will get
dumped into the global namespace – but that’s what was
happening anyways when you were running with FXRuby 1.0.13

Lyle_Johnson6 · 14 November 2002 14:39

Rich Kilmer wrote:

I already made this change to FreeRIDE this afternoon. Every class that
uses Fox constants now specifically includes Fox. I agree that this is
better/safer from a namespace perspective. Are you going to patch
FXRuby with the changes I/you list here (explicit reference to Fox:: in
responder.rb and responder2.rb)?

I have made those patches in the CVS, but am I correct that since you’ve
changed FreeRIDE that it’s no longer a showstopper? In other words, will
FreeRIDE will now work with FXRuby 1.0.15 as released (with the
unpatched versions of responder.rb and responder2.rb)?

Thanks for always being so supportive!

Thanks for helping me get this cleared up. I’m looking forward to the
first FreeRIDE release.

Rich_Kilmer · 14 November 2002 14:46

From: Lyle Johnson [mailto:lyle@users.sourceforge.net]
Sent: Thursday, November 14, 2002 9:40 AM
To: ruby-talk ML
Subject: Re: FXRuby issue

Rich Kilmer wrote:

I already made this change to FreeRIDE this afternoon. Every class
that uses Fox constants now specifically includes Fox. I
agree that
this is better/safer from a namespace perspective. Are you
going to
patch FXRuby with the changes I/you list here (explicit
reference to
Fox:: in responder.rb and responder2.rb)?

I have made those patches in the CVS, but am I correct that
since you’ve
changed FreeRIDE that it’s no longer a showstopper? In other
words, will
FreeRIDE will now work with FXRuby 1.0.15 as released (with the
unpatched versions of responder.rb and responder2.rb)?

I did add the ‘include Fox’ everywhere I use Fox which solved that
problem. But I actually get a lot of exceptions without the patched
responder files. The responder code itself does not have Fox in its
namespace (since they are root modules like Fox) so I added the explicit
references and let FreeRIDE folks know. I believe this will be a
problem for everyone (or at least it should be). If its not, I don’t
understand why. Andy wants to do a distribution on win32 and before he
uses 1.0.15 you may want to make sure other people are not having any
problems with the responder code as shipped.

Thanks for always being so supportive!

Thanks for helping me get this cleared up. I’m looking forward to the
first FreeRIDE release.

Me too

···

-----Original Message-----

Lyle_Johnson6 · 14 November 2002 15:00

Rich Kilmer wrote:

One other one in responder2.rb:

SELTYPE(sel) needs to be Fox::SELTYPE(sel)

Yup, got it.

Topic		Replies	Views
Where to download FXRuby library; where to put it; RUBYLIB, RUBYPATH env. vars ruby-talk	13	113	28 May 2004
FXRuby 1.2.0 / Fox 1.2.6 ruby-talk	4	143	11 July 2004
FXRuby 1.2.6 using rubygems ruby-talk	10	146	3 May 2005
Fox vs Fox12 ruby-talk	6	70	28 March 2005
Problem with gem or ruby 1.8.5 or fxruby or maybe 64bit? ruby-talk	3	157	6 September 2006

FXRuby issue

Define range of function types

Define range of function types

Related topics