sup talk - Nov 2007 - ''undefined method `longname'' for nil:NilClass'' (error type NoMethodError)

This is seen when I run sup. The previous one was with sup-sync.

Looks like some problem with handling encoded messages.
How can I back track?
Thanks,
-Manish


The problem was: ''undefined method `longname'' for
nil:NilClass'' (error
type NoMethodError)
A backtrace follows:
/usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:102:in `do_poll'': 
undefined method `longname'' for nil:NilClass (NoMethodError)
        from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:157:in 
`add_messages_from''
        from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/source.rb:93:in 
`each''
        from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:431:in 
`send''
        from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:431:in 
`__pass''
        from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:420:in 
`method_missing''
        from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:139:in 
`add_messages_from''
        from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:96:in 
`do_poll''
        from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:84:in 
`each''
         ... 24 levels...
        from 
/usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/modes/thread-index-mode.rb:431:in 
`load_threads''
        from /usr/lib/ruby/gems/1.8/gems/sup-0.2/bin/sup:193
        from /usr/bin/sup:16:in `load''
        from /usr/bin/sup:16

Excerpts from Manish Sapariya''s message of Wed Nov 07 01:35:07 -0800
2007:
> The problem was: ''undefined method `longname'' for
nil:NilClass'' (error
> type NoMethodError)
> A backtrace follows:
> /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:102:in
`do_poll'': undefined method `longname'' for nil:NilClass
(NoMethodError)
This should be fixed in SVN now. You may have to re-index the offending
source (sup-sync --all <source uri>).

-- 
William <wmorgan-sup at masanjin.net>

Hi Williams,
Thanks for the fix. However looks like I have some weird mail in my box.
The body and the charset both are nil. Is there any way I can backtrack the
offending message and find out whats the character set and encoding used
for that message?
Thanks,
Manish

(rdb:1) list
[372, 381] in /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/message.rb
   372    def self.convert_from body, charset
   373      begin
   374        raise MessageFormatError, "RubyMail decode returned a null 
body" unless body
   375        return body unless charset
   376        Iconv.iconv($encoding, charset, body).join
   377      rescue Errno::EINVAL, Iconv::InvalidEncoding, 
Iconv::IllegalSequence, MessageFormatError => e
   378        Redwood::log "warning: error (#{e.class.name}) decoding 
message body from #{charset}: #{e.message}"
   379        File.open("sup-unable-to-decode.txt", "w") {
|f| f.write
body }
   380        body
   381      end
(rdb:1) p m.charset
nil
(rdb:1) p m.body
nil



William Morgan wrote:
> Excerpts from Manish Sapariya''s message of Wed Nov 07 01:35:07
-0800 2007:
>   
>> The problem was: ''undefined method `longname'' for
nil:NilClass'' (error
>> type NoMethodError)
>> A backtrace follows:
>> /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:102:in
`do_poll'': undefined method `longname'' for nil:NilClass
(NoMethodError)
>>     
>
> This should be fixed in SVN now. You may have to re-index the offending
> source (sup-sync --all <source uri>).
>
>

Excerpts from Manish Sapariya''s message of Wed Nov 07 21:15:09 -0800
2007:
> Thanks for the fix. However looks like I have some weird mail in my
> box.  The body and the charset both are nil. Is there any way I can
> backtrack the offending message and find out whats the character set
> and encoding used for that message?
You have two options: insert some puts or logging statements in the code
and try and figure out what the message id was (which then you can use
to locate the message in the source), or convert the source into an mbox
file (if it isn''t already) and divide and conquer it until you find the
offending message.

Probably the first one is easier at this point.

-- 
William <wmorgan-sup at masanjin.net>