I tested it on Windows and on Linux with Ruby CVS-HEAD:
dewd@heaven:~ $ ruby -v
ruby 1.9.0 (2005-05-01) [i686-linux]
Is it on purpose? Because it breaks some code in at least a lib that I
know of (in rakewx.rb from wxRuby).
Dunno...
Additional note: 1.8.2 doesn't show this behavior. But: never trust IRB
when it comes to local variables. Did you also try that in a script or
with ruby -e '...'?
Additional note: 1.8.2 doesn't show this behavior. But: never trust IRB
when it comes to local variables. Did you also try that in a script or
with ruby -e '...'?
This looks like it may be the result of a bug in the new proc calling
feature. If I understand correctly, it translates foo(something) into
foo.call(something) where foo is a local variable. And since "opa"
becomes a local variable in that line, it tries to call it, and finds
it to be nil. I think.
cheers,
Mark
···
On 5/4/05, Robert Klemme <bob.news@gmx.net> wrote:
Joao Pedrosa wrote:
> Hi,
>
> dewd@heaven:~ $ ruby -v
> ruby 1.9.0 (2005-05-01) [i686-linux]
> dewd@heaven:~ $ irb
> irb(main):001:0> def opa s
> irb(main):002:1> 'z'
> irb(main):003:1> end
> => nil
> irb(main):004:0> opa 'kct'
> => "z"
> irb(main):005:0> opa = opa('kct')
> NoMethodError: undefined method `call' for nil:NilClass
> from (irb):5
> irb(main):006:0> exit
> dewd@heaven:~ $
>
> I tested it on Windows and on Linux with Ruby CVS-HEAD:
> dewd@heaven:~ $ ruby -v
> ruby 1.9.0 (2005-05-01) [i686-linux]
>
> Is it on purpose? Because it breaks some code in at least a lib that I
> know of (in rakewx.rb from wxRuby).
Dunno...
Additional note: 1.8.2 doesn't show this behavior. But: never trust IRB
when it comes to local variables. Did you also try that in a script or
with ruby -e '...'?
Isn't that illegal? The name 'opa' has already been defined.
/me pulls out copy of ISO Ruby standard.
/me notices that it's missing.
···
On 5/4/05, David A. Black <dblack@wobblini.net> wrote:
Hi --
On Thu, 5 May 2005, Joe Van Dyk wrote:
> Can someone fill me in on what's going on here?
>
> It looks like the code reads something like:
>
> def opa(s)
> 'z'
> end
>
> So,
> opa('kct')
> should return 'z'.
>
> But I have no idea what
> opa = opa('kct')
> is trying to do.
It's trying to set a local variable called opa to the result of
calling (the method) opa with arg 'kct'.
On 5/4/05, David A. Black <dblack@wobblini.net> wrote:
Hi --
On Thu, 5 May 2005, Joe Van Dyk wrote:
Can someone fill me in on what's going on here?
It looks like the code reads something like:
def opa(s)
'z'
end
So,
opa('kct')
should return 'z'.
But I have no idea what
opa = opa('kct')
is trying to do.
It's trying to set a local variable called opa to the result of
calling (the method) opa with arg 'kct'.
Isn't that illegal? The name 'opa' has already been defined.
That's exactly what Joao is asking Up to 1.8.2, at least, it's
legal: the namespaces for local vars and methods are separate. In
the 1.9 CVS it's behaving as if it's illegal, though the nature of the
error message (and the nature of the change itself) raises the
question of whether the change is intentional.
"Joe Van Dyk" <joevandyk@gmail.com> schrieb im Newsbeitrag news:c715e640505040933dc1a4a9@mail.gmail.com...
Hi --
> Can someone fill me in on what's going on here?
>
> It looks like the code reads something like:
>
> def opa(s)
> 'z'
> end
>
> So,
> opa('kct')
> should return 'z'.
>
> But I have no idea what
> opa = opa('kct')
> is trying to do.
It's trying to set a local variable called opa to the result of
calling (the method) opa with arg 'kct'.
Isn't that illegal? The name 'opa' has already been defined.
IMHO that's perfectly ok as long as all uses are non ambiguous.
/me pulls out copy of ISO Ruby standard.
/me notices that it's missing.
/me too
But that's also ok and fits well with Ruby's dynamic nature. Hint: no static typing, no ISO spec.
Kind regards
robert
···
On 5/4/05, David A. Black <dblack@wobblini.net> wrote:
"Joe Van Dyk" <joevandyk@gmail.com> schrieb im Newsbeitrag news:c715e640505040933dc1a4a9@mail.gmail.com...
/me pulls out copy of ISO Ruby standard.
/me notices that it's missing.
/me too
But that's also ok and fits well with Ruby's dynamic nature. Hint: no static typing, no ISO spec.
You've hit on one of my pet theories about Ruby discourse and
discussion: namely, that the reason so much discussion revolves around
changing Ruby (as opposed to using Ruby) is that people get inspired
by the dynamic nature of Ruby objects and start to see Ruby itself as
such an object. Of course, unlike "def obj.x; end", if some of the
changes we've seen talked about were actually implemented,
Ruby.object_id would cease to return the same number
I've often found myself wishing for a written spec, partly because at
times I've been uneasy about the lack of clarity on what constitutes a
"Ruby interpreter". But Matz isn't interested in doing a spec, I
think, and so far, in spite of my qualms, nothing horrible seems to
have happened.
In message "Re: Bug or on purpose?" on Thu, 5 May 2005 01:42:36 +0900, "David A. Black" <dblack@wobblini.net> writes:
That's exactly what Joao is asking Up to 1.8.2, at least, it's
legal: the namespaces for local vars and methods are separate. In
the 1.9 CVS it's behaving as if it's illegal, though the nature of the
error message (and the nature of the change itself) raises the
question of whether the change is intentional.
>That's exactly what Joao is asking Up to 1.8.2, at least, it's
>legal: the namespaces for local vars and methods are separate. In
>the 1.9 CVS it's behaving as if it's illegal, though the nature of the
>error message (and the nature of the change itself) raises the
>question of whether the change is intentional.
It's intentional. We are in experiment.
Thank you for answering.
You know, I have found at least 3 libraries that have had problems
with this change so far:
- wxRuby - when running the rake command.
- RMagic - installation setup.
- REXML - triggered from the SVG::Graph library (burn).
Here is a sample from "/usr/local/lib/ruby/1.9/rexml/doctype.rb":
corresponding method names, and this is causing the problem to surface
more often than I can bare (even in development mode). I'm
reverting back to the 1.8.2 release from december until a newer
version becomes practical.
Take your time for experimentations. No need to hurry.
BTW, I'm going to the release of december because it seems a little
bit more stable on Windows than the latest 1.8.2 snapshot. So if you
plan on releasing 1.8.3, maybe some tests with VC++ would be welcome.
I see that there were many changes in Makefile.sub and mkmf.rb, for
instance, which may need some more tests on Windows.
Cheers,
Joao
···
From my samples, people give names to variables that have
