Reformatted excerpts from Andrew Pimlott's message of 2009-05-11:
> On Fri, May 08, 2009 at 09:42:26AM -0700, Andrew Pimlott wrote:
> > I don't have any memory limits set. Is it possible that sup-sync or
> > ruby uses some itself? Any other ideas?
Very mysterious. Sup-sync doesn't do anything fancy with memory; it's a
fairly straight-forward Ruby script. Maybe one of the C extensions (like
Ferret) has a memory leak.
> I forgot to mention, this was the latest release (0.7) installed with
> gem. I just tried the current git mainline (clearing all my .sup
> state first), and it got through my whole mailbox without a problem.
Evey more mysterious. The differences between these two versions are
trivial:
diff --git a/origin/release-0.7:bin/sup-sync b/origin/master:bin/sup-sync
index ac5caf6..91710d4 100644
--- a/origin/release-0.7:bin/sup-sync
+++ b/origin/master:bin/sup-sync
@@ -143,12 +143,7 @@ begin
next if target == :changed && entry && entry[:source_id].to_i ==
source.id && entry[:source_info].to_i == offset
## get the state currently in the index
- index_state =
- if entry
- entry[:label].split(/\s+/).map { |x| x.intern }
- else
- nil
- end
+ index_state = entry[:label].split(/\s+/).map { |x| x.intern } if entry
## skip if we're operating on restored messages, and this one
## ain't.
@@ -163,7 +158,7 @@ begin
## assign message labels based on the operation we're performing
case op
when :asis
- m.labels = index_state if index_state
+ m.labels = ((m.labels - [:unread, :inbox]) + index_state).uniq if
index_state
when :restore
## if the entry exists on disk
if restored_state[m.id]
I'm at a loss.
--
William <[email protected]>
_______________________________________________
sup-talk mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/sup-talk
