Archive of RubyForge sup-talk mailing list
 help / color / mirror / Atom feed
* [sup-talk]  Checking for unexpected types
@ 2008-06-04 18:26 fedzor
  2008-06-04 19:12 ` William Morgan
  0 siblings, 1 reply; 2+ messages in thread
From: fedzor @ 2008-06-04 18:26 UTC (permalink / raw)


Yes, this could very well turn into a "dynamic vs. static" debate,  
but I don't want it to.

--- SystemExit from thread: main
undefined method `each' for false:FalseClass
/Users/ari/local//lib/ruby/gems/1.8/gems/sup-0.5/lib/sup.rb:64:in  
`select'
/Users/ari/local//lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/buffer.rb: 
31:in `nonblocking_getch'
/Users/ari/local//lib/ruby/gems/1.8/gems/sup-0.5/bin/sup:227
/Users/ari/local/lib/ruby/gems/1.8/bin/sup:19:in `load'
/Users/ari/local/lib/ruby/gems/1.8/bin/sup:19

I get way too many of these. Maybe it's because I'm using gmail and  
it just gets sooooooo many hits that some get lost, but I'm tired of  
it. I want to switch over to sup full-time, but I can't because it  
crashes often, when I scroll down too much or when it tries to load a  
lot of emails.

So... Is this some other problem, or should I go through and add a  
bunch of "unless type === Something" throughout the code?

Option two.... Add NilClass#coerce

Is it worth doing this? I'm going to fix this either way, so the  
question is.... Which will impact performance the least? Ruby is  
interpreted so I don't have to worry about screwing up branch  
prediction, but I'm worried about method calls.

Mr. Morgan, any advice for which path I should take?

Thanks,
-------------------------------------------------------|
~ Ari
".. NOT INTENDED FOR USE IN ... NUCLEAR FACILITIES, AIRCRAFT  
NAVIGATION ... LIFE SUPPORT MACHINES" - iTunes EULA



^ permalink raw reply	[flat|nested] 2+ messages in thread

* [sup-talk] Checking for unexpected types
  2008-06-04 18:26 [sup-talk] Checking for unexpected types fedzor
@ 2008-06-04 19:12 ` William Morgan
  0 siblings, 0 replies; 2+ messages in thread
From: William Morgan @ 2008-06-04 19:12 UTC (permalink / raw)


Reformatted excerpts from fedzor's message of 2008-06-04:
> --- SystemExit from thread: main
> undefined method `each' for false:FalseClass
> /Users/ari/local//lib/ruby/gems/1.8/gems/sup-0.5/lib/sup.rb:64:in  
> `select'
> /Users/ari/local//lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/buffer.rb: 
> 31:in `nonblocking_getch'
> /Users/ari/local//lib/ruby/gems/1.8/gems/sup-0.5/bin/sup:227
> /Users/ari/local/lib/ruby/gems/1.8/bin/sup:19:in `load'
> /Users/ari/local/lib/ruby/gems/1.8/bin/sup:19
> 
> I get way too many of these. Maybe it's because I'm using gmail and
> it just gets sooooooo many hits that some get lost, but I'm tired of
> it. I want to switch over to sup full-time, but I can't because it
> crashes often, when I scroll down too much or when it tries to load a
> lot of emails.

Interesting. Sup rarely crashes for me any more, and I make it work
pretty hard. I don't use IMAP, so that might be the difference. (Pretty
much everyone seems to have problems with the Ruby IMAP library.)

I don't think typechecking is the right way to handle this. Typically a
NME is a symptom of something else being wrong (like NPEs in Java), so
fixing that is just symptomatic medicine.

The backtrace above doesn't make any sense. 'Undefined method' generates
a NoMethodError, not a SystemExit, and there's no select method in
sup.rb. This is a sign that something weird is happening with threads
and exception handling.

So, if you can make this happen consistently, then I would recommend
trying to track down the source(s) of the problem. Is it just one line?
Or is it really a systematic problem throughout Sup?

Things to try:
 - apply commit 7f2af9ac8bc70ff41b0dc64eccd068118abe19f2, which I've
   just merged into master and next. This requires fastthread, and adds
   some synchronization around the exception handling. I've attached the
   patch for your convenience, though I'm not sure if it will apply
   cleanly to 0.5. This might help produce intelligence backtraces.

 - Run sup with -n (which turns off threading) and see if you can get a
   real backtrace for the above error.

 - Use offlineimap and see if you can still induce the exceptions.
-- 
William <wmorgan-sup at masanjin.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-exception-cleanup-synchronize-access-and-require-f.patch
Type: application/octet-stream
Size: 3228 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20080604/d946b7d4/attachment.obj>


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-06-04 19:12 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-06-04 18:26 [sup-talk] Checking for unexpected types fedzor
2008-06-04 19:12 ` William Morgan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox