pathname.rb:270: warning: `*' interpreted as argument prefix

  • Thread starter R.. Kumar 1.9.1 OSX
  • Start date
R

R.. Kumar 1.9.1 OSX

/opt/local/lib/ruby1.9/1.9.1/pathname.rb:270: warning: `*' interpreted
as argument prefix


I keep getting this. I am including highline, sqlite3 and arrayfields in
my code.

I am using ruby -w inside my code.

ruby 1.9.1p376 (2009-12-07 revision 26041) [i386-darwin10]
Mac OSX Intel (Snow leopard).

I get this when running the examples in highline also.
 
B

Brian Candler

R.. Kumar 1.9.1 OSX said:
/opt/local/lib/ruby1.9/1.9.1/pathname.rb:270: warning: `*' interpreted
as argument prefix

Can you post line 270 of that file, with a few lines of context?

Can you replicate the problem standalone? e.g.

#!/usr/bin/ruby19 -w
require 'pathname'
puts Pathname.new("/etc")

This doesn't give any warning for me, but does it for you? If not,
what's the smallest program you can make which shows the warning?
 
J

Josh Cheek

[Note: parts of this message were removed to make it a legal post.]

/opt/local/lib/ruby1.9/1.9.1/pathname.rb:270: warning: `*' interpreted
as argument prefix


I keep getting this. I am including highline, sqlite3 and arrayfields in
my code.

I am using ruby -w inside my code.

ruby 1.9.1p376 (2009-12-07 revision 26041) [i386-darwin10]
Mac OSX Intel (Snow leopard).

I get this when running the examples in highline also.
It is a warning to let you know that it considers what you typed to be
ambiguous, and it is concerned that the way it interprets your code may not
be what you intended

ary = [ 10 , 20 , 30 ]

ary.first * 2 # => 20
(ary.first) * 2 # => 20
(ary.first) * (2) # => 20
(ary.first * 2) # => 20
(ary.first * 2) # => 20
ary.first.*(2) # => 20


ary.first *2 # => [10, 20] # !> `*' interpreted as argument prefix
ary.first *[2] # => [10, 20] # !> `*' interpreted as argument prefix
ary.first(*[2]) # => [10, 20]
ary.first(*2) # => [10, 20]
ary.first(2) # => [10, 20]
ary.first 2 # => [10, 20]


In particular notice the first from each set
ary.first * 2 # => 20
ary.first *2 # => [10, 20] # !> `*' interpreted as argument prefix

-----

In your particular case, it sees:

# Return a pathname which is substituted by String#sub.
def sub(pattern, *rest, &block)
if block
path = @path.sub(pattern, *rest) {|*args|
begin
old = Thread.current[:pathname_sub_matchdata]
Thread.current[:pathname_sub_matchdata] = $~
eval("$~ = Thread.current[:pathname_sub_matchdata]",
block.binding)
ensure
Thread.current[:pathname_sub_matchdata] = old
end
yield *args
}
else
path = @path.sub(pattern, *rest)
end
self.class.new(path)
end

and it is worried about the ambiguity of yield *args (get the results of the
block and multiply it by the variable named args vs take the variable args,
invoke the * on it to turn it into a sort of variable argument list, and
then pass those arguments to in to the block)

Anyway, if it bothers you, you can go put parens around it so it becomes
yield(*args) and is not ambiguous. But you don't need to worry about it,
look where it got those args from:
path = @path.sub(pattern, *rest) {|*args|

So it is recursively invoking itself, passing the args through the calls,
clearly the author did want it to be interpreted this way.

-----

Note: can anyone explain to me what unary * is? I looked in the Pickaxe page
333, and don't see it listed with the other operators. I tried defining *@
as an instance method, and I couldn't define it. I tried locating the method
2.method('*@') and it was undefined. I tried looking at parse.y, and found
tSTAR mlhs_node { $$ = NEW_MASGN(0, $2); } which I suspect defines the
interpreter match for it, but couldn't figure out how to then determine what
happens with this. What is it / where did it come from (is it an object?)
 
B

Brian Candler

Josh said:
Note: can anyone explain to me what unary * is?

It's just the "splat". AFAIK it's not really an operator and is not
mapped to a method call; it's part of the language syntax.
 
R

R.. Kumar 1.9.1 OSX

Brian said:
Can you post line 270 of that file, with a few lines of context?

Can you replicate the problem standalone? e.g.
#!/usr/bin/ruby19 -w
require 'pathname'

The above is enough to give the error.

1. I do not want to fix the problem in my own copy of ruby 1.9 and have
it keep returning when i upgrade versions, or have others get it.

2. While googling, I found that the problem was fixed in 1.8.x but
perhaps not in 1.9. Is that the case ?

The code in pathname.rb is

259 # Return a pathname which is substituted by String#sub.
260 def sub(pattern, *rest, &block)
261 if block
262 path = @path.sub(pattern, *rest) {|*args|
263 begin
264 old = Thread.current[:pathname_sub_matchdata]
265 Thread.current[:pathname_sub_matchdata] = $~
266 eval("$~ = Thread.current[:pathname_sub_matchdata]",
block.binding)
267 ensure
268 Thread.current[:pathname_sub_matchdata] = old
269 end
270 yield *args
271 }
272 else
273 path = @path.sub(pattern, *rest)
274 end
275 self.class.new(path)
276 end
 
R

R.. Kumar 1.9.1 OSX

Josh said:
Anyway, if it bothers you, you can go put parens around it so it becomes
yield(*args) and is not ambiguous. But you don't need to worry about it,
look where it got those args from:

Okay, i've put a parens around the *args. I no longer get the warning.
However, why i did not do this earlier, is that when i was googling and
i saw the commit (change) for this issue, there seemed to be several
lines of change involved.

I hope i am not altering the behavior by putting the parens.
 
J

Josh Cheek

[Note: parts of this message were removed to make it a legal post.]

Okay, i've put a parens around the *args. I no longer get the warning.
However, why i did not do this earlier, is that when i was googling and
i saw the commit (change) for this issue, there seemed to be several
lines of change involved.

I hope i am not altering the behavior by putting the parens.
You aren't, you probably see them because your warning levels are different
than other people's


$ ruby -we "def x; yield *[12] end; puts x{|n|n}"
-e:1: warning: `*' interpreted as argument prefix
12

$ ruby -e "def x; yield *[12] end; puts x{|n|n}"
12

-----

Also, I appear to not be receiving Brian's posts. I only realized that
anyone other than R. Kumar and I were in this thread by seeing Kumar reply
to him, and checking ruby-forum, where I saw that Brian had responded. I
checked my mail with the filter from:[email protected] and don't have
anything since 15 June.

I'm on gmail. Does anyone else on gmail not see his posts?

Possible factors: I think he posted into this thread while I was writing my
initial response, because I remember clicking to have it show me what he had
said. Perhaps this is a gmail bug? I don't think I blocked him, I don't even
know how to block people, if I consistently get spam from addresses, I set
up a filter to trash their messages, but I checked my filters and didn't see
in there (plus it seems like that would be difficult to do by accident).
 
J

Jesús Gabriel y Galán

Okay, i've put a parens around the *args. I no longer get the warning.
However, why i did not do this earlier, is that when i was googling and
i saw the commit (change) for this issue, there seemed to be several
lines of change involved.

I hope i am not altering the behavior by putting the parens.
You aren't, you probably see them because your warning levels are different
than other people's


$ ruby -we "def x; yield *[12] end; puts x{|n|n}"
-e:1: warning: `*' interpreted as argument prefix
12

$ ruby -e "def x; yield *[12] end; puts x{|n|n}"
12

-----

Also, I appear to not be receiving Brian's posts. I only realized that
anyone other than R. Kumar and I were in this thread by seeing Kumar reply
to him, and checking ruby-forum, where I saw that Brian had responded. I
checked my mail with the filter from:[email protected] and don't have
anything since 15 June.

I'm on gmail. Does anyone else on gmail not see his posts?

I'm on gmail too, and I see 7 posts in this thread: 3 from RKumar and
2 each from Brian and you.
It has sometimes happened to me that some people get flagged as
spammers by Gmail. Check your Trash folder, maybe Gmail is sending
Brian's emails there. Several times I've had to go there and flag them
as not spam.

Jesus.
 
J

Jesús Gabriel y Galán

2010/7/1 Jes=FAs Gabriel y Gal=E1n said:
Josh Cheek wrote:

Anyway, if it bothers you, you can go put parens around it so it beco= mes
yield(*args) and is not ambiguous. But you don't need to worry about = it,
look where it got those args from:

Okay, i've put a parens around the *args. I no longer get the warning.
However, why i did not do this earlier, is that when i was googling and
i saw the commit (change) for this issue, there seemed to be several
lines of change involved.

I hope i am not altering the behavior by putting the parens.
You aren't, you probably see them because your warning levels are differ= ent
than other people's


$ ruby -we "def x; yield *[12] end; puts x{|n|n}"
-e:1: warning: `*' interpreted as argument prefix
12

$ ruby -e "def x; yield *[12] end; puts x{|n|n}"
12

-----

Also, I appear to not be receiving Brian's posts. I only realized that
anyone other than R. Kumar and I were in this thread by seeing Kumar rep= ly
to him, and checking ruby-forum, where I saw that Brian had responded. I
checked my mail with the filter from:[email protected] and don't have
anything since 15 June.

I'm on gmail. Does anyone else on gmail not see his posts?

I'm on gmail too, and I see 7 posts in this thread: 3 from RKumar and
2 each from Brian and you.
It has sometimes happened to me that some people get flagged as
spammers by Gmail. Check your Trash folder, maybe Gmail is sending
Brian's emails there. Several times I've had to go there and flag them
as not spam.

Sorry, I meant the Spam folder, not the Trash.

Jesus.
 
J

Josh Cheek

[Note: parts of this message were removed to make it a legal post.]

It's just the "splat". AFAIK it's not really an operator and is not
mapped to a method call; it's part of the language syntax.
I am still unsure what it is, I think that when it is parsed, it just
invokes the to_a method, and then does some interpreter level magic to line
up the args and the params.

Anyway, it definitely invokes to_a (I expect this is similar to how the
ampersand invokes to_proc)

def y(x)
def x.to_a() [12] end
yield *x
end
y(/1,2,3/) { |param| param } # => 12
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top