From nicolas.pouillard@gmail.com Thu Oct 1 03:36:00 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Thu, 01 Oct 2009 09:36:00 +0200 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1254339746-sup-79@masanjin.net> References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net> <1252004144-sup-6662@javelin> <1252004285-sup-476@masanjin.net> <1252004504-sup-3189@javelin> <1254339746-sup-79@masanjin.net> Message-ID: <1254382434-sup-4435@peray> Excerpts from William Morgan's message of Wed Sep 30 21:56:55 +0200 2009: > Reformatted excerpts from Edward Z. Yang's message of 2009-09-03: > > > What if you just delete messages in the the third condition? > > > > Then replies show up. :-) > > I am still thinking about this, BTW. I think solution will either be: > treat deleted like killed for the purposes of inbox-mode (so a thread > with at least one deleted message will just never appear in inbox-mode), > or have a combined delete-and-kill command. > > FWIW, I believe Gmail will pull a thread with a deleted message back > into the inbox if someone replies. Yes I think so (and merely hope so). Notice that while GMail do not have the kill thread feature, Google Wave does have a "mute this thread" button, that will cause these threads to no longer appear in the inbox, however you can still search for is:mute threads. -- Nicolas Pouillard http://nicolaspouillard.fr From wmorgan-sup@masanjin.net Thu Oct 1 09:34:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 06:34:50 -0700 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1254382434-sup-4435@peray> References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net> <1252004144-sup-6662@javelin> <1252004285-sup-476@masanjin.net> <1252004504-sup-3189@javelin> <1254339746-sup-79@masanjin.net> <1254382434-sup-4435@peray> Message-ID: <1254404057-sup-2374@masanjin.net> Reformatted excerpts from Nicolas Pouillard's message of 2009-10-01: > Notice that while GMail do not have the kill thread feature I think it does (but it didn't always). They also call it "mute". http://mail.google.com/support/bin/answer.py?hl=en&answer=47787 -- William From wmorgan-sup@masanjin.net Thu Oct 1 09:43:48 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 06:43:48 -0700 Subject: [sup-talk] Crash while scrolling In-Reply-To: <1254160696-sup-3522@ben-laptop> References: <20090911165830.GA11260@ben-laptop> <1252773189-sup-246@masanjin.net> <20090916172340.GA20566@ben-laptop> <1253975267-sup-8308@masanjin.net> <1254160696-sup-3522@ben-laptop> Message-ID: <1254404181-sup-8448@masanjin.net> Reformatted excerpts from Ben Gamari's message of 2009-09-28: > This does raise one important question, however. It seems that > offlineimap will delete messages if they are found to have been > deleted in the remote respository. Is there any way that you know of > to disable this behavior, such that it will only drop new messages > into the local repository, thus making it somewhat compatible with > sup's add-only source requirement? Maybe someone who uses offlineimap can comment on this. In the worst case, I'm sure the patch wouldn't be too hard. > This actually brings up a larger question. How difficult would it be > to relax sup's assumption that sources are add-only? It's not difficult per se, it just requires scanning over the entire source, which is slow. Removing this assumption would be tantamount to running sup-sync -c every time you start up sup. Here's the idea: scanning over a mailstore is slow. Much of this slowness is due to Ruby. So let's rewrite this code in C. Then we would have something as fast as, say, Mutt. But Mutt bogs down on my mbox file because it's too big. So my *only* reasonable choice with a large mailstore is Sup and the assumption that the source is add only. -- William From wmorgan-sup@masanjin.net Thu Oct 1 09:46:20 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 06:46:20 -0700 Subject: [sup-talk] [PATCH] xapian: do less work for update_message_state In-Reply-To: <1254341186-sup-4357@zyrg.net> References: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu> <1254339542-sup-886@masanjin.net> <1254341186-sup-4357@zyrg.net> Message-ID: <1254404707-sup-9253@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-09-30: > They're about 3 times faster on my machine with this patch. An > optimization the Xapian devs have been planning to make (and that this > patch is necessary to take advantage of) should increase performance > much more. Awesome. Out of curiousity, what's the optimization? -- William From wmorgan-sup@masanjin.net Thu Oct 1 09:49:54 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 06:49:54 -0700 Subject: [sup-talk] Bug: Converting the index to xapian fails with a message with very old date In-Reply-To: <1254001080-sup-5742@midna.zekjur.net> References: <1253475875-sup-5119@midna.zekjur.net> <1253973258-sup-3347@masanjin.net> <1254001080-sup-5742@midna.zekjur.net> Message-ID: <1254404956-sup-6574@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-09-26: > truncated date is Thu Jan 01 01:00:00 +0100 1970 > date_value is "\200" > /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `_dump': year too big to marshal > (ArgumentError) > from /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `dump' > from /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `index_message' > from /usr/lib/ruby/1.8/sup/xapian_index.rb:124:in `sync_message' At this point I'm hoping that Rich will chime in. :) -- William From nicolas.pouillard@gmail.com Thu Oct 1 10:07:01 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Thu, 1 Oct 2009 16:07:01 +0200 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1254404057-sup-2374@masanjin.net> References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net> <1252004144-sup-6662@javelin> <1252004285-sup-476@masanjin.net> <1252004504-sup-3189@javelin> <1254339746-sup-79@masanjin.net> <1254382434-sup-4435@peray> <1254404057-sup-2374@masanjin.net> Message-ID: On Thu, Oct 1, 2009 at 3:34 PM, William Morgan wrote: > Reformatted excerpts from Nicolas Pouillard's message of 2009-10-01: >> Notice that while GMail do not have the kill thread feature > > I think it does (but it didn't always). They also call it "mute". > http://mail.google.com/support/bin/answer.py?hl=en&answer=47787 The name and semantics seems just great. -- Nicolas Pouillard http://nicolaspouillard.fr From gregor@hoffleit.de Thu Oct 1 11:47:17 2009 From: gregor@hoffleit.de (Gregor Hoffleit) Date: Thu, 01 Oct 2009 17:47:17 +0200 Subject: [sup-talk] Bug: store_message writes invalid From lines with locales set Message-ID: <1254411555-sup-7650@sam> Obviously store_message uses the current locale settings to dump the date into the From line (loader.rb, line 179): f.puts "From #{from_email} #{date.utc}" The result: Using LANG=de_DE, sup crashed on me today when I had sent my first mail of October. Problem was that sup failed to grok the localized abbreviated month name ("Okt") in the From line: From gregor at hoffleit.de Do Okt 01 14:39:43 UTC 2009 which in turn was written by loader.rb (eat your own food, you know). Everything worked fine for me in August and September, since those month names are spelled the same in German and English ;-). Regards, Gregor Hoffleit From wmorgan-sup@masanjin.net Thu Oct 1 12:38:36 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 09:38:36 -0700 Subject: [sup-talk] Bug: store_message writes invalid From lines with locales set In-Reply-To: <1254411555-sup-7650@sam> References: <1254411555-sup-7650@sam> Message-ID: <1254414095-sup-8087@masanjin.net> Reformatted excerpts from Gregor Hoffleit's message of 2009-10-01: > f.puts "From #{from_email} #{date.utc}" Whoops. That should be date.rfc2822. I've fixed in git and this will go out in 0.9. > Everything worked fine for me in August and September, since those > month names are spelled the same in German and English ;-). You expect your email client to work for more than two months a year? -- William From wmorgan-sup@masanjin.net Thu Oct 1 12:44:43 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 09:44:43 -0700 Subject: [sup-talk] i18n? In-Reply-To: <1254353101-sup-1021@thinkpad-ubuntu> References: <1254353101-sup-1021@thinkpad-ubuntu> Message-ID: <1254415145-sup-635@masanjin.net> Reformatted excerpts from Christopher Bertels's message of 2009-09-30: > are there any plans on doing some internationalization? If not, would > people like to have something like this, now that I have mentioned it? I have no immediate plans personally, but I would love to have this in Sup. > I guess something yaml-based could work, there are some good libraries > out there afaik. There is a Ruby-Gettext package, which we already use for other reasons. I think this is probably the best thing to start with, unless it turns out to be too hard to use, in which case we could consider a custom solution. http://www.yotabanana.com/hiki/ruby-gettext.html > I could take care of some german translation (and I suppose I'm not > the only one on this list ;)) I know we have a fair amount of German and French representation on the list, and that's probably representative of the user population in general. So you should have an appreciative audience. -- William From wmorgan-sup@masanjin.net Thu Oct 1 12:53:15 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 09:53:15 -0700 Subject: [sup-talk] [PATCH] Handle added messages in label-list-mode In-Reply-To: <1252789445-30193-1-git-send-email-gigabo@gmail.com> References: <1252789445-30193-1-git-send-email-gigabo@gmail.com> Message-ID: <1254415913-sup-6275@masanjin.net> Reformatted excerpts from Bo Borgerson's message of 2009-09-12: > Register label-list-mode with the UpdateManager and handle added > updates with a reload to keep unread message counts up to date Branch label-list-mode-auto-update, merged into next. I'm a little concerned with performance, but we'll see how it goes. What do you think about handling labeled and deleted updates as well? -- William From wmorgan-sup@masanjin.net Thu Oct 1 12:54:48 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 09:54:48 -0700 Subject: [sup-talk] [PATCH] Add command for polling unusual sources In-Reply-To: <1252852715-9601-1-git-send-email-gigabo@gmail.com> References: <1252852715-9601-1-git-send-email-gigabo@gmail.com> Message-ID: <1254416074-sup-7585@masanjin.net> Reformatted excerpts from Bo Borgerson's message of 2009-09-13: > bin/sup: Add new global key binding, '{', to poll unusual sources > (requires confirmation). This allows update of unusual sources > without having to leave sup to run a sync. Branch poll-unusual, merged into next. Thanks! -- William From wmorgan-sup@masanjin.net Thu Oct 1 12:58:16 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 09:58:16 -0700 Subject: [sup-talk] [PATCH] Add hooks to sort and format label-list-mode display. In-Reply-To: <1253303493-sup-288@kronos> References: <1253303493-sup-288@kronos> Message-ID: <1254416245-sup-4497@masanjin.net> Hi William, Sorry for the delay. I like this patch but I can't get it to apply cleanly to master. git am -3 complains: Did you hand edit your patch? It does not apply to blobs recorded in its index. Cannot fall back to three-way merge. Patch failed at 0001. If you can resubmit against a recent master, I will apply it. Thanks! -- William From rlane@club.cc.cmu.edu Thu Oct 1 13:02:18 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 01 Oct 2009 13:02:18 -0400 Subject: [sup-talk] [PATCH] xapian: do less work for update_message_state In-Reply-To: <1254404707-sup-9253@masanjin.net> References: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu> <1254339542-sup-886@masanjin.net> <1254341186-sup-4357@zyrg.net> <1254404707-sup-9253@masanjin.net> Message-ID: <1254416360-sup-8957@zyrg.net> Excerpts from William Morgan's message of Thu Oct 01 09:46:20 -0400 2009: > Reformatted excerpts from Rich Lane's message of 2009-09-30: > > They're about 3 times faster on my machine with this patch. An > > optimization the Xapian devs have been planning to make (and that this > > patch is necessary to take advantage of) should increase performance > > much more. > > Awesome. Out of curiousity, what's the optimization? replace_document currently deletes all the old postings and inserts new ones. It can be optimized to make the minimal set of modifications. From wmorgan-sup@masanjin.net Thu Oct 1 13:04:52 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 10:04:52 -0700 Subject: [sup-talk] [PATCH] Allow thread index view to sort oldest first In-Reply-To: <1253911610-sup-2052@yoom.home.cworth.org> References: <1253911610-sup-2052@yoom.home.cworth.org> Message-ID: <1254416597-sup-8156@masanjin.net> Hi Carl, I am interested in trying these changes but I think these patches were generated against a custom version of master (e.g. I see the inbox refine-search command in the context, which hasn't been published yet). Can you rebase them onto a recent non-modified master so that I can apply? Thanks! -- William From wmorgan-sup@masanjin.net Thu Oct 1 13:07:20 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 10:07:20 -0700 Subject: [sup-talk] [PATCH] Add new :crypto_default configuration option. In-Reply-To: <1254178611-sup-369@yoom.home.cworth.org> References: <1254178611-sup-369@yoom.home.cworth.org> Message-ID: <1254416783-sup-5518@masanjin.net> I like the idea, but how about a hook instead? I think the reply-mode hook is exactly equivalent to this. (Which maybe I will one day rename to default-reply-mode.) I have a strong aversion to adding configuration options. -- William From wmorgan-sup@masanjin.net Thu Oct 1 13:10:12 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 10:10:12 -0700 Subject: [sup-talk] [PATCH] When providing a wildcard as file for an attachment, correctly expand it In-Reply-To: <1254343324-sup-7275@midna.zekjur.net> References: <1254343324-sup-7275@midna.zekjur.net> Message-ID: <1254416978-sup-2395@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-09-30: > the attached patch will expand wildcards given as filename when adding > attachments to a message. Thus, you can now add ~/work/foo/* at once. Branch attach-wildcards, merged into next. Thanks! This is awesome. > As with the last patch, please review, test and merge. I changed one minor thing: Dir["#{fn}"] -> Dir[fn]. :) -- William From cworth@cworth.org Thu Oct 1 13:13:47 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 01 Oct 2009 10:13:47 -0700 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net> <1252004144-sup-6662@javelin> <1252004285-sup-476@masanjin.net> <1252004504-sup-3189@javelin> <1254339746-sup-79@masanjin.net> <1254382434-sup-4435@peray> <1254404057-sup-2374@masanjin.net> Message-ID: <1254417174-sup-3659@yoom.home.cworth.org> Excerpts from Nicolas Pouillard's message of Thu Oct 01 07:07:01 -0700 2009: > On Thu, Oct 1, 2009 at 3:34 PM, William Morgan wrote: > > Reformatted excerpts from Nicolas Pouillard's message of 2009-10-01: > >> Notice that while GMail do not have the kill thread feature > > > > I think it does (but it didn't always). They also call it "mute". > > http://mail.google.com/support/bin/answer.py?hl=en&answer=47787 > > The name and semantics seems just great. It seems a simple, little thing. But I'm all in favor of non-violent metaphors in the interfaces of programs I use. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From michael+sup@stapelberg.de Thu Oct 1 13:27:40 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Thu, 01 Oct 2009 19:27:40 +0200 Subject: [sup-talk] [PATCH] more inline GPG madness In-Reply-To: <1254348163-sup-6170@midna.zekjur.net> References: <1254348163-sup-6170@midna.zekjur.net> Message-ID: <1254417896-sup-2359@midna.zekjur.net> Hi, Excerpts from Michael Stapelberg's message of Do Okt 01 00:08:39 +0200 2009: > Attached comes a patch which fixes the behaviour. However (!) the patch is not > well aligned, the error case (else) is untested and should probably be handled > differently and the old_charset line can probably be written more elegantly in > ruby. By the way, the charset stuff is necessary to get the correct character > set for messages which are sent inline. I really start to dislike Thunderbird > and other crappy software for that :-\. I am sorry for the confusion. Please do not merge this patch without close review if these PGP headers are valid at all. Turns out the headers were produced by a custom procmail rule I had forgotton about. I will instead implement support for "correct" inline GPG. Best regards, Michael From cworth@cworth.org Thu Oct 1 13:31:00 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 01 Oct 2009 10:31:00 -0700 Subject: [sup-talk] [PATCH] Add new :crypto_default configuration option. In-Reply-To: <1254416783-sup-5518@masanjin.net> References: <1254178611-sup-369@yoom.home.cworth.org> <1254416783-sup-5518@masanjin.net> Message-ID: <1254417826-sup-6584@yoom.home.cworth.org> Excerpts from William Morgan's message of Thu Oct 01 10:07:20 -0700 2009: > I like the idea, but how about a hook instead? I think the reply-mode > hook is exactly equivalent to this. (Which maybe I will one day rename > to default-reply-mode.) > > I have a strong aversion to adding configuration options. I'm intrigued. What makes a hook preferable over a configuration option? I've been getting concerned watching the number of hooks in sup grow as each creates a maintenance burden. Either: 1. All hooks are supported forever with consistent arguments/semantics, (which may make it more difficult to make changes in sup than it would be otherwise) OR: 2. Hooks are not supported forever, in which case users may find that things just start working when upgrading. Neither of those seem options look nice to me, and both seem easy to avoid with configuration options. If the plan is to go with (1) I'm concerned that I don't see sup shipping documentation for the current possible hooks. (This applies to configuration options too though. I think the maintainer should reject patches that add either without also adding documentation to the standard list.[*]) [*] Assuming the pre-condition of such documentation existing of course. On the other hand, I also dislike configuration options (and hooks, equally), to the extent that they might be used as an excuse to avoid putting the most sane and useful default functionality into sup itself. Obviously, this can be complicated by some people not agreeing on what the most sane and useful behavior is. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Thu Oct 1 13:37:06 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 10:37:06 -0700 Subject: [sup-talk] [PATCH] Save all attachments to a folder In-Reply-To: <1254340829-sup-2273@midna.zekjur.net> References: <1254340829-sup-2273@midna.zekjur.net> Message-ID: <1254418612-sup-4759@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-09-30: > I finally implemented saving all attachments of a message to a folder. > Please review and test this patch, I would be happy if we could merge > it into mainline. Branch save-all-attachments, merged into next. -- William From ezyang@MIT.EDU Thu Oct 1 13:38:27 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Thu, 01 Oct 2009 13:38:27 -0400 Subject: [sup-talk] Bugfix for custom-search Message-ID: <1254418685-sup-6611@javelin> I think there's a slight bug in the custom-search implementation. Patch is here: >From cea17180933469570e9502ffa7bf67ccaa8ccfc7 Mon Sep 17 00:00:00 2001 From: Edward Z. Yang Date: Wed, 10 Jun 2009 01:42:50 -0400 Subject: [PATCH] Fix bug in which custom-search substitutions are not used. Signed-off-by: Edward Z. Yang --- lib/sup/ferret_index.rb | 2 +- lib/sup/xapian_index.rb | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/sup/ferret_index.rb b/lib/sup/ferret_index.rb index d605e8d..34dff87 100644 --- a/lib/sup/ferret_index.rb +++ b/lib/sup/ferret_index.rb @@ -340,7 +340,7 @@ EOS query = {} subs = HookManager.run("custom-search", :subs => s) || s - subs = s.gsub(/\b(to|from):(\S+)\b/) do + subs = subs.gsub(/\b(to|from):(\S+)\b/) do field, name = $1, $2 if(p = ContactManager.contact_for(name)) [field, p.email] diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index ab25ea0..e1cfe65 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -193,7 +193,7 @@ EOS query = {} subs = HookManager.run("custom-search", :subs => s) || s - subs = s.gsub(/\b(to|from):(\S+)\b/) do + subs = subs.gsub(/\b(to|from):(\S+)\b/) do field, name = $1, $2 if(p = ContactManager.contact_for(name)) [field, p.email] -- 1.6.4.4 From cworth@cworth.org Thu Oct 1 13:43:25 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 01 Oct 2009 10:43:25 -0700 Subject: [sup-talk] [PATCH] Allow thread index view to sort oldest first In-Reply-To: <1254416597-sup-8156@masanjin.net> References: <1253911610-sup-2052@yoom.home.cworth.org> <1254416597-sup-8156@masanjin.net> Message-ID: <1254418822-sup-7654@yoom.home.cworth.org> Excerpts from William Morgan's message of Thu Oct 01 10:04:52 -0700 2009: > I am interested in trying these changes but I think these patches were > generated against a custom version of master (e.g. I see the inbox > refine-search command in the context, which hasn't been published yet). Guilty as charged. > Can you rebase them onto a recent non-modified master so that I can > apply? Thanks! See the attached patches. And as before, the behavior is split into two commits so that you can decide whether to change the default or not. And there's still the one minor bug that the oldest-first mode doesn't actually guarantee that the oldest message is displayed first when newer messages arrive for an old thread. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-thread-index-view-to-sort-oldest-first.patch Type: application/octet-stream Size: 7502 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Change-the-default-sort-for-inbox-mode-to-be-oldest-.patch Type: application/octet-stream Size: 777 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From bgamari.foss@gmail.com Thu Oct 1 13:44:19 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Thu, 01 Oct 2009 13:44:19 -0400 Subject: [sup-talk] Crash while scrolling In-Reply-To: <1254404181-sup-8448@masanjin.net> References: <20090911165830.GA11260@ben-laptop> <1252773189-sup-246@masanjin.net> <20090916172340.GA20566@ben-laptop> <1253975267-sup-8308@masanjin.net> <1254160696-sup-3522@ben-laptop> <1254404181-sup-8448@masanjin.net> Message-ID: <1254418089-sup-5800@ben-laptop> Excerpts from William Morgan's message of Thu Oct 01 09:43:48 -0400 2009: > Reformatted excerpts from Ben Gamari's message of 2009-09-28: > > This actually brings up a larger question. How difficult would it be > > to relax sup's assumption that sources are add-only? > > It's not difficult per se, it just requires scanning over the entire > source, which is slow. Removing this assumption would be tantamount to > running sup-sync -c every time you start up sup. > > Here's the idea: scanning over a mailstore is slow. Much of this > slowness is due to Ruby. So let's rewrite this code in C. Then we would > have something as fast as, say, Mutt. But Mutt bogs down on my mbox file > because it's too big. So my *only* reasonable choice with a large > mailstore is Sup and the assumption that the source is add only. It seems that C would definitely be a good start (or perhaps C++ would be a better idea as that is the language in which Xapian is written). However, I think one of the real issues is the exclusive nature of index access. In fact, this is one of my primary gripes with the sup workflow. After processing a large number of messages, the write-out time can be quite substantial upon killing the buffer. This can be a noticeable interruption to workflow. It seems to me that index access should be asynchronous at least. If this were the case, then we could get support for mutable sources for free, as we could synchronize against sources without interrupting workflow (although keeping the view in sync with the backend would be a bit tricky). As an aside, it would be quite nice if one could run multiple simultaneous instances of sup. It seems that if one only held write access to the index during writes (is this the case presently?), there should be nothing preventing this from being possible. Correct me if I'm wrong in any part of my above assessment. Hope things are going well, - Ben From ezyang@MIT.EDU Thu Oct 1 13:56:12 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Thu, 01 Oct 2009 13:56:12 -0400 Subject: [sup-talk] Configurable poll time Message-ID: <1254419578-sup-5569@javelin> Hey all, I know William is generally opposed to configuration values, but I think I've found one that would be good to do: DELAY in poll.rb. I specifically have had to reduce this value in order to prevent a naughty IMAP server from silently dropping the connection (and causing sup to consequently hang). I'll cook up a patch if people are receptive. Cheers, Edward From mailinglist@flasht.de Thu Oct 1 14:15:50 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Thu, 01 Oct 2009 20:15:50 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1254415145-sup-635@masanjin.net> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> Message-ID: <1254420802-sup-3742@thinkpad-ubuntu> Excerpts from William Morgan's message of Do Okt 01 18:44:43 +0200 2009: > I have no immediate plans personally, but I would love to have this in > Sup. Alright, good to know. > There is a Ruby-Gettext package, which we already use for other reasons. > I think this is probably the best thing to start with, unless it turns > out to be too hard to use, in which case we could consider a custom > solution. > > http://www.yotabanana.com/hiki/ruby-gettext.html Cool, I'll have a look at it. Another reason for adding this would be that for example gpg's output is different for me (in german) than what sup expects. So trust-paths for example aren't recognized by default, since the regular expression in crypto.rb only looks for english output. I fixed this for myself but I figured it would make more sense to put this kind of stuff to a central location. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From mailinglist@flasht.de Thu Oct 1 14:21:48 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Thu, 01 Oct 2009 20:21:48 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1254415145-sup-635@masanjin.net> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> Message-ID: <1254421306-sup-8840@thinkpad-ubuntu> Excerpts from William Morgan's message of Do Okt 01 18:44:43 +0200 2009: > I have no immediate plans personally, but I would love to have this in > Sup. Ok, great! > There is a Ruby-Gettext package, which we already use for other reasons. > I think this is probably the best thing to start with, unless it turns > out to be too hard to use, in which case we could consider a custom > solution. > > http://www.yotabanana.com/hiki/ruby-gettext.html Thanks, I'll have a look at it. Btw, another reason for adding something like this would be that sup depends on an english version of gpg. For checking a trust-path, for example, it uses a regular expression that checks for a certain output of gpg (in english). Since I have a german version, this obviously doesn't work (I had to patch it for my needs). I guess there probably are more things where different languages could play a role, so putting it in a central, well-defined location makes sense. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 From wmorgan-sup@masanjin.net Thu Oct 1 14:22:44 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 11:22:44 -0700 Subject: [sup-talk] Configurable poll time In-Reply-To: <1254419578-sup-5569@javelin> References: <1254419578-sup-5569@javelin> Message-ID: <1254421340-sup-4697@masanjin.net> Reformatted excerpts from Edward Z. Yang's message of 2009-10-01: > I know William is generally opposed to configuration values, but I > think I've found one that would be good to do: DELAY in poll.rb. I > specifically have had to reduce this value in order to prevent a > naughty IMAP server from silently dropping the connection (and causing > sup to consequently hang). I'd be fine with this one, especially if it were a per-source configuration that lived in sources.yaml. -- William From wmorgan-sup@masanjin.net Thu Oct 1 14:24:57 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 11:24:57 -0700 Subject: [sup-talk] i18n? In-Reply-To: <1254420802-sup-3742@thinkpad-ubuntu> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> Message-ID: <1254421405-sup-8083@masanjin.net> Reformatted excerpts from Christopher Bertels's message of 2009-10-01: > Another reason for adding this would be that for example gpg's output > is different for me (in german) than what sup expects. So trust-paths > for example aren't recognized by default, since the regular expression > in crypto.rb only looks for english output. It will be interesting to see how gettext handles the case of regular expressions (which is also probably what you want for the "attachment" detector). If it's not natural to wedge regexen into gettext, we should consider a custom solution. -- William From wmorgan-sup@masanjin.net Thu Oct 1 14:31:20 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 11:31:20 -0700 Subject: [sup-talk] Crash while scrolling In-Reply-To: <1254418089-sup-5800@ben-laptop> References: <20090911165830.GA11260@ben-laptop> <1252773189-sup-246@masanjin.net> <20090916172340.GA20566@ben-laptop> <1253975267-sup-8308@masanjin.net> <1254160696-sup-3522@ben-laptop> <1254404181-sup-8448@masanjin.net> <1254418089-sup-5800@ben-laptop> Message-ID: <1254421545-sup-8303@masanjin.net> Reformatted excerpts from Ben Gamari's message of 2009-10-01: > It seems that C would definitely be a good start (or perhaps C++ would > be a better idea as that is the language in which Xapian is written). I was proposing that as a strawman argument. C does not solve my problem. > However, I think one of the real issues is the exclusive nature of > index access. In fact, this is one of my primary gripes with the sup > workflow. After processing a large number of messages, the write-out > time can be quite substantial upon killing the buffer. It is possible to address this in a variety of ways, many of which have been discussed over the years, but yes, I agree that a delay is nonideal. > If this were the case, then we could get support for mutable sources > for free, as we could synchronize against sources without interrupting > workflow (although keeping the view in sync with the backend would be > a bit tricky). Making message state saving fast, or backgrounded, is a different beast from scanning over a mailstore. I have been working on a Sup server for quite some time that would address many of these problems, but progress is slow. > As an aside, it would be quite nice if one could run multiple > simultaneous instances of sup. It seems that if one only held write > access to the index during writes (is this the case presently?), there > should be nothing preventing this from being possible. It might be possible to do this with Xapian, especially if there were no expectation of updates being transmitted across processes. With Ferret, if it is possible, it's only with a tremendous amount of effort. -- William From mailinglist@flasht.de Thu Oct 1 14:33:03 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Thu, 01 Oct 2009 20:33:03 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1254415145-sup-635@masanjin.net> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> Message-ID: <1254421963-sup-7532@thinkpad-ubuntu> Please excuse my double posting. Sup crashed after sending a message. I have the exception log attached. Seems like it has a problem with the sent.mbox and wants me to sup-sync --changed sup://sent I switched from ferret to xapian today and the error clearly happens there. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: exception-log.txt URL: From cworth@cworth.org Thu Oct 1 14:41:59 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 01 Oct 2009 11:41:59 -0700 Subject: [sup-talk] Writing time-sensitive portions of sup in C In-Reply-To: <1254418089-sup-5800@ben-laptop> References: <20090911165830.GA11260@ben-laptop> <1252773189-sup-246@masanjin.net> <20090916172340.GA20566@ben-laptop> <1253975267-sup-8308@masanjin.net> <1254160696-sup-3522@ben-laptop> <1254404181-sup-8448@masanjin.net> <1254418089-sup-5800@ben-laptop> Message-ID: <1254421959-sup-9506@yoom.home.cworth.org> Excerpts from Ben Gamari's message of Thu Oct 01 10:44:19 -0700 2009: > Excerpts from William Morgan's message of Thu Oct 01 09:43:48 -0400 2009: > > Here's the idea: scanning over a mailstore is slow. Much of this > > slowness is due to Ruby. So let's rewrite this code in C. Then we would > > have something as fast as, say, Mutt. But Mutt bogs down on my mbox file > > because it's too big. So my *only* reasonable choice with a large > > mailstore is Sup and the assumption that the source is add only. > > It seems that C would definitely be a good start (or perhaps C++ would > be a better idea as that is the language in which Xapian is written). I've started some experiments along these lines, (basically just writing C code (with C++ where necessary) using the Xapian tutorial and little peeks into sup/xapian-index.rb to get the right prefix values, etc.). > However, I think one of the real issues is the exclusive nature of index > access. In fact, this is one of my primary gripes with the sup > workflow. After processing a large number of messages, the write-out > time can be quite substantial upon killing the buffer. This can be a > noticeable interruption to workflow. It seems to me that index access > should be asynchronous at least. What I'm hoping to end up with is a C library that provides asynchronous access to a sup-compatible index. I'll keep you posted if I make any actual progress on this front. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Thu Oct 1 14:43:49 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 01 Oct 2009 11:43:49 -0700 Subject: [sup-talk] [ANN] Sup 0.9 released Message-ID: <1254422532-sup-9948@masanjin.net> I'm pleased to announce the release of Sup 0.9. Sup is a console-based email client for people with a lot of email. It supports tagging, very fast full-text search, automatic contact- list management, and more. If you're the type of person who treats email as an extension of your long-term memory, Sup is for you. Get it: gem install sup Learn it: http://sup.rubyforge.org Love it: sup-talk at rubyforge.org Excitement in 0.9: * Experimental Xapian backend to replace Ferret. Not everything works with it, but it's fast and less likely to barf. See release notes. * New keybinding: "G" for reply-all. * New hook: custom-search, for adding your own query expansions. * Better preemptive thread loading. * Random UI tweaks: display labels before subjects, change thread-view-mode's 'n' and 'p' commands slightly * Better killing of other Sup processes. * Die gracefully upon SIGKILL. * Finally figure out the curses+ruby magic to make SIGWINCH (i.e. xterm resizing) work correctly. * Add a console mode (press ~) for interactively playing with the index. * Finally figure out the curses magic to stop the weird keyboard behavior after leaving the editor. * Improved logging. Logging now supports SUP_LOG_LEVEL environment variable. Set this to "debug" for verbiage. * As always, many bugfixes and tweaks. Release notes: There's a new Xapian backend as an alternative to the Ferret one. It's still in a beta stage. It's much faster and much less prone to the random crashes than Ferret, but certain things don't work yet, most noticeably the unread message counts in label-list-mode. You can switch back and forth between both indexes without harm, *except* any new messages added to the one index won't be picked up by the other. Follow these instructions: To TRY the Xapian index, without screwing Ferret up: 1. sup-dump > dump # takes a while 2. export SUP_INDEX=xapian # or however you do it in your shell 3. sup-sync --all --all-sources --restore dump # takes a long time 4. sup -n # -n ensures that no polling is done. don't hit 'P' either Step 1 will take a long time, and step 3 will take a very long time. At this point, whenever you run Sup, the SUP_INDEX environment variable will determine which index you use. If it's unset, or "ferret", you will use the ferret index. If it's "xapian", the Xapian index. Make sure when you run sup with the Xapian index, you use -n and don't hit 'P', to avoid loading new messages into it. If you want to switch to Xapian permanently, you can then: 1. rm -rf ~/.sup/ferret 2. permanently set SUP_INDEX=xapian according to your shell 3. Run sup as normal, i.e. without -n. If you want to go back to Ferret, you can just rm -rf ~/.sup/xapian and make sure your SUP_INDEX environment variable is unset. -- William From rlane@club.cc.cmu.edu Thu Oct 1 14:47:44 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 01 Oct 2009 14:47:44 -0400 Subject: [sup-talk] i18n? In-Reply-To: <1254421963-sup-7532@thinkpad-ubuntu> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254421963-sup-7532@thinkpad-ubuntu> Message-ID: <1254422768-sup-4646@zyrg.net> Excerpts from Christopher Bertels's message of Thu Oct 01 14:33:03 -0400 2009: > undefined method `[]' for nil:NilClass > /home/bakkdoor/projekte/ruby/sup/lib/sup/xapian_index.rb:558:in `mkterm' What commit is your tree at? From bgamari.foss@gmail.com Thu Oct 1 14:45:20 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Thu, 01 Oct 2009 14:45:20 -0400 Subject: [sup-talk] Crash while loading thread index buffer Message-ID: <1254422128-sup-970@ben-laptop> I just had this[1] crash while loading a buffer with has:lkml. Crash occurs in, @threads = @ts.threads.select { |t| !@hidden_threads[t] }.sort_by { |t| [t.date, t.first.id] }.reverse Is this perhaps the result of an index inconsistency? It seems to me that t.first should never be nil. Seems like sup is very susceptible to these nils slipping in unexpectedly. Is there perhaps a better way to deal with it other than crashing the client? Seems like a pretty extreme measure (although granted, it's a pretty serious issue as well) - Ben [1] Exception log --- RuntimeError from thread: load threads for thread-index-mode wrong id called on nil /opt/exp/sup/lib/sup.rb:17:in `id' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update' /opt/exp/sup/lib/sup/hook.rb:121:in `sort_by' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:637:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background' /opt/exp/sup/lib/sup.rb:77:in `reporting_thread' /opt/exp/sup/lib/sup.rb:75:in `initialize' /opt/exp/sup/lib/sup.rb:75:in `new' /opt/exp/sup/lib/sup.rb:75:in `reporting_thread' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:33:in `spawn_nicely' /opt/exp/sup/lib/sup/modes/label-list-mode.rb:93:in `select_label' /opt/exp/sup/lib/sup/mode.rb:51:in `send' /opt/exp/sup/lib/sup/mode.rb:51:in `handle_input' /opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input' /usr/bin/sup:238 From bgamari.foss@gmail.com Thu Oct 1 15:01:35 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Thu, 01 Oct 2009 15:01:35 -0400 Subject: [sup-talk] Crash while scrolling In-Reply-To: <1254421545-sup-8303@masanjin.net> References: <20090911165830.GA11260@ben-laptop> <1252773189-sup-246@masanjin.net> <20090916172340.GA20566@ben-laptop> <1253975267-sup-8308@masanjin.net> <1254160696-sup-3522@ben-laptop> <1254404181-sup-8448@masanjin.net> <1254418089-sup-5800@ben-laptop> <1254421545-sup-8303@masanjin.net> Message-ID: <1254422805-sup-9288@ben-laptop> Excerpts from William Morgan's message of Thu Oct 01 14:31:20 -0400 2009: > Reformatted excerpts from Ben Gamari's message of 2009-10-01: > > It seems that C would definitely be a good start (or perhaps C++ would > > be a better idea as that is the language in which Xapian is written). > > I was proposing that as a strawman argument. C does not solve my > problem. Certainly, you will never be able to write a message indexer fast enough to index a source instantly. That is why we have an index to begin with. That being said, I think we can do substantially better than we are currently doing in a lower-level language. With mutt, I can come close to saturating my drive bandwidth while loading a folder. While synchronizing in sup, I am lucky to get a few hundred kilobytes/second. Certainly a large amount of that difference has to do with the amount of processing done by each, but even adjusting for this it seems to me that we should still be I/O bound (or at least close to it). > > > However, I think one of the real issues is the exclusive nature of > > index access. In fact, this is one of my primary gripes with the sup > > workflow. After processing a large number of messages, the write-out > > time can be quite substantial upon killing the buffer. > > It is possible to address this in a variety of ways, many of which have > been discussed over the years, but yes, I agree that a delay is > nonideal. Glad we agree. > > Making message state saving fast, or backgrounded, is a different beast > from scanning over a mailstore. If we are unable to update the index while the client is active, rescanning sources would destroy usability. I would argue that asynchronous writeout is very much a prerequisite for mutable sources. > > I have been working on a Sup server for quite some time that would > address many of these problems, but progress is slow. This was largely what I had in mind. It seems like moving index manipulation out-of-process might be best, ultimately. > > > As an aside, it would be quite nice if one could run multiple > > simultaneous instances of sup. It seems that if one only held write > > access to the index during writes (is this the case presently?), there > > should be nothing preventing this from being possible. > > It might be possible to do this with Xapian, especially if there were no > expectation of updates being transmitted across processes. I think initially no updates between processes would be fine. > With Ferret, > if it is possible, it's only with a tremendous amount of effort. Is ferret even going to be supported after the Xapian backend stabilizes? Thanks for the comments and sup. - Ben From mailinglist@flasht.de Thu Oct 1 20:19:35 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Fri, 02 Oct 2009 02:19:35 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1254421405-sup-8083@masanjin.net> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> Message-ID: <1254442420-sup-3771@thinkpad-ubuntu> Excerpts from William Morgan's message of Do Okt 01 20:24:57 +0200 2009: > It will be interesting to see how gettext handles the case of regular > expressions (which is also probably what you want for the "attachment" > detector). If it's not natural to wedge regexen into gettext, we should > consider a custom solution. Hmm. Well I started working on something simple based on yaml files. I looked at gettext but that seemed a little weird to me. Since Ruby's yaml module supports regular expressions, this is a plus point, I guess. It worked with the attachments example. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 902 bytes Desc: not available URL: From olly@survex.com Fri Oct 2 03:57:55 2009 From: olly@survex.com (Olly Betts) Date: Fri, 2 Oct 2009 07:57:55 +0000 (UTC) Subject: [sup-talk] [PATCH] xapian: do less work for update_message_state References: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu> <1254339542-sup-886@masanjin.net> <1254341186-sup-4357@zyrg.net> <1254404707-sup-9253@masanjin.net> <1254416360-sup-8957@zyrg.net> Message-ID: On 2009-10-01, Rich Lane wrote: > Excerpts from William Morgan's message of Thu Oct 01 09:46:20 -0400 2009: >> Reformatted excerpts from Rich Lane's message of 2009-09-30: >> > They're about 3 times faster on my machine with this patch. An >> > optimization the Xapian devs have been planning to make (and that this >> > patch is necessary to take advantage of) should increase performance >> > much more. >> >> Awesome. Out of curiousity, what's the optimization? > > replace_document currently deletes all the old postings and inserts new > ones. It can be optimized to make the minimal set of modifications. This is the ticket for it: http://trac.xapian.org/ticket/250 Cheers, Olly From gregor@hoffleit.de Fri Oct 2 05:25:04 2009 From: gregor@hoffleit.de (Gregor Hoffleit) Date: Fri, 02 Oct 2009 11:25:04 +0200 Subject: [sup-talk] Bug: store_message writes invalid From lines with locales set In-Reply-To: <1254414095-sup-8087@masanjin.net> References: <1254411555-sup-7650@sam> <1254414095-sup-8087@masanjin.net> Message-ID: <1254475145-sup-5397@sam> * William Morgan [Thu Oct 01 18:38:36 +0200 2009] > > Everything worked fine for me in August and September, since those > > month names are spelled the same in German and English ;-). > > You expect your email client to work for more than two months a year? Ok. I admit the right way to fix this would have been to take a time of absence in the months of March, May, October and December. Should have thought about that before complaining ;-). Thanks for the quick fix, Gregor From mailinglist@flasht.de Fri Oct 2 08:52:47 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Fri, 02 Oct 2009 14:52:47 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1254442420-sup-3771@thinkpad-ubuntu> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> Message-ID: <1254487575-sup-5468@thinkpad-ubuntu> I've uploaded what I've done so far to http://www.gitorious.org/~bakkdoor/sup/bakkdoors-clone/trees/i18n You can get it via git here: git://gitorious.org/~bakkdoor/sup/bakkdoors-clone.git (branch: i18n) Please tell me what you think. I know it's pretty simple but for now I guess that's all we need. Or am I missing something? One thing I wanted to add as well is, that if there is no translation found for a different language, it will default to the english version (instead of returning nil). -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 From rlane@club.cc.cmu.edu Fri Oct 2 16:35:42 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Fri, 02 Oct 2009 16:35:42 -0400 Subject: [sup-talk] Bug: Converting the index to xapian fails with a message with very old date In-Reply-To: <1254404956-sup-6574@masanjin.net> References: <1253475875-sup-5119@midna.zekjur.net> <1253973258-sup-3347@masanjin.net> <1254001080-sup-5742@midna.zekjur.net> <1254404956-sup-6574@masanjin.net> Message-ID: <1254513417-sup-8419@zyrg.net> Excerpts from William Morgan's message of Thu Oct 01 09:49:54 -0400 2009: > Reformatted excerpts from Michael Stapelberg's message of 2009-09-26: > > truncated date is Thu Jan 01 01:00:00 +0100 1970 > > date_value is "\200" > > /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `_dump': year too big to marshal > > (ArgumentError) > > from /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `dump' > > from /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `index_message' > > from /usr/lib/ruby/1.8/sup/xapian_index.rb:124:in `sync_message' > > At this point I'm hoping that Rich will chime in. :) This strikes me as a bug in Marshal.dump - it should be able to handle arbitrary dates. I've never messed with custom marshalling functions before, but monkey patching one in could be a workaround. Or we could just truncate the dates before putting them in the index entry. From stettberger@dokucode.de Fri Oct 2 16:48:24 2009 From: stettberger@dokucode.de (Christian Dietrich) Date: Fri, 02 Oct 2009 22:48:24 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1254334371-sup-5145@masanjin.net> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> Message-ID: <1254516195-sup-4619@peer.zerties.org> Excerpts from William Morgan's message of Mi Sep 30 20:17:55 +0200 2009: > Cool idea. I'd like to see how this looks. > > > I tried to implement the feature by my self, but the mapping beetween > > `curpos' and `@threads' in modes/thread-index-mode.rb made this a > > little bit hard, and i didn't know how to solve this problem without > > breaking sup. Perhaps you can give me a hint, how this problem with > > the direct mapping can be solved. > > If you look at #regen_text, @text and @lines are the two variables that > control the display. @text is an array of the GUI elements for each line > of the display. Right now it's just set to one line for each thread. You > want to add one additional element at the appropriate position. for each > date line. GUI elements are represented as arrays of [color, text] > pairs; you can look at #text_for_thread_at for an example. > > Then, you want to make sure that @lines is set correctly. @lines is a > map (hash) from line number to thread (so that when the user presses a > key, we know which thread the cursor is resting on). Thank you, that helped a much. I implemented the feature, it is available at git://github.com/stettberger/sup-mail.git branch time_marks, it is one commit ahead of next. It is enabled with setting the config option ":time_markers_in_index_mode: true" At runtime it can be toggled via '%' (just randomly choosen by me) greetz didi -- No documentation is better than bad documentation -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt. From eg@gaute.vetsj.com Sat Oct 3 06:36:39 2009 From: eg@gaute.vetsj.com (gauteh) Date: Sat, 3 Oct 2009 03:36:39 -0700 (PDT) Subject: [sup-talk] Bug: Xapian exception after having polled Message-ID: <25727581.post@talk.nabble.com> Greetings, Sup fails with the attached backtrace right after having polled the messages. The messages show up in the inbox before it fails, possibly failing before they are shown, but they then show up the next time, before the same exception happens again. It doesn't matter if I have new messages or not. This happenes both in f6873cee9960 and newest; 93b5552730c1 I keep my messages in maildir, synced with offlineimap on a Gmail account. - gaute http://www.nabble.com/file/p25727581/exception-log.txt exception-log.txt -- View this message in context: http://www.nabble.com/Bug%3A-Xapian-exception-after-having-polled-tp25727581p25727581.html Sent from the SUP Talk mailing list archive at Nabble.com. From tarko@lanparty.ee Sat Oct 3 06:31:16 2009 From: tarko@lanparty.ee (Tarko Tikan) Date: Sat, 03 Oct 2009 13:31:16 +0300 Subject: [sup-talk] labels-before-subject and ask_for_contacts config knobs Message-ID: <1254565800-sup-5590@lanparty.ee> hey, First, 0.9 is nice, thanks for that. I want to ask the list about a thing (2 things actually, since 0.9) that has been bugging me. ask_for_contacts is loading 10 contacts from index, imho this doesn't make a sane default (it's too low). I've always patched this to 500 on my end - yes, it takes a second or two to load that many contacts from index but this doesn't bug me as much as first looking up the person and then composing to him. second, since labels-before-subject was integrated, it's hard to follow thread index on small screen. Most of my inbox is tagged with 3 labels, mailing-list could be tagged with up to 5 labels. The problem is especially bad on very small screens (like mobiles with ssh clients). I'm tempted to submit a patch that enables to tune these behaviors via config. I don't find these hook-worthy as first is just a integer (default must stay reasonably low for people with slower computers) and second only makes sense together with full thread-index line customization (I'm not sure about the performance impact or complexity it might bring). Anyone else sharing my view or I just keep patching on my end? :) -- tarko From rlane@club.cc.cmu.edu Sat Oct 3 14:19:57 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 3 Oct 2009 11:19:57 -0700 Subject: [sup-talk] [PATCH] don't downcase a nil content-type Message-ID: <1254593997-32634-1-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/message.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/message.rb b/lib/sup/message.rb index 979597a..cbedb33 100644 --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -501,7 +501,7 @@ private # Lowercase the filename because searches are easier that way @attachments.push filename.downcase unless filename =~ /^sup-attachment-/ add_label :attachment unless filename =~ /^sup-attachment-/ - content_type = m.header.content_type.downcase || "application/unknown" # sometimes RubyMail gives us nil + content_type = (m.header.content_type || "application/unknown").downcase # sometimes RubyMail gives us nil [Chunk::Attachment.new(content_type, filename, m, sibling_types)] ## otherwise, it's body text -- 1.6.4.2 From rlane@club.cc.cmu.edu Sat Oct 3 14:22:34 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 03 Oct 2009 14:22:34 -0400 Subject: [sup-talk] Bug: Xapian exception after having polled In-Reply-To: <25727581.post@talk.nabble.com> References: <25727581.post@talk.nabble.com> Message-ID: <1254594099-sup-719@zyrg.net> Apply the attached patch and let us know what the new backtrace is. -------------- next part -------------- A non-text attachment was scrubbed... Name: nil-msgid-asserts.patch Type: application/octet-stream Size: 1254 bytes Desc: not available URL: From guillaume.quintard@gmail.com Sat Oct 3 16:04:14 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Sat, 3 Oct 2009 22:04:14 +0200 Subject: [sup-talk] Crash, bad index, and ensuing misery Message-ID: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com> Hi, I crash my computer with sup running, and it seems the index didn't really like. sup-sync -a didn't help, what can I do? --- RuntimeError from thread: load threads for thread-index-mode DocNotFoundError: Document 2461178145 not found. ./lib/sup/xapian_index.rb:132:in `document' ./lib/sup/xapian_index.rb:132:in `each_message_in_thread_for' ./lib/sup/xapian_index.rb:132:in `map' ./lib/sup/xapian_index.rb:132:in `each_message_in_thread_for' ./lib/sup/thread.rb:341:in `load_thread_for_message' ./lib/sup/thread.rb:333:in `load_n_threads' ./lib/sup/xapian_index.rb:117:in `each_id_by_date' ./lib/sup/xapian_index.rb:110:in `each_id' ./lib/sup/xapian_index.rb:110:in `each' ./lib/sup/xapian_index.rb:110:in `each_id' ./lib/sup/xapian_index.rb:117:in `each_id_by_date' ./lib/sup/thread.rb:328:in `load_n_threads' ./lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' ./lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background' ./lib/sup.rb:77:in `reporting_thread' ./lib/sup.rb:75:in `initialize' ./lib/sup.rb:75:in `new' ./lib/sup.rb:75:in `reporting_thread' ./lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' ./lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' bin/sup:197 -- Guillaume From rlane@club.cc.cmu.edu Sat Oct 3 16:17:54 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 03 Oct 2009 16:17:54 -0400 Subject: [sup-talk] Crash, bad index, and ensuing misery In-Reply-To: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com> References: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com> Message-ID: <1254600926-sup-5190@zyrg.net> Excerpts from Guillaume Quintard's message of Sat Oct 03 16:04:14 -0400 2009: > Hi, I crash my computer with sup running, and it seems the index > didn't really like. sup-sync -a didn't help, what can I do? I'd hoped this kind of corruption wouldn't be possible with newer xapian-index versions. What sup commit are you on? What version of Xapian are you using? Which Xapian backend, Flint or Chert? From marco-oweber@gmx.de Sat Oct 3 16:49:40 2009 From: marco-oweber@gmx.de (Marc Weber) Date: Sat, 03 Oct 2009 22:49:40 +0200 Subject: [sup-talk] next search in buffer view.. Message-ID: <1254602805-sup-2900@nixos> buffer.rb def handle_input c if @focus_buf if @focus_buf.mode.in_search? && c != CONTINUE_IN_BUFFER_SEARCH_KEY[0] @focus_buf.mode.cancel_search! @focus_buf.mark_dirty end @focus_buf.mode.handle_input c end end Why is the search canceled when typing any other char? That's really annoying because there are some mails I have to use the same search multiple times. However I also have to scroll up /down to see enough context. So why has this been implemented? Is it safe to remove that if statement? Seems to work for me. It would be better if the next search would continue from the current line rather than the last search result. I'd like to see 'N' (search backward) as well. If you like these ideas I'm going to supply a patch. Comments? Marc Weber From guillaume.quintard@gmail.com Sat Oct 3 17:06:36 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Sat, 3 Oct 2009 23:06:36 +0200 Subject: [sup-talk] Crash, bad index, and ensuing misery In-Reply-To: <1254600926-sup-5190@zyrg.net> References: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com> <1254600926-sup-5190@zyrg.net> Message-ID: <1e5fdab70910031406x713fad49ubb42b42463899c87@mail.gmail.com> On Sat, Oct 3, 2009 at 10:17 PM, Rich Lane wrote: > I'd hoped this kind of corruption wouldn't be possible with newer > xapian-index versions. What sup commit are you on? What version of > Xapian are you using? Which Xapian backend, Flint or Chert? > ubuntu 9.10 libxapian-ruby1.8 1.0.14-1 I'd say flink since I often have to remove flintlock after sup commiting suicide. and git status says # On branch next # Your branch is ahead of 'origin/next' by 6 commits. (ahead?) -- Guillaume From rlane@club.cc.cmu.edu Sat Oct 3 17:39:42 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 03 Oct 2009 17:39:42 -0400 Subject: [sup-talk] Crash, bad index, and ensuing misery In-Reply-To: <1e5fdab70910031406x713fad49ubb42b42463899c87@mail.gmail.com> References: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com> <1254600926-sup-5190@zyrg.net> <1e5fdab70910031406x713fad49ubb42b42463899c87@mail.gmail.com> Message-ID: <1254605615-sup-5636@zyrg.net> Excerpts from Guillaume Quintard's message of Sat Oct 03 17:06:36 -0400 2009: > On Sat, Oct 3, 2009 at 10:17 PM, Rich Lane wrote: > > I'd hoped this kind of corruption wouldn't be possible with newer > > xapian-index versions. What sup commit are you on? What version of > > Xapian are you using? Which Xapian backend, Flint or Chert? > > > > ubuntu 9.10 > libxapian-ruby1.8 1.0.14-1 > I'd say flink since I often have to remove flintlock after sup > commiting suicide. > > and git status says > # On branch next > # Your branch is ahead of 'origin/next' by 6 commits. > > (ahead?) > Please post the output of "git log --pretty=oneline 'origin/next^'.." From guillaume.quintard@gmail.com Sat Oct 3 17:54:28 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Sat, 3 Oct 2009 23:54:28 +0200 Subject: [sup-talk] Crash, bad index, and ensuing misery In-Reply-To: <1254605615-sup-5636@zyrg.net> References: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com> <1254600926-sup-5190@zyrg.net> <1e5fdab70910031406x713fad49ubb42b42463899c87@mail.gmail.com> <1254605615-sup-5636@zyrg.net> Message-ID: <1e5fdab70910031454n28c57ae5m1f33f10f4e4acaab@mail.gmail.com> On Sat, Oct 3, 2009 at 11:39 PM, Rich Lane wrote: > Please post the output of "git log --pretty=oneline 'origin/next^'.." > here you go 80789d873ac555bb1979f7734e95f104d848007e Merge branch 'next' of git://gitorious.org/sup/mainline into next 0eee0973223b625b66e30c196ccd45d2f7bf358b Merge branch 'master' into next 93b5552730c10e2a352bd33f5ee98800bcd8679e more release-script updates d1eabf9cb21940b933464ab3efc25df3c1a5f7e1 Merge branch 'next' of git://gitorious.org/sup/mainline into next df96980d0573cf91742a8f9ae5e8a49366d338b8 Merge branch 'next' of git://gitorious.org/sup/mainline into next a6dcb02dda7dd8bb1742890d460b1b0abfc28454 Merge branch 'next' of git://gitorious.org/sup/mainline into next 823148627f554fbf5a7fb13379567276eeee14c7 Merge branch 'next' of git://gitorious.org/sup/mainline into next 40ecc407a8aacf16d7f9f104501311cfd1fb2eb7 Revert "Merge branch 'after-add-message-hook' into next" -- Guillaume From rlane@club.cc.cmu.edu Sat Oct 3 18:25:19 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 03 Oct 2009 18:25:19 -0400 Subject: [sup-talk] Crash, bad index, and ensuing misery In-Reply-To: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com> References: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com> Message-ID: <1254607735-sup-864@zyrg.net> Excerpts from Guillaume Quintard's message of Sat Oct 03 16:04:14 -0400 2009: > --- RuntimeError from thread: load threads for thread-index-mode > DocNotFoundError: Document 2461178145 not found. > ./lib/sup/xapian_index.rb:132:in `document' The relevant line: docs = term_docids(mkterm(:thread, thread_id)).map { |x| @xapian.document x } Basically expands to: @xapian.postlist(term).map { |x| @xapian.document x.docid } So, Xapian is giving us docids it can't turn into documents. At this point I think you should just do a sup-dump (which might still work), move the old xapian directory out of the way, and re-sync. You can try running xapian-check on the corrupted version to see if it finds anything interesting. From nicolas.pouillard@gmail.com Sun Oct 4 08:36:02 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Sun, 04 Oct 2009 14:36:02 +0200 Subject: [sup-talk] Simple E-Mail Delaying Message-ID: <1254659599-sup-7377@peray> Hi all, I've written a blog post about improving my email experience. And since it interacts nicely with sup it may be of some interest for you. Best Regards, -- Nicolas Pouillard http://nicolaspouillard.fr From marcus-sup@bar-coded.net Sun Oct 4 10:42:37 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Sun, 04 Oct 2009 15:42:37 +0100 Subject: [sup-talk] labels-before-subject and ask_for_contacts config knobs In-Reply-To: <1254565800-sup-5590@lanparty.ee> References: <1254565800-sup-5590@lanparty.ee> Message-ID: <1254667184-sup-153@bar-coded.net> On 3.10.2009, Tarko Tikan wrote: > second, since labels-before-subject was integrated, it's hard to follow thread > index on small screen. Most of my inbox is tagged with 3 labels, mailing-list > could be tagged with up to 5 labels. The problem is especially bad on very > small screens (like mobiles with ssh clients). If you search through the archives you should find a patch I submitted for an alternate view. The default alternate view I find very good on smaller devices and its configurable via a hook if you want anything more. Not sure if its going to get integrated into sup though (Any thoughts William? - I can resubmit if necessary) You would need to change the keypress from "~" to something that isnt taken (currently thats taken as a console view). HTH Marcus From sgoldman@tower-research.com Sun Oct 4 10:46:40 2009 From: sgoldman@tower-research.com (Steve Goldman) Date: Sun, 04 Oct 2009 10:46:40 -0400 Subject: [sup-talk] Simple E-Mail Delaying In-Reply-To: <1254659599-sup-7377@peray> References: <1254659599-sup-7377@peray> Message-ID: <1254667426-sup-9509@sgoldmanlinux.tower-research.com> Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009: > Hi all, > > I've written a blog post about improving my email experience. And since it > interacts nicely with sup it may be of some interest for you. > > Best Regards, > This is brilliant. Can you help me get it work? What defines FULLEMAIL? I can't get the script past that. (I'm not on the latest sup checkout, but i grepped the next branch for FULLEMAIL and didn't see anything.) Thanks. -- Steve Goldman sgoldman at tower-research.com T: 212.219.6014 F: 212.219.6007 Tower Research Capital, LLC 377 Broadway, 11th Fl. New York, NY 10013 From web-sup@superscript.com Sun Oct 4 11:51:51 2009 From: web-sup@superscript.com (William Baxter) Date: Sun, 04 Oct 2009 11:51:51 -0400 Subject: [sup-talk] Simple E-Mail Delaying In-Reply-To: <1254659599-sup-7377@peray> References: <1254659599-sup-7377@peray> Message-ID: <1254671303-sup-2911@kronos> Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009: > I've written a blog post about improving my email experience. And since it > interacts nicely with sup it may be of some interest for you. I also employ a tickler system in sup, one that relies exclusively on labels. To mark a thread for review on day DD of the month, label it with #DD. Obviously this extends forward only one month. I have not found that problematic. I also use #E to indicate the need to reply, #W as waiting for something, #A for action required, etc. The choice of # came from two considerations. First, it sorts before letters. Second, it does not require quoting in searches. The date labels could do without the prefix, but I began with the # labels, and like the way that the common prefix sets these elements apart in label-list-mode. Cheers, W. From gigabo@gmail.com Sun Oct 4 12:23:17 2009 From: gigabo@gmail.com (Bo Borgerson) Date: Sun, 04 Oct 2009 12:23:17 -0400 Subject: [sup-talk] [PATCH] Handle added messages in label-list-mode In-Reply-To: <1254415913-sup-6275@masanjin.net> References: <1252789445-30193-1-git-send-email-gigabo@gmail.com> <1254415913-sup-6275@masanjin.net> Message-ID: <1254669536-sup-2700@longword> Excerpts from William Morgan's message of Thu Oct 01 12:53:15 -0400 2009: > Reformatted excerpts from Bo Borgerson's message of 2009-09-12: > > Register label-list-mode with the UpdateManager and handle added > > updates with a reload to keep unread message counts up to date > > Branch label-list-mode-auto-update, merged into next. > Hi William. Thanks for looking at this. > I'm a little concerned with performance, but we'll see how it goes. > Yeah, I think I might be spoiled by my relatively few messages / labels. If it turns out to be an issue maybe it could be made toggle-able with a key-press? (Default off / configurable)? I actually use the label-list-mode as my "home" screen. I like it to stay up-to-date so I can quickly scan which labels have new messages. Incidentally the recent discussion in another thread about making the inbox more like other labels resonates with me. My workflow for all other labels is just to 'x' out when I'm done, but with the inbox I have to '$'ave and 'B'uffer-switch. > What do you think about handling labeled and deleted updates as well? Is there a way to label or delete threads without leaving the label-list-mode? There's already a refresh when switching back to the label-list-mode from elsewhere, I think, so any changes that are $aved should be reflected immediately when you get back. Labels added automatically in a before-add-message hook should already be present when the 'added' update event is received, right? I'm not trying to argue against adding handlers for labeled and deleted updates. I just want to make sure I understand the use cases so I know how to test. Thanks, Bo From rlane@club.cc.cmu.edu Sun Oct 4 14:45:55 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 04 Oct 2009 14:45:55 -0400 Subject: [sup-talk] Bug: Xapian exception after having polled In-Reply-To: <20091004101550.GA7330@qwerzila.bluecom.no> References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net> <20091004101550.GA7330@qwerzila.bluecom.no> Message-ID: <1254681739-sup-4089@zyrg.net> Ok, I've attached a patch with more assertions. Also, can you try with a clean checkout of next and see if the problem still occurs? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-more-id-assertions.patch Type: application/octet-stream Size: 1695 bytes Desc: not available URL: From eg@gaute.vetsj.com Sun Oct 4 14:56:31 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Sun, 4 Oct 2009 20:56:31 +0200 Subject: [sup-talk] Bug: Xapian exception after having polled In-Reply-To: <1254681739-sup-4089@zyrg.net> References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net> <20091004101550.GA7330@qwerzila.bluecom.no> <1254681739-sup-4089@zyrg.net> Message-ID: <5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com> Still having problems, but got a bit more output, see attached exception.log [sup.git](next) $ git log --oneline -6 a209178 more id assertions 0eee097 Merge branch 'master' into next 93b5552 more release-script updates f56badb Merge branch 'master' into next b9071e5 change date for 0.9 release 9a5c0d1 Merge branch 'save-all-attachments' into next - gaute On Sun, Oct 4, 2009 at 8:45 PM, Rich Lane wrote: > Ok, I've attached a patch with more assertions. Also, can you try with a clean > checkout of next and see if the problem still occurs? > -------------- next part -------------- --- RuntimeError from thread: main @id nil /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in `build_from_source' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in `each_message_from' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in `each_message_from' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:73:in `reporting_thread' /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287 /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load' /home/gaute/.gem/ruby/1.8/bin/sup:19 From rlane@club.cc.cmu.edu Sun Oct 4 15:03:51 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 04 Oct 2009 15:03:51 -0400 Subject: [sup-talk] Bug: Xapian exception after having polled In-Reply-To: <5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com> References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net> <20091004101550.GA7330@qwerzila.bluecom.no> <1254681739-sup-4089@zyrg.net> <5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com> Message-ID: <1254682966-sup-6629@zyrg.net> Oops, sorry, bad assertions. Please move the two in self.build_from_source to the end of load_from_source!. Excerpts from Gaute Hope's message of Sun Oct 04 14:56:31 -0400 2009: > Still having problems, but got a bit more output, see attached exception.log > > [sup.git](next) $ git log --oneline -6 > a209178 more id assertions > 0eee097 Merge branch 'master' into next > 93b5552 more release-script updates > f56badb Merge branch 'master' into next > b9071e5 change date for 0.9 release > 9a5c0d1 Merge branch 'save-all-attachments' into next > > - gaute > > On Sun, Oct 4, 2009 at 8:45 PM, Rich Lane wrote: > > Ok, I've attached a patch with more assertions. Also, can you try with a clean > > checkout of next and see if the problem still occurs? > > > --- RuntimeError from thread: main > @id nil > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in > `build_from_source' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in > `each_message_from' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in > `each_message_from' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' > /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:73:in `reporting_thread' > /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287 > /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load' > /home/gaute/.gem/ruby/1.8/bin/sup:19 From eg@gaute.vetsj.com Sun Oct 4 15:20:50 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Sun, 4 Oct 2009 21:20:50 +0200 Subject: [sup-talk] Bug: Xapian exception after having polled In-Reply-To: <1254682966-sup-6629@zyrg.net> References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net> <20091004101550.GA7330@qwerzila.bluecom.no> <1254681739-sup-4089@zyrg.net> <5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com> <1254682966-sup-6629@zyrg.net> Message-ID: <5a5b14cf0910041220p26a4c830va172df0e33542480@mail.gmail.com> Still the same.. (run without '-n' then P this time, thats the reason for the longer exception..) [sup.git](next-nil) $ git log --oneline -4 7e99810 for your confirmation.. eafea2b more id assertions 0eee097 Merge branch 'master' into next 93b5552 more release-script updates - gaute On Sun, Oct 4, 2009 at 9:03 PM, Rich Lane wrote: > Oops, sorry, bad assertions. Please move the two in > self.build_from_source to the end of load_from_source!. > > Excerpts from Gaute Hope's message of Sun Oct 04 14:56:31 -0400 2009: >> Still having problems, but got a bit more output, see attached exception.log >> >> [sup.git](next) $ git log --oneline -6 >> a209178 more id assertions >> 0eee097 Merge branch 'master' into next >> 93b5552 more release-script updates >> f56badb Merge branch 'master' into next >> b9071e5 change date for 0.9 release >> 9a5c0d1 Merge branch 'save-all-attachments' into next >> >> - gaute >> >> On Sun, Oct 4, 2009 at 8:45 PM, Rich Lane wrote: >> > Ok, I've attached a patch with more assertions. Also, can you try with a clean >> > checkout of next and see if the problem still occurs? >> > >> --- RuntimeError from thread: main >> @id nil >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in >> `build_from_source' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in >> `each_message_from' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in >> `each_message_from' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:73:in `reporting_thread' >> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287 >> /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load' >> /home/gaute/.gem/ruby/1.8/bin/sup:19 > -------------- next part -------------- --- RuntimeError from thread: poll after loading inbox @id nil /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:254:in `load_from_source!' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in `build_from_source' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in `each_message_from' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/source.rb:104:in `each' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in `each_message_from' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `initialize' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `new' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread' /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in `call' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in `__unprotected_load_threads' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in `call' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in `load_n_threads_background' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `initialize' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `new' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197 /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load' /home/gaute/.gem/ruby/1.8/bin/sup:19 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-for-your-confirmation.patch Type: text/x-patch Size: 1346 bytes Desc: not available URL: From guillaume.quintard@gmail.com Sun Oct 4 15:59:44 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Sun, 4 Oct 2009 21:59:44 +0200 Subject: [sup-talk] Crash while scrolling In-Reply-To: <20090911165830.GA11260@ben-laptop> References: <20090911165830.GA11260@ben-laptop> Message-ID: <1e5fdab70910041259j40ceaaeue4473d17136a5efc@mail.gmail.com> On Fri, Sep 11, 2009 at 6:58 PM, Ben Gamari wrote: > I can also produce a very similar crash[2] by attempting to load all > threads. Thanks, I get the same thing when loading all the threads. Index has just been rebuilt, and I'm using an mbox file. -- Guillaume From marco-oweber@gmx.de Sun Oct 4 16:55:42 2009 From: marco-oweber@gmx.de (Marc Weber) Date: Sun, 04 Oct 2009 22:55:42 +0200 Subject: [sup-talk] next search in buffer view.. In-Reply-To: <1254602805-sup-2900@nixos> References: <1254602805-sup-2900@nixos> Message-ID: <1254689522-sup-2800@nixos> Mmh. Maybe its not that a bad idea to keep the search mode. However it would be nice to provide the last search term as default. This minimal patch adds this feature. However the search_query_input should be global. So where is the place to add this "last-search-term" ? Isn't it already present in the ask history? Can you give me a hint to find it faster? Marc Weber diff --git a/lib/sup/modes/scroll-mode.rb b/lib/sup/modes/scroll-mode.rb index c131425..a97f13c 100644 --- a/lib/sup/modes/scroll-mode.rb +++ b/lib/sup/modes/scroll-mode.rb @@ -35,6 +35,7 @@ class ScrollMode < Mode @slip_rows = opts[:slip_rows] || 0 # when we pgup/pgdown, # how many lines do we keep? @twiddles = opts.member?(:twiddles) ? opts[:twiddles] : true + @search_query_input = "" @search_query = nil @search_line = nil @status = "" @@ -81,9 +82,10 @@ class ScrollMode < Mode end def search_in_buffer - query = BufferManager.ask :search, "search in buffer: " + query = BufferManager.ask :search, "search in buffer: ", @search_query_input return if query.nil? || query.empty? @search_query = Regexp.escape query + @search_query_input = query continue_search_in_buffer end From nicolas.pouillard@gmail.com Mon Oct 5 03:55:09 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 05 Oct 2009 09:55:09 +0200 Subject: [sup-talk] Simple E-Mail Delaying In-Reply-To: <1254667426-sup-9509@sgoldmanlinux.tower-research.com> References: <1254659599-sup-7377@peray> <1254667426-sup-9509@sgoldmanlinux.tower-research.com> Message-ID: <1254728881-sup-3528@peray> Excerpts from Steve Goldman's message of Sun Oct 04 16:46:40 +0200 2009: > Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009: > > Hi all, > > > > I've written a blog post about improving my email experience. And since it > > interacts nicely with sup it may be of some interest for you. > > > > Best Regards, > > > > This is brilliant. > > Can you help me get it work? Of course. > What defines FULLEMAIL? I can't get the script past that. I defined it in my shell profile (.zshrc actually), export FULLEMAIL="Nicolas Pouillard " I know that is not standard, and I can be easily convinced to support something more portable. In my .zshrc I have $EMAIL, $MAILADDR as well. -- Nicolas Pouillard http://nicolaspouillard.fr From nicolas.pouillard@gmail.com Mon Oct 5 03:59:45 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 05 Oct 2009 09:59:45 +0200 Subject: [sup-talk] Simple E-Mail Delaying In-Reply-To: <1254671303-sup-2911@kronos> References: <1254659599-sup-7377@peray> <1254671303-sup-2911@kronos> Message-ID: <1254729313-sup-1910@peray> Excerpts from William Baxter's message of Sun Oct 04 17:51:51 +0200 2009: > Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009: > > I've written a blog post about improving my email experience. And since it > > interacts nicely with sup it may be of some interest for you. > > I also employ a tickler system in sup, one that relies exclusively on labels. > To mark a thread for review on day DD of the month, label it with #DD. > Obviously this extends forward only one month. I have not found that > problematic. I also use #E to indicate the need to reply, #W as waiting for > something, #A for action required, etc. > > The choice of # came from two considerations. First, it sorts before letters. > Second, it does not require quoting in searches. The date labels could do > without the prefix, but I began with the # labels, and like the way > that the common prefix sets these elements apart in label-list-mode. Thanks for the tip! I already use a "pending" label for a mix of "waiting", "need to reply", and "action required". I'm thinking about switching to shorter and more distinct naming like yours. However I like the system proposed because it is event based and can be more fine grained than "a day of the month". Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr From mailinglist@flasht.de Mon Oct 5 12:00:25 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Mon, 05 Oct 2009 18:00:25 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1254487575-sup-5468@thinkpad-ubuntu> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> Message-ID: <1254758256-sup-7400@thinkpad-ubuntu> I think I've translated most of sup's UI-related part (translating error messages doesn't seem like a good idea, since we really don't want multilingual bug-reports and exception logs...) I'd like to hear some feedback and/or opinions/suggestions and would like to see it integrated into sup. I'll add more translations, if I find anything I havent missed yet and that is part of the user interface. Cheers, Christopher. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 From eg@gaute.vetsj.com Mon Oct 5 18:01:18 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Tue, 06 Oct 2009 00:01:18 +0200 Subject: [sup-talk] Bug: Xapian exception after having polled In-Reply-To: <5a5b14cf0910041220p26a4c830va172df0e33542480@mail.gmail.com> References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net> <20091004101550.GA7330@qwerzila.bluecom.no> <1254681739-sup-4089@zyrg.net> <5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com> <1254682966-sup-6629@zyrg.net> <5a5b14cf0910041220p26a4c830va172df0e33542480@mail.gmail.com> Message-ID: <1254780036-sup-3214@qwerzila> Did a 'sup-sync --changed -o' and the problem seems to be gone. - gaute Excerpts from Gaute Hope's message of su. okt. 04 21:20:50 +0200 2009: > Still the same.. > > (run without '-n' then P this time, thats the reason for the longer exception..) > > [sup.git](next-nil) $ git log --oneline -4 > 7e99810 for your confirmation.. > eafea2b more id assertions > 0eee097 Merge branch 'master' into next > 93b5552 more release-script updates > > - gaute > > On Sun, Oct 4, 2009 at 9:03 PM, Rich Lane wrote: > > Oops, sorry, bad assertions. Please move the two in > > self.build_from_source to the end of load_from_source!. > > > > Excerpts from Gaute Hope's message of Sun Oct 04 14:56:31 -0400 2009: > >> Still having problems, but got a bit more output, see attached exception.log > >> > >> [sup.git](next) $ git log --oneline -6 > >> a209178 more id assertions > >> 0eee097 Merge branch 'master' into next > >> 93b5552 more release-script updates > >> f56badb Merge branch 'master' into next > >> b9071e5 change date for 0.9 release > >> 9a5c0d1 Merge branch 'save-all-attachments' into next > >> > >> - gaute > >> > >> On Sun, Oct 4, 2009 at 8:45 PM, Rich Lane wrote: > >> > Ok, I've attached a patch with more assertions. Also, can you try with a clean > >> > checkout of next and see if the problem still occurs? > >> > > >> --- RuntimeError from thread: main > >> @id nil > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in > >> `build_from_source' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in > >> `each_message_from' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in > >> `each_message_from' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:73:in `reporting_thread' > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287 > >> /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load' > >> /home/gaute/.gem/ruby/1.8/bin/sup:19 > > > --- RuntimeError from thread: poll after loading inbox > @id nil > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:254:in > `load_from_source!' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in > `build_from_source' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in > `each_message_from' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/source.rb:104:in `each' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in > `each_message_from' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' > /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `initialize' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `new' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread' > /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in > `call' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in > `__unprotected_load_threads' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in > `call' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in > `load_n_threads_background' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `initialize' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `new' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in > `load_n_threads_background' > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:679:in > `__unprotected_load_threads' > (eval):12:in `load_threads' > /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197 > /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load' > /home/gaute/.gem/ruby/1.8/bin/sup:19 From nicolas.pouillard@gmail.com Mon Oct 5 18:11:17 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Tue, 06 Oct 2009 00:11:17 +0200 Subject: [sup-talk] Simple E-Mail Delaying In-Reply-To: <1254728881-sup-3528@peray> References: <1254659599-sup-7377@peray> <1254667426-sup-9509@sgoldmanlinux.tower-research.com> <1254728881-sup-3528@peray> Message-ID: <1254780524-sup-6949@peray> Excerpts from Nicolas Pouillard's message of Mon Oct 05 09:55:09 +0200 2009: > Excerpts from Steve Goldman's message of Sun Oct 04 16:46:40 +0200 2009: > > Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009: > > > Hi all, > > > > > > I've written a blog post about improving my email experience. And since it > > > interacts nicely with sup it may be of some interest for you. > > > > > > Best Regards, > > > > > > > This is brilliant. > > > > Can you help me get it work? > > Of course. > > > What defines FULLEMAIL? I can't get the script past that. > > I defined it in my shell profile (.zshrc actually), > > export FULLEMAIL="Nicolas Pouillard " > > I know that is not standard, and I can be easily convinced to support > something more portable. > > In my .zshrc I have $EMAIL, $MAILADDR as well. I have updated my gist [1], to reflect two changes the first is to set the date at the sending time (not when running email-reminder) and the second is to use $EMAIL and $REALNAME which are a bit more self-explanatory. [1]: http://gist.github.com/199197 -- Nicolas Pouillard http://nicolaspouillard.fr From guillaume.quintard@gmail.com Tue Oct 6 06:14:43 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Tue, 6 Oct 2009 12:14:43 +0200 Subject: [sup-talk] Bug: Xapian exception after having polled In-Reply-To: <1254780036-sup-3214@qwerzila> References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net> <20091004101550.GA7330@qwerzila.bluecom.no> <1254681739-sup-4089@zyrg.net> <5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com> <1254682966-sup-6629@zyrg.net> <5a5b14cf0910041220p26a4c830va172df0e33542480@mail.gmail.com> <1254780036-sup-3214@qwerzila> Message-ID: <1e5fdab70910060314i6a4cce5ck92e7605ec54f98a1@mail.gmail.com> On Tue, Oct 6, 2009 at 12:01 AM, Gaute Hope wrote: > Did a 'sup-sync --changed -o' and the problem seems to be gone. It doesn't for me. During sup-sync I get this: [Tue Oct 06 11:22:55 +0200 2009] hook: error running hook: cannot generate tempfile `/tmp/12016-9-attachments/389068.html' [Tue Oct 06 11:22:55 +0200 2009] hook: /usr/lib/ruby/1.8/tempfile.rb:52:in `initialize' ./lib/sup/message-chunks.rb:149:in `new' ./lib/sup/message-chunks.rb:149:in `write_to_disk' ./lib/sup/message-chunks.rb:105:in `initialize' ./lib/sup/hook.rb:51:in `call' ./lib/sup/hook.rb:51:in `filename' /home/shivan/.sup/hooks/mime-decode.rb:4:in `__run' ./lib/sup/hook.rb:42:in `__run' ./lib/sup/hook.rb:82:in `run' ./lib/sup/util.rb:520:in `send' ./lib/sup/util.rb:520:in `method_missing' ./lib/sup/message-chunks.rb:104:in `initialize' ./lib/sup/message.rb:503:in `new' ./lib/sup/message.rb:503:in `message_to_chunks' ./lib/sup/message.rb:435:in `message_to_chunks' ./lib/sup/message.rb:435:in `map' ./lib/sup/message.rb:435:in `message_to_chunks' ./lib/sup/message.rb:239:in `load_from_source!' ./lib/sup/message.rb:335:in `build_from_source' ./lib/sup/poll.rb:160:in `each_message_from' ./lib/sup/source.rb:104:in `each' ./lib/sup/util.rb:560:in `send' ./lib/sup/util.rb:560:in `__pass' ./lib/sup/util.rb:547:in `method_missing' ./lib/sup/poll.rb:154:in `each_message_from' ./lib/sup/util.rb:520:in `send' ./lib/sup/util.rb:520:in `method_missing' bin/sup-sync:146 bin/sup-sync:141:in `each' bin/sup-sync:141 I got rid of the hooks, ran sup-sync again, the message goes away, but I still get: --- RuntimeError from thread: load threads for thread-index-mode wrong id called on nil ./lib/sup.rb:17:in `id' ./lib/sup/modes/thread-index-mode.rb:225:in `update' ./lib/sup/hook.rb:121:in `sort_by' ./lib/sup/modes/thread-index-mode.rb:225:in `each' ./lib/sup/modes/thread-index-mode.rb:225:in `sort_by' ./lib/sup/modes/thread-index-mode.rb:225:in `update' ./lib/sup/modes/thread-index-mode.rb:223:in `synchronize' ./lib/sup/modes/thread-index-mode.rb:223:in `update' ./lib/sup/modes/thread-index-mode.rb:637:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' ./lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background' ./lib/sup.rb:77:in `reporting_thread' ./lib/sup.rb:75:in `initialize' ./lib/sup.rb:75:in `new' ./lib/sup.rb:75:in `reporting_thread' ./lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' ./lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' bin/sup:197 upon loading -- Guillaume From olly@survex.com Tue Oct 6 08:40:25 2009 From: olly@survex.com (Olly Betts) Date: Tue, 6 Oct 2009 12:40:25 +0000 (UTC) Subject: [sup-talk] Crash, bad index, and ensuing misery References: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com> <1254600926-sup-5190@zyrg.net> <1e5fdab70910031406x713fad49ubb42b42463899c87@mail.gmail.com> Message-ID: Guillaume Quintard writes: > On Sat, Oct 3, 2009 at 10:17 PM, Rich Lane club.cc.cmu.edu> wrote: > > I'd hoped this kind of corruption wouldn't be possible with newer > > xapian-index versions. What sup commit are you on? What version of > > Xapian are you using? Which Xapian backend, Flint or Chert? > > ubuntu 9.10 > libxapian-ruby1.8 1.0.14-1 > I'd say flink since I often have to remove flintlock after sup > commiting suicide. NEVER EVER remove the flintlock file. It's not the presence of the file which determines the lock, but rather whether there's an fcntl() lock on it, so removing it smashes any lock which is currently held, but leaves the process which held it thinking it still has exclusive write access to the database, which will likely quickly lead to a corrupt database, especially if you're doing so because Xapian says the database is already locked. If Xapian says that, then there really is a process which still has the database open for writing. My guess is that removing the flintlock file is the cause of the corruption you're seeing. Can you reproduce it on a database where you haven't removed this file? Also, both chert and flint use the same locking approach with a file called flintlock, so that doesn't discriminate between them. The easy way to tell which you have is whether there's a file called "iamflint" or "iamchert" in the database directory. Cheers, Olly From guillaume.quintard@gmail.com Tue Oct 6 09:10:44 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Tue, 6 Oct 2009 15:10:44 +0200 Subject: [sup-talk] Crash, bad index, and ensuing misery In-Reply-To: References: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com> <1254600926-sup-5190@zyrg.net> <1e5fdab70910031406x713fad49ubb42b42463899c87@mail.gmail.com> Message-ID: <1e5fdab70910060610n7486dc1bi27b07c4f5f51faa6@mail.gmail.com> On Tue, Oct 6, 2009 at 2:40 PM, Olly Betts wrote: > NEVER EVER remove the flintlock file. Ooops, didn't know, won't do it again. > My guess is that removing the flintlock file is the cause of the corruption > you're seeing. ?Can you reproduce it on a database where you haven't removed > this file? Unfortunately, no > which you have is whether there's a file called "iamflint" or "iamchert" in Flint then -- Guillaume From eg@gaute.vetsj.com Tue Oct 6 09:34:51 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Tue, 06 Oct 2009 15:34:51 +0200 Subject: [sup-talk] Bug: Xapian exception after having polled In-Reply-To: <1e5fdab70910060314i6a4cce5ck92e7605ec54f98a1@mail.gmail.com> References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net> <20091004101550.GA7330@qwerzila.bluecom.no> <1254681739-sup-4089@zyrg.net> <5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com> <1254682966-sup-6629@zyrg.net> <5a5b14cf0910041220p26a4c830va172df0e33542480@mail.gmail.com> <1254780036-sup-3214@qwerzila> <1e5fdab70910060314i6a4cce5ck92e7605ec54f98a1@mail.gmail.com> Message-ID: <1254835794-sup-6000@qwerzila> Excerpts from Guillaume Quintard's message of ty. okt. 06 12:14:43 +0200 2009: > On Tue, Oct 6, 2009 at 12:01 AM, Gaute Hope wrote: > > Did a 'sup-sync --changed -o' and the problem seems to be gone. > --- RuntimeError from thread: load threads for thread-index-mode > wrong id called on nil > ./lib/sup.rb:17:in `id' I was getting a slightly different error: --- RuntimeError from thread: poll after loading inbox @id nil /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:254:in `load_from_source!' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in `build_from_source' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in `each_message_from' - gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Tue Oct 6 10:59:07 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 06 Oct 2009 07:59:07 -0700 Subject: [sup-talk] Bug: Xapian exception after having polled In-Reply-To: <1e5fdab70910060314i6a4cce5ck92e7605ec54f98a1@mail.gmail.com> References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net> <20091004101550.GA7330@qwerzila.bluecom.no> <1254681739-sup-4089@zyrg.net> <5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com> <1254682966-sup-6629@zyrg.net> <5a5b14cf0910041220p26a4c830va172df0e33542480@mail.gmail.com> <1254780036-sup-3214@qwerzila> <1e5fdab70910060314i6a4cce5ck92e7605ec54f98a1@mail.gmail.com> Message-ID: <1254840860-sup-2494@masanjin.net> Reformatted excerpts from Guillaume Quintard's message of 2009-10-06: > [Tue Oct 06 11:22:55 +0200 2009] hook: error running hook: cannot > generate tempfile `/tmp/12016-9-attachments/389068.html' > [Tue Oct 06 11:22:55 +0200 2009] hook: > /usr/lib/ruby/1.8/tempfile.rb:52:in `initialize' > ./lib/sup/message-chunks.rb:149:in `new' > ./lib/sup/message-chunks.rb:149:in `write_to_disk' > ./lib/sup/message-chunks.rb:105:in `initialize' > ./lib/sup/hook.rb:51:in `call' > ./lib/sup/hook.rb:51:in `filename' > /home/shivan/.sup/hooks/mime-decode.rb:4:in `__run' I think that's an unrelated issue, but it's weird that it couldn't create that file in /tmp. Are you out of disk space, missing a /tmp directory, or something weird like that? -- William From wmorgan-sup@masanjin.net Tue Oct 6 11:38:39 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 06 Oct 2009 08:38:39 -0700 Subject: [sup-talk] i18n? In-Reply-To: <1254758256-sup-7400@thinkpad-ubuntu> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1254758256-sup-7400@thinkpad-ubuntu> Message-ID: <1254842820-sup-9099@masanjin.net> Hi Christopher, Reformatted excerpts from Christopher Bertels's message of 2009-10-05: > I'd like to hear some feedback and/or opinions/suggestions and would > like to see it integrated into sup. I'll add more translations, if I > find anything I havent missed yet and that is part of the user > interface. This looks great. A couple comments: 1. I would prefer that uppercase substitution symbols made lowercase. The uppercase seems weird and un-Rubyish to me. 2. I think it would be nice to have a simple module along the lines of: module M17n def m s, o={}; I18n[m, o] end end and to have that be the primary entry point when you want a translated string. Then classes can include that module if they want m17n support, and instead of writing I18n["text", { :var => value }] you can have m("text", :var => value) which is a little easier to read, IMO. 3. Should we call it m17n instead of i18n? I think that might be a little more accurate. Perhaps too nitpicky. What do you think? 4. A finishing touch would be to have sup-config ask the user what language they are interested in. -- William From bgamari.foss@gmail.com Tue Oct 6 11:53:18 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Tue, 06 Oct 2009 11:53:18 -0400 Subject: [sup-talk] Crash while in thread-view-mode In-Reply-To: <1254844050-sup-4148@ben-laptop> References: <1254844050-sup-4148@ben-laptop> Message-ID: <1254844166-sup-1028@ben-laptop> Well, it seems like whatever caused the crash earlier did something to my index. Now any attempt to open a thread-index-mode of my LKML label (which I was viewing in the earlier crash) causes the client to immediately crash. Do any of the sup utilities have any sort of index sanity checker to find potential causes of this sort of issue? Thanks, - Ben --- RuntimeError from thread: load threads for thread-index-mode wrong id called on nil /opt/exp/sup/lib/sup.rb:17:in `id' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update' /usr/lib64/ruby/1.8/rubygems/custom_require.rb:31:in `sort_by' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:628:in `__unprotected_load_n_threads' /opt/exp/sup/lib/sup/thread.rb:334:in `load_n_threads' /opt/exp/sup/lib/sup/xapian_index.rb:117:in `each_id_by_date' /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id' /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each' /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id' /opt/exp/sup/lib/sup/xapian_index.rb:117:in `each_id_by_date' /opt/exp/sup/lib/sup/thread.rb:328:in `load_n_threads' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background' /opt/exp/sup/lib/sup.rb:77:in `reporting_thread' /opt/exp/sup/lib/sup.rb:75:in `initialize' /opt/exp/sup/lib/sup.rb:75:in `new' /opt/exp/sup/lib/sup.rb:75:in `reporting_thread' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:33:in `spawn_nicely' /opt/exp/sup/lib/sup/modes/label-list-mode.rb:103:in `select_label' /opt/exp/sup/lib/sup/mode.rb:51:in `send' /opt/exp/sup/lib/sup/mode.rb:51:in `handle_input' /opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input' /usr/bin/sup:239 Excerpts from Ben Gamari's message of Tue Oct 06 11:47:34 -0400 2009: > I just had sup crash on me while reading a thread. Not really sure what > to make of the backtrace. Looks like it failed during polling but who > knows why. Thanks, > > - Ben > From bgamari.foss@gmail.com Tue Oct 6 11:47:34 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Tue, 06 Oct 2009 11:47:34 -0400 Subject: [sup-talk] Crash while in thread-view-mode Message-ID: <1254844050-sup-4148@ben-laptop> I just had sup crash on me while reading a thread. Not really sure what to make of the backtrace. Looks like it failed during polling but who knows why. Thanks, - Ben --- RuntimeError from thread: periodic poll wrong id called on nil /opt/exp/sup/lib/sup.rb:17:in `id' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update' /opt/exp/sup/lib/sup/xapian_index.rb:325:in `sort_by' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:702:in `add_or_unhide' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:188:in `handle_added_update' /opt/exp/sup/lib/sup/update.rb:26:in `send' /opt/exp/sup/lib/sup/update.rb:26:in `relay' /opt/exp/sup/lib/sup/update.rb:26:in `each' /opt/exp/sup/lib/sup/update.rb:26:in `relay' /opt/exp/sup/lib/sup/util.rb:520:in `send' /opt/exp/sup/lib/sup/util.rb:520:in `method_missing' /opt/exp/sup/lib/sup/poll.rb:181:in `add_new_message' /opt/exp/sup/lib/sup/poll.rb:124:in `do_poll' /opt/exp/sup/lib/sup/poll.rb:166:in `each_message_from' /opt/exp/sup/lib/sup/maildir.rb:160:in `each' /opt/exp/sup/lib/sup/maildir.rb:157:in `upto' /opt/exp/sup/lib/sup/maildir.rb:157:in `each' /opt/exp/sup/lib/sup/util.rb:560:in `send' /opt/exp/sup/lib/sup/util.rb:560:in `__pass' /opt/exp/sup/lib/sup/util.rb:547:in `method_missing' /opt/exp/sup/lib/sup/poll.rb:154:in `each_message_from' /opt/exp/sup/lib/sup/poll.rb:108:in `do_poll' /opt/exp/sup/lib/sup/poll.rb:96:in `each' /opt/exp/sup/lib/sup/poll.rb:96:in `do_poll' /opt/exp/sup/lib/sup/poll.rb:95:in `synchronize' /opt/exp/sup/lib/sup/poll.rb:95:in `do_poll' /opt/exp/sup/lib/sup/util.rb:520:in `send' /opt/exp/sup/lib/sup/util.rb:520:in `method_missing' /opt/exp/sup/lib/sup/modes/poll-mode.rb:15:in `poll' /opt/exp/sup/lib/sup/poll.rb:47:in `poll_with_sources' /opt/exp/sup/lib/sup/poll.rb:62:in `poll' /opt/exp/sup/lib/sup/poll.rb:80:in `start' /opt/exp/sup/lib/sup.rb:77:in `reporting_thread' /opt/exp/sup/lib/sup.rb:75:in `initialize' /opt/exp/sup/lib/sup.rb:75:in `new' /opt/exp/sup/lib/sup.rb:75:in `reporting_thread' /opt/exp/sup/lib/sup/poll.rb:77:in `start' /opt/exp/sup/lib/sup/util.rb:520:in `send' /opt/exp/sup/lib/sup/util.rb:520:in `method_missing' /usr/bin/sup:204 From bgamari.foss@gmail.com Tue Oct 6 12:15:46 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Tue, 06 Oct 2009 12:15:46 -0400 Subject: [sup-talk] Crash while in thread-view-mode In-Reply-To: <1254844166-sup-1028@ben-laptop> References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop> Message-ID: <1254845543-sup-9458@ben-laptop> Excerpts from Ben Gamari's message of Tue Oct 06 11:53:18 -0400 2009: > Well, it seems like whatever caused the crash earlier did something to > my index. Now any attempt to open a thread-index-mode of my LKML label > (which I was viewing in the earlier crash) causes the client to > immediately crash. > Hmm, it seems like the problem is spreading. I now come to find out that another label triggers this same crash (although I guess it's possible that the intersection of the two labels is non-nil). I tried running a sup-sync -oc on the relevant sources to no avail. I really don't have time to devote to debugging this at the moment so it looks like I might need to take another hiatus from sup. Just as I was starting to get used to it... sigh. Anyways, if anyone has any ideas for improving things, let me know. Thanks! - Ben From wmorgan-sup@masanjin.net Tue Oct 6 12:35:36 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 06 Oct 2009 09:35:36 -0700 Subject: [sup-talk] next search in buffer view.. In-Reply-To: <1254689522-sup-2800@nixos> References: <1254602805-sup-2900@nixos> <1254689522-sup-2800@nixos> Message-ID: <1254846869-sup-9463@masanjin.net> Reformatted excerpts from Marc Weber's message of 2009-10-04: > However the search_query_input should be global. So where is the place > to add this "last-search-term" ? Isn't it already present in the ask > history? Can you give me a hint to find it faster? Probably the best place is to make it a class variable, i.e. @@search_query_input. Then it will be shared across all buffers with modes that have search functionality. -- William From marka@pobox.com Tue Oct 6 12:39:08 2009 From: marka@pobox.com (Mark Alexander) Date: Tue, 06 Oct 2009 12:39:08 -0400 Subject: [sup-talk] Crash while in thread-view-mode In-Reply-To: <1254845543-sup-9458@ben-laptop> References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop> <1254845543-sup-9458@ben-laptop> Message-ID: <1254846746-sup-1820@r50p> > I really don't have > time to devote to debugging this at the moment so it looks like I might > need to take another hiatus from sup. You could try running an older version. I've been using 0.8 at work, and a May 20 snapshot of next at home, and both have been very solid. They're good enough, in fact, that I don't feel the need to upgrade. Maybe after the dust settles from all the recent code churn... From wmorgan-sup@masanjin.net Tue Oct 6 13:11:06 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 06 Oct 2009 10:11:06 -0700 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1254417174-sup-3659@yoom.home.cworth.org> References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net> <1252004144-sup-6662@javelin> <1252004285-sup-476@masanjin.net> <1252004504-sup-3189@javelin> <1254339746-sup-79@masanjin.net> <1254382434-sup-4435@peray> <1254404057-sup-2374@masanjin.net> <1254417174-sup-3659@yoom.home.cworth.org> Message-ID: <1254849015-sup-5884@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-10-01: > It seems a simple, little thing. But I'm all in favor of non-violent > metaphors in the interfaces of programs I use. I will accept a patch that renames this and adds "M" as an additional command. -- William From wmorgan-sup@masanjin.net Tue Oct 6 13:16:20 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 06 Oct 2009 10:16:20 -0700 Subject: [sup-talk] [PATCH] Add new :crypto_default configuration option. In-Reply-To: <1254417826-sup-6584@yoom.home.cworth.org> References: <1254178611-sup-369@yoom.home.cworth.org> <1254416783-sup-5518@masanjin.net> <1254417826-sup-6584@yoom.home.cworth.org> Message-ID: <1254849104-sup-6471@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-10-01: > What makes a hook preferable over a configuration option? I would like to support everyone's crazy desires, and a hook is worth a thousand configuration options. In this case, I'm sure it's only a matter of time before someone wants to automatically determine the crypto setting based on the recipient, or based on the message body. A hook would allow that. > 2. Hooks are not supported forever, in which case users may find that > things just start working when upgrading. I am fine with this. Users be damned! (Or at least, required to read the changelog.) > Neither of those seem options look nice to me, and both seem easy to > avoid with configuration options. How so? Configuration options can change just as easily. > If the plan is to go with (1) I'm concerned that I don't see sup > shipping documentation for the current possible hooks. (This applies > to configuration options too though. I think the maintainer should > reject patches that add either without also adding documentation to > the standard list.[*]) sup -l is supposed to produce all the hook documentation you'd need, assuming a reasonable knowledge of Ruby. -- William From wmorgan-sup@masanjin.net Tue Oct 6 13:30:09 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 06 Oct 2009 10:30:09 -0700 Subject: [sup-talk] On making inbox-mode and search-results-mode more similar In-Reply-To: <1251323747-sup-1595@yoom.home.cworth.org> References: <1251323747-sup-1595@yoom.home.cworth.org> Message-ID: <1254850185-sup-1817@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-26: > This is just a copy of SearchResultsMode's refine_search command. A > much cleaner, but more involved, approach would be to rework InboxMode > to derive from SearchResultsMode in the first place. Branch refine-inbox-mode, merged into next. Sorry for the long delay. -- William From mailinglist@flasht.de Tue Oct 6 16:35:46 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Tue, 06 Oct 2009 22:35:46 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1254842820-sup-9099@masanjin.net> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1254758256-sup-7400@thinkpad-ubuntu> <1254842820-sup-9099@masanjin.net> Message-ID: <1254861112-sup-590@thinkpad-ubuntu> Excerpts from William Morgan's message of Di Okt 06 17:38:39 +0200 2009: > This looks great. A couple comments: Cool, good to know you like it! > 1. I would prefer that uppercase substitution symbols made lowercase. > The uppercase seems weird and un-Rubyish to me. Ok, sounds good. I thought making them uppercase to let them be more distict from the rest of the string but since we surround them by #{} as in Ruby, you're making a good point here. I'll change that. > 2. I think it would be nice to have a simple module along the lines of: > > module M17n > def m s, o={}; I18n[m, o] end > end > > and to have that be the primary entry point when you want a translated > string. Then classes can include that module if they want m17n support, > and instead of writing > > I18n["text", { :var => value }] > > you can have > > m("text", :var => value) > > which is a little easier to read, IMO. Same here. Think this is nicer, too. > 3. Should we call it m17n instead of i18n? I think that might be a > little more accurate. Perhaps too nitpicky. What do you think? I couldn't care less about the name - but I guess m17n fits better, since it's just multilingualization. :) > 4. A finishing touch would be to have sup-config ask the user what > language they are interested in. Alright, cool. I'll add that as well, once I have the rest changed & working. Cheers, Christopher. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From mailinglist@flasht.de Tue Oct 6 17:56:19 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Tue, 06 Oct 2009 23:56:19 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1254861112-sup-590@thinkpad-ubuntu> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1254758256-sup-7400@thinkpad-ubuntu> <1254842820-sup-9099@masanjin.net> <1254861112-sup-590@thinkpad-ubuntu> Message-ID: <1254866136-sup-6974@thinkpad-ubuntu> OK, I've changed it as mentioned. See my previously mentioned gitorious branch. Cheers, Christopher. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 From ezyang@MIT.EDU Tue Oct 6 18:44:09 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Tue, 06 Oct 2009 18:44:09 -0400 Subject: [sup-talk] Bugfix for custom-search In-Reply-To: <1254418685-sup-6611@javelin> References: <1254418685-sup-6611@javelin> Message-ID: <1254869038-sup-9250@javelin> Excerpts from Edward Z. Yang's message of Thu Oct 01 13:38:27 -0400 2009: > I think there's a slight bug in the custom-search implementation. Any comments? Cheers, Edward From rlane@club.cc.cmu.edu Wed Oct 7 02:44:34 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 07 Oct 2009 02:44:34 -0400 Subject: [sup-talk] Crash while in thread-view-mode In-Reply-To: <1254845543-sup-9458@ben-laptop> References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop> <1254845543-sup-9458@ben-laptop> Message-ID: <1254896214-sup-5969@zyrg.net> Excerpts from Ben Gamari's message of Tue Oct 06 12:15:46 -0400 2009: > Excerpts from Ben Gamari's message of Tue Oct 06 11:53:18 -0400 2009: > > Well, it seems like whatever caused the crash earlier did something to > > my index. Now any attempt to open a thread-index-mode of my LKML label > > (which I was viewing in the earlier crash) causes the client to > > immediately crash. > > > > Hmm, it seems like the problem is spreading. I now come to find out that > another label triggers this same crash (although I guess it's possible > that the intersection of the two labels is non-nil). I tried running a > sup-sync -oc on the relevant sources to no avail. I really don't have > time to devote to debugging this at the moment so it looks like I might > need to take another hiatus from sup. Just as I was starting to get used > to it... sigh. Anyways, if anyone has any ideas for improving things, > let me know. Thanks! I've been seeing this crash for a long time. I think it's a race between the poll thread / load-more-threads thread and the rest of the UI in the main thread. Basically any operation on a thread object in ThreadIndexMode needs to be protected against ThreadSet#add_message (and probably other ThreadSet methods) because add_message can remove containers from the thread tree, leaving you with an empty thread whose "date" method returns nil. You could try running sup with the -n flag to disable threading. The major downside is that you have to hit P to poll manually. I look forward to having a sup-server - I plan on writing a little android client in Scala using actors. Almost no mutable state and absolutely no ncurses. From guillaume.quintard@gmail.com Wed Oct 7 04:48:56 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Wed, 7 Oct 2009 10:48:56 +0200 Subject: [sup-talk] Crash while in thread-view-mode In-Reply-To: <1254896214-sup-5969@zyrg.net> References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop> <1254845543-sup-9458@ben-laptop> <1254896214-sup-5969@zyrg.net> Message-ID: <1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com> On Wed, Oct 7, 2009 at 8:44 AM, Rich Lane wrote: > You could try running sup with the -n flag to disable threading. The > major downside is that you have to hit P to poll manually. That "solves" the problem for me. -- Guillaume From guillaume.quintard@gmail.com Wed Oct 7 05:07:47 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Wed, 7 Oct 2009 11:07:47 +0200 Subject: [sup-talk] Crash while in thread-view-mode In-Reply-To: <1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com> References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop> <1254845543-sup-9458@ben-laptop> <1254896214-sup-5969@zyrg.net> <1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com> Message-ID: <1e5fdab70910070207q3aada8d7y2e2482e0dbbe8bd2@mail.gmail.com> On Wed, Oct 7, 2009 at 10:48 AM, Guillaume Quintard wrote: > That "solves" the problem for me. Scratch that, I just relaunched sup, and I still get the wrong id called on nil error. -- Guillaume From gregor@hoffleit.de Wed Oct 7 06:52:34 2009 From: gregor@hoffleit.de (Gregor Hoffleit) Date: Wed, 07 Oct 2009 12:52:34 +0200 Subject: [sup-talk] [PATCH] Attachment filenames: RFC2184 and extension guessing Message-ID: <1254912361-sup-5340@sam.mediasupervision.de> I noticed sup has trouble handling attachments sent by Roundcube webmail. Somehow, those mails use an alternative encoding of filenames, specified in RFC2184: Content-Transfer-Encoding: base64 Content-Type: image/jpeg; name*="UTF-8''20090912-i004232-gr000.jpg"; Content-Disposition: attachment; filename*="UTF-8''20090912-i004232-gr000.jpg"; Bugs: 1. Sup fails to detect these filenames. 2. When trying to save these attachements, the filenames generated by sup have a trailing semicolon. The attached patch is a quick and dirty fix for these specific problems. There's probably a better way to implement this. Regards, Gregor Hoffleit -------------- next part -------------- A non-text attachment was scrubbed... Name: rfc2184.diff Type: application/octet-stream Size: 954 bytes Desc: not available URL: From bgamari.foss@gmail.com Wed Oct 7 18:42:09 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Wed, 07 Oct 2009 18:42:09 -0400 Subject: [sup-talk] Fwd: Re: Crash while in thread-view-mode Message-ID: <1254955312-sup-7085@ben-laptop> Excerpts from Guillaume Quintard's message of Wed Oct 07 04:48:56 -0400 2009: > On Wed, Oct 7, 2009 at 8:44 AM, Rich Lane wrote: > > You could try running sup with the -n flag to disable threading. The > > major downside is that you have to hit P to poll manually. > > That "solves" the problem for me. > After going through the process of rebuilding my index (again), things seem to be more stable (for now). I understand that designing software around a contingency like this might not be the best practice, but the frequency with which I've needed to rebuild really does make me think that ruby isn't the best language for the indexer. This is easily the fifth time I've needed to rebuild and each time it has taken over 30 minutes for 1.5 GB of mail. That's substantially less than 1MB/second for what should be an I/O bound operation. Ouch. It'll be really interesting to see how Carl's work comes out. - Ben From bgamari.foss@gmail.com Wed Oct 7 18:46:39 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Wed, 07 Oct 2009 18:46:39 -0400 Subject: [sup-talk] Crash while in thread-view-mode In-Reply-To: <1254945119-sup-3401@ben-laptop> References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop> <1254845543-sup-9458@ben-laptop> <1254896214-sup-5969@zyrg.net> <1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com> <1254945119-sup-3401@ben-laptop> Message-ID: <1254955351-sup-5944@ben-laptop> Excerpts from Ben Gamari's message of Wed Oct 07 15:56:43 -0400 2009: > After going through the process of rebuilding my index (again), things > seem to be more stable (for now). Well, this was true for a while. Unfortunately, it seems that my LKML label is yet again crashing sup. The exception is very similar to that which I experienced prior to rebuilding. It's quite reproducible, always crashing after loading a few hundred messages or so. There must be a better way to deal with these invalid ids than crashing. Is there any reason this needs to be a show-stopping event? Thanks, - Ben --- RuntimeError from thread: load threads for thread-index-mode wrong id called on nil /opt/exp/sup/lib/sup.rb:17:in `id' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update' /opt/exp/sup/lib/sup/hook.rb:121:in `sort_by' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:628:in `__unprotected_load_n_threads' /opt/exp/sup/lib/sup/thread.rb:334:in `load_n_threads' /opt/exp/sup/lib/sup/xapian_index.rb:117:in `each_id_by_date' /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id' /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each' /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id' /opt/exp/sup/lib/sup/xapian_index.rb:117:in `each_id_by_date' /opt/exp/sup/lib/sup/thread.rb:328:in `load_n_threads' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background' /opt/exp/sup/lib/sup.rb:77:in `reporting_thread' /opt/exp/sup/lib/sup.rb:75:in `initialize' /opt/exp/sup/lib/sup.rb:75:in `new' /opt/exp/sup/lib/sup.rb:75:in `reporting_thread' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:81:in `initialize' /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `call' /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `initialize' /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `each' /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `initialize' /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:19:in `new' /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:19:in `initialize' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:54:in `initialize' /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:9:in `initialize' /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `new' /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `spawn_nicely' /opt/exp/sup/lib/sup/buffer.rb:350:in `spawn_unless_exists' /opt/exp/sup/lib/sup/util.rb:520:in `send' /opt/exp/sup/lib/sup/util.rb:520:in `method_missing' /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `spawn_nicely' /opt/exp/sup/lib/sup/modes/label-list-mode.rb:103:in `select_label' /opt/exp/sup/lib/sup/mode.rb:51:in `send' /opt/exp/sup/lib/sup/mode.rb:51:in `handle_input' /opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input' /usr/bin/sup:239 From stettberger@dokucode.de Thu Oct 8 03:05:47 2009 From: stettberger@dokucode.de (Christian Dietrich) Date: Thu, 08 Oct 2009 09:05:47 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1254516195-sup-4619@peer.zerties.org> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> Message-ID: <1254985425-sup-2303@peer.zerties.org> Excerpts from Christian Dietrich's message of Fr Okt 02 22:48:24 +0200 2009: > Thank you, that helped a much. I implemented the feature, it is > available at git://github.com/stettberger/sup-mail.git > branch time_marks, it is one commit ahead of next. It is enabled > with setting the config option ":time_markers_in_index_mode: true" > At runtime it can be toggled via '%' (just randomly choosen by me) Ok now i did a little bit of reworking the code (don't make it sup crash :-) and added a little bit color). The is now :time_marker_color. I attached a screenshot of the time_marks. greetz didi -- No documentation is better than bad documentation -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt. -------------- next part -------------- A non-text attachment was scrubbed... Name: sup-time-mark.png Type: image/png Size: 38362 bytes Desc: not available URL: From mailinglist@flasht.de Thu Oct 8 08:31:24 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Thu, 08 Oct 2009 14:31:24 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1254985425-sup-2303@peer.zerties.org> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> Message-ID: <1255005056-sup-7120@thinkpad-ubuntu> Excerpts from Christian Dietrich's message of Do Okt 08 09:05:47 +0200 2009: > Ok now i did a little bit of reworking the code (don't make it sup > crash :-) and added a little bit color). The is now > :time_marker_color. I attached a screenshot of the time_marks. Looks really cool, I'll give it a try :) -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From mailinglist@flasht.de Thu Oct 8 08:44:32 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Thu, 08 Oct 2009 14:44:32 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255005056-sup-7120@thinkpad-ubuntu> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> Message-ID: <1255005777-sup-7020@thinkpad-ubuntu> Ok, I like it so far. But what would really rock (IMO) would be the possibility to collapse all messages, that are from yesterday or 2 weeks ago etc. What do you think? -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From stettberger@dokucode.de Thu Oct 8 14:28:59 2009 From: stettberger@dokucode.de (Christian Dietrich) Date: Thu, 08 Oct 2009 20:28:59 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255005777-sup-7020@thinkpad-ubuntu> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> Message-ID: <1255026503-sup-3624@peer.zerties.org> Excerpts from Christopher Bertels's message of Do Okt 08 14:44:32 +0200 2009: > Ok, I like it so far. But what would really rock (IMO) would be the > possibility to collapse all messages, that are from yesterday or 2 > weeks ago etc. > What do you think? Yeah thats cool, i implemented it, just type on a Time Mark (after pulling) greetz didi -- No documentation is better than bad documentation -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt. From nicolas.pouillard@gmail.com Thu Oct 8 15:24:21 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Thu, 08 Oct 2009 21:24:21 +0200 Subject: [sup-talk] Ruby 1.9 status? Message-ID: <1255029826-sup-8182@peray> Hi all, I would like to know what is the sup status w.r.t ruby 1.9? -- Nicolas Pouillard http://nicolaspouillard.fr From mailinglist@flasht.de Thu Oct 8 15:33:44 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Thu, 08 Oct 2009 21:33:44 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255026503-sup-3624@peer.zerties.org> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> Message-ID: <1255030392-sup-1135@thinkpad-ubuntu> Excerpts from Christian Dietrich's message of Do Okt 08 20:28:59 +0200 2009: > Yeah thats cool, i implemented it, just type on a Time Mark > (after pulling) Indeed, very nice. Thanks :) I'd like to see this in sup's mainline, btw :) -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: not available URL: From eg@gaute.vetsj.com Thu Oct 8 15:44:30 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Thu, 08 Oct 2009 21:44:30 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255030392-sup-1135@thinkpad-ubuntu> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> <1255030392-sup-1135@thinkpad-ubuntu> Message-ID: <1255031039-sup-4070@qwerzila> Excerpts from Christopher Bertels's message of to. okt. 08 21:33:44 +0200 2009: > Excerpts from Christian Dietrich's message of Do Okt 08 20:28:59 +0200 2009: > > Yeah thats cool, i implemented it, just type on a Time Mark > > (after pulling) > > Indeed, very nice. Thanks :) > I'd like to see this in sup's mainline, btw :) +1 ! Looks great! - gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From benoit.pierre@gmail.com Thu Oct 8 16:04:10 2009 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=) Date: Thu, 08 Oct 2009 22:04:10 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255026503-sup-3624@peer.zerties.org> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> Message-ID: <1255032019-sup-3406@localdomain> Excerpts from Christian Dietrich's message of Thu Oct 08 20:28:59 +0200 2009: > Excerpts from Christopher Bertels's message of Do Okt 08 14:44:32 +0200 2009: > > Ok, I like it so far. But what would really rock (IMO) would be the > > possibility to collapse all messages, that are from yesterday or 2 > > weeks ago etc. > > What do you think? > > Yeah thats cool, i implemented it, just type on a Time Mark > (after pulling) This is great, I love it. Attached 2 small patches: - fix a warning (space before opening parenthesis in function call) - fix a bug with thread selection when time marks are not visible Cheers, -- A: Because it destroys the flow of conversation. Q: Why is top posting dumb? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-warning-fix.patch Type: application/octet-stream Size: 770 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-fix-selection-when-time-marks-are-disabled.patch Type: application/octet-stream Size: 1114 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: not available URL: From eg@gaute.vetsj.com Thu Oct 8 16:12:31 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Thu, 08 Oct 2009 22:12:31 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255031039-sup-4070@qwerzila> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> <1255030392-sup-1135@thinkpad-ubuntu> <1255031039-sup-4070@qwerzila> Message-ID: <1255032615-sup-8961@qwerzila> Excerpts from Gaute Hope's message of to. okt. 08 21:44:30 +0200 2009: > Excerpts from Christopher Bertels's message of to. okt. 08 21:33:44 +0200 2009: > > Excerpts from Christian Dietrich's message of Do Okt 08 20:28:59 +0200 2009: > > > Yeah thats cool, i implemented it, just type on a Time Mark > > > (after pulling) Would be nice if the '1' keybinding would select the first message and not the first line. Possibly another binding to collapse the current day when a message is selected (maybe h or E to keep things similar to the message view)? - gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From benoit.pierre@gmail.com Thu Oct 8 16:26:12 2009 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=) Date: Thu, 08 Oct 2009 22:26:12 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255032615-sup-8961@qwerzila> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> <1255030392-sup-1135@thinkpad-ubuntu> <1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila> Message-ID: <1255033079-sup-8556@localdomain> Excerpts from Gaute Hope's message of Thu Oct 08 22:12:31 +0200 2009: > Excerpts from Gaute Hope's message of to. okt. 08 21:44:30 +0200 2009: > > Excerpts from Christopher Bertels's message of to. okt. 08 21:33:44 +0200 2009: > > > Excerpts from Christian Dietrich's message of Do Okt 08 20:28:59 +0200 2009: > > > > Yeah thats cool, i implemented it, just type on a Time Mark > > > > (after pulling) > > Would be nice if the '1' keybinding would select the first message and > not the first line. Possibly another binding to collapse the current day when > a message is selected (maybe h or E to keep things similar to the > message view)? And 't' should select the next thread, not the next line. 'a' and 'A' too, in fact a time tag should only be selectable manually, using Up/Down or 'j'/'k'. Or never if collapsing/expending is possible with a mapping (my vote goes to 'E'). Cheers, -- A: Because it destroys the flow of conversation. Q: Why is top posting dumb? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From stettberger@dokucode.de Thu Oct 8 16:50:07 2009 From: stettberger@dokucode.de (Christian Dietrich) Date: Thu, 08 Oct 2009 22:50:07 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255032615-sup-8961@qwerzila> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> <1255030392-sup-1135@thinkpad-ubuntu> <1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila> Message-ID: <1255034958-sup-5628@peer.zerties.org> > Would be nice if the '1' keybinding would select the first message and > not the first line. Possibly another binding to collapse the current day when > a message is selected (maybe h or E to keep things similar to the > message view)? Yeah, implemented that, and the other two patches in the branch, like the idea. greetz didi -- No documentation is better than bad documentation -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt. From stettberger@dokucode.de Fri Oct 9 03:19:30 2009 From: stettberger@dokucode.de (Christian Dietrich) Date: Fri, 09 Oct 2009 09:19:30 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255033079-sup-8556@localdomain> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> <1255030392-sup-1135@thinkpad-ubuntu> <1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila> <1255033079-sup-8556@localdomain> Message-ID: <1255072730-sup-9414@peer.zerties.org> > And 't' should select the next thread, not the next line. 'a' and 'A' > too, in fact a time tag should only be selectable manually, using > Up/Down or 'j'/'k'. Or never if collapsing/expending is possible with a > mapping (my vote goes to 'E'). Jep thats right, i fixed that. Please pull. greetz didi -- No documentation is better than bad documentation -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt. From eg@gaute.vetsj.com Fri Oct 9 03:31:38 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Fri, 09 Oct 2009 09:31:38 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255034958-sup-5628@peer.zerties.org> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> <1255030392-sup-1135@thinkpad-ubuntu> <1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila> <1255034958-sup-5628@peer.zerties.org> Message-ID: <1255073126-sup-6984@qwerzila> Excerpts from Christian Dietrich's message of to. okt. 08 22:50:07 +0200 2009: > > Would be nice if the '1' keybinding would select the first message and > > not the first line. Possibly another binding to collapse the current day when > > a message is selected (maybe h or E to keep things similar to the > > message view)? > > Yeah, implemented that, and the other two patches in the branch, > like the idea. This doesn't work for me: '1'/'^' just makes the view scroll one down; hiding the Today marker (same as hitting 'J' one time). 0 works like expected. a/A/&/d/S/t and E seems to be working alright. - gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From stettberger@dokucode.de Fri Oct 9 03:44:02 2009 From: stettberger@dokucode.de (Christian Dietrich) Date: Fri, 09 Oct 2009 09:44:02 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255073126-sup-6984@qwerzila> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> <1255030392-sup-1135@thinkpad-ubuntu> <1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila> <1255034958-sup-5628@peer.zerties.org> <1255073126-sup-6984@qwerzila> Message-ID: <1255074206-sup-7503@peer.zerties.org> Excerpts from Gaute Hope's message of Fr Okt 09 09:31:38 +0200 2009: > This doesn't work for me: '1'/'^' just makes the view scroll one down; hiding > the > Today marker (same as hitting 'J' one time). 0 works like expected. > > a/A/&/d/S/t and E seems to be working alright. Yeah ok, that should be fixed now. (I didn't even now about this keystroke before...) greetz didi -- No documentation is better than bad documentation -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt. From eg@gaute.vetsj.com Fri Oct 9 05:45:13 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Fri, 09 Oct 2009 11:45:13 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255074206-sup-7503@peer.zerties.org> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> <1255030392-sup-1135@thinkpad-ubuntu> <1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila> <1255034958-sup-5628@peer.zerties.org> <1255073126-sup-6984@qwerzila> <1255074206-sup-7503@peer.zerties.org> Message-ID: <1255081131-sup-7915@qwerzila> Excerpts from Christian Dietrich's message of fr. okt. 09 09:44:02 +0200 2009: > Excerpts from Gaute Hope's message of Fr Okt 09 09:31:38 +0200 2009: > > This doesn't work for me: '1'/'^' just makes the view scroll one down; hiding > > the > > Today marker (same as hitting 'J' one time). 0 works like expected. > > > > a/A/&/d/S/t and E seems to be working alright. > > Yeah ok, that should be fixed now. (I didn't even now about this > keystroke before...) Just discovered a weird bug.. when this thread got polled and updated the message count, in this case (13), got attached to the thread beneath, which only had one message, and appeared where it shouldn't be anything.. the top thread didn't have any post count. It seemed to only have affected the top two messages, as the count on the third one seemed normal. Not entierly sure what caused it since I can't really reproduce it by sending myself emails.. if it happens again ill post screenshot. Im using time_marker branch rebased ontop of origin/next. - gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From eg@gaute.vetsj.com Fri Oct 9 06:12:21 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Fri, 09 Oct 2009 12:12:21 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255081131-sup-7915@qwerzila> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> <1255030392-sup-1135@thinkpad-ubuntu> <1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila> <1255034958-sup-5628@peer.zerties.org> <1255073126-sup-6984@qwerzila> <1255074206-sup-7503@peer.zerties.org> <1255081131-sup-7915@qwerzila> Message-ID: <1255083021-sup-226@qwerzila> Excerpts from Gaute Hope's message of fr. okt. 09 11:45:13 +0200 2009: > Not entierly sure what caused it since I can't really reproduce it by > sending myself emails.. if it happens again ill post screenshot. > > Im using time_marker branch rebased ontop of origin/next. Ok.. now the top message count just got copied down to the line beneath (which should be empty). Sup had just been running for a while, no new messages, didn't happen on first pool.. - gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: 2009-10-09-120801_634x755_scrot.png Type: image/png Size: 29135 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From stettberger@dokucode.de Fri Oct 9 06:39:27 2009 From: stettberger@dokucode.de (Christian Dietrich) Date: Fri, 09 Oct 2009 12:39:27 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255083021-sup-226@qwerzila> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> <1255030392-sup-1135@thinkpad-ubuntu> <1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila> <1255034958-sup-5628@peer.zerties.org> <1255073126-sup-6984@qwerzila> <1255074206-sup-7503@peer.zerties.org> <1255081131-sup-7915@qwerzila> <1255083021-sup-226@qwerzila> Message-ID: <1255084730-sup-671@peer.zerties.org> Excerpts from Gaute Hope's message of Fr Okt 09 12:12:21 +0200 2009: > Excerpts from Gaute Hope's message of fr. okt. 09 11:45:13 +0200 2009: > > Not entierly sure what caused it since I can't really reproduce it by > > sending myself emails.. if it happens again ill post screenshot. > > > > Im using time_marker branch rebased ontop of origin/next. > > Ok.. now the top message count just got copied down to the line > beneath (which should be empty). Sup had just been running for a while, > no new messages, didn't happen on first pool.. I have no idea whats causing this, seems like the data of two threads is mixed together? greetz didi -- No documentation is better than bad documentation -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt. From eg@gaute.vetsj.com Fri Oct 9 07:00:19 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Fri, 09 Oct 2009 13:00:19 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255084730-sup-671@peer.zerties.org> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> <1255030392-sup-1135@thinkpad-ubuntu> <1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila> <1255034958-sup-5628@peer.zerties.org> <1255073126-sup-6984@qwerzila> <1255074206-sup-7503@peer.zerties.org> <1255081131-sup-7915@qwerzila> <1255083021-sup-226@qwerzila> <1255084730-sup-671@peer.zerties.org> Message-ID: <1255085867-sup-8410@qwerzila> Excerpts from Christian Dietrich's message of fr. okt. 09 12:39:27 +0200 2009: > Excerpts from Gaute Hope's message of Fr Okt 09 12:12:21 +0200 2009: > > Excerpts from Gaute Hope's message of fr. okt. 09 11:45:13 +0200 2009: > > > Not entierly sure what caused it since I can't really reproduce it by > > > sending myself emails.. if it happens again ill post screenshot. > > > > > > Im using time_marker branch rebased ontop of origin/next. > > > > Ok.. now the top message count just got copied down to the line > > beneath (which should be empty). Sup had just been running for a while, > > no new messages, didn't happen on first pool.. > > I have no idea whats causing this, seems like the data of two > threads is mixed together? Or the thread count isn't aware of the Today mark and still thinks line 2 is thread 2? Don't really know anything about the implementation. When it happens it doesn't dissapear before I do a M or there is a pull that redraws the screen.. just pressing Ctrl+L or opening/closing a thread doesn't remove it. As said earlier it only seems to affect the top two threads. - gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From tero@tilus.net Sat Oct 10 03:21:33 2009 From: tero@tilus.net (Tero Tilus) Date: Sat, 10 Oct 2009 10:21:33 +0300 Subject: [sup-talk] [PATCH] moved deriving the cmd for bouncing to Account and fixed a bug in it Message-ID: <1255159160-sup-8754@tilus.net> The default sendmail command used for bouncing mail was derived from Account#sendmail in ThreadViewMode#bounce. Moved it to Account#bounce_sendmail. Part of work towards more DRY mail bouncing within mark-as-spam hook. The code also had a bug, "$1" (instead of $1 or "#{$1}"). Fixed it. Signed-off-by: Tero Tilus --- lib/sup/account.rb | 11 +++++++++++ lib/sup/modes/thread-view-mode.rb | 7 +------ 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/lib/sup/account.rb b/lib/sup/account.rb index eed2794..bf8a8a0 100644 --- a/lib/sup/account.rb +++ b/lib/sup/account.rb @@ -10,6 +10,17 @@ class Account < Person @sendmail = h[:sendmail] @signature = h[:signature] end + + # Default sendmail command for bouncing mail, + # deduced from #sendmail + def bounce_sendmail + sendmail.sub(/\s(\-(ti|it|t))\b/) do |match| + case $1 + when '-t' then '' + else ' -i' + end + end + end end class AccountManager diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index 81197c2..e7f4a4f 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -202,12 +202,7 @@ EOS m = @message_lines[curpos] or return to = BufferManager.ask_for_contacts(:people, "Bounce To: ") or return - defcmd = AccountManager.default_account.sendmail.sub(/\s(\-(ti|it|t))\b/) do |match| - case "$1" - when '-t' then '' - else ' -i' - end - end + defcmd = AccountManager.default_account.bounce_sendmail cmd = case (hookcmd = HookManager.run "bounce-command", :from => m.from, :to => to) when nil, /^$/ then defcmd -- 1.5.6.5 -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From sven.schober@uni-ulm.de Sat Oct 10 08:01:14 2009 From: sven.schober@uni-ulm.de (Sven Schober) Date: Sat, 10 Oct 2009 14:01:14 +0200 Subject: [sup-talk] pinentry-curses messes up sup Message-ID: <1255175624-sup-8207@hysbald> Hi Suppers! First of all, let me say i really enjoy using sup :) Thanks for the great mua! No to my problem: I'm experiencing the problem described by Nicolas Pouillard, here [1]. After using pinentry-curses to enter my gpg passphrase sup seems to be a little messed up, as the arrow keys won't work any more, or at least, not as expected (pressing left has horrendous consequences as its control sequence seems to be ^[[D, which caused some major mail deletion for me *g*). As that thread is rather old, i would like to now if there's been some development on this? Are there any console alternatives to pinentry-curses? Keep up the good work! Cheers, Sven [1]: -- Sven Schober, sven.schober at uni-ulm.de |UNI ULM http://www-vs.informatik.uni-ulm.de/dept/staff/schober/ |DISTRIBUTED Room O27-346, Phone: +49-731-5024146 [+49-179-5060182] |SYSTEMS LAB -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mailinglist@flasht.de Sat Oct 10 10:41:29 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Sat, 10 Oct 2009 16:41:29 +0200 Subject: [sup-talk] show labels of polled messages Message-ID: <1255184817-sup-1561@thinkpad-ubuntu> Hi, I always thought it would be nice to see to which labels new polled messages have been added. Usually, when I see new messages arrived, most of them aren't in my inbox, since I archive the messages of most of my sources (e.g. mailinglists like this one). Then, I usually go and look at the labels-list-mode to see where new messages got added. I've attached a patch that displays the labels of newly polled messages at the bottom, next to the amount of total messages added from polling. The patch is based on my i18n branch, but it should be easy to rebase it on next or master. What do you think of it? Cheers, Christopher. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: label_notification.patch Type: application/octet-stream Size: 3505 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From kevinr@free-dissociation.com Sat Oct 10 16:56:46 2009 From: kevinr@free-dissociation.com (Kevin Riggle) Date: Sat, 10 Oct 2009 16:56:46 -0400 Subject: [sup-talk] Exception in thread-view-mode Message-ID: <1255208137-sup-835@black-opal.mit.edu> I ran a search, I hit enter to load a message, I changed my mind and 'x'ed out before the message finished loading, and Sup crashed with: --- NoMethodError from thread: load messages for thread-view-mode undefined method `content_width' for nil:NilClass ./lib/sup/modes/thread-index-mode.rb:882:in `from_width' ./lib/sup/modes/thread-index-mode.rb:807:in `text_for_thread_at' ./lib/sup/hook.rb:122:in `each_with_index' ./lib/sup/modes/thread-index-mode.rb:806:in `each' ./lib/sup/modes/thread-index-mode.rb:806:in `each_with_index' ./lib/sup/modes/thread-index-mode.rb:806:in `text_for_thread_at' ./lib/sup/modes/thread-index-mode.rb:751:in `update_text_for_line' ./lib/sup/modes/thread-index-mode.rb:119:in `select' ./lib/sup.rb:77:in `reporting_thread' ./lib/sup.rb:75:in `initialize' ./lib/sup.rb:75:in `new' ./lib/sup.rb:75:in `reporting_thread' ./lib/sup/modes/thread-index-mode.rb:101:in `select' ./lib/sup/mode.rb:51:in `send' ./lib/sup/mode.rb:51:in `handle_input' ./lib/sup/buffer.rb:267:in `handle_input' bin/sup:239 - Kevin -- Kevin Riggle (kevinr at free-dissociation.com) http://free-dissociation.com From wmorgan-sup@masanjin.net Sun Oct 11 16:25:33 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 11 Oct 2009 13:25:33 -0700 Subject: [sup-talk] pinentry-curses messes up sup In-Reply-To: <1255175624-sup-8207@hysbald> References: <1255175624-sup-8207@hysbald> Message-ID: <1255292709-sup-2216@masanjin.net> Reformatted excerpts from Sven Schober's message of 2009-10-10: > As that thread is rather old, i would like to now if there's been some > development on this? Are there any console alternatives to > pinentry-curses? I think I've fixed this in git next. Please try that. -- William From wmorgan-sup@masanjin.net Sun Oct 11 16:28:48 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 11 Oct 2009 13:28:48 -0700 Subject: [sup-talk] Fwd: Re: Crash while in thread-view-mode In-Reply-To: <1254955312-sup-7085@ben-laptop> References: <1254955312-sup-7085@ben-laptop> Message-ID: <1255292742-sup-3957@masanjin.net> Reformatted excerpts from Ben Gamari's message of 2009-10-07: > I understand that designing software around a contingency like this > might not be the best practice, but the frequency with which I've > needed to rebuild really does make me think that ruby isn't the best > language for the indexer. The indexer isn't in Ruby, it's written in C++ in the case of Xapian and C in the case of Ferret. > This is easily the fifth time I've needed to rebuild and each time it > has taken over 30 minutes for 1.5 GB of mail. That's substantially > less than 1MB/second for what should be an I/O bound operation. Ouch. I think this isn't the indexer's fault so much as the mbox parsing, which is Ruby. I'm sorry you've had to rebuild the index so many times. The Xapian side of things is very new, and I think you've had a run of bad luck. But I am personally not motivated to improve index time performance, because that's not a common event. At least, it shouldn't be. -- William From wmorgan-sup@masanjin.net Sun Oct 11 16:30:08 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 11 Oct 2009 13:30:08 -0700 Subject: [sup-talk] curses exception In-Reply-To: References: Message-ID: <1255292940-sup-5558@masanjin.net> Reformatted excerpts from Dan Falcone's message of 2009-10-06: > I'm trying to get sup running on my work machine, which is unfortunately a > windows box. I have cygwin installed, along with the cygwin packages for > ruby and ncurses. Here's the contents of ~/.sup/exception-log.txt: > > --- ArgumentError from thread: main > couldn't initialize curses color pair 4, -1 (key 1) > /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/colormap.rb:133:in `color_for' Weird. We've had other people get it working on Cygwin before, I believe. Are you running this within Cygwin's rxvt? What if you modify lib/sup/colormap.rb so that NUM_COLORS=15? -- William From wmorgan-sup@masanjin.net Sun Oct 11 16:31:49 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 11 Oct 2009 13:31:49 -0700 Subject: [sup-talk] Crash while scrolling In-Reply-To: <1254422805-sup-9288@ben-laptop> References: <20090911165830.GA11260@ben-laptop> <1252773189-sup-246@masanjin.net> <20090916172340.GA20566@ben-laptop> <1253975267-sup-8308@masanjin.net> <1254160696-sup-3522@ben-laptop> <1254404181-sup-8448@masanjin.net> <1254418089-sup-5800@ben-laptop> <1254421545-sup-8303@masanjin.net> <1254422805-sup-9288@ben-laptop> Message-ID: <1255293077-sup-9788@masanjin.net> Reformatted excerpts from Ben Gamari's message of 2009-10-01: > Is ferret even going to be supported after the Xapian backend > stabilizes? No, I'm going to drop it at some point. I barely have enough time or energy for Sup's current set of problems as is. :) -- William From bgamari.foss@gmail.com Sun Oct 11 17:04:53 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Sun, 11 Oct 2009 17:04:53 -0400 Subject: [sup-talk] Fwd: Re: Crash while in thread-view-mode In-Reply-To: <1255292742-sup-3957@masanjin.net> References: <1254955312-sup-7085@ben-laptop> <1255292742-sup-3957@masanjin.net> Message-ID: <1255294905-sup-8@ben-laptop> Excerpts from William Morgan's message of Sun Oct 11 16:28:48 -0400 2009: > Reformatted excerpts from Ben Gamari's message of 2009-10-07: > > I understand that designing software around a contingency like this > > might not be the best practice, but the frequency with which I've > > needed to rebuild really does make me think that ruby isn't the best > > language for the indexer. > > The indexer isn't in Ruby, it's written in C++ in the case of Xapian and > C in the case of Ferret. Sorry, I was referring to the mail indexer (i.e. message, mbox/maildir parser), not the backend indexing engine (e.g. Xapian). Should have been more specific. > > > This is easily the fifth time I've needed to rebuild and each time it > > has taken over 30 minutes for 1.5 GB of mail. That's substantially > > less than 1MB/second for what should be an I/O bound operation. Ouch. > > I think this isn't the indexer's fault so much as the mbox parsing, > which is Ruby. Exactly. This is where I think C++ is probably appropriate. > > I'm sorry you've had to rebuild the index so many times. The Xapian side > of things is very new, and I think you've had a run of bad luck. But I > am personally not motivated to improve index time performance, because > that's not a common event. At least, it shouldn't be. Completely understandable. I really don't have a right to complain. It does work a large majority of the time, after all. Just figured I'd let you know of problems as they happen. Thanks for the awesome client. - Ben From stettberger@dokucode.de Mon Oct 12 03:11:35 2009 From: stettberger@dokucode.de (Christian Dietrich) Date: Mon, 12 Oct 2009 09:11:35 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255085867-sup-8410@qwerzila> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> <1255030392-sup-1135@thinkpad-ubuntu> <1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila> <1255034958-sup-5628@peer.zerties.org> <1255073126-sup-6984@qwerzila> <1255074206-sup-7503@peer.zerties.org> <1255081131-sup-7915@qwerzila> <1255083021-sup-226@qwerzila> <1255084730-sup-671@peer.zerties.org> <1255085867-sup-8410@qwerzila> Message-ID: <1255331296-sup-5993@peer.zerties.org> Excerpts from Gaute Hope's message of Fr Okt 09 13:00:19 +0200 2009: > Or the thread count isn't aware of the Today mark and still thinks line > 2 is thread 2? Don't really know anything about the implementation. > > When it happens it doesn't dissapear before I do a M or there is a pull > that redraws the screen.. just pressing Ctrl+L or opening/closing a > thread doesn't remove it. > > As said earlier it only seems to affect the top two threads. Hi, i also experienced now this Problem, but can't see were this problem is located, because i don't touch the internal states of the threads. There must be one @thread[curpos] left, which causes this Problem. greetz didi -- No documentation is better than bad documentation -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt. From wmorgan-sup@masanjin.net Mon Oct 12 08:14:42 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 12 Oct 2009 05:14:42 -0700 Subject: [sup-talk] Ruby 1.9 status? In-Reply-To: <1255029826-sup-8182@peray> References: <1255029826-sup-8182@peray> Message-ID: <1255349584-sup-5924@masanjin.net> Reformatted excerpts from Nicolas Pouillard's message of 2009-10-08: > I would like to know what is the sup status w.r.t ruby 1.9? The code is syntactically ready for 1.9. There's a Ferret 1.9 gem as of recently, which you can try. Someone wrote a blog post here: http://trickyco.de/2009/09/24/installing-the-sup-mua-on-64bit-arch-linux And made some patches, which I haven't had a chance to review yet. At some point I tried Xapian with 1.9 and ran into some weird errors. If you search the mailing list, you should find it. -- William From wmorgan-sup@masanjin.net Mon Oct 12 08:48:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 12 Oct 2009 05:48:50 -0700 Subject: [sup-talk] [PATCH] Allow thread index view to sort oldest first In-Reply-To: <1253911610-sup-2052@yoom.home.cworth.org> References: <1253911610-sup-2052@yoom.home.cworth.org> Message-ID: <1255350472-sup-5679@masanjin.net> Hi Carl & Keith, Reformatted excerpts from Carl Worth's message of 2009-09-25: > The below patches are a first cut at implementing this. I've finally gotten a chance to look at this. It looks good so far. I would like to merge this in in such a way that it doesn't change behavior for anyone who doesn't want it. So I definitely don't want the second patch which changes the default order. The configuration boolean is fine. (And if you want to add a question to sup-config, that's icing on the cake.) I would also like to disable forcing the loading of all messages. Personalyl, I follow the inbox 30,000 philosophy. The 'o' keybinding is cool, but if I scroll down then suddenly the thread loading goes crazy. For those who have inboxes that are small enough to load but bigger than one screen (the "reverse inbox 50" crowd), I don't think that pressing !! is too onerous. > 1. When doing oldest-first searching, it wasn't obvious if it's even > possible to query for only the N oldest messages (to lazily load > new threads while navigating as sup currently does). So the patch > currently loads all threads when in oldest-first mode. It is possible in Ferret: remove the DESC in ferret_index.rb line 160. It is also possible in Xapian, but we're building the Xapian index to optimize newest-first access. (Of course that would also be possible to change, but then we're talking about a total index rebuild.) If you wanted to tweak that, the load-all-threads wouldn't be necessary. Either way, I'm happy to merge the first patch with the "n = -1" thing removed. > 2. Currently sup uses the date of the newest message in a thread as > the key for sorting that message. This is correct for newest-first > sorting. But when doing the new oldest-first sorting, the patch > really should be augmented to instead use the date of the oldest > message in a thread that matches the current search criteria. > > We haven't looked yet into how hard this would be to fix. (And we'd > of course be glad for any help or pointers.) Pretty easy to change. In thread.rb, there's a date method which takes a max; you can make it take a min instead. The hard work for both of these things is wiring this option through. Although $config is a global variable, I don't really want to use it directly in e.g. thread.rb. > PS. We're still total ruby newbies, so please point out any silly > mistakes we're missing with respect to ruby idioms. Everything looks good. The only slgihtly non-idiomatic thing is using "if !x" instead of "unless x". -- William From wmorgan-sup@masanjin.net Mon Oct 12 09:30:21 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 12 Oct 2009 06:30:21 -0700 Subject: [sup-talk] [PATCH] Add hooks to sort and format label-list-mode display. In-Reply-To: <1254418284-sup-3486@kronos> References: <1253303493-sup-288@kronos> <1254416245-sup-4497@masanjin.net> <1254418284-sup-3486@kronos> Message-ID: <1255354211-sup-1536@masanjin.net> Branch label-list-mode-hooks, merged into next. Thanks! -- William From wmorgan-sup@masanjin.net Mon Oct 12 09:31:21 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 12 Oct 2009 06:31:21 -0700 Subject: [sup-talk] [PATCH] don't downcase a nil content-type In-Reply-To: <1254593997-32634-1-git-send-email-rlane@club.cc.cmu.edu> References: <1254593997-32634-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1255354267-sup-3594@masanjin.net> Applied directly to master. Thanks! -- William From wmorgan-sup@masanjin.net Mon Oct 12 09:42:10 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 12 Oct 2009 06:42:10 -0700 Subject: [sup-talk] labels-before-subject and ask_for_contacts config knobs In-Reply-To: <1254565800-sup-5590@lanparty.ee> References: <1254565800-sup-5590@lanparty.ee> Message-ID: <1255354888-sup-8991@masanjin.net> Reformatted excerpts from Tarko Tikan's message of 2009-10-03: > ask_for_contacts is loading 10 contacts from index, imho this doesn't > make a sane default (it's too low). I've always patched this to 500 on > my end - yes, it takes a second or two to load that many contacts from > index but this doesn't bug me as much as first looking up the person > and then composing to him. Yeah, this number should be increased. Unfortunately the time required is tied to your index size and your machine, and 500 is way too slow for me. There are actually two numbers: the number of initial contacts, and the number that gets added when you press "M". I've changed the first to (2 * # of screen rows) and the second to 100. Hopefully that's a little more usable to you. -- William From wmorgan-sup@masanjin.net Mon Oct 12 09:43:48 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 12 Oct 2009 06:43:48 -0700 Subject: [sup-talk] labels-before-subject and ask_for_contacts config knobs In-Reply-To: <1254667184-sup-153@bar-coded.net> References: <1254565800-sup-5590@lanparty.ee> <1254667184-sup-153@bar-coded.net> Message-ID: <1255354943-sup-8569@masanjin.net> Reformatted excerpts from Marcus Williams's message of 2009-10-04: > If you search through the archives you should find a patch I submitted > for an alternate view. The default alternate view I find very good on > smaller devices and its configurable via a hook if you want anything > more. Not sure if its going to get integrated into sup though (Any > thoughts William? - I can resubmit if necessary) I'm a little wary of starting down the slippery slope of a million different screen configurations, but maybe it's ok to have a "small screen mode". Is that what the alternate view is for? -- William From wmorgan-sup@masanjin.net Mon Oct 12 09:46:44 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 12 Oct 2009 06:46:44 -0700 Subject: [sup-talk] [PATCH] Handle added messages in label-list-mode In-Reply-To: <1254669536-sup-2700@longword> References: <1252789445-30193-1-git-send-email-gigabo@gmail.com> <1254415913-sup-6275@masanjin.net> <1254669536-sup-2700@longword> Message-ID: <1255355098-sup-4003@masanjin.net> Reformatted excerpts from Bo Borgerson's message of 2009-10-04: > Is there a way to label or delete threads without leaving the > label-list-mode? There's already a refresh when switching back to the > label-list-mode from elsewhere, I think, so any changes that are $aved > should be reflected immediately when you get back. That's a good point. Yeah, this is unnecessary until we make some major interface redesigns. -- William From wmorgan-sup@masanjin.net Mon Oct 12 09:51:31 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 12 Oct 2009 06:51:31 -0700 Subject: [sup-talk] Bugfix for custom-search In-Reply-To: <1254869038-sup-9250@javelin> References: <1254418685-sup-6611@javelin> <1254869038-sup-9250@javelin> Message-ID: <1255355369-sup-9880@masanjin.net> Reformatted excerpts from Edward Z. Yang's message of 2009-10-06: > Any comments? Sorry about the delay. Applied directly to master. I was sure I had done this right, but somehow it was only reflected in next, not in master. Oh well. Thanks! -- William From wmorgan-sup@masanjin.net Mon Oct 12 09:54:06 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 12 Oct 2009 06:54:06 -0700 Subject: [sup-talk] [PATCH] more inline GPG madness In-Reply-To: <1254417896-sup-2359@midna.zekjur.net> References: <1254348163-sup-6170@midna.zekjur.net> <1254417896-sup-2359@midna.zekjur.net> Message-ID: <1255355627-sup-2988@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-10-01: > I will instead implement support for "correct" inline GPG. I've reworked this code a bit in recent commits, so make sure you have an up-to-date copy. -- William From marcus-sup@bar-coded.net Mon Oct 12 12:35:48 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Mon, 12 Oct 2009 17:35:48 +0100 Subject: [sup-talk] labels-before-subject and ask_for_contacts config knobs In-Reply-To: <1255354943-sup-8569@masanjin.net> References: <1254565800-sup-5590@lanparty.ee> <1254667184-sup-153@bar-coded.net> <1255354943-sup-8569@masanjin.net> Message-ID: <1255365030-sup-4877@bar-coded.net> On 12.10.2009, William Morgan wrote: > I'm a little wary of starting down the slippery slope of a million > different screen configurations, but maybe it's ok to have a "small > screen mode". Is that what the alternate view is for? Thats certainly what I use it for. The default "alternative" is just to strip authors/dates from the index view (see screenshot). A hook allows you to do what you want with it (like remove the labels). Its only toggleable via a keypress currently, but I find it useful on a smaller screen. If you're happy with it I might change the default alternative view to not include labels (or maybe move them to the end of the subject) before resubmission. My hooked version doesnt bother displaying the labels at all. Marcus -------------- next part -------------- A non-text attachment was scrubbed... Name: sup.jpg Type: image/jpeg Size: 187012 bytes Desc: not available URL: From stettberger@dokucode.de Mon Oct 12 15:23:48 2009 From: stettberger@dokucode.de (Christian Dietrich) Date: Mon, 12 Oct 2009 21:23:48 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1255331296-sup-5993@peer.zerties.org> References: <1254247706-sup-2745@peer.zerties.org> <1254334371-sup-5145@masanjin.net> <1254516195-sup-4619@peer.zerties.org> <1254985425-sup-2303@peer.zerties.org> <1255005056-sup-7120@thinkpad-ubuntu> <1255005777-sup-7020@thinkpad-ubuntu> <1255026503-sup-3624@peer.zerties.org> <1255030392-sup-1135@thinkpad-ubuntu> <1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila> <1255034958-sup-5628@peer.zerties.org> <1255073126-sup-6984@qwerzila> <1255074206-sup-7503@peer.zerties.org> <1255081131-sup-7915@qwerzila> <1255083021-sup-226@qwerzila> <1255084730-sup-671@peer.zerties.org> <1255085867-sup-8410@qwerzila> <1255331296-sup-5993@peer.zerties.org> Message-ID: <1255375298-sup-2024@peer.zerties.org> Excerpts from Christian Dietrich's message of Mo Okt 12 09:11:35 +0200 2009: > Excerpts from Gaute Hope's message of Fr Okt 09 13:00:19 +0200 2009: > > Or the thread count isn't aware of the Today mark and still thinks line > > 2 is thread 2? Don't really know anything about the implementation. > > > > When it happens it doesn't dissapear before I do a M or there is a pull > > that redraws the screen.. just pressing Ctrl+L or opening/closing a > > thread doesn't remove it. > > > > As said earlier it only seems to affect the top two threads. > > Hi, > i also experienced now this Problem, but can't see were this problem > is located, because i don't touch the internal states of the > threads. There must be one @thread[curpos] left, which causes this > Problem. > > greetz didi Hi, i think i've fixed the problem now, it was a wrong mapping in update_text_for_line, now the situation that caused the error before succeeds. There was a misguiding declaration of @size_widgets in the init function. @size_widgets isn't a Hash, mapping line numbers to a size_widget, it is the same index as in @threads for the specific thread. greetz didi PS: please pull :-) -- No documentation is better than bad documentation -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt. From tero@tilus.net Mon Oct 12 17:50:20 2009 From: tero@tilus.net (Tero Tilus) Date: Tue, 13 Oct 2009 00:50:20 +0300 Subject: [sup-talk] Oddities of marking spam Message-ID: <20091012215020.GA31940@tilus.net> First of all, Sup is a mindblowing experience! Really. Right after first trial I decided it will (no ifs) replace mutt as my primary MUA. I'll do whatever it takes to make this one work for me too. It almost does already. In between tuning other things I made a couple of observations (branch next). Sorry about not having a patch (not working on this, right now I'm trying to make Xapian eat my 100k+ mails). Marking spam in thread-view-mode does not run mark-as-spam hook. This isn't intentional? If I look at spam (L, 'spam', ret) and then decide there's a false positive and hit S, spam-tag is removed but thread will not disappear from the view. If I then view the thread, hit .s spam label is correctly added to the thread but at the same time it is _removed_ from the previously mentioned spam list. The same happens if I don't view the thread but hit S again. Pressing M doesn't bring the re-spammed thread back to the label search view showing spam. Killing the buffer and doing L, 'spam', ret again does. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From tero@tilus.net Mon Oct 12 18:34:49 2009 From: tero@tilus.net (Tero Tilus) Date: Tue, 13 Oct 2009 01:34:49 +0300 Subject: [sup-talk] Xapian: Term too long Message-ID: <20091012223449.GB31940@tilus.net> sup-sync blows up like this /home/terotil/src/sup/lib/sup/xapian_index.rb:446:in `replace_document': InvalidArgumentError: Term too long (> 245): Lfwd: =?iso-8859-1?q?tekij=e4n_oikeudet=5d?= (ArgumentError) x-enigmail-version: 0.92.0.0 content-type: multipart/mixed; boundary="------------010606010007070802040301" x-virus-scanned: amavisd-new at cc.jyu.fi x-spam-status: no, hits=-2.373 required=5 tests=[awl=0.226, bayes_00=-2.599 from /home/terotil/src/sup/lib/sup/xapian_index.rb:446:in `sync_message' from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' from /home/terotil/src/sup/lib/sup/xapian_index.rb:363:in `synchronize' from /home/terotil/src/sup/lib/sup/xapian_index.rb:440:in `sync_message' from /home/terotil/src/sup/lib/sup/xapian_index.rb:92:in `add_message' from /home/terotil/src/sup/bin/sup-sync:211 ... Relevant part of the problematic mail looks like this User-Agent: Debian Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mutikainen at iki.fi Subject: [Fwd: =?ISO-8859-1?Q?tekij=E4n_oikeudet=5D?= X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/mixed; boundary="------------010606010007070802040301" X-Virus-Scanned: amavisd-new at cc.jyu.fi X-Spam-Status: No, hits=-2.373 required=5 tests=[AWL=0.226, BAYES_00=-2.599] X-Spam-Level: X-Sorted: Whitelist Content-Length: 11892 This is how I solved it for me, for now diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index ad45b0e..d3b3e25 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -443,7 +443,11 @@ EOS warn "docid underflow, dropping #{m.id.inspect}" return end - @xapian.replace_document docid, doc + begin + @xapian.replace_document docid, doc + rescue StandardError => err + warn "Failed to add message #{m.id.inspect} to Xapian index: #{err}" + end end m.labels.each { |l| LabelManager << l } Looks like lib/sup/xapian_index.rb tries to override Xapian::Document#add_term with a version which is wired to ditch too long terms. Only that you can't override methods just by including a module. Methods of the including class override methods in included module. terotil at sotka:~$ irb > class Foo; def bar; :bar; end; end => nil > module Baz; def bar; :baz; end; end => nil > class Foo; include Baz; end => Foo > Foo.new.bar => :bar > Foo.ancestors => [Foo, Baz, Object, Kernel] # Foo before Baz, methods in Foo take priority It is still Foo#bar being called, not Baz#bar. You need to open up Xapian::Document and then do alias method chaining to override methods. Or you could do tricks like http://coderrr.wordpress.com/2008/10/29/secure-alias-method-chaining/ -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From cworth@cworth.org Mon Oct 12 19:02:30 2009 From: cworth@cworth.org (Carl Worth) Date: Mon, 12 Oct 2009 16:02:30 -0700 Subject: [sup-talk] [PATCH] Allow thread index view to sort oldest first In-Reply-To: <1255350472-sup-5679@masanjin.net> References: <1253911610-sup-2052@yoom.home.cworth.org> <1255350472-sup-5679@masanjin.net> Message-ID: <1255388543-sup-7477@yoom.home.cworth.org> Excerpts from William Morgan's message of Mon Oct 12 05:48:50 -0700 2009: > I've finally gotten a chance to look at this. It looks good so far. Thanks for taking a look at it. > So I definitely don't want the second patch which changes the default > order. The configuration boolean is fine. (And if you want to add a > question to sup-config, that's icing on the cake.) I totally understand that, and that's why I did that part as a separate patch. > I would also like to disable forcing the loading of all messages. I can understand that too. > It is possible in Ferret: remove the DESC in ferret_index.rb line 160. > It is also possible in Xapian, but we're building the Xapian index to > optimize newest-first access. (Of course that would also be possible to > change, but then we're talking about a total index rebuild.) > > If you wanted to tweak that, the load-all-threads wouldn't be necessary. How do we get this behavior in xapian? I'm fine if the index is not optimized for this. The current newest-first optimization is perfect for actual searching, (as opposed to reading of new messages), and the patches don't change that. > Either way, I'm happy to merge the first patch with the "n = -1" thing > removed. I wouldn't want the patch accepted with just that change. It results in a "broken" view, (it claims to be showing the oldest message first, but it doesn't, and trying to scroll "up" to see earlier messages also doesn't work). So I'll see if I can figure out how to just load the N oldest message instead. (My working theory was that this perform similarly to actually loading all the messages, and that's why the patch just did that). > Pretty easy to change. In thread.rb, there's a date method which takes a > max; you can make it take a min instead. Excellent. I'll take a look at that. > The hard work for both of these things is wiring this option through. > Although $config is a global variable, I don't really want to use it > directly in e.g. thread.rb. OK. I'll see if there's nearby code to mimic for this. -Carl > > PS. We're still total ruby newbies, so please point out any silly > > mistakes we're missing with respect to ruby idioms. > > Everything looks good. The only slgihtly non-idiomatic thing is using > "if !x" instead of "unless x". Heh. Just today I noticed "unless" while poking around in some sup code. I have to say that "unless ... else" seems like a downright malicious construct to unleash against people reading code. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From tero@tilus.net Mon Oct 12 19:22:15 2009 From: tero@tilus.net (Tero Tilus) Date: Tue, 13 Oct 2009 02:22:15 +0300 Subject: [sup-talk] RMail chokes on broken headers Message-ID: <20091012232215.GD31940@tilus.net> RMail::Header#content_type breaks when it encounters broken Content-Type and takes sup-sync down with it /usr/lib/ruby/gems/1.8/gems/rmail-1.0.0/lib/rmail/header.rb:537:in `content_type': undefined method `downcase' for nil:NilClass (NoMethodError) from /home/terotil/src/sup/lib/sup/message.rb:439:in `message_to_chunks' from /home/terotil/src/sup/lib/sup/message.rb:239:in `load_from_source!' from /home/terotil/src/sup/lib/sup/message.rb:335:in `build_from_source' from /home/terotil/src/sup/lib/sup/poll.rb:160:in `each_message_from' Worked around it this way diff --git a/lib/sup/message.rb b/lib/sup/message.rb index f9f87de..5ff3e48 100644 --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -436,7 +436,7 @@ private end chunks - elsif m.header.content_type && m.header.content_type.downcase == "message/rfc822" + elsif (m.header.content_type == "message/rfc822" rescue false) # rmail 1.0.0 may choke on broken content-type header, FIXME: fix rmail if m.body payload = RMail::Parser.read(m.body) from = payload.header.from.first ? payload.header.from.first.format : "" @@ -456,7 +456,7 @@ private debug "no body for message/rfc822 enclosure; skipping" [] end - elsif m.header.content_type && m.header.content_type.downcase == "application/pgp" && m.body + elsif (m.header.content_type.downcase == "application/pgp" rescue false) && m.body # rmail 1.0.0 may choke on broken content-type header, FIXME: fix rmail ## apparently some versions of Thunderbird generate encryped email that ## does not follow RFC3156, e.g. messages with X-Enigmail-Version: 0.95.0 ## they have no MIME multipart and just set the body content type to The problem itself is inside RMail. I reported it. http://rubyforge.org/tracker/index.php?func=detail&aid=27282&group_id=446&atid=1754 RMail looks abandoned. Development is pretty much stalled. No functional changes since 2004-04-27. None of the reported bugs have been fixed. Might it be worth to think about switching to another mail lib? TMail author's http://github.com/mikel/mail/ looks promising. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From sven.schober@uni-ulm.de Tue Oct 13 04:13:53 2009 From: sven.schober@uni-ulm.de (Sven Schober) Date: Tue, 13 Oct 2009 10:13:53 +0200 Subject: [sup-talk] pinentry-curses messes up sup In-Reply-To: <1255292709-sup-2216@masanjin.net> References: <1255175624-sup-8207@hysbald> <1255292709-sup-2216@masanjin.net> Message-ID: <1255421626-sup-4525@hysbald> Excerpts from William Morgan's message of Sun Oct 11 22:25:33 +0200 2009: > Reformatted excerpts from Sven Schober's message of 2009-10-10: > > As that thread is rather old, i would like to now if there's been some > > development on this? Are there any console alternatives to > > pinentry-curses? > > I think I've fixed this in git next. Please try that. Works like a charm :) Thanks! -- Sven Schober, sven.schober at uni-ulm.de |UNI ULM http://www-vs.informatik.uni-ulm.de/dept/staff/schober/ |DISTRIBUTED Room O27-346, Phone: +49-731-5024146 [+49-179-5060182] |SYSTEMS LAB -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From tero@tilus.net Tue Oct 13 08:40:03 2009 From: tero@tilus.net (Tero Tilus) Date: Tue, 13 Oct 2009 15:40:03 +0300 Subject: [sup-talk] IMAP and recursion Message-ID: <20091013124002.GA7129@tilus.net> I had quite a lot of IMAP folders to add and went looking for recursion. I found old sup-talk threads on the subject and thought of it a while. I might have missed something, but I could not easily get around sup-add asking me all the time which account she should use. So I went on to add --force-account user at host to be able to batch-add IMAP sources. What do you think? --- diff --git a/bin/sup-add b/bin/sup-add index e27a0eb..c53378d 100755 --- a/bin/sup-add +++ b/bin/sup-add @@ -39,6 +39,7 @@ EOS opt :unusual, "Do not automatically poll these sources for new messages." opt :labels, "A comma-separated set of labels to apply to all messages from this source", :type => String opt :force_new, "Create a new account for this source, even if one already exists." + opt :force_account, "Reuse previously defined account user at hostname.", :type => String end Trollop::die "require one or more sources" if ARGV.empty? @@ -56,13 +57,20 @@ def get_login_info uri, sources username, password = nil, nil unless accounts.empty? || $opts[:force_new] - say "Would you like to use the same account as for a previous source for #{uri}?" - choose do |menu| - accounts.each do |host, olduser, oldpw| - menu.choice("Use the account info for #{olduser}@#{host}") { username, password = olduser, oldpw } + if $opts[:force_account] + host, username, password = accounts.find { |h, u, p| $opts[:force_account] == "#{u}@#{h}" } + unless username && password + say "No previous account #{$opts[:force_account].inspect} found." + end + else + say "Would you like to use the same account as for a previous source for #{uri}?" + choose do |menu| + accounts.each do |host, olduser, oldpw| + menu.choice("Use the account info for #{olduser}@#{host}") { username, password = olduser, oldpw } + end + menu.choice("Use a new account") { } + menu.prompt = "Account selection? " end - menu.choice("Use a new account") { } - menu.prompt = "Account selection? " end end --- -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From bgamari.foss@gmail.com Tue Oct 13 16:18:44 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Tue, 13 Oct 2009 16:18:44 -0400 Subject: [sup-talk] Fwd: Re: Crash while in thread-view-mode In-Reply-To: <1255292742-sup-3957@masanjin.net> References: <1254955312-sup-7085@ben-laptop> <1255292742-sup-3957@masanjin.net> Message-ID: <1255464686-sup-4163@ben-laptop> Excerpts from William Morgan's message of Sun Oct 11 16:28:48 -0400 2009: > I'm sorry you've had to rebuild the index so many times. The Xapian side > of things is very new, and I think you've had a run of bad luck. But I > am personally not motivated to improve index time performance, because > that's not a common event. At least, it shouldn't be. Unfortunately, it seems that the crashes have returned (In fact, they returned only hours after I rebuilt). Interestingly, it is once again my LKML label that is the culprit. On the note of crashing, is it really necessary for the "wrong id called on nil" exception to be fatal? Couldn't the client at least make some attempt at recovering (skipping the problematic thread while catching and logging the exception)? It seems like these issues could be rather tricky to sort out (I've put an hour or so into tracking down the source of the nils to no avail), and with a dynamically typed language like Ruby, could occur at any time. Considering this, it seems like it might be a good idea to handle these failures a bit more gracefully. Would this be problematic? Regardless, it might be a good idea to have a hierarchy of exception classes instead of just throwing Strings. It seems that throwing specialized classes would make the above substantially easier. Thanks, - Ben --- RuntimeError from thread: load threads for thread-index-mode wrong id called on nil /opt/exp/sup/lib/sup.rb:17:in `id' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update' /usr/lib64/ruby/1.8/rubygems/custom_require.rb:31:in `sort_by' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:628:in `__unprotected_load_n_threads' /opt/exp/sup/lib/sup/thread.rb:334:in `load_n_threads' /opt/exp/sup/lib/sup/xapian_index.rb:117:in `each_id_by_date' /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id' /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each' /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id' /opt/exp/sup/lib/sup/xapian_index.rb:117:in `each_id_by_date' /opt/exp/sup/lib/sup/thread.rb:328:in `load_n_threads' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background' /opt/exp/sup/lib/sup.rb:77:in `reporting_thread' /opt/exp/sup/lib/sup.rb:75:in `initialize' /opt/exp/sup/lib/sup.rb:75:in `new' /opt/exp/sup/lib/sup.rb:75:in `reporting_thread' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:81:in `initialize' /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `call' /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `initialize' /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `each' /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `initialize' /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:19:in `new' /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:19:in `initialize' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:54:in `initialize' /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:9:in `initialize' /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `new' /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `spawn_nicely' /opt/exp/sup/lib/sup/buffer.rb:350:in `spawn_unless_exists' /opt/exp/sup/lib/sup/util.rb:520:in `send' /opt/exp/sup/lib/sup/util.rb:520:in `method_missing' /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `spawn_nicely' /opt/exp/sup/lib/sup/modes/label-list-mode.rb:134:in `select_label' /opt/exp/sup/lib/sup/mode.rb:51:in `send' /opt/exp/sup/lib/sup/mode.rb:51:in `handle_input' /opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input' /usr/bin/sup:245 From olly@survex.com Tue Oct 13 16:51:10 2009 From: olly@survex.com (Olly Betts) Date: Tue, 13 Oct 2009 20:51:10 +0000 (UTC) Subject: [sup-talk] [PATCH] Allow thread index view to sort oldest first References: <1253911610-sup-2052@yoom.home.cworth.org> <1255350472-sup-5679@masanjin.net> <1255388543-sup-7477@yoom.home.cworth.org> Message-ID: On 2009-10-12, Carl Worth wrote: > How do we get this behavior in xapian? I'm fine if the index is not > optimized for this. The current newest-first optimization is perfect > for actual searching, (as opposed to reading of new messages), and the > patches don't change that. @enquire.docid_order = Xapian::Enquire::DESCENDING This means that the docid order (which is used as the least significant ordering) is descending rather than ascending. In this case (I assume) we're using Xapian::BoolWeight so this is the only ordering. Cheers, Olly From tero@tilus.net Wed Oct 14 09:34:55 2009 From: tero@tilus.net (Tero Tilus) Date: Wed, 14 Oct 2009 16:34:55 +0300 Subject: [sup-talk] Sup finds ghost messages Message-ID: <1255526768-sup-3152@tilus.net> sup-sync --all (using xapian) from a new source occasionally says 1-2 messages already were in the index, even if they most certainly weren't. I noticed this when I added sup-talk archives to my index. I'm 100% sure I did not have any sup-talk mails from somewhere 2007-2008 in any of my other sources. Still sup-sync said it did not add a couple of messages which supposedly already were in the index. ps. Happily on sup now. \o/ All mails in, 1G index. Xapian is blazing fast... pps. Why bugs to this list? Why not use a tracker? (besides that sup is awesome tracker too ;) -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From tero@tilus.net Wed Oct 14 18:27:03 2009 From: tero@tilus.net (Tero Tilus) Date: Thu, 15 Oct 2009 01:27:03 +0300 Subject: [sup-talk] Wrapping long lines Message-ID: <1255558925-sup-2369@tilus.net> How can I make sup wrap long lines? I occasionally receive unwrapped text/plain mails and it would be cool to have the "i dont care what you need to do, but just fit it in the terminal window width" button. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From michael+sup@stapelberg.de Thu Oct 15 06:50:13 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Thu, 15 Oct 2009 12:50:13 +0200 Subject: [sup-talk] About faking message IDs Message-ID: <1255603625-sup-2558@midna.zekjur.net> Hi, I just noticed that the lack of emails from my backup program seems to be because of the missing message ids in the mail script I use. In case of no message id inside the header, sup uses the md5sum of the whole header (see lib/sup/message.rb:74). This effectively means that messages having the same md5sum of their header (which happened, since the header was also generated completely by the script and the values did not change) will "overwrite" the old message. As a workaround, I now added the current time to my script, so that every header will have a different md5 sum. But maybe we can think of a more clever way to generate faked message ids? Maybe also hash the body of the message? Best regards, Michael From wmorgan-sup@masanjin.net Thu Oct 15 08:46:51 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 15 Oct 2009 05:46:51 -0700 Subject: [sup-talk] Crash while in thread-view-mode In-Reply-To: <1254955351-sup-5944@ben-laptop> References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop> <1254845543-sup-9458@ben-laptop> <1254896214-sup-5969@zyrg.net> <1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com> <1254945119-sup-3401@ben-laptop> <1254955351-sup-5944@ben-laptop> Message-ID: <1255610731-sup-7030@masanjin.net> Reformatted excerpts from Ben Gamari's message of 2009-10-07: > There must be a better way to deal with these invalid ids than > crashing. Is there any reason this needs to be a show-stopping event? This is probably a symptom of some thread protection issues. You're right, there's no reason this needs to crash Sup. You could apply this: diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index 82f258b..17d5836 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -222,7 +222,7 @@ EOS def update @mutex.synchronize do ## let's see you do THIS in python - @threads = @ts.threads.select { |t| !@hidden_threads[t] }.sort_by { |t| [t.date, t.first.id] }.reverse + @threads = @ts.threads.select { |t| !@hidden_threads[t] }.select { |t| t.first }.sort_by { |t| [t.date, t.first.id] }.reverse @size_widgets = @threads.map { |t| size_widget_for_thread t } @size_widget_width = @size_widgets.max_of { |w| w.display_length } end -- William From wmorgan-sup@masanjin.net Thu Oct 15 08:51:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 15 Oct 2009 05:51:50 -0700 Subject: [sup-talk] curses exception In-Reply-To: References: <1255292940-sup-5558@masanjin.net> Message-ID: <1255611057-sup-1320@masanjin.net> Reformatted excerpts from Dan Falcone's message of 2009-10-12: > Honestly, it's probably an issue with my setup... is there a guide > anywhere on how to get sup running in cygwin? Maybe I'm missing a > required package? There's no guide per se. Other people have definitely made it work in the past. Are you able to get other color curses programs to work? I suspect it's not a Sup issue per se, but I'm not that familiar with the intricacies of Cygwin. -- William From wmorgan-sup@masanjin.net Thu Oct 15 08:56:29 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 15 Oct 2009 05:56:29 -0700 Subject: [sup-talk] Oddities of marking spam In-Reply-To: <20091012215020.GA31940@tilus.net> References: <20091012215020.GA31940@tilus.net> Message-ID: <1255611277-sup-9644@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2009-10-12: > Marking spam in thread-view-mode does not run mark-as-spam hook. This > isn't intentional? Good point, that's a bug. > If I look at spam (L, 'spam', ret) and then decide there's a false > positive and hit S, spam-tag is removed but thread will not disappear > from the view. If I then view the thread, hit .s spam label is > correctly added to the thread but at the same time it is _removed_ > from the previously mentioned spam list. The same happens if I don't > view the thread but hit S again. Pressing M doesn't bring the > re-spammed thread back to the label search view showing spam. Killing > the buffer and doing L, 'spam', ret again does. The auto-adding and auto-removing of threads from search-result-mode is only able to work in certain limited cases, in general, but this sounds like a bug too. -- William From wmorgan-sup@masanjin.net Thu Oct 15 08:59:53 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 15 Oct 2009 05:59:53 -0700 Subject: [sup-talk] Xapian: Term too long In-Reply-To: <20091012223449.GB31940@tilus.net> References: <20091012223449.GB31940@tilus.net> Message-ID: <1255611567-sup-8695@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2009-10-12: > Looks like lib/sup/xapian_index.rb tries to override > Xapian::Document#add_term with a version which is wired to ditch too > long terms. Only that you can't override methods just by including a > module. Methods of the including class override methods in included > module. Very good point. Thanks! -- William From wmorgan-sup@masanjin.net Thu Oct 15 09:11:36 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 15 Oct 2009 06:11:36 -0700 Subject: [sup-talk] RMail chokes on broken headers In-Reply-To: <20091012232215.GD31940@tilus.net> References: <20091012232215.GD31940@tilus.net> Message-ID: <1255612194-sup-3880@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2009-10-12: > RMail looks abandoned. Development is pretty much stalled. No > functional changes since 2004-04-27. None of the reported bugs have > been fixed. Might it be worth to think about switching to another > mail lib? TMail author's http://github.com/mikel/mail/ looks > promising. Yeah, this is certainly an option. But it seems like a lot of work. And every day our set of rmail workarounds grows more robust. :) Not to say I wouldn't accept a patch that magically did this all for me, of course. -- William From wmorgan-sup@masanjin.net Thu Oct 15 09:45:47 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 15 Oct 2009 06:45:47 -0700 Subject: [sup-talk] Sup finds ghost messages In-Reply-To: <1255526768-sup-3152@tilus.net> References: <1255526768-sup-3152@tilus.net> Message-ID: <1255612303-sup-410@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2009-10-14: > sup-sync --all (using xapian) from a new source occasionally says 1-2 > messages already were in the index, even if they most certainly > weren't. I noticed this when I added sup-talk archives to my index. Can you run with -v and grep to make sure those message ids don't actually appear more than once in the mbox file? If they don't, can you isolate a particular one and use devel/console.sh to find out where Sup thinks the previous occurence is? > pps. Why bugs to this list? Why not use a tracker? (besides that sup > is awesome tracker too ;) If there's a good one out there I'd like to hear about it. We used ditz for a while because I hate clicking the mouse, but eventually it became too much effort. -- William From guillaume.quintard@gmail.com Thu Oct 15 09:47:00 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Thu, 15 Oct 2009 15:47:00 +0200 Subject: [sup-talk] Crash while in thread-view-mode In-Reply-To: <1255610731-sup-7030@masanjin.net> References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop> <1254845543-sup-9458@ben-laptop> <1254896214-sup-5969@zyrg.net> <1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com> <1254945119-sup-3401@ben-laptop> <1254955351-sup-5944@ben-laptop> <1255610731-sup-7030@masanjin.net> Message-ID: <1255614287-sup-4683@altis> Excerpts from William Morgan's message of Thu Oct 15 14:46:51 +0200 2009: > Reformatted excerpts from Ben Gamari's message of 2009-10-07: > > There must be a better way to deal with these invalid ids than > > crashing. Is there any reason this needs to be a show-stopping event? > > This is probably a symptom of some thread protection issues. You're > right, there's no reason this needs to crash Sup. You could apply this: > > diff --git a/lib/sup/modes/thread-index-mode.rb > b/lib/sup/modes/thread-index-mode.rb > index 82f258b..17d5836 100644 > --- a/lib/sup/modes/thread-index-mode.rb > +++ b/lib/sup/modes/thread-index-mode.rb > @@ -222,7 +222,7 @@ EOS > def update > @mutex.synchronize do > ## let's see you do THIS in python > - @threads = @ts.threads.select { |t| !@hidden_threads[t] }.sort_by { |t| > [t.date, t.first.id] }.reverse > + @threads = @ts.threads.select { |t| !@hidden_threads[t] }.select { |t| > t.first }.sort_by { |t| [t.date, t.first.id] }.reverse > @size_widgets = @threads.map { |t| size_widget_for_thread t } > @size_widget_width = @size_widgets.max_of { |w| w.display_length } > end Man, I love you, I can finally use sup again. (and I love the Python comment, even if I have no effing idea of what the code could mean.) Thanks! -- Guillaume From wmorgan-sup@masanjin.net Thu Oct 15 09:47:36 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 15 Oct 2009 06:47:36 -0700 Subject: [sup-talk] About faking message IDs In-Reply-To: <1255603625-sup-2558@midna.zekjur.net> References: <1255603625-sup-2558@midna.zekjur.net> Message-ID: <1255614431-sup-5910@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-10-15: > I just noticed that the lack of emails from my backup program seems to be > because of the missing message ids in the mail script I use. In case of > no message id inside the header, sup uses the md5sum of the whole header > (see lib/sup/message.rb:74). This effectively means that messages having > the same md5sum of their header (which happened, since the header was also > generated completely by the script and the values did not change) will > "overwrite" the old message. Doesn't the header include the date? -- William From michael+sup@stapelberg.de Thu Oct 15 09:55:13 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Thu, 15 Oct 2009 15:55:13 +0200 Subject: [sup-talk] before-edit hook and accessing the original sender Message-ID: <1255614656-sup-7039@midna.zekjur.net> Hi, I just configured a before-edit hook which prepends my usual greeting to the message and appends my greeting. To personalize the greeting, I access header["To"]. However, when replying to emails, this is not always the original sender of the message I am replying to (think of mailing lists). So, the question is, can I somehow access the message to which I am replying to when in the before-edit hook called when replying to a message. Best regards, Michael PS: I am not using the signature hook as I want to edit my signature inside my $EDITOR. Also, I need the greeting at the top of the message. From michael+sup@stapelberg.de Thu Oct 15 09:59:01 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Thu, 15 Oct 2009 15:59:01 +0200 Subject: [sup-talk] About faking message IDs In-Reply-To: <1255614431-sup-5910@masanjin.net> References: <1255603625-sup-2558@midna.zekjur.net> <1255614431-sup-5910@masanjin.net> Message-ID: <1255615018-sup-5653@midna.zekjur.net> Hi William, Excerpts from William Morgan's message of Thu Oct 15 15:47:36 +0200 2009: > Doesn't the header include the date? No, in my case it did not. The reason for that is calling "deliver" directly, that is without talking SMTP to a mailserver. Thus, no headers are getting added. Surely this is a corner case, but I think it will cause headache for system administrators running into this one, if they notice it all (overwriting messages is quite dangerous). Best regards, Michael From bgamari.foss@gmail.com Thu Oct 15 11:03:04 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Thu, 15 Oct 2009 11:03:04 -0400 Subject: [sup-talk] Crash while in thread-view-mode In-Reply-To: <1255610731-sup-7030@masanjin.net> References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop> <1254845543-sup-9458@ben-laptop> <1254896214-sup-5969@zyrg.net> <1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com> <1254945119-sup-3401@ben-laptop> <1254955351-sup-5944@ben-laptop> <1255610731-sup-7030@masanjin.net> Message-ID: <1255618838-sup-1025@ben-laptop> Excerpts from William Morgan's message of Thu Oct 15 08:46:51 -0400 2009: > Reformatted excerpts from Ben Gamari's message of 2009-10-07: > > There must be a better way to deal with these invalid ids than > > crashing. Is there any reason this needs to be a show-stopping event? > > This is probably a symptom of some thread protection issues. You're > right, there's no reason this needs to crash Sup. You could apply this: > Yep, this fixes it. Thank you so much. Now to sort through my backlog of mail. Thanks again, - Ben From wmorgan-sup@masanjin.net Thu Oct 15 11:16:36 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 15 Oct 2009 08:16:36 -0700 Subject: [sup-talk] Crash while in thread-view-mode In-Reply-To: <1255614287-sup-4683@altis> References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop> <1254845543-sup-9458@ben-laptop> <1254896214-sup-5969@zyrg.net> <1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com> <1254945119-sup-3401@ben-laptop> <1254955351-sup-5944@ben-laptop> <1255610731-sup-7030@masanjin.net> <1255614287-sup-4683@altis> Message-ID: <1255619752-sup-3707@masanjin.net> Reformatted excerpts from Guillaume Quintard's message of 2009-10-15: > (and I love the Python comment, even if I have no effing idea of what > the code could mean.) It refers to the fact that Python programs don't have bugs. -- William From wmorgan-sup@masanjin.net Thu Oct 15 11:27:44 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 15 Oct 2009 08:27:44 -0700 Subject: [sup-talk] curses exception In-Reply-To: References: <1255292940-sup-5558@masanjin.net> <1255611057-sup-1320@masanjin.net> Message-ID: <1255620005-sup-7616@masanjin.net> Reformatted excerpts from Dan Falcone's message of 2009-10-15: > Hmm... good question. I regularly use emacs with colors enabled, but > I'm not sure if that uses curses. I tried typespeed and that seemed > to work. According to its man page, it uses curses. Hm. What version of the ncurses gem do you have? (gem list --local should tell you.) What does this program print? require 'rubygems' require 'ncurses' x = begin Ncurses::initscr(); Ncurses::has_colors?() ensure Ncurses::endwin(); end puts x If it prints true, then, if you look in the contents of the gem (wherever that is on your system), there should be an examples/ directory. If you run examples/tlock.rb or examples/rain.rb, (probably with ruby -rubygems), do you see color? -- William From wmorgan-sup@masanjin.net Thu Oct 15 11:29:29 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 15 Oct 2009 08:29:29 -0700 Subject: [sup-talk] About faking message IDs In-Reply-To: <1255615018-sup-5653@midna.zekjur.net> References: <1255603625-sup-2558@midna.zekjur.net> <1255614431-sup-5910@masanjin.net> <1255615018-sup-5653@midna.zekjur.net> Message-ID: <1255620476-sup-8113@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-10-15: > No, in my case it did not. The reason for that is calling "deliver" > directly, that is without talking SMTP to a mailserver. Thus, no > headers are getting added. Surely this is a corner case, but I think > it will cause headache for system administrators running into this > one, if they notice it all (overwriting messages is quite dangerous). Ok. I think it's fine to generate the message id via another mechanism, e.g. the way we do it in edit-message-mode ("<#{Time.now.to_i}-sup-#{rand 10000}@#{hostname}"). -- William From wmorgan-sup@masanjin.net Thu Oct 15 11:32:54 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 15 Oct 2009 08:32:54 -0700 Subject: [sup-talk] before-edit hook and accessing the original sender In-Reply-To: <1255614656-sup-7039@midna.zekjur.net> References: <1255614656-sup-7039@midna.zekjur.net> Message-ID: <1255620578-sup-9650@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-10-15: > So, the question is, can I somehow access the message to which I am > replying to when in the before-edit hook called when replying to a > message. Not currently. We could wire that through without too much effort, I think. -- William From cworth@cworth.org Thu Oct 15 13:23:40 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 15 Oct 2009 10:23:40 -0700 Subject: [sup-talk] Indexing messages without ruby Message-ID: <1255623468-sup-2284@yoom.home.cworth.org> I've gone forward with an experiment I had mentioned I might try: trying to create a faster sup-sync by using C rather than ruby. My approach was to use Xapian to create a sup-compatible index, and to use libgmime for the mail parsing. That meant that I only had to write a tiny bit of code to glue gmime together with xapian. The code is an unholy mess of C and C++, (so there are as many as three different string types, sometimes all in one function!), but it seems to be working at least. I wrote a little xapian-dump program to make a textual dump of a database, (all data, terms, and values for each document), and I verified that my program, notmuch, could create identical[*] terms and values when indexing about 150 recent messages from the sup-talk mailing list. I've also verified that notmuch can index my own collection of nearly 600,000 email messages without any problems. The big difference in notmuch that makes the resulting index incompatible with sup is that it doesn't generate a serialized ruby data structure for the document data like sup currently expects. Instead it just shoves the mail message's filename into the data field. So if anyone wanted to use notmuch with sup, this would need to be resolved on one side or the other.[**] As for performance, things look pretty good, but perhaps not as good as I had hoped. From a test of importing about 400,000 messages from my mail archive, notmuch starts out between 300 - 400 messages/sec. but after about 40,000 messages slows down to about 100 messages/sec. and stabilizes there. I haven't tested sup recently, but from my recollection indexing the same archive on the same computer, sup started out at about 40 messages/sec. and slowed down to about 20 messages/sec. (for as long as I watched it). So this is preliminary, but it looks like notmuch gives a 5-10x performance improvement over sup, (but likely closer to the 5x end of that range unless you've got a very small index---at which point who cares how fast/slow things are?). A quick glance with a profiler shows xapian dominating the notmuch profile at 62% and gmime hardly appearing at all (near 2%). As contrast, ruby dominates the sup-sync profile with xapian down in the 8% range. (So there's the 10x target there.) One other advantage is that with xapian dominating the profile, notmuch stands to benefit from future performance improvements to xapian itself. If that ruby time is dominated by mail parsing, it's possible that much of the advantage of notmuch could be gained by simply switching from rmail to a non-ruby-based parser like gmime. But that's just a guess as I haven't tried to find where the ruby time is being spent. If anyone is interested in playing along at home, my code is available via git with: git clone git://git.cworth.org/git/notmuch Have fun, -Carl [*] Some minor differences exist in the heuristics for reognizing signatures, and sup sometimes splits numbers into multiple terms (such as "1754" indexed as two terms "17" and "54") which I couldn't explain nor replicate. Finally notmuch doesn't attempt to index encrypted messages. [**] Beyond this incompatibility, notmuch is not even close to being a functional replacement for sup-sync. It currently only knows how to shove new documents into the database and doesn't know how to do any updating. Similarly it doesn't have any code to examine mtimes to identify new or changed messages to be updated. It also doesn't look at maildir filename flags to determine labels, nor does it provide any means for the user to request custom labels to be attached to certain messages. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From nicolas.pouillard@gmail.com Thu Oct 15 15:21:29 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Thu, 15 Oct 2009 21:21:29 +0200 Subject: [sup-talk] About faking message IDs In-Reply-To: <1255620476-sup-8113@masanjin.net> References: <1255603625-sup-2558@midna.zekjur.net> <1255614431-sup-5910@masanjin.net> <1255615018-sup-5653@midna.zekjur.net> <1255620476-sup-8113@masanjin.net> Message-ID: <1255634425-sup-8445@peray> Excerpts from William Morgan's message of Thu Oct 15 17:29:29 +0200 2009: > Reformatted excerpts from Michael Stapelberg's message of 2009-10-15: > > No, in my case it did not. The reason for that is calling "deliver" > > directly, that is without talking SMTP to a mailserver. Thus, no > > headers are getting added. Surely this is a corner case, but I think > > it will cause headache for system administrators running into this > > one, if they notice it all (overwriting messages is quite dangerous). > > Ok. I think it's fine to generate the message id via another mechanism, > e.g. the way we do it in edit-message-mode ("<#{Time.now.to_i}-sup-#{rand 10000}@#{hostname}"). This way we loose the reproducibility, but I concede that we can't have both. -- Nicolas Pouillard http://nicolaspouillard.fr From cworth@cworth.org Thu Oct 15 20:14:09 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 15 Oct 2009 17:14:09 -0700 Subject: [sup-talk] About faking message IDs In-Reply-To: <1255620476-sup-8113@masanjin.net> References: <1255603625-sup-2558@midna.zekjur.net> <1255614431-sup-5910@masanjin.net> <1255615018-sup-5653@midna.zekjur.net> <1255620476-sup-8113@masanjin.net> Message-ID: <1255651999-sup-9911@yoom.home.cworth.org> Excerpts from William Morgan's message of Thu Oct 15 08:29:29 -0700 2009: > Ok. I think it's fine to generate the message id via another mechanism, > e.g. the way we do it in edit-message-mode ("<#{Time.now.to_i}-sup-#{rand > 10000}@#{hostname}"). Won't that then make sup insert duplicate documents into the index for any run of sup-sync --all over the relevant sources? -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From michael+sup@stapelberg.de Sat Oct 17 18:32:25 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Sun, 18 Oct 2009 00:32:25 +0200 Subject: [sup-talk] [PATCH] more inline GPG madness In-Reply-To: <1255355627-sup-2988@masanjin.net> References: <1254348163-sup-6170@midna.zekjur.net> <1254417896-sup-2359@midna.zekjur.net> <1255355627-sup-2988@masanjin.net> Message-ID: <1255818685-sup-6010@midna.zekjur.net> Hi, Excerpts from William Morgan's message of Mo Okt 12 15:54:06 +0200 2009: > Reformatted excerpts from Michael Stapelberg's message of 2009-10-01: > > I will instead implement support for "correct" inline GPG. See the attached patch. Please consider merging it :). Best regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Implement-inline-GPG.patch Type: application/octet-stream Size: 5354 bytes Desc: not available URL: From kirr@landau.phys.spbu.ru Sun Oct 18 07:50:00 2009 From: kirr@landau.phys.spbu.ru (Kirill Smelkov) Date: Sun, 18 Oct 2009 15:50:00 +0400 Subject: [sup-talk] BUG: Sup crashes on startup (bisected) Message-ID: <20091018114959.GA11630@roro3.zxlink> Hello up there. I'm using sup master from git, and after recent upgrade, sup began crashing on startup. Here is the backtrace: --- NoMethodError from thread: main undefined method `title' for nil:NilClass /home/kirr/src/tools/mail/sup/lib/sup/buffer.rb:772:in `get_status_and_title' /home/kirr/src/tools/mail/sup/lib/sup/buffer.rb:305:in `draw_screen' /home/kirr/src/tools/mail/sup/lib/sup/buffer.rb:726:in `flash' /home/kirr/src/tools/mail/sup/lib/sup/util.rb:520:in `send' /home/kirr/src/tools/mail/sup/lib/sup/util.rb:520:in `method_missing' /home/kirr/src/tools/mail/sup/lib/sup/colormap.rb:203:in `populate_colormap' /home/kirr/src/tools/mail/sup/bin/sup:169 Just to give you some help (no ruby knowledge here at the moment, sorry): Does not crash: 95eaf6 Crashes at startup: 2dfd37 Bisected to: 723e22 (rewrite logging to have multiple levels: debug, info, etc) Thanks beforehand, Kirill From garoth@gmail.com Sun Oct 18 11:05:57 2009 From: garoth@gmail.com (Andrei Thorp) Date: Sun, 18 Oct 2009 11:05:57 -0400 Subject: [sup-talk] Arch Linux Sup Package (Ruby 1.9.1 + Sup 0.9) Message-ID: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com> Hello. Remember me? ;) Anyway, I've rolled the 0.9 package for Arch Linux in the AUR (community repos). It works, but: - Ruby 1.9.1 has pretty screwed up dependencies for Sup. Ncurses and ferret in particular were broken (at least in Arch.) - The package is a big ol' pile of hacks. - Ferret index is disabled (sorry for removing it early, but Ruby 1.9.1 is the reality for us in Arch.) - I've applyed Lloyd's patch for fixing the UTF-8 check. - There seem to be a few small bugs. Anyway, I'd appreciate some suggestions. The package is viewable here: http://aur.archlinux.org/packages.php?ID=26439 Some of the sketchier things: - I've set Xapian to the default by wrapping all of Sup's binaries with the SUP_INDEX variable in a script. - q no longer works properly. It prompts you with the regular yes/no option as to whether you really want to quit. Neither y nor n seem to have any effect; it is still possible to quit with Q. - Will that patch get applied? It seems reasonable on a surface level. Anyway, as some of you can probably tell, I don't have Sup set up at the moment. I'm working on it. Regardless, managing mail is a nightmare just now! Once I do manage to get it set up, I'll continue testing. I'm not sure, but I'm getting the impression that rather little testing has been done with the new Ruby as it's not quite mainstream yet. -Andrei "Garoth" Thorp From wagnerdm@seas.upenn.edu Sun Oct 18 21:22:12 2009 From: wagnerdm@seas.upenn.edu (wagnerdm at seas.upenn.edu) Date: Sun, 18 Oct 2009 21:22:12 -0400 Subject: [sup-talk] Arch Linux Sup Package (Ruby 1.9.1 + Sup 0.9) In-Reply-To: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com> References: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com> Message-ID: <20091018212212.18607cbsd1pxbds0@webmail.seas.upenn.edu> Quoting Andrei Thorp : > - Ferret index is disabled (sorry for removing it early, but Ruby > 1.9.1 is the reality for us in Arch.) As long as your comfortable with AUR, there are a ruby1.8 and rubygems1.8 packages available. ~d From lists@onerussian.com Mon Oct 19 13:01:19 2009 From: lists@onerussian.com (Yaroslav Halchenko) Date: Mon, 19 Oct 2009 13:01:19 -0400 Subject: [sup-talk] as asked -- little bug report Message-ID: <20091019170119.GM17964@onerussian.com> Sup, thanks for sup! I have been with (mutt+mairix)-in-screen guy for a while, now I am considering sup -- it seems quite nice, although it took days to import my inbox (26k messages) without yet touching any lists in the other folders (where I am going to assign some tags on import whenever I get more familiar with sup). One of the side-effects was: since I was not "processing" fetched emails while they were fetched by sup, inbox listing was growing and growing until UI became barely responsive and I guess good chunk of CPU time was taken to handle just UI. So, it might be desirable to have automatic way to 'hide' older messages in the listing whenever more and more new ones come in? FWIW some of the issues I hit: 1. At first I was running released version shipped with Debian sid (0.8.1-1), and while I was watching a thread and decided to archive and jump to next I pressed sequence ",a" and then sup crashed entirely with: --- NoMethodError from thread: main undefined method `mark_dirty' for nil:NilClass /usr/lib/ruby/1.8/sup/modes/line-cursor-mode.rb:55:in `set_cursor_pos' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:148:in `launch_another_thread' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:131:in `launch_next_thread_after' /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:473:in `dispatch' /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:431:in `archive_and_then' /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:418:in `archive_and_next' /usr/lib/ruby/1.8/sup/mode.rb:50:in `send' /usr/lib/ruby/1.8/sup/mode.rb:50:in `handle_input' /usr/lib/ruby/1.8/sup/buffer.rb:249:in `handle_input' /usr/bin/sup-mail:236 2. further I was hit with another one (see below) for which I think I found a fix 1dbe8fe8b2a57803d697739b4a585e72b1f91885 which seems relevant http://gitorious.org/sup/ehabkost-hacks/commit/1dbe8fe8b2a57803d697739b4a585e72b1f91885 but it never was absorbed in mainline Here is actual traceback --- NoMethodError from thread: poll after loading inbox undefined method `content_width' for nil:NilClass /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:866:in `from_width' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:792:in `text_for_thread_at' /usr/lib/ruby/1.8/sup/hook.rb:134:in `each_with_index' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:791:in `each' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:791:in `each_with_index' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:791:in `text_for_thread_at' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:752:in `regen_text' /usr/lib/ruby/1.8/sup/util.rb:354:in `map_with_index' /usr/lib/ruby/1.8/sup/hook.rb:134:in `each_with_index' /usr/lib/ruby/1.8/sup/util.rb:354:in `each' /usr/lib/ruby/1.8/sup/util.rb:354:in `each_with_index' /usr/lib/ruby/1.8/sup/util.rb:354:in `map_with_index' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:752:in `regen_text' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:228:in `update' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:696:in `add_or_unhide' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:186:in `handle_added_update' /usr/lib/ruby/1.8/sup/update.rb:27:in `send' /usr/lib/ruby/1.8/sup/update.rb:27:in `relay' /usr/lib/ruby/1.8/sup/update.rb:27:in `each' /usr/lib/ruby/1.8/sup/update.rb:27:in `relay' /usr/lib/ruby/1.8/sup/util.rb:513:in `send' /usr/lib/ruby/1.8/sup/util.rb:513:in `method_missing' /usr/lib/ruby/1.8/sup/poll.rb:162:in `add_messages_from' /usr/lib/ruby/1.8/sup/maildir.rb:130:in `each' /usr/lib/ruby/1.8/sup/maildir.rb:127:in `upto' /usr/lib/ruby/1.8/sup/maildir.rb:127:in `each' /usr/lib/ruby/1.8/sup/util.rb:552:in `send' /usr/lib/ruby/1.8/sup/util.rb:552:in `__pass' /usr/lib/ruby/1.8/sup/util.rb:539:in `method_missing' /usr/lib/ruby/1.8/sup/poll.rb:141:in `add_messages_from' /usr/lib/ruby/1.8/sup/poll.rb:98:in `do_poll' /usr/lib/ruby/1.8/sup/poll.rb:86:in `each' /usr/lib/ruby/1.8/sup/poll.rb:86:in `do_poll' /usr/lib/ruby/1.8/sup/poll.rb:85:in `synchronize' /usr/lib/ruby/1.8/sup/poll.rb:85:in `do_poll' /usr/lib/ruby/1.8/sup/util.rb:513:in `send' /usr/lib/ruby/1.8/sup/util.rb:513:in `method_missing' /usr/lib/ruby/1.8/sup/modes/poll-mode.rb:17:in `poll' /usr/lib/ruby/1.8/sup/poll.rb:53:in `poll' /usr/lib/ruby/1.8/sup/util.rb:513:in `send' /usr/lib/ruby/1.8/sup/util.rb:513:in `method_missing' /usr/bin/sup-mail:204 3. btw -- I wonder why git repository has no actual tags but just "like converted from svn" off-branches for each release? is that a feature or a bug (like forgotten --tags upon push ;)) 4. in general -- should I follow the crash message and complain here or just report bugs within Debian using reportbug? 5. Since for me released sup had too many corner stones to run reliably I've decided to run from git. Looking at the git history, it looked like I should stick to the 'next' branch. Is that correct? 6. In code from next branch (09e6a71e232d2d3352fe45b13789c3441e3ac937) which I run with "ruby -I lib -w bin/sup" (sorry if there is a better way I didn't find, this is my first ever experience with Ruby-based project), I hit some new issues: * periodically some warnings are dumped to stderr which obscures current UI rendering... ie warnings like /usr/lib/ruby/1.8/time.rb:180: warning: 2 digits year is used imho they should go to the same log, shouldn't they? * some "elderly" crash where I don't remember the context which caused it unknown drawable object: nil in # for line 3 ./lib/sup/modes/scroll-mode.rb:200:in `draw_line' ./lib/sup/modes/line-cursor-mode.rb:52:in `draw_line' ./lib/sup/modes/line-cursor-mode.rb:120:in `cursor_up' ./lib/sup/mode.rb:51:in `send' ./lib/sup/mode.rb:51:in `handle_input' ./lib/sup/buffer.rb:267:in `handle_input' bin/sup:245 * Now that I've fetched big bulk of emails into inbox... I wonder if there is a logical way to archive all threads BUT not starred ones? thanks in advance for any reply ;) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From yoh@dartmouth.edu Mon Oct 19 13:07:44 2009 From: yoh@dartmouth.edu (Yaroslav Halchenko) Date: Mon, 19 Oct 2009 13:07:44 -0400 Subject: [sup-talk] little wishlist: don't confuse 'mark as spam' and 'search for mails from sender' on the same shortcut Message-ID: <20091019170744.GE13747@onerussian.com> After I've done it about 10 times I figured it out what is going wrong with my motor-reflexes-getting-used-to-sup-shortcuts: in the index-mode: S : Mark/unmark thread as spam in the thread-view-mode: S : Search for messages from particular people .s : Mark this thread as spam and kill buffer So, I've got used to use S to check for other emails from this sender so I could tag/archive them appropriately while going through inbox, but it is working only in thread mode... nevertheless I keep hitting S in index box since I see no big reason why it shouldn't work in index mode ;) would it be possible to unify somehow? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From lists@onerussian.com Mon Oct 19 13:39:01 2009 From: lists@onerussian.com (Yaroslav Halchenko) Date: Mon, 19 Oct 2009 13:39:01 -0400 Subject: [sup-talk] little wishlist: don't confuse 'mark as spam' and 'search for mails from sender' on the same shortcut Message-ID: <20091019173901.GF13747@onerussian.com> After I've done it about 10 times I figured it out what is going wrong with my motor-reflexes-getting-used-to-sup-shortcuts: in the index-mode: S : Mark/unmark thread as spam in the thread-view-mode: S : Search for messages from particular people .s : Mark this thread as spam and kill buffer So, I've got used to use S to check for other emails from this sender so I could tag/archive them appropriately while going through inbox, but it is working only in thread mode... nevertheless I keep hitting S in index box since I see no big reason why it shouldn't work in index mode ;) would it be possible to unify somehow? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From helgedt@tihlde.org Mon Oct 19 10:07:26 2009 From: helgedt@tihlde.org (Helge Titlestad) Date: Mon, 19 Oct 2009 16:07:26 +0200 Subject: [sup-talk] [PATCH] detect and set charset on text/* attachments Message-ID: <1255961127-sup-3168@tihlde.org> I got some feedback from non-suppers that my utf-8 text attachments were messed up. When I checked they (the MIME headers) lacked any info on charset, which I believe should be set for text/*. Here's a patch that uses the chardet gem to (try to) detect the appropriate charset and sets it in the Content-Type header. Can't guarantee its robustness - have only tried on a couple of text files and one non-text file. Please tell me if I should use some different way of sending patches... This git flow is a bit new to me. (= -- alge -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Detect-charset-for-text-file-attachments.patch Type: application/octet-stream Size: 1927 bytes Desc: not available URL: From daveadams@gmail.com Mon Oct 19 14:46:41 2009 From: daveadams@gmail.com (David Adams) Date: Mon, 19 Oct 2009 14:46:41 -0400 Subject: [sup-talk] Best practice for customizing keymaps? Message-ID: <87af9a490910191146o6b34b81ev4723521d17924ae4@mail.gmail.com> Hello everyone, I'd like to make some customizations to the default keymaps for a few modes, and I was wondering what was the safest way to do so. On the Hooks wiki page, the entry for startup.rb shows how to add keystrokes, but based on trying that example out, it appears to work only for adding new keystrokes, not overriding existing ones. So after poking around at the code a bit, dropping this code into startup.rb seems to work to entirely replace a keymap with my preferences: class Redwood::Mode @@keymaps[Redwood::ThreadViewMode] = Redwood::Keymap.new do |k| # key mappings omitted end end So my questions are: Is this unsafe in any way (other than that new versions of sup may invalidate the specifics of keymap implementation)? And is there a better way? Thanks! -dave From cworth@cworth.org Tue Oct 20 00:24:21 2009 From: cworth@cworth.org (Carl Worth) Date: Mon, 19 Oct 2009 21:24:21 -0700 Subject: [sup-talk] Indexing messages without ruby In-Reply-To: <1255623468-sup-2284@yoom.home.cworth.org> References: <1255623468-sup-2284@yoom.home.cworth.org> Message-ID: <1256009934-sup-9323@yoom.home.cworth.org> Excerpts from Carl Worth's message of Thu Oct 15 10:23:40 -0700 2009: > As for performance, things look pretty good, but perhaps not as good > as I had hoped. I know William already said he's not all that concerned with the performance of sup-sync since it's not a common operation, but me, I can't stop working on the problem. And I think that's justified, really. For one thing, the giant sup-sync is one of the first things a new user has to do. And I think that having to wait for an operation that's measured in hours before being able to use the program at all can be very off-putting. I think we could do better to give a good first impression. > So this is preliminary, but it looks like notmuch gives a 5-10x > performance improvement over sup, (but likely closer to the 5x end of > that range unless you've got a very small index---at which point who > cares how fast/slow things are?). Those numbers were off. I now believe that my original code gained only a 3x improvement by switching from ruby/rmail to C/GMime for mail parsing. But I've done a little more coding since. Here are the current results: For a benchmark of ~ 45000 messages, rate in messages/sec.: Rate Commit ID Significant change ----- --------- ------------------ 41 sup (with xapian, from next) 120 5fbdbeb33 Switch from ruby to C (with GMime) 538 9bc4253fa Index headers only, not body 1050 371091139 Use custom header parser, not GMime (Before each run the Linux disk cache was cleared with: sync; echo 3 > /proc/sys/vm/drop_caches ) So beyond the original 3x improvement, I gained a further 4x improvement by simply doing less work. I'm now starting off by only indexing message-id and thread-id data. That's obviously "cheating" in terms of comparing performance, but I think it really makes sense to do this. The idea is that by just computing the thread-ids and indexing those for a collection of email, that initial sup-sync could be performed very quickly. Then, later, (as a background thread while sup is running), the full-text indexing could be performed. Finally, I gained a final 2x improvement by not using GMime at all, (which constructs a data structure for the entire message, even if I only want a few header), and instead just rolling a simple parser for email headers. (Did you know you can hide nested parenthesized comments all over the place in email headers? I didn't.) I'm quite happy with the final result that's 25x faster than sup. I can build a cold-cache index from my half-million message archive in less than 10 minutes, (rather than 4 hours). And performance is fairly IO-bound at this point, (in the 10-minute run, less than 7 minutes of CPU are used). Anyway, there are some ideas to consider for sup. If anyone wants to play with my code, it's here: git clone git://notmuch.org/notmuch I won't bore the list with further developments in notmuch, if any, unless it's on-topic, (such as someone trying to make sup work on top of an index built by notmuch). And I'd be delighted to see that kind of thing happen. Happy hacking, -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From rlane@club.cc.cmu.edu Tue Oct 20 01:34:37 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Mon, 19 Oct 2009 22:34:37 -0700 Subject: [sup-talk] [PATCH] xapian: replace DocumentMethods module with plain monkeypatching In-Reply-To: <20091012223449.GB31940@tilus.net> References: <20091012223449.GB31940@tilus.net> Message-ID: <1256016877-5238-1-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/xapian_index.rb | 25 +++++++++++++++++++++++++ 1 files changed, 25 insertions(+), 0 deletions(-) diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index e1cfe65..c373c17 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -560,7 +560,32 @@ EOS raise "Invalid term type #{type}" end end +end end +class Xapian::Document + def entry + Marshal.load data + end + + def entry=(x) + self.data = Marshal.dump x + end + + def index_text text, prefix, weight=1 + term_generator = Xapian::TermGenerator.new + term_generator.stemmer = Xapian::Stem.new(Redwood::XapianIndex::STEM_LANGUAGE) + term_generator.document = self + term_generator.index_text text, weight, prefix + end + + alias old_add_term add_term + def add_term term + if term.length <= Redwood::XapianIndex::MAX_TERM_LENGTH + old_add_term term + else + warn "dropping excessively long term #{term}" + end + end end -- 1.6.4.2 From rlane@club.cc.cmu.edu Tue Oct 20 02:13:58 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Tue, 20 Oct 2009 02:13:58 -0400 Subject: [sup-talk] [PATCH] xapian: replace DocumentMethods module with plain monkeypatching In-Reply-To: <1256016877-5238-1-git-send-email-rlane@club.cc.cmu.edu> References: <20091012223449.GB31940@tilus.net> <1256016877-5238-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1256019034-sup-9298@zyrg.net> Disregard this one. (I thought master had already gotten my update-message-state patch) Excerpts from Rich Lane's message of Tue Oct 20 01:34:37 -0400 2009: > --- > lib/sup/xapian_index.rb | 25 +++++++++++++++++++++++++ > 1 files changed, 25 insertions(+), 0 deletions(-) > > diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb > index e1cfe65..c373c17 100644 > --- a/lib/sup/xapian_index.rb > +++ b/lib/sup/xapian_index.rb > @@ -560,7 +560,32 @@ EOS > raise "Invalid term type #{type}" > end > end > +end > > end > > +class Xapian::Document > + def entry > + Marshal.load data > + end > + > + def entry=(x) > + self.data = Marshal.dump x > + end > + > + def index_text text, prefix, weight=1 > + term_generator = Xapian::TermGenerator.new > + term_generator.stemmer = > Xapian::Stem.new(Redwood::XapianIndex::STEM_LANGUAGE) > + term_generator.document = self > + term_generator.index_text text, weight, prefix > + end > + > + alias old_add_term add_term > + def add_term term > + if term.length <= Redwood::XapianIndex::MAX_TERM_LENGTH > + old_add_term term > + else > + warn "dropping excessively long term #{term}" > + end > + end > end From rlane@club.cc.cmu.edu Tue Oct 20 02:14:07 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Mon, 19 Oct 2009 23:14:07 -0700 Subject: [sup-talk] [PATCH] xapian: replace DocumentMethods module with plain monkeypatching In-Reply-To: <20091012223449.GB31940@tilus.net> References: <20091012223449.GB31940@tilus.net> Message-ID: <1256019247-6046-1-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/xapian_index.rb | 47 ++++++++++++++++++++++------------------------- 1 files changed, 22 insertions(+), 25 deletions(-) diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index ad45b0e..34d67d5 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -565,35 +565,32 @@ EOS raise "Invalid term type #{type}" end end +end - module DocumentMethods - def entry - Marshal.load data - end - - def entry=(x) - self.data = Marshal.dump x - end +end - def index_text text, prefix, weight=1 - term_generator = Xapian::TermGenerator.new - term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE) - term_generator.document = self - term_generator.index_text text, weight, prefix - end +class Xapian::Document + def entry + Marshal.load data + end - def add_term term - if term.length <= MAX_TERM_LENGTH - super term - else - warn "dropping excessively long term #{term}" - end - end + def entry=(x) + self.data = Marshal.dump x end -end -end + def index_text text, prefix, weight=1 + term_generator = Xapian::TermGenerator.new + term_generator.stemmer = Xapian::Stem.new(Redwood::XapianIndex::STEM_LANGUAGE) + term_generator.document = self + term_generator.index_text text, weight, prefix + end -class Xapian::Document - include Redwood::XapianIndex::DocumentMethods + alias old_add_term add_term + def add_term term + if term.length <= Redwood::XapianIndex::MAX_TERM_LENGTH + old_add_term term + else + warn "dropping excessively long term #{term}" + end + end end -- 1.6.4.2 From mailinglist@flasht.de Tue Oct 20 08:33:35 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Tue, 20 Oct 2009 14:33:35 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1254866136-sup-6974@thinkpad-ubuntu> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1254758256-sup-7400@thinkpad-ubuntu> <1254842820-sup-9099@masanjin.net> <1254861112-sup-590@thinkpad-ubuntu> <1254866136-sup-6974@thinkpad-ubuntu> Message-ID: <1256041985-sup-5427@thinkpad-ubuntu> Just wondering, if anyone is still interested in this, since no one has replied yet. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From cworth@cworth.org Tue Oct 20 11:35:57 2009 From: cworth@cworth.org (Carl Worth) Date: Tue, 20 Oct 2009 08:35:57 -0700 Subject: [sup-talk] Indexing messages without ruby In-Reply-To: <1256009934-sup-9323@yoom.home.cworth.org> References: <1255623468-sup-2284@yoom.home.cworth.org> <1256009934-sup-9323@yoom.home.cworth.org> Message-ID: <1256052859-sup-6008@yoom.home.cworth.org> Excerpts from Carl Worth's message of Mon Oct 19 21:24:21 -0700 2009: > git clone git://notmuch.org/notmuch That should be: git clone git://notmuchmail.org/git/notmuch Clearly typing without my braing engaged. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From usul@aruba.it Wed Oct 21 08:29:59 2009 From: usul@aruba.it (Fabio Riga) Date: Wed, 21 Oct 2009 14:29:59 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1256041985-sup-5427@thinkpad-ubuntu> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1254758256-sup-7400@thinkpad-ubuntu> <1254842820-sup-9099@masanjin.net> <1254861112-sup-590@thinkpad-ubuntu> <1254866136-sup-6974@thinkpad-ubuntu> <1256041985-sup-5427@thinkpad-ubuntu> Message-ID: <1256127705-sup-5539@doma> Excerpts from Christopher Bertels's message of mar ott 20 14:33:35 +0200 2009: > Just wondering, if anyone is still interested in this, since no one has replied > yet. Well, I'm really interested, but I'm just a user. I could only make Italian translation, but how? Is it a normal gettext .po file? What I have to do? Cheers, Fabio From guillaume.quintard@gmail.com Wed Oct 21 12:41:00 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Wed, 21 Oct 2009 18:41:00 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1256127705-sup-5539@doma> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1254758256-sup-7400@thinkpad-ubuntu> <1254842820-sup-9099@masanjin.net> <1254861112-sup-590@thinkpad-ubuntu> <1254866136-sup-6974@thinkpad-ubuntu> <1256041985-sup-5427@thinkpad-ubuntu> <1256127705-sup-5539@doma> Message-ID: <1256143200-sup-8858@altis> > Excerpts from Christopher Bertels's message of mar ott 20 14:33:35 +0200 2009: > Well, I'm really interested, but I'm just a user. I could only make > Italian translation, but how? Is it a normal gettext .po file? What I > have to do? Same here, with french translation. Sorry for the late reply. -- Guillaume From mailinglist@flasht.de Wed Oct 21 14:37:34 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Wed, 21 Oct 2009 20:37:34 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1256127705-sup-5539@doma> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1254758256-sup-7400@thinkpad-ubuntu> <1254842820-sup-9099@masanjin.net> <1254861112-sup-590@thinkpad-ubuntu> <1254866136-sup-6974@thinkpad-ubuntu> <1256041985-sup-5427@thinkpad-ubuntu> <1256127705-sup-5539@doma> Message-ID: <1256149858-sup-8291@thinkpad-ubuntu> Excerpts from Fabio Riga's message of Mi Okt 21 14:29:59 +0200 2009: > Well, I'm really interested, but I'm just a user. I could only make > Italian translation, but how? Is it a normal gettext .po file? What I > have to do? Get my sup clone git repository at gitorious: $ git clone git://gitorious.org/~bakkdoor/sup/bakkdoors-clone.git Then, checkout the i18n branch. $ cd bakkdoors-clone $ git checkout i18n Then have a look at the m17n folder. You should find a de.yaml and en.yaml file. They are for german and english translations. You can create your own translation files in there. For example, fr.yaml for french or it.yaml for italian. Have a look at en.yaml to see, what the original texts are (in english) and come up with your own translation. That's basically it. Then, if you have sup set up to run from that branch, you can set within your sup config file (~/.sup/config.yaml) to use any language, e.g.: :language: de for german. Sup will then look into the m17n folder for a file called "de.yaml" I hope that helped. Cheers, Christopher. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From richard@infoarts.info Wed Oct 21 22:36:53 2009 From: richard@infoarts.info (Richard Sandilands) Date: Thu, 22 Oct 2009 13:36:53 +1100 Subject: [sup-talk] Sup crashing upon save changes ($) Message-ID: <1256178926-sup-1780@Richard-Sandilandss-MacBook-Pro.local> I'm tracking next and when I hit $, sup crashes and logs this: Any clues on how to get things ironed out would be appreciated. Exception log: --- Errno::ENOENT from thread: load messages for thread-view-mode No such file or directory - /Users/richard/.sup/drafts/18 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/draft.rb:74:in `initialize' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/draft.rb:74:in `open' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/draft.rb:74:in `load_header' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `send' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/message.rb:235:in `load_from_source!' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:108:in `select' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/hook.rb:121:in `each_with_index' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:81:in `each' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:170:in `each_with_stuff' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:168:in `each_with_stuff' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:170:in `each_with_stuff' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:169:in `each' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:169:in `each_with_stuff' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:78:in `each' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:75:in `each' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:105:in `each_with_index' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:105:in `select' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/buffer.rb:709:in `say' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:104:in `select' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `initialize' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `new' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:101:in `select' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/mode.rb:51:in `send' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/mode.rb:51:in `handle_input' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/buffer.rb:260:in `handle_input' /Users/richard/src/mainline/bin/sup:245 -- Richard Sandilands From mailinglist@flasht.de Thu Oct 22 04:26:42 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Thu, 22 Oct 2009 10:26:42 +0200 Subject: [sup-talk] Completion for search queries Message-ID: <1256199860-sup-4407@thinkpad-ubuntu> Hi, I just came up with an idea (don't know if this has been requested yet). What I'd really like to see is some kind of query-completion when searching in sup. Often, when I want to search for messages, I don't know all the supported query operators (like from:, +label: etc.) It would be super cool if you'd get some kind of completion (or even a list of possible completions?) when hitting tab. Anyone else who would like to have this feature in sup? Cheers, Christopher. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 902 bytes Desc: not available URL: From gregor@hoffleit.de Thu Oct 22 09:10:10 2009 From: gregor@hoffleit.de (Gregor Hoffleit) Date: Thu, 22 Oct 2009 15:10:10 +0200 Subject: [sup-talk] (Orphaned?) bug tracker at rubyforge.org? Message-ID: <1256216959-sup-8012@sam.mediasupervision.de> The Sup Gitorious homepage (http://gitorious.org/sup) mentions a Ditz bugtracker at sup.rubyforge.org, which seems to be orphaned since 2008, though. This is in contrast to the Sup homepage, which says to report bugs to this mailing list, sup-talk. If the bug tracker is not to be acticely used any longer, shouldn't it be removed from the Sup Gitorious page? Regards, Gregor Hoffleit From tero@tilus.net Fri Oct 23 02:00:12 2009 From: tero@tilus.net (Tero Tilus) Date: Fri, 23 Oct 2009 09:00:12 +0300 Subject: [sup-talk] Localized date on mbox From line in sent messages Message-ID: <1256276875-sup-5782@tilus.net> This might be known. I accidentally used 0.8.1 instead of git next once and it screwed up my sent box. After forwarding a mail sup started to blow up (what felt like) after initiall poll. NoMethodError from thread: poll after loading inbox undefined method `[]' for nil:NilClass /home/terotil/src/sup/lib/sup/xapian_index.rb:567:in `mkterm' /home/terotil/src/sup/lib/sup/xapian_index.rb:338:in `find_docid' /home/terotil/src/sup/lib/sup/xapian_index.rb:344:in `find_doc' /home/terotil/src/sup/lib/sup/xapian_index.rb:354:in `get_entry' /home/terotil/src/sup/lib/sup/xapian_index.rb:73:in `build_message' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /home/terotil/src/sup/lib/sup/xapian_index.rb:363:in `synchronize' /home/terotil/src/sup/lib/sup/xapian_index.rb:73:in `build_message' /home/terotil/src/sup/lib/sup/util.rb:520:in `send' /home/terotil/src/sup/lib/sup/util.rb:520:in `method_missing' /home/terotil/src/sup/lib/sup/poll.rb:109:in `do_poll' /home/terotil/src/sup/lib/sup/poll.rb:166:in `each_message_from' /home/terotil/src/sup/lib/sup/source.rb:104:in `each' I went to throw in debugger and see what was inside. /home/terotil/src/sup/lib/sup/poll.rb:109 old_m = Index.build_message m.id (rdb:1) eval m #], @dirty=true, @snippet_contains_encrypted_content=false, @source=#, @mutex=#, @o=#, @mutex=#, @labels=#, @id=nil, @usual=true>>, @encrypted=false, @refs=[], @labels=#, @snippet=nil> Okay, it could not load a message from sent box because it thought the message wasnt there anymore. The missmatch was because of the starting From line had broken date. It was a localized version of what should have been there, with an added bonus of multibyte chars (two nonbreaking spaces after month name, no idea how thats even possible). Fixed it by fixing the mbox. Dunno how the broken header came to be. The file has most certainly been accessed by sup alone. Full broken headers follow >From tero at tilus.net pe loka?? 16 19:06:58 +0300 2009 Subject: Fwd: Neuroscience, Cogmed, and learning disabilities From: Tero Tilus To: joonas.kekkonen Date: Fri, 16 Oct 2009 19:06:58 +0300 Message-Id: <1255709172-sup-7715 at kuovi.tilus.net> User-Agent: Sup/0.8.1 Content-Transfer-Encoding: 8bit Content-Type: multipart/mixed; boundary="=-1255709218-544380-431-3013-1-=" MIME-Version: 1.0 -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From tero@tilus.net Fri Oct 23 02:35:46 2009 From: tero@tilus.net (Tero Tilus) Date: Fri, 23 Oct 2009 09:35:46 +0300 Subject: [sup-talk] (Orphaned?) bug tracker at rubyforge.org? In-Reply-To: <1256216959-sup-8012@sam.mediasupervision.de> References: <1256216959-sup-8012@sam.mediasupervision.de> Message-ID: <1256279637-sup-3085@tilus.net> Gregor Hoffleit, 2009-10-22 16:10: > If the bug tracker is not to be acticely used any longer, shouldn't > it be removed from the Sup Gitorious page? Definitely should if that is the intention. Is it? Why use this list to track bugs in the first place? -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From tero@tilus.net Fri Oct 23 03:00:21 2009 From: tero@tilus.net (Tero Tilus) Date: Fri, 23 Oct 2009 10:00:21 +0300 Subject: [sup-talk] i18n? In-Reply-To: <1254487575-sup-5468@thinkpad-ubuntu> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> Message-ID: <1256280223-sup-736@tilus.net> Excerpts from 's message of pe loka 02 15:52:47 +0300 2009: > Please tell me what you think. Why not default to the english strings as translation keys and fallback to key itself in case of missing translation? This has imo several advantages. You can go grep the source using what you see in sup UI (instead of first greping language yaml). Adding new strings is cumbersome with (mostly unnecessary) key indirection. Code is more readable when messages are inlined. If you change a string a check of translations is forced (there is no translation for the changed version). Most translation workflow tools expect this kind of behavior. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From usul@aruba.it Fri Oct 23 07:23:06 2009 From: usul@aruba.it (Fabio Riga) Date: Fri, 23 Oct 2009 13:23:06 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1256280223-sup-736@tilus.net> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1256280223-sup-736@tilus.net> Message-ID: <1256295847-sup-9437@viajero> Excerpts from Tero Tilus's message of ven ott 23 09:00:21 +0200 2009: > Excerpts from 's message of pe loka 02 15:52:47 +0300 2009: > > Please tell me what you think. > > Why not default to the english strings as translation keys and > fallback to key itself in case of missing translation? This has imo > several advantages. You can go grep the source using what you see in > sup UI (instead of first greping language yaml). Well, I finally read the code and I agree with Tero. I also think that the use of gettext will be simpler for both developer and translator. In this way, every time a developer add a new string he need to write it twice, or another developer has to hack it. Instead with gettext the developer write his string, surrounded with _() or n_() and he's done (tell me, if I'm wrong). Furthermore people used to .po files (like me) will know what to do and are already provided with tools for that purpose (i.e. Vim :-) ). Can anyone explain me where and why a translated string in the UI should be searchable with a regular expression? (Maybe this question is due to the fact that I still don't understand sup internals...) Cheers, Fabio From gregor@hoffleit.de Fri Oct 23 07:48:31 2009 From: gregor@hoffleit.de (Gregor Hoffleit) Date: Fri, 23 Oct 2009 13:48:31 +0200 Subject: [sup-talk] A fix for the joining threads bug with Ferret Message-ID: <1256297205-sup-683@sam.mediasupervision.de> I did a little bit research regarding the problem that joining threads isn't persistent (as described in [1]-[3]). I managed to track down the problem until the following line in FerretIndex#sync_message in lib/sup/ferret_index.rb. d = { ... :refs => (entry[:refs] || (m.refs + m.replytos).uniq.join(" ")) } I have problems to understand what this line is supposed to do. For me, it always evaluates to "entry[:refs]" (even if that's an empty string!), losing the reference in the modified message m, which was added by add_ref. Therefore the manual join is always lost. With my limited Ruby knowledge, my quick and dirty fix was: if entry[:refs]!="" then d[:refs]=entry[:refs] else d[:refs]=(m.refs + m.replytos).uniq.join(" ") end Is this what the above code is about? Btw, the code in xapian_index.rb looks much different. Still, I'd like to see this fixed for Xapian. Regards, Gregor Hoffleit [1] http://sup.rubyforge.org/ditz/issue-4e501973cea5bd1f28739ae4cea98edce8249895.html [2] http://rubyforge.org/pipermail/sup-talk/2009-April/002050.html [3] http://rubyforge.org/pipermail/sup-talk/2009-April/002060.html From tero@tilus.net Fri Oct 23 09:15:50 2009 From: tero@tilus.net (Tero Tilus) Date: Fri, 23 Oct 2009 16:15:50 +0300 Subject: [sup-talk] A fix for the joining threads bug with Ferret In-Reply-To: <1256297205-sup-683@sam.mediasupervision.de> References: <1256297205-sup-683@sam.mediasupervision.de> Message-ID: <1256302994-sup-9955@tilus.net> Excerpts from Gregor Hoffleit's message: > With my limited Ruby knowledge, my quick and dirty fix was: > > if entry[:refs]!="" then > d[:refs]=entry[:refs] > else > d[:refs]=(m.refs + m.replytos).uniq.join(" ") > end > > Is this what the above code is about? I would expect it to be something alike. Rails has Object#empty? which is true (I think) for nil, false, empty list and empty string. I'd go with entry[:refs].to_s != "" to handle nil as "no refs" too. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From pioto@pioto.org Fri Oct 23 17:13:35 2009 From: pioto@pioto.org (Mike Kelly) Date: Fri, 23 Oct 2009 17:13:35 -0400 Subject: [sup-talk] mbox date fail Message-ID: <2aeb4e149305569502f106c7e54ae107@localhost> Hi, I seem to be caught in a bit of a catch-22. I can't reliably use mbox because of shortcomings in its format. And, I can't use maildir because sup-sync-back doesn't support it. More specifically, I seem to come across this much more often that I should. It's caused by someone starting a line of their message with "From". For example: ... X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.0 Status: X-Keywords: Content-Length: 1742 From the ticket he states that 1.2.3.4 is the IP: ... That yields this exception: [Fri Oct 23 17:07:00 -0400 2009] unlocking /usr/home/staff/mike/.sup/lock... /usr/local/lib/ruby/1.8/time.rb:184:in `local': argument out of range (ArgumentError) from /usr/local/lib/ruby/1.8/time.rb:184:in `make_time' from /usr/local/lib/ruby/1.8/time.rb:243:in `parse' from /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/mbox.rb:15:in `is_break_line?' from /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/mbox/loader.rb:165:in `next' from /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/mbox/loader.rb:145:in `synchronize' from /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/mbox/loader.rb:145:in `next' from /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/source.rb:103:in `each' from /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `send' from /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass' from /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing' from /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:139:in `each_message_from' from /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' from /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' from /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:146 from /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:141:in `each' from /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:141 from /usr/home/staff/mike/lib/ruby/gems/1.8/bin/sup-sync:19:in `load' from /usr/home/staff/mike/lib/ruby/gems/1.8/bin/sup-sync:19 Is there much of anything that I can do to mitigate this problem, aside from manually altering every offending message? It seems like the messages' Content-Length header should be used to skip past the body and ignore the offending Froms? Or, at least, if that sort of ArgumentError is thrown, maybe it should be caught and handled better? I'm running current master (2dfd378b616243d03203e49f5ee29636051d3cbf). Thanks. -- Mike Kelly From sgoldman@tower-research.com Mon Oct 26 16:15:04 2009 From: sgoldman@tower-research.com (Steve Goldman) Date: Mon, 26 Oct 2009 16:15:04 -0400 Subject: [sup-talk] Can't search without crashing Message-ID: <1256588053-sup-8922@sgoldmanlinux.tower-research.com> Wow, I guess I haven't tried to search in a while... I can't search for *anything* without it crashing hard. Every time. I'm on master. Anyone?? --- RuntimeError from thread: load threads for thread-index-mode invalid source 4 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:260:in `build_message' /apps/home/sgoldman/lib/ruby/1.8/monitor.rb:242:in `synchronize' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:256:in `build_message' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:163:in `each_id_by_date' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/thread.rb:332:in `call' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/thread.rb:332:in `load_n_threads' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:163:in `each_id_by_date' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:162:in `each' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:162:in `each_id_by_date' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/thread.rb:328:in `load_n_threads' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:77:in `reporting_thread' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:75:in `initialize' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:75:in `new' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:75:in `reporting_thread' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:81:in `initialize' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in `call' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in `initialize' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in `each' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in `initialize' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:19:in `new' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:19:in `initialize' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:54:in `initialize' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/search-results-mode.rb:6:in `initialize' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/search-results-mode.rb:30:in `new' /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/search-results-mode.rb:30:in `spawn_from_query' bin/sup:275 -- Steve Goldman sgoldman at tower-research.com T: 212.219.6014 F: 212.219.6007 Tower Research Capital, LLC 377 Broadway, 11th Fl. New York, NY 10013 From sgoldman@tower-research.com Mon Oct 26 19:30:20 2009 From: sgoldman@tower-research.com (Steve Goldman) Date: Mon, 26 Oct 2009 19:30:20 -0400 Subject: [sup-talk] Can't search without crashing In-Reply-To: <1256588053-sup-8922@sgoldmanlinux.tower-research.com> References: <1256588053-sup-8922@sgoldmanlinux.tower-research.com> Message-ID: <1256599752-sup-9794@sgoldmanlinux.tower-research.com> It's not every time. Here's my theory: my mail sits on a server across a network. When I can access that data *quickly*, sup doesn't crash. When the network (or file system or whatever) takes longer, sup crashes. Can anyone back that up? Thanks. Excerpts from Steve Goldman's message of Mon Oct 26 16:15:04 -0400 2009: > > Wow, I guess I haven't tried to search in a while... I can't search > for *anything* without it crashing hard. Every time. I'm on master. > > Anyone?? > > > --- RuntimeError from thread: load threads for thread-index-mode > invalid source 4 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:260:in > `build_message' > /apps/home/sgoldman/lib/ruby/1.8/monitor.rb:242:in `synchronize' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:256:in > `build_message' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:163:in > `each_id_by_date' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/thread.rb:332:in `call' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/thread.rb:332:in > `load_n_threads' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:163:in > `each_id_by_date' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:162:in `each' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:162:in > `each_id_by_date' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/thread.rb:328:in > `load_n_threads' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:625: > in `__unprotected_load_n_threads' > (eval):12:in `load_n_threads' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:609: > in `load_n_threads_background' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:77:in `reporting_thread' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:75:in `initialize' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:75:in `new' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:75:in `reporting_thread' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:608: > in `load_n_threads_background' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:679: > in `__unprotected_load_threads' > (eval):12:in `load_threads' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:81:i > n `initialize' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in > `call' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in > `initialize' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in > `each' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in > `initialize' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:19:in > `new' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:19:in > `initialize' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:54:i > n `initialize' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/search-results-mode.rb:6: > in `initialize' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/search-results-mode.rb:30 > :in `new' > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/search-results-mode.rb:30 > :in `spawn_from_query' > bin/sup:275 > -- > > Steve Goldman > sgoldman at tower-research.com > > T: 212.219.6014 > F: 212.219.6007 > > Tower Research Capital, LLC > 377 Broadway, 11th Fl. > New York, NY 10013 -- Steve Goldman sgoldman at tower-research.com T: 212.219.6014 F: 212.219.6007 Tower Research Capital, LLC 377 Broadway, 11th Fl. New York, NY 10013 From tero@tilus.net Tue Oct 27 05:58:47 2009 From: tero@tilus.net (Tero Tilus) Date: Tue, 27 Oct 2009 11:58:47 +0200 Subject: [sup-talk] Can't search without crashing In-Reply-To: <1256588053-sup-8922@sgoldmanlinux.tower-research.com> References: <1256588053-sup-8922@sgoldmanlinux.tower-research.com> Message-ID: <1256637386-sup-8828@tilus.net> Steve Goldman, 2009-10-26 22:15: > Wow, I guess I haven't tried to search in a while... I can't search > for *anything* without it crashing hard. Every time. I'm on master. > > Anyone?? > > --- RuntimeError from thread: load threads for thread-index-mode > invalid source 4 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:260:in > `build_message' http://gitorious.org/sup/mainline/blobs/master/lib/sup/ferret_index.rb#line260 Looks like Sup cant find the source for a message (appearing in results?). Have you altered your sources lately? Afaik you might need to rebuild your index. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From kvrkreddy@gmail.com Tue Oct 27 07:34:34 2009 From: kvrkreddy@gmail.com (k.v.ramakrishna reddy) Date: Tue, 27 Oct 2009 17:04:34 +0530 Subject: [sup-talk] Using TLS instead of ssl Message-ID: <2b29d9f30910270434k65550eaqf5187d048b604020@mail.gmail.com> Hi, What are the changes that i need to make so that sup uses TLS instead of ssl when connecting to my source ? Further more how can i delete a source ? thanks very much karri -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgoldman@tower-research.com Tue Oct 27 08:14:50 2009 From: sgoldman@tower-research.com (Steve Goldman) Date: Tue, 27 Oct 2009 08:14:50 -0400 Subject: [sup-talk] Can't search without crashing In-Reply-To: <1256637386-sup-8828@tilus.net> References: <1256588053-sup-8922@sgoldmanlinux.tower-research.com> <1256637386-sup-8828@tilus.net> Message-ID: <1256645659-sup-3884@sgoldmanlinux.tower-research.com> Excerpts from Tero Tilus's message of Tue Oct 27 05:58:47 -0400 2009: > Steve Goldman, 2009-10-26 22:15: > > Wow, I guess I haven't tried to search in a while... I can't search > > for *anything* without it crashing hard. Every time. I'm on master. > > > > Anyone?? > > > > --- RuntimeError from thread: load threads for thread-index-mode > > invalid source 4 > > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:260:in > > `build_message' > > http://gitorious.org/sup/mainline/blobs/master/lib/sup/ferret_index.rb#line260 > > Looks like Sup cant find the source for a message (appearing in > results?). Have you altered your sources lately? Afaik you might > need to rebuild your index. > No, it can find it. But sometimes it takes a long time. Is there some sort of timeout built into the polling process that could cause a crash? -- Steve Goldman sgoldman at tower-research.com T: 212.219.6014 F: 212.219.6007 Tower Research Capital, LLC 377 Broadway, 11th Fl. New York, NY 10013 From jdugan@es.net Wed Oct 28 12:59:20 2009 From: jdugan@es.net (Jon Dugan) Date: Wed, 28 Oct 2009 11:59:20 -0500 Subject: [sup-talk] exception in mainline Message-ID: <1256749083-sup-3681@arrakis.es.net> i now get this when i start sup. i'm running mainline. --- RuntimeError from thread: load threads for thread-index-mode wrong id called on nil ./lib/sup.rb:17:in `id' ./lib/sup/modes/thread-index-mode.rb:225:in `update' ./lib/sup/hook.rb:122:in `sort_by' ./lib/sup/modes/thread-index-mode.rb:225:in `each' ./lib/sup/modes/thread-index-mode.rb:225:in `sort_by' ./lib/sup/modes/thread-index-mode.rb:225:in `update' ./lib/sup/modes/thread-index-mode.rb:223:in `synchronize' ./lib/sup/modes/thread-index-mode.rb:223:in `update' ./lib/sup/modes/thread-index-mode.rb:628:in `__unprotected_load_n_threads' ./lib/sup/thread.rb:334:in `load_n_threads' ./lib/sup/xapian_index.rb:151:in `each_id_by_date' ./lib/sup/xapian_index.rb:144:in `each_id' ./lib/sup/xapian_index.rb:144:in `each' ./lib/sup/xapian_index.rb:144:in `each_id' ./lib/sup/xapian_index.rb:151:in `each_id_by_date' ./lib/sup/thread.rb:328:in `load_n_threads' ./lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' ./lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background' ./lib/sup.rb:77:in `reporting_thread' ./lib/sup.rb:75:in `initialize' ./lib/sup.rb:75:in `new' ./lib/sup.rb:75:in `reporting_thread' ./lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' ./lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' bin/sup:199 -- Jon M. Dugan ESnet Network Engineering Group Lawrence Berkeley National Laboratory From jdugan@es.net Wed Oct 28 13:14:51 2009 From: jdugan@es.net (Jon Dugan) Date: Wed, 28 Oct 2009 12:14:51 -0500 Subject: [sup-talk] [PATCH] minor nits in exception apology message Message-ID: <1256749942-sup-4831@arrakis.es.net> make path to the exception log relative to BASE_DIR fix a typo in email address of list. --- bin/sup | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/bin/sup b/bin/sup index 7641401..a881284 100755 --- a/bin/sup +++ b/bin/sup @@ -360,8 +360,8 @@ unless Redwood::exceptions.empty? ---------------------------------------------------------------- I'm very sorry. It seems that an error occurred in Sup. Please accept my sincere apologies. If you don't mind, please send the -contents of ~/.sup/exception-log.txt and a brief report of the -circumstances to sup-talk at rubyforge dot orgs so that I might +contents of #{BASE_DIR}/.sup/exception-log.txt and a brief report of the +circumstances to sup-talk at rubyforge dot org so that I might address this problem. Thank you! Sincerely, -- 1.6.4.4 -- Jon M. Dugan ESnet Network Engineering Group Lawrence Berkeley National Laboratory From nicolas.pouillard@gmail.com Wed Oct 28 16:05:27 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Wed, 28 Oct 2009 21:05:27 +0100 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1256749942-sup-4831@arrakis.es.net> References: <1256749942-sup-4831@arrakis.es.net> Message-ID: <1256760295-sup-9873@peray> Excerpts from Jon Dugan's message of Wed Oct 28 18:14:51 +0100 2009: > make path to the exception log relative to BASE_DIR > fix a typo in email address of list. > > --- > bin/sup | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/bin/sup b/bin/sup > index 7641401..a881284 100755 > --- a/bin/sup > +++ b/bin/sup > @@ -360,8 +360,8 @@ unless Redwood::exceptions.empty? > ---------------------------------------------------------------- > I'm very sorry. It seems that an error occurred in Sup. Please > accept my sincere apologies. If you don't mind, please send the > -contents of ~/.sup/exception-log.txt and a brief report of the > -circumstances to sup-talk at rubyforge dot orgs so that I might > +contents of #{BASE_DIR}/.sup/exception-log.txt and a brief report of the > +circumstances to sup-talk at rubyforge dot org so that I might I think the *orgs* was on purpose. -- Nicolas Pouillard http://nicolaspouillard.fr From jdugan@es.net Wed Oct 28 16:22:32 2009 From: jdugan@es.net (Jon Dugan) Date: Wed, 28 Oct 2009 15:22:32 -0500 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1256760295-sup-9873@peray> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> Message-ID: <1256760970-sup-8118@arrakis.es.net> Excerpts from Nicolas Pouillard's message of Wed Oct 28 15:05:27 -0500 2009: > Excerpts from Jon Dugan's message of Wed Oct 28 18:14:51 +0100 2009: > > make path to the exception log relative to BASE_DIR > > fix a typo in email address of list. > > > > --- > > bin/sup | 4 ++-- > > 1 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/bin/sup b/bin/sup > > index 7641401..a881284 100755 > > --- a/bin/sup > > +++ b/bin/sup > > @@ -360,8 +360,8 @@ unless Redwood::exceptions.empty? > > ---------------------------------------------------------------- > > I'm very sorry. It seems that an error occurred in Sup. Please > > accept my sincere apologies. If you don't mind, please send the > > -contents of ~/.sup/exception-log.txt and a brief report of the > > -circumstances to sup-talk at rubyforge dot orgs so that I might > > +contents of #{BASE_DIR}/.sup/exception-log.txt and a brief report of the > > +circumstances to sup-talk at rubyforge dot org so that I might > > I think the *orgs* was on purpose. I was wondering about that. It seemed odd to me to be obfuscating the email address at all in this context since this is an error message not a webpage. In my mind the usability enhancement of being able to cut and paste the email address would increase the likelyhood of people reporting errors. Obviously not a big deal either way... Jon -- Jon M. Dugan ESnet Network Engineering Group Lawrence Berkeley National Laboratory From Jonah@GoodCoffee.ca Wed Oct 28 18:06:43 2009 From: Jonah@GoodCoffee.ca (Jonah) Date: Wed, 28 Oct 2009 18:06:43 -0400 Subject: [sup-talk] [PATCH] change opening attachements on darwin to use open instead of run-mailcap Message-ID: <4AE8C073.404@GoodCoffee.ca> Hey everyone, I've been working on getting sup to work in MacOSX (darwin). MacOSX has a special command (open) for opening files - there is no support for mailcap. This patch uses case to run the appropriate command depending on the architecture used. I still haven't gotten sup to send mail yet,.. so more patches for MacOSX will probably be forthcoming. :) I'm loving sup so far, keep up the great work! Cheers, Jonah --- lib/sup/message-chunks.rb | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb index edc40c4..581b707 100644 --- a/lib/sup/message-chunks.rb +++ b/lib/sup/message-chunks.rb @@ -132,7 +132,12 @@ EOS def initial_state; :open end def viewable?; @lines.nil? end def view_default! path - cmd = "/usr/bin/run-mailcap --action=view '#{@content_type}:#{path}'" + case Config::CONFIG['arch'] + when /darwin/ + cmd = "open '#{path}'" + else + cmd = "/usr/bin/run-mailcap --action=view '#{@content_type}:#{path}'" + end debug "running: #{cmd.inspect}" BufferManager.shell_out(cmd) $? == 0 -- 1.6.3.3 From garoth@gmail.com Wed Oct 28 20:32:00 2009 From: garoth@gmail.com (Andrei Thorp) Date: Wed, 28 Oct 2009 20:32:00 -0400 Subject: [sup-talk] Arch Linux Sup Package (Ruby 1.9.1 + Sup 0.9) In-Reply-To: <20091029000759.GA5109@gmail.com> References: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com> <20091029000759.GA5109@gmail.com> Message-ID: <80055d7c0910281732v60908755kd5b43464aaac30ce@mail.gmail.com> On Wed, Oct 28, 2009 at 8:07 PM, Sean Escriva wrote: > > On Sun, Oct 18, 2009 at 11:05:57AM -0400, Andrei Thorp wrote: >> Hello. Remember me? ;) >> >> Anyway, I've rolled the 0.9 package for Arch Linux in the >> AUR (community repos). It works, but: >> ?- Ruby 1.9.1 has pretty screwed up dependencies for Sup. Ncurses and ferret in >> ? ?particular were broken (at least in Arch.) >> ?- The package is a big ol' pile of hacks. >> ?- Ferret index is disabled (sorry for removing it early, but Ruby 1.9.1 is the >> ? ?reality for us in Arch.) >> ?- I've applyed Lloyd's patch for fixing the UTF-8 check. >> ?- There seem to be a few small bugs. >> >> Anyway, I'd appreciate some suggestions. The package is viewable here: >> http://aur.archlinux.org/packages.php?ID=26439 > > I gave the sup package a try today. I had previously put all the new > ruby stuff on Hold. It didn't work for me. I post my output on the > aur page. > > Any tips are appreciated, thanks. Trace on AUR: > tried this today and everything installs fine, trying to run sup gives: > > /usr/lib/ruby/gems/1.9.1/gems/lockfile-1.4.3/lib/lockfile.rb:475:in `load_lock_id': undefined method `each' for # (NoMethodError) > from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:26:in `lockinfo_on_disk' > from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/index.rb:40:in `rescue in lock' > from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/index.rb:37:in `lock' > from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing' > from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/interactive-lock.rb:26:in `lock_interactively' > from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:115:in `' > from /usr/bin/supbin/sup-sync:19:in `load' > from /usr/bin/supbin/sup-sync:19:in `
' Delete comment Hmm... works for me. Could you please give me a few more details: - 64 bit or 32 bit? Any other system specs worth noting? - This happens immediately on run or do you need to perform some action? - Please try running sup while in ~. I've found some bugs occasionally if you're in some strange directory. - While building my package, does it say that it is rolling lockfile for you? It seems your lockfile's a bit screwy rather than Sup. If lockfile already exists on the system, my package might not roll a new one. - That said, try removing the lockfile gem and installing a fresh one using the "gem" utility. The error up there doesn't really make sense. Each not defined on buffer strings? Seems unlikely. You could also try running the commands in my build step manually and install yourself the sup dependencies that I list + the dependencies in the Arch repos and see if sup does something then. This would be more serious debugging. Anyway, for now, I can't reproduce the error on my system, and I'm fully up to date with the Arch repos. I don't really know what to say. Did you remember to switch your indexes to Xapian and so on? Good luck, -Andrei Thorp From nicolas.pouillard@gmail.com Thu Oct 29 06:29:31 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Thu, 29 Oct 2009 11:29:31 +0100 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1256760970-sup-8118@arrakis.es.net> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> Message-ID: <1256812101-sup-6316@peray> Excerpts from Jon Dugan's message of Wed Oct 28 21:22:32 +0100 2009: > Excerpts from Nicolas Pouillard's message of Wed Oct 28 15:05:27 -0500 2009: > > Excerpts from Jon Dugan's message of Wed Oct 28 18:14:51 +0100 2009: > > > make path to the exception log relative to BASE_DIR > > > fix a typo in email address of list. > > > > > > --- > > > bin/sup | 4 ++-- > > > 1 files changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/bin/sup b/bin/sup > > > index 7641401..a881284 100755 > > > --- a/bin/sup > > > +++ b/bin/sup > > > @@ -360,8 +360,8 @@ unless Redwood::exceptions.empty? > > > ---------------------------------------------------------------- > > > I'm very sorry. It seems that an error occurred in Sup. Please > > > accept my sincere apologies. If you don't mind, please send the > > > -contents of ~/.sup/exception-log.txt and a brief report of the > > > -circumstances to sup-talk at rubyforge dot orgs so that I might > > > +contents of #{BASE_DIR}/.sup/exception-log.txt and a brief report of the > > > +circumstances to sup-talk at rubyforge dot org so that I might > > > > I think the *orgs* was on purpose. > > I was wondering about that. It seemed odd to me to be obfuscating the email > address at all in this context since this is an error message not a webpage. Although the error message appears in the source code, and in all emails were it has been copied and paste. -- Nicolas Pouillard http://nicolaspouillard.fr From mariano.mara@gmail.com Thu Oct 29 19:02:46 2009 From: mariano.mara@gmail.com (Mariano Mara) Date: Thu, 29 Oct 2009 20:02:46 -0300 Subject: [sup-talk] RMail chokes on broken headers In-Reply-To: <1255612194-sup-3880@masanjin.net> References: <20091012232215.GD31940@tilus.net> <1255612194-sup-3880@masanjin.net> Message-ID: 2009/10/15 William Morgan > Reformatted excerpts from Tero Tilus's message of 2009-10-12: > > RMail looks abandoned. Development is pretty much stalled. No > > functional changes since 2004-04-27. None of the reported bugs have > > been fixed. Might it be worth to think about switching to another > > mail lib? TMail author's http://github.com/mikel/mail/ looks > > promising. > > Yeah, this is certainly an option. But it seems like a lot of work. And > every day our set of rmail workarounds grows more robust. :) > > Not to say I wouldn't accept a patch that magically did this all for me, > of course. > -- Hi there, I'm facing the same error as reported by Tero. I applied the modifications he sent, however it's failing in another place and my total ignorance of Ruby prevents me from fixing it. Would anyone be so kind to suggest a workaround? Below is the complete exception recorded. TIA, Mariano --- NoMethodError from thread: poll after loading inbox undefined method `downcase' for nil:NilClass /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:502:in `message_to_chunks' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:435:in `message_to_chunks' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:435:in `map' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:435:in `message_to_chunks' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:239:in `load_from_source!' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:335:in `build_from_source' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:145:in `each_message_from' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/maildir.rb:160:in `each' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/maildir.rb:157:in `upto' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/maildir.rb:157:in `each' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:560:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:560:in `__pass' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:547:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:139:in `each_message_from' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:93:in `do_poll' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:81:in `each' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:81:in `do_poll' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:80:in `synchronize' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:80:in `do_poll' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/poll-mode.rb:15:in `poll' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:48:in `poll' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.9/bin/sup:196 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:77:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `initialize' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `new' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.9/bin/sup:196 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:669:in `call' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:669:in `__unprotected_load_threads' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:610:in `call' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:610:in `load_n_threads_background' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:77:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `initialize' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `new' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' /usr/lib/ruby/gems/1.8/gems/sup-0.9/bin/sup:196 /usr/bin/sup:19:in `load' /usr/bin/sup:19 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stevenrwalter@gmail.com Fri Oct 30 13:17:32 2009 From: stevenrwalter@gmail.com (Steven Walter) Date: Fri, 30 Oct 2009 13:17:32 -0400 Subject: [sup-talk] Recovering a busted ferret db? Message-ID: I think my ferret db is corrupted. Whenever I do a tag search for a specific tag, sup loads 2 messages and then hangs. Actually, it's using 100% CPU, but I have to kill -9 it; ctrl-c doesn't work. Is there any hope of fixing this without losing all my tag information? -- -Steven Walter From wmorgan-sup@masanjin.net Fri Oct 30 17:48:32 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 30 Oct 2009 14:48:32 -0700 Subject: [sup-talk] Recovering a busted ferret db? In-Reply-To: References: Message-ID: <1256939095-sup-4201@masanjin.net> Reformatted excerpts from Steven Walter's message of 2009-10-30: > I think my ferret db is corrupted. Whenever I do a tag search for a > specific tag, sup loads 2 messages and then hangs. Actually, it's > using 100% CPU, but I have to kill -9 it; ctrl-c doesn't work. Is > there any hope of fixing this without losing all my tag information? You can certainly move to the Xapian index without losing all of your tags. Sup-dump will output everything precious from your index. Is it possible you have a very large thread with that label? E.g. thousands of messages, all replying to each other, from some script? -- William From wmorgan-sup@masanjin.net Fri Oct 30 17:50:41 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 30 Oct 2009 14:50:41 -0700 Subject: [sup-talk] RMail chokes on broken headers In-Reply-To: References: <20091012232215.GD31940@tilus.net> <1255612194-sup-3880@masanjin.net> Message-ID: <1256939410-sup-8456@masanjin.net> Reformatted excerpts from Mariano Mara's message of 2009-10-29: > Hi there, I'm facing the same error as reported by Tero. I applied the > modifications he sent, however it's failing in another place and my > total ignorance of Ruby prevents me from fixing it. Would anyone be so > kind to suggest a workaround? This is fixed in git master. Maybe I should release an 0.9.1. -- William From wmorgan-sup@masanjin.net Fri Oct 30 17:53:08 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 30 Oct 2009 14:53:08 -0700 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1256760970-sup-8118@arrakis.es.net> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> Message-ID: <1256939476-sup-2864@masanjin.net> Reformatted excerpts from Jon Dugan's message of 2009-10-28: > I was wondering about that. It seemed odd to me to be obfuscating the email > address at all in this context since this is an error message not a webpage. Yep, it was intentional. As Nicolas points out, the error message is often copied-and-pasted, and the source code is indexable via Gitorious. The change for BASE_DIR is great though. If you remove the obfuscation I will accept the patch. > In my mind the usability enhancement of being able to cut and paste > the email address would increase the likelyhood of people reporting > errors. I hate people reporting errors. I should actually change that whole thing to suggest they to send a bugfix patch. -- William From wmorgan-sup@masanjin.net Fri Oct 30 17:56:53 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 30 Oct 2009 14:56:53 -0700 Subject: [sup-talk] Arch Linux Sup Package (Ruby 1.9.1 + Sup 0.9) In-Reply-To: <80055d7c0910281732v60908755kd5b43464aaac30ce@mail.gmail.com> References: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com> <20091029000759.GA5109@gmail.com> <80055d7c0910281732v60908755kd5b43464aaac30ce@mail.gmail.com> Message-ID: <1256939734-sup-4021@masanjin.net> Reformatted excerpts from Andrei Thorp's message of 2009-10-28: > On Wed, Oct 28, 2009 at 8:07 PM, Sean Escriva wrote: > > tried this today and everything installs fine, trying to run sup gives: > > > > /usr/lib/ruby/gems/1.9.1/gems/lockfile-1.4.3/lib/lockfile.rb:475:in `load_lock_id': undefined method `each' for # (NoMethodError) > > from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:26:in `lockinfo_on_disk' [snip] > Hmm... works for me. Could you please give me a few more details: [snip] > The error up there doesn't really make sense. Each not defined on > buffer strings? It makes sense to me. There's no String#each in Ruby 1.9, so this is probably a (trivially fixable) bug in the lockfile gem for 1.9. -- William From wmorgan-sup@masanjin.net Fri Oct 30 18:02:00 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 30 Oct 2009 15:02:00 -0700 Subject: [sup-talk] Arch Linux Sup Package (Ruby 1.9.1 + Sup 0.9) In-Reply-To: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com> References: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com> Message-ID: <1256939901-sup-1662@masanjin.net> Reformatted excerpts from Andrei Thorp's message of 2009-10-18: > Anyway, I've rolled the 0.9 package for Arch Linux in the > AUR (community repos). Very cool, thank you! I am very interested in moving to 1.9 so I'm doubly happy someone else is doing the work. :) > - I've set Xapian to the default by wrapping all of Sup's binaries > with the SUP_INDEX variable in a script. Seems fine. Eventually this will be the default. > - q no longer works properly. It prompts you with the regular yes/no > option as to whether you really want to quit. Neither y nor n seem to > have any effect; it is still possible to quit with Q. Now that's weird. Do multi-commands (like ,n in thread-view-mode) work? If not, we can insert some debugging code in BufferManager#ask_getch to see what's going on? > - Will that patch get applied? It seems reasonable on a surface level. Yes. Sorry, I'm very behind on patches. > Once I do manage to get it set up, I'll continue testing. I'm not sure, > but I'm getting the impression that rather little testing has been done > with the new Ruby as it's not quite mainstream yet. Which makes it perfect a complement to Sup. :) -- William From wmorgan-sup@masanjin.net Fri Oct 30 18:07:19 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 30 Oct 2009 15:07:19 -0700 Subject: [sup-talk] [PATCH] change opening attachements on darwin to use open instead of run-mailcap In-Reply-To: <4AE8C073.404@GoodCoffee.ca> References: <4AE8C073.404@GoodCoffee.ca> Message-ID: <1256940409-sup-4411@masanjin.net> Reformatted excerpts from Jonah's message of 2009-10-28: > I've been working on getting sup to work in MacOSX (darwin). MacOSX has a > special command (open) for opening files - there is no support for mailcap. > This patch uses case to run the appropriate command depending on the > architecture used. Branch no-mailcap-on-darwin, merged into next. Thanks! > I still haven't gotten sup to send mail yet,.. so more patches for > MacOSX will probably be forthcoming. :) Great, glad to have them. -- William From stevenrwalter@gmail.com Fri Oct 30 18:14:32 2009 From: stevenrwalter@gmail.com (Steven Walter) Date: Fri, 30 Oct 2009 18:14:32 -0400 Subject: [sup-talk] Recovering a busted ferret db? In-Reply-To: <1256939095-sup-4201@masanjin.net> References: <1256939095-sup-4201@masanjin.net> Message-ID: On Fri, Oct 30, 2009 at 5:48 PM, William Morgan wrote: > Reformatted excerpts from Steven Walter's message of 2009-10-30: >> I think my ferret db is corrupted. ?Whenever I do a tag search for a >> specific tag, sup loads 2 messages and then hangs. ?Actually, it's >> using 100% CPU, but I have to kill -9 it; ctrl-c doesn't work. ?Is >> there any hope of fixing this without losing all my tag information? > > You can certainly move to the Xapian index without losing all of your > tags. Sup-dump will output everything precious from your index. Looks like sup-dump hangs, too. > Is it possible you have a very large thread with that label? E.g. > thousands of messages, all replying to each other, from some script? Not very likely. I could believe tens, up to a hundred; 200 at the most. I am able to Ctrl-C sup-dump when it hangs. Here's the ruby backtrace: /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:206:in `split': Interrupt from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:206:in `split_on_commas' from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/person.rb:108:in `from_address_list' from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/message.rb:104:in `parse_header' from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:276:in `build_message' from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:256:in `build_message' from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/index.rb:150:in `each_message' from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:319:in `each_id' from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:319:in `map' from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:319:in `each_id' from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/index.rb:149:in `each_message' from /var/lib/gems/1.8/gems/sup-0.9/bin/sup-dump:28 -- -Steven Walter From jdugan@es.net Fri Oct 30 19:13:39 2009 From: jdugan@es.net (Jon Dugan) Date: Fri, 30 Oct 2009 18:13:39 -0500 Subject: [sup-talk] [PATCH] change opening attachements on darwin to use open instead of run-mailcap In-Reply-To: <4AE8C073.404@GoodCoffee.ca> References: <4AE8C073.404@GoodCoffee.ca> Message-ID: <1256944116-sup-2844@arrakis.es.net> Excerpts from Jonah's message of Wed Oct 28 17:06:43 -0500 2009: > I still haven't gotten sup to send mail yet,.. so more patches for MacOSX will > probably be forthcoming. :) I use msmtp via MacPorts to send mail from OS X. The sup wiki has some information on how to use msmtp in the "how mail leaves" section: http://sup.rubyforge.org/wiki/wiki.pl And the MacPorts homepage is at: http://macports.org/ Jon -- Jon M. Dugan ESnet Network Engineering Group Lawrence Berkeley National Laboratory From tero@tilus.net Sat Oct 31 07:28:09 2009 From: tero@tilus.net (Tero Tilus) Date: Sat, 31 Oct 2009 13:28:09 +0200 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1256939476-sup-2864@masanjin.net> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> Message-ID: <1256987483-sup-338@tilus.net> William Morgan, 2009-10-30 23:53: >> the email address would increase the likelyhood of people reporting >> errors. > > I hate people reporting errors. :D > I should actually change that whole thing to suggest they to send a > bugfix patch. Not all the people who are capable of producing good quality bug reports are (practically) capable of producing patches. Good bug reports are usefull. Do you feel burdened by bugreports sent to you or to this list? (I most definitely would be.) If so, could we somehow "unburden" you? How about setting up a loose team which would handle the incoming bug reports (for you), track/sort all of them and fix what they feel like fixing and maybe upon request/occasionally report somewhere the current status (how many minors and majors open). I could be involved in something like that if it is what you and sup community want/need. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From wmorgan-sup@masanjin.net Sat Oct 31 10:03:35 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 31 Oct 2009 07:03:35 -0700 Subject: [sup-talk] slowly catching up Message-ID: <1256997213-sup-2725@masanjin.net> Hi all, Just wanted to let you know that I am slowly catching up with the backlog of patches and bug reports. We just had our first baby so it's been a busy few weeks. If you haven't heard back about something in the next week or so, please ping me about it. In the near future I would like to face reality and change the process so that I am not the one and only bottleneck to development. (Which is entirely a situation I have created myself.) E.g. use a bug tracker (not ditz), delegate some responsibility to people who are interested, etc. I would like to see the development of Sup continue, but not limited by the small amount of time I have for it. Suggestions welcome. (Thanks, Tero, for starting on this already.) -- William From mariano.mara@gmail.com Sat Oct 31 16:18:19 2009 From: mariano.mara@gmail.com (Mariano Mara) Date: Sat, 31 Oct 2009 17:18:19 -0300 Subject: [sup-talk] RMail chokes on broken headers In-Reply-To: <1256939410-sup-8456@masanjin.net> References: <20091012232215.GD31940@tilus.net> <1255612194-sup-3880@masanjin.net> <1256939410-sup-8456@masanjin.net> Message-ID: 2009/10/30 William Morgan > Reformatted excerpts from Mariano Mara's message of 2009-10-29: > > Hi there, I'm facing the same error as reported by Tero. I applied the > > modifications he sent, however it's failing in another place and my > > total ignorance of Ruby prevents me from fixing it. Would anyone be so > > kind to suggest a workaround? > > This is fixed in git master. Maybe I should release an 0.9.1. > -- > William > Thanks a lot! It would be great if you could release 0.9.1 Mariano -------------- next part -------------- An HTML attachment was scrubbed... URL: