IRC#names issue

[Spotnyk]

I keep having this issue, and assumed it was my code. Then I kept reducing my code down further and further. Finally I used your example code from the docs. It worked without throwing the error.

However, when I put it in a loop, the error threw.

So this works:

irc.names( '#napalmlabs', function( channel, names ) {
    this.privmsg( channel, 'Hi ' + names.join( ', ' ) + '!' )
})

But this code:

for ( var i=0; i<options.channels.length; i++ ) {
    irc.names( '#'+ options.channels[i].name, function( channel, names ) {
        this.privmsg( channel, 'Hi ' + names.join( ', ' ) + '!' )
    });
}

..throws this error..

events.js:129
    throw new Error('removeListener only takes instances of Function');
          ^
Error: removeListener only takes instances of Function
    at EventEmitter.removeListener (events.js:129:11)
    at Timer.callback (/usr/spot/node/lib/node/.npm/irc-js/0.2.25/package/lib/irc.js:309:17)

Ideas?

[gf3]

Yes, this is a bug. I didn't anticipate this scenario. The solution is to queue up NAMES requests internally. On it!

[Spotnyk]

Awesome! Thanks man. I feel bad for keep hitting you with this stuff. But the thought of it getting more solid is great!

[Spotnyk]

Hey man, not to put any pressure on you. I am just wondering if a patch for this will be anytime soon? I ask because the project I'm using this for, cannot move forward before I get this done. So if it's going to be a bit still, I'll restructure my stuff and code around this bug.

Thanks.

[ile]

I had troubles with the "once" method combined with "names".. worked around it like this in irc.js:

this.names = function( channel, hollaback ) {
// 4.2.5
// Register event for names query

if (hollaback)
{
  this.once( '353', function( message ) {
    var chan = message.params[1] == '=' ? message.params[2] : message.params[1]
    hollaback.call( this, chan, $w( message.params.slice( -1 ) ) )
  })
}

return this.raw( 'NAMES' + param( channel ) )

}

In essence I don't provide the callback here and I registered the NAMES callback separately. Seems to be a bit more robust since the names callback can fire unexpectedly sometimes (for example with dircproxy).

[ile]

Feel free to pull that from my repo if you feel like it.

[gf3]

Hey, sorry, I am working on a refactor right now to allow me to really test the internals. As soon as that's done, I'll tackle this issue.

[meelash]

I think there are a number of scenarios where once could cause this kind of problem, not just /names. One easy idea for fixing it is to instead of using the callback as the hash key:
internal.single_listener_cache[hollaback]
assign some kind of unique id to each instance of hollaback that is passed. That way you can call once multiple times with the same hollaback without it breaking.

[gf3]

@meelash Unfortunately this won't solve the issue because we can't tell which /list data is associated with which holdback, so we have to lock and queue them.