From rlane@club.cc.cmu.edu Sat Aug 1 02:28:19 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 01 Aug 2009 02:28:19 -0400 Subject: [sup-talk] xapian question In-Reply-To: <1248807365-sup-4965@masanjin.net> References: <1248716325-sup-7534@masanjin.net> <1248795865-sup-6634@pion.club.cc.cmu.edu> <1248807365-sup-4965@masanjin.net> Message-ID: <1249098509-sup-6664@pion.club.cc.cmu.edu> I tried out using add_term/remove_term for immediate label changes. It's significantly faster than sync_message, but it still makes the interface feel laggy. There's known room for improvement in Xapian's replace_document. However, we'll still have a lot of latency when we start using remote sup-servers, so I don't think it's a good idea to do these index operations synchronously with the UI. We could queue up index writes and execute them in a background thread. We'd want label additions to show up immediately in a search, though. This is easy to do for inbox-mode and label-view-mode, which covers most of my daily usage. If/when we support multiple clients connecting to a sup-server, we'll need a way to notify them that someone else modified a message. We can implement a simple version of this now that notifies search-results-mode after the write completes. If we're getting rid of buffer saving, it'd probably be easiest to use a weak-ref table so we keep at most 1 copy of each message in memory - this would make updating messages across buffers simpler. How is sup-server development going? From mailinglist@flasht.de Sat Aug 1 05:26:25 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Sat, 01 Aug 2009 11:26:25 +0200 Subject: [sup-talk] Smooth Paging In-Reply-To: <1249055039-sup-8105@masanjin.net> References: <1249053249-sup-9884@Longbow> <1249055039-sup-8105@masanjin.net> Message-ID: <1249118728-sup-5483@thinkpad-debian> Excerpts from William Morgan's message of Fr Jul 31 17:44:25 +0200 2009: > Have you tried J and K vs j and k to scroll? Wow, cool. :) Good to know. -- ================================ Christopher Bertels http://www.adztec-independent.de From guillaume.quintard@gmail.com Sat Aug 1 13:44:50 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Sat, 1 Aug 2009 19:44:50 +0200 Subject: [sup-talk] Fwd: xapian merged into next In-Reply-To: <1e5fdab70908010934l30373447r4a405c5ca0e406f9@mail.gmail.com> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> <1248712876-sup-1446@entry> <1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com> <1248713360-sup-5448@entry> <1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com> <1248716073-sup-7443@masanjin.net> <1e5fdab70908010934l30373447r4a405c5ca0e406f9@mail.gmail.com> Message-ID: <1e5fdab70908011044q6743d213o554a7bd039e237c2@mail.gmail.com> I get this when I run "SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore dumpfile" (only had the time to do it today): ./lib/sup/xapian_index.rb:435:in `replace_document': InvalidArgumentError: Term too long (> 245): E"name.surname at enst-bretagne.fr, my_name.my_surname at enst-bretagne.fr, name.surname at enst-bretagne.fr, name.surname at enst-bretagne.fr, name.surname at telecom-bretagne.eu, name.surname at telecom-bretagne.eu, name.surname at telecom-bretagne.eu, name.surname"@telecom-bretagne.eu (ArgumentError) ? ? ? ?from ./lib/sup/xapian_index.rb:435:in `index_message' ? ? ? ?from ./lib/sup/xapian_index.rb:117:in `sync_message' ? ? ? ?from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' ? ? ? ?from ./lib/sup/xapian_index.rb:330:in `synchronize' ? ? ? ?from ./lib/sup/xapian_index.rb:116:in `sync_message' ? ? ? ?from ./lib/sup/util.rb:519:in `send' ? ? ? ?from ./lib/sup/util.rb:519:in `method_missing' ? ? ? ?from ./lib/sup/poll.rb:157:in `add_messages_from' ? ? ? ?from ./lib/sup/source.rb:100:in `each' ? ? ? ?from ./lib/sup/util.rb:558:in `send' ? ? ? ?from ./lib/sup/util.rb:558:in `__pass' ? ? ? ?from ./lib/sup/util.rb:545:in `method_missing' ? ? ? ?from ./lib/sup/poll.rb:141:in `add_messages_from' ? ? ? ?from ./lib/sup/util.rb:519:in `send' ? ? ? ?from ./lib/sup/util.rb:519:in `method_missing' ? ? ? ?from bin/sup-sync:140 ? ? ? ?from bin/sup-sync:135:in `each' ? ? ? ?from bin/sup-sync:135 Cheers! -- Guillaume From rlane@club.cc.cmu.edu Sat Aug 1 14:14:34 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 01 Aug 2009 14:14:34 -0400 Subject: [sup-talk] Fwd: xapian merged into next In-Reply-To: <1e5fdab70908011044q6743d213o554a7bd039e237c2@mail.gmail.com> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> <1248712876-sup-1446@entry> <1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com> <1248713360-sup-5448@entry> <1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com> <1248716073-sup-7443@masanjin.net> <1e5fdab70908010934l30373447r4a405c5ca0e406f9@mail.gmail.com> <1e5fdab70908011044q6743d213o554a7bd039e237c2@mail.gmail.com> Message-ID: <1249149855-sup-2211@pion.club.cc.cmu.edu> Excerpts from Guillaume Quintard's message of Sat Aug 01 13:44:50 -0400 2009: > E"name.surname at enst-bretagne.fr, > my_name.my_surname at enst-bretagne.fr, name.surname at enst-bretagne.fr, > name.surname at enst-bretagne.fr, > name.surname at telecom-bretagne.eu, > name.surname at telecom-bretagne.eu, > name.surname at telecom-bretagne.eu, name.surname"@telecom-bretagne.eu That's a very strange email address :). Could you track down the message causing this and post the headers? It looks like it's getting parsed incorrectly. I think we'd be safe not adding terms for email addresses longer than 244 characters on the assumption that the user isn't going to want to search for them. From guillaume.quintard@gmail.com Sat Aug 1 14:31:55 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Sat, 01 Aug 2009 20:31:55 +0200 Subject: [sup-talk] Fwd: xapian merged into next In-Reply-To: <1249149855-sup-2211@pion.club.cc.cmu.edu> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> <1248712876-sup-1446@entry> <1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com> <1248713360-sup-5448@entry> <1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com> <1248716073-sup-7443@masanjin.net> <1e5fdab70908010934l30373447r4a405c5ca0e406f9@mail.gmail.com> <1e5fdab70908011044q6743d213o554a7bd039e237c2@mail.gmail.com> <1249149855-sup-2211@pion.club.cc.cmu.edu> Message-ID: <1249151189-sup-3864@altis> Excerpts from Rich Lane's message of Sat Aug 01 20:14:34 +0200 2009: > I think we'd be safe not adding terms for email addresses longer than > 244 characters on the assumption that the user isn't going to want to > search for them. http://files.getdropbox.com/u/155904/grepped I did a simple grep, tell me if it's not enough (I'd rather not dive into the humongous mbox file). The mails come from the mailing-list admin tool (sympa), encoding problem it looks, the mangled part is "Propri?taires de liste" (list owners in french) -- Guillaume From vasudeva@linkswarm.com Sat Aug 1 17:58:13 2009 From: vasudeva@linkswarm.com (vasudeva) Date: Sat, 01 Aug 2009 17:58:13 -0400 Subject: [sup-talk] Smooth Paging In-Reply-To: <1249118728-sup-5483@thinkpad-debian> References: <1249053249-sup-9884@Longbow> <1249055039-sup-8105@masanjin.net> <1249118728-sup-5483@thinkpad-debian> Message-ID: <1249163726-sup-5839@lenin> Excerpts from Christopher Bertels's message of Sat Aug 01 05:26:25 -0400 2009: > Excerpts from William Morgan's message of Fr Jul 31 17:44:25 +0200 2009: > > Have you tried J and K vs j and k to scroll? > > Wow, cool. :) > Good to know. That is nifty -- I didn't know it existed either. It seems slow on this machine though, and after using it in thread-view-mode, inbox-mode seems to have lost its mind a bit. I had wondered if the behavior the original poster was after might be akin to vim's 'scrolloff' setting. Setting scrolloff=10 in vim means the selected line moves freely up and down but you're always going to have 10 lines of context at the edges; that is, the text starts scrolling upward when the selected line reaches 10 lines from the bottom. It kind of applies a 'force field' to the top and bottom edges of the page view so you never hit top or bottom of the viewport until you're at the top or bottom of the file itself. -- linkswarm.com :: Collaborative Insolence vasudeva.linkswarm.com/gallery2 :: For The Faint of Heart From rlane@club.cc.cmu.edu Sat Aug 1 18:56:09 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 1 Aug 2009 15:56:09 -0700 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms Message-ID: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/xapian_index.rb | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index 6358a20..5a5dfc1 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -304,6 +304,8 @@ class XapianIndex < BaseIndex DATE_VALUENO = 0 + MAX_TERM_LENGTH = 245 + # Xapian can very efficiently sort in ascending docid order. Sup always wants # to sort by descending date, so this method maps between them. In order to # handle multiple messages per second, we use a logistic curve centered @@ -428,7 +430,7 @@ class XapianIndex < BaseIndex @term_generator.document = doc text.each { |text,prefix| @term_generator.index_text text, 1, prefix } - terms.each { |term| doc.add_term term } + terms.each { |term| doc.add_term term if term.length <= MAX_TERM_LENGTH } doc.add_value DATE_VALUENO, date_value doc.data = m.id -- 1.6.0.4 From rlane@club.cc.cmu.edu Sat Aug 1 19:03:06 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 01 Aug 2009 19:03:06 -0400 Subject: [sup-talk] Fwd: xapian merged into next In-Reply-To: <1249151189-sup-3864@altis> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> <1248712876-sup-1446@entry> <1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com> <1248713360-sup-5448@entry> <1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com> <1248716073-sup-7443@masanjin.net> <1e5fdab70908010934l30373447r4a405c5ca0e406f9@mail.gmail.com> <1e5fdab70908011044q6743d213o554a7bd039e237c2@mail.gmail.com> <1249149855-sup-2211@pion.club.cc.cmu.edu> <1249151189-sup-3864@altis> Message-ID: <1249167402-sup-6423@pion.club.cc.cmu.edu> Excerpts from Guillaume Quintard's message of Sat Aug 01 14:31:55 -0400 2009: > Excerpts from Rich Lane's message of Sat Aug 01 20:14:34 +0200 2009: > > I think we'd be safe not adding terms for email addresses longer than > > 244 characters on the assumption that the user isn't going to want to > > search for them. > > http://files.getdropbox.com/u/155904/grepped > > I did a simple grep, tell me if it's not enough (I'd rather not dive > into the humongous mbox file). > The mails come from the mailing-list admin tool (sympa), encoding > problem it looks, the mangled part is "Propri?taires de liste" (list > owners in french) > I posted a patch that should keep Xapian from throwing an exception with long email addresses. I'm not any sort of encoding expert, but I'd guess that sup isn't responsible for the mangling. From guillaume.quintard@gmail.com Sat Aug 1 19:35:25 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Sun, 02 Aug 2009 01:35:25 +0200 Subject: [sup-talk] Fwd: xapian merged into next In-Reply-To: <1249167402-sup-6423@pion.club.cc.cmu.edu> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> <1248712876-sup-1446@entry> <1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com> <1248713360-sup-5448@entry> <1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com> <1248716073-sup-7443@masanjin.net> <1e5fdab70908010934l30373447r4a405c5ca0e406f9@mail.gmail.com> <1e5fdab70908011044q6743d213o554a7bd039e237c2@mail.gmail.com> <1249149855-sup-2211@pion.club.cc.cmu.edu> <1249151189-sup-3864@altis> <1249167402-sup-6423@pion.club.cc.cmu.edu> Message-ID: <1249169629-sup-5176@altis> Excerpts from Rich Lane's message of Sun Aug 02 01:03:06 +0200 2009: > with long email addresses. I'm not any sort of encoding expert, but I'd > guess that sup isn't responsible for the mangling. it isn't, the mangling comes from the mbox file, yet sup was able to import it at some point. I guesse the quotes don't really help. -- Guillaume From mailinglist@flasht.de Sat Aug 1 19:51:06 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Sun, 02 Aug 2009 01:51:06 +0200 Subject: [sup-talk] Smooth Paging In-Reply-To: <1249163726-sup-5839@lenin> References: <1249053249-sup-9884@Longbow> <1249055039-sup-8105@masanjin.net> <1249118728-sup-5483@thinkpad-debian> <1249163726-sup-5839@lenin> Message-ID: <1249170613-sup-5276@thinkpad-debian> Excerpts from vasudeva's message of Sa Aug 01 23:58:13 +0200 2009: > I had wondered if the behavior the original poster was after might be akin to > vim's 'scrolloff' setting. > > Setting scrolloff=10 in vim means the selected line moves freely up and down > but you're always going to have 10 lines of context at the edges; that is, the > text starts scrolling upward when the selected line reaches 10 lines from the > bottom. It kind of applies a 'force field' to the top and bottom edges of the > page view so you never hit top or bottom of the viewport until you're at the > top or bottom of the file itself. I'd actually love to see something like this in sup as well. -- ================================ Christopher Bertels http://www.adztec-independent.de From benoit.pierre@gmail.com Sun Aug 2 11:23:47 2009 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=) Date: Sun, 02 Aug 2009 17:23:47 +0200 Subject: [sup-talk] [PATCH] run-mailcap fix Message-ID: <1249226521-sup-4719@localdomain> I use this line in my ~/.mailcap to view HTML attachements in Mutt: text/html; w3m -dump -T text/html %s | pager; needsterminal; description=HTML Text; nametemplate=%s.html which doesn't work with Sup. The attached patch fix this by not redirecting stderr to /dev/null. It also restores the correct ncurses state (including arrow keypresses, thanks to Edward Z. Yang recent patch). -- A: Because it destroys the flow of conversation. Q: Why is top posting dumb? -------------- next part -------------- A non-text attachment was scrubbed... Name: sup-run-mailcap.patch Type: application/octet-stream Size: 704 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mark@markdrayton.info Mon Aug 3 04:16:24 2009 From: mark@markdrayton.info (Mark Drayton) Date: Mon, 3 Aug 2009 09:16:24 +0100 Subject: [sup-talk] Stack overflow in regexp matcher Message-ID: <92457f310908030116k146a901aleee95a09db907d97@mail.gmail.com> Hi there I'm trying to run sup 0.8.1 on Mac OS 10.5.6, Ruby 1.8.6 but sup-sync is repeatedly dying: MC-S001930:~ draytm01$ sup-sync -c [..] [Mon Aug 03 08:45:18 +0100 2009] Connecting to IMAP server foo:143... [Mon Aug 03 08:45:18 +0100 2009] Logging in... [..] [Mon Aug 03 08:45:19 +0100 2009] fetching IMAP headers 1..1002 [Mon Aug 03 08:45:20 +0100 2009] done fetching IMAP headers Scanning imap://foo/INBOX... [..] ## read 440m (about 52%) @ 2.2m/s. 0:03:19 elapsed, about 0:03:03 remaining [Mon Aug 03 08:48:49 +0100 2009] unlocking /Users/draytm01/.sup/lock... /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:204:in `split': Stack overflow in regexp matcher: /,\s*(?=(?:[^"]*"[^"]*")*(?![^"]*"))/ (RegexpError) from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:204:in `split_on_commas' from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/person.rb:110:in `from_address_list' from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/message.rb:104:in `parse_header' from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/message.rb:208:in `load_from_source!' from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/poll.rb:151:in `add_messages_from' from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/imap.rb:187:in `each' from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/imap.rb:175:in `upto' from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/imap.rb:175:in `each' ... 7 levels... from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/bin/sup-sync:135:in `each' from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/bin/sup-sync:135 from /usr/bin/sup-sync:19:in `load' from /usr/bin/sup-sync:19 This error seems to have cropped up in other software so I suspect it's a problem with Ruby, not sup. Anyone able to confirm this? Cheers, Mark From wmorgan-sup@masanjin.net Mon Aug 3 13:18:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 03 Aug 2009 10:18:50 -0700 Subject: [sup-talk] Odd bug with lazy-loaded messages In-Reply-To: <1248716007-sup-5156@javelin> References: <1248716007-sup-5156@javelin> Message-ID: <1249319474-sup-8322@masanjin.net> Sorry I didn't respond to this earlier. Reformatted excerpts from Edward Z. Yang's message of 2009-07-27: > Specifically, the "default" opened message when I open a thread > gets a weird misrendering of the headers that looks like: > > To: foo > foo > foo > > And so forth, for all lines in To and Cc. This is because we store a couple variants of the address in the index (e.g. the email address to the left of the @), so that a search on any of them will bring up the message. Without #load_from_source!, the message is loaded from the index, so it reflects those fields. So it's basically a hack at this point. You could further hack it by undoing that transformation. Or we could add the original version of the fields to the index in a separate, non-searchable field, incurring the associated storage penalties. -- William From wmorgan-sup@masanjin.net Mon Aug 3 13:31:34 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 03 Aug 2009 10:31:34 -0700 Subject: [sup-talk] Handling big mailing lists In-Reply-To: References: <1248874122-sup-3830@masanjin.net> Message-ID: <1249320458-sup-6019@masanjin.net> Reformatted excerpts from iny+dev's message of 2009-07-29: > I guess so. How long it takes to index few months of ruby-talk? Offhand I see index speeds of 50-80 messages/s depending on index size, backend, etc. > Could Sup use IMAP search features? No, that would require a very different architecture and philosophy. -- William From wmorgan-sup@masanjin.net Mon Aug 3 14:03:54 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 03 Aug 2009 11:03:54 -0700 Subject: [sup-talk] xapian question In-Reply-To: <1249098509-sup-6664@pion.club.cc.cmu.edu> References: <1248716325-sup-7534@masanjin.net> <1248795865-sup-6634@pion.club.cc.cmu.edu> <1248807365-sup-4965@masanjin.net> <1249098509-sup-6664@pion.club.cc.cmu.edu> Message-ID: <1249320789-sup-2608@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-07-31: > I tried out using add_term/remove_term for immediate label changes. > It's significantly faster than sync_message, Excellent. > but it still makes the interface feel laggy. There's known room for > improvement in Xapian's replace_document. However, we'll still have a > lot of latency when we start using remote sup-servers, so I don't > think it's a good idea to do these index operations synchronously with > the UI. I agree, synchronous is not an option. > We could queue up index writes and execute them in a background > thread. We'd want label additions to show up immediately in a search, > though. This is easy to do for inbox-mode and label-view-mode, which > covers most of my daily usage. I'm fine with queuing up index writes and letting the user continue while they take effect in the background. I'm also fine with the easier option of just blocking during a search until the writes are complete. > If/when we support multiple clients connecting to a sup-server, we'll > need a way to notify them that someone else modified a message. I think this is more of a nice-to-have than a necessity, but it would be nice to have, even if it was a "we've detected a change somewhere on the internet; reload? (y/n)"-kinda thing. > How is sup-server development going? Well. I have a simple version that stores "items" to files on disk, and uses Ferret to provide the search semantics. It's modular enough that upgrading to Xapian shouldn't be as painful as it was with Sup. There are even unit tests that enforce the semantics of the modules. Go me. I'm going to make a couple internal API changes in Sup and then try throwing the code together. -- William From tom@dbservice.com Tue Aug 4 05:56:11 2009 From: tom@dbservice.com (Tomas Carnecky) Date: Tue, 4 Aug 2009 11:56:11 +0200 Subject: [sup-talk] sup on opensolaris In-Reply-To: <1249059559-sup-8960@matrix> References: <1249059559-sup-8960@matrix> Message-ID: I hate mailing lists that force me to subscribe. Luckily I have a friend who was already subscribed and forwarded me the emails. > >> I have an ugly patch for lib/sup/textfield.rb that uses its own >> string >> buffer instead of relying on field_buffer(). It's not perfect, but it >> at least allows me to write emails and assign tags. > > If it's not too much work to clean up, I'd be interested in this > patch. > The field buffer stuff is broken in weird ways anyways (the history > never seems to be quite right), and anything that reduces the reliance > on ncurses is always the right approach. I never programed in ruby before and I don't intend to learn it. Feel free to look at the last commit in the solaris-fixes:curses-form- buffer branch. It is the simplest possible solution to the problem at hand that didn't require me to learn too much ruby. It still needs a considerable amount of work before it is useful (like, being able to delete characters in the stringio buffer etc). I'm not planing to work on the patch in the foreseeable future, but someone else might find the patch useful as a starting point. > >> - strftime("%P") is a GNU extension, I work around this by using >> strftime("%p").downcase. > > Submit a patch! I'm fine with this. > >> - Iconv.iconv(target + "//IGNORE", charset, text + " ") <- the "// >> IGNORE" is causing an InvalidEncoding exception, removing it didn't >> seem to cause any regressions > > Hm, this is a trickier one. Allegedly the //IGNORE reduces the > exceptions thrown by Iconv, but since we're catching them all anyways, > we might be able to get away with removing this. Or we could > special-case it to your arch. Both patches are available in the solaris-fixes master branch. tom From wmorgan-sup@masanjin.net Wed Aug 5 09:55:47 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 05 Aug 2009 06:55:47 -0700 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms In-Reply-To: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu> References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1249480531-sup-9805@masanjin.net> Applied, thanks! BTW I've merged the xapian stuff into master. -- William From dato@net.com.org.es Wed Aug 5 10:09:26 2009 From: dato@net.com.org.es (=?utf-8?q?Adeodato_Sim=C3=B3?=) Date: Wed, 05 Aug 2009 16:09:26 +0200 Subject: [sup-talk] sup ignoring SIGTERM? Message-ID: <1249481294-sup-9967@chistera.yi.org> Hello, it is my impression that sup is ignoring SIGTERM, whereas I would be expecting for sup to clean up (including removal of the lock file) and exit normally upon receiving this signal. Any clues about this? (I tried inserting a "trap", but it didn't seem to help.) Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai From ezyang@MIT.EDU Wed Aug 5 10:54:31 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 05 Aug 2009 10:54:31 -0400 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms In-Reply-To: <1249480531-sup-9805@masanjin.net> References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu> <1249480531-sup-9805@masanjin.net> Message-ID: <1249484040-sup-1879@javelin> Excerpts from William Morgan's message of Wed Aug 05 09:55:47 -0400 2009: > BTW I've merged the xapian stuff into master. Exciting days we live in. :-) Maybe I'll wait another week and update my local checkout. Cheers, Edward From wmorgan-sup@masanjin.net Wed Aug 5 11:29:27 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 05 Aug 2009 08:29:27 -0700 Subject: [sup-talk] sup crashing after sending mail In-Reply-To: References: Message-ID: <1249486021-sup-1246@masanjin.net> Hi Igor, Reformatted excerpts from Igor Brkic's message of 2009-08-02: > For mail sending I use sSMTP and my ISP's SMTP server. When I try to > send mail from sup, after pressing y on keyboard, mail gets sent but > sup crashes (exception-log_0.txt in attachment). A few people have reported this and I'm trying to track it down. Would you mind applying the following patch, and then running: sup-sync -a sup://sent Hopefully that will generate a little debugging output I can use. Thanks! diff --git a/lib/sup/message.rb b/lib/sup/message.rb index 5372fc7..fc9af59 100644 --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -92,11 +92,11 @@ class Message begin Time.parse date rescue ArgumentError => e - #Redwood::log "faking mangled date header for #{@id} (orig #{header['date'] + Redwood::log "faking mangled date header for #{@id} (orig #{header['date']. Time.now end else - #Redwood::log "faking non-existent date header for #{@id}" + Redwood::log "faking non-existent date header for #{@id}" Time.now end diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb index 354bd21..365f828 100644 --- a/lib/sup/poll.rb +++ b/lib/sup/poll.rb @@ -148,7 +148,9 @@ EOS labels = labels + (source.archived? ? [] : [:inbox]) m = Message.new :source => source, :source_info => offset, :labels => label + Redwood::log "XX before load: #{m.date.inspect}" m.load_from_source! + Redwood::log "XX after load: #{m.date.inspect}" if m.source_marked_read? m.remove_label :unread @@ -157,7 +159,9 @@ EOS docid, entry = Index.load_entry_for_id m.id HookManager.run "before-add-message", :message => m + Redwood::log "XX after add-message: #{m.date.inspect}" m = yield(m, offset, entry) or next if block_given? + Redwood::log "XX after yield: #{m.date.inspect}" times = Index.sync_message m, false, docid, entry, opts UpdateManager.relay self, :added, m unless entry end -- William From rlane@club.cc.cmu.edu Wed Aug 5 11:36:19 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 05 Aug 2009 11:36:19 -0400 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms In-Reply-To: <1249480531-sup-9805@masanjin.net> References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu> <1249480531-sup-9805@masanjin.net> Message-ID: <1249485678-sup-4545@pion.club.cc.cmu.edu> Excerpts from William Morgan's message of Wed Aug 05 09:55:47 -0400 2009: > BTW I've merged the xapian stuff into master. Let's not advertise this as stable just yet - I've got a patchset that removes the GDBM databases which will break compatibility. Using just Xapian means better consistency if your kernel panics and potentially better performance. However, I have some Xapian bugs to squash before it's usable. From wmorgan-sup@masanjin.net Wed Aug 5 11:48:35 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 05 Aug 2009 08:48:35 -0700 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms In-Reply-To: <1249485678-sup-4545@pion.club.cc.cmu.edu> References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu> <1249480531-sup-9805@masanjin.net> <1249485678-sup-4545@pion.club.cc.cmu.edu> Message-ID: <1249487110-sup-1824@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-08-05: > Let's not advertise this as stable just yet - I've got a patchset that > removes the GDBM databases which will break compatibility. Since the xapian stuff is only enabled via an obscure environment variable, I'm not too concerned about it being uber-stable. I've merged this more for the internal API changes, which seem stable and which I'm now building off of. -- William From nicolas.pouillard@gmail.com Wed Aug 5 13:29:48 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Wed, 05 Aug 2009 19:29:48 +0200 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms In-Reply-To: <1249485678-sup-4545@pion.club.cc.cmu.edu> References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu> <1249480531-sup-9805@masanjin.net> <1249485678-sup-4545@pion.club.cc.cmu.edu> Message-ID: <1249493306-sup-4994@ausone.home> Excerpts from Rich Lane's message of Wed Aug 05 17:36:19 +0200 2009: > Excerpts from William Morgan's message of Wed Aug 05 09:55:47 -0400 2009: > > BTW I've merged the xapian stuff into master. > > Let's not advertise this as stable just yet - > I've got a patchset that > removes the GDBM databases which will break compatibility. I was planning to try a migration today, should I better wait a little? -- Nicolas Pouillard http://nicolaspouillard.fr From rlane@club.cc.cmu.edu Wed Aug 5 13:48:11 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 05 Aug 2009 13:48:11 -0400 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms In-Reply-To: <1249493306-sup-4994@ausone.home> References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu> <1249480531-sup-9805@masanjin.net> <1249485678-sup-4545@pion.club.cc.cmu.edu> <1249493306-sup-4994@ausone.home> Message-ID: <1249493896-sup-7335@pion.club.cc.cmu.edu> Excerpts from Nicolas Pouillard's message of Wed Aug 05 13:29:48 -0400 2009: > I was planning to try a migration today, should I better wait a little? I'd say go for it, just be aware you'll need to reindex soon. For the full experience compile svn xapian and export XAPIAN_PREFER_CHERT=1. From nicolas.pouillard@gmail.com Wed Aug 5 13:58:43 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Wed, 05 Aug 2009 19:58:43 +0200 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms In-Reply-To: <1249493896-sup-7335@pion.club.cc.cmu.edu> References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu> <1249480531-sup-9805@masanjin.net> <1249485678-sup-4545@pion.club.cc.cmu.edu> <1249493306-sup-4994@ausone.home> <1249493896-sup-7335@pion.club.cc.cmu.edu> Message-ID: <1249495000-sup-6057@ausone.home> Excerpts from Rich Lane's message of Wed Aug 05 19:48:11 +0200 2009: > Excerpts from Nicolas Pouillard's message of Wed Aug 05 13:29:48 -0400 2009: > > I was planning to try a migration today, should I better wait a little? > > I'd say go for it, just be aware you'll need to reindex soon. For the > full experience compile svn xapian and export XAPIAN_PREFER_CHERT=1. When you say the svn version you mean the trunk or the 1.0-branch ? -- Nicolas Pouillard http://nicolaspouillard.fr From rlane@club.cc.cmu.edu Wed Aug 5 14:06:39 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 05 Aug 2009 14:06:39 -0400 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms In-Reply-To: <1249495000-sup-6057@ausone.home> References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu> <1249480531-sup-9805@masanjin.net> <1249485678-sup-4545@pion.club.cc.cmu.edu> <1249493306-sup-4994@ausone.home> <1249493896-sup-7335@pion.club.cc.cmu.edu> <1249495000-sup-6057@ausone.home> Message-ID: <1249495530-sup-6312@pion.club.cc.cmu.edu> Excerpts from Nicolas Pouillard's message of Wed Aug 05 13:58:43 -0400 2009: > Excerpts from Rich Lane's message of Wed Aug 05 19:48:11 +0200 2009: > > Excerpts from Nicolas Pouillard's message of Wed Aug 05 13:29:48 -0400 2009: > > > I was planning to try a migration today, should I better wait a little? > > > > I'd say go for it, just be aware you'll need to reindex soon. For the > > full experience compile svn xapian and export XAPIAN_PREFER_CHERT=1. > > When you say the svn version you mean the trunk or the 1.0-branch ? Trunk. From wmorgan-sup@masanjin.net Wed Aug 5 16:03:09 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 05 Aug 2009 13:03:09 -0700 Subject: [sup-talk] sup ignoring SIGTERM? In-Reply-To: <1249481294-sup-9967@chistera.yi.org> References: <1249481294-sup-9967@chistera.yi.org> Message-ID: <1249502171-sup-8079@masanjin.net> Reformatted excerpts from Adeodato Sim?'s message of 2009-08-05: > it is my impression that sup is ignoring SIGTERM, whereas I would be > expecting for sup to clean up (including removal of the lock file) and > exit normally upon receiving this signal. Good point. I've fixed that in branch ncurses-fixes, which I've merged into next. Let me know if it works for you. I'm also happy to report that I've finally managed to get Sup to deal with screen resizes, which, oddly enough, was a related problem. Go me! Steps closer to curses-induced insanity: 4! Available on next or ncurses-fixes branches. -- William From nicolas.pouillard@gmail.com Wed Aug 5 16:25:49 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Wed, 05 Aug 2009 22:25:49 +0200 Subject: [sup-talk] sup ignoring SIGTERM? In-Reply-To: <1249502171-sup-8079@masanjin.net> References: <1249481294-sup-9967@chistera.yi.org> <1249502171-sup-8079@masanjin.net> Message-ID: <1249503870-sup-1415@ausone.home> Excerpts from William Morgan's message of Wed Aug 05 22:03:09 +0200 2009: > Reformatted excerpts from Adeodato Sim?'s message of 2009-08-05: > > it is my impression that sup is ignoring SIGTERM, whereas I would be > > expecting for sup to clean up (including removal of the lock file) and > > exit normally upon receiving this signal. > > Good point. I've fixed that in branch ncurses-fixes, which I've merged > into next. Let me know if it works for you. > > I'm also happy to report that I've finally managed to get Sup to deal > with screen resizes, which, oddly enough, was a related problem. Go me! > Steps closer to curses-induced insanity: 4! > > Available on next or ncurses-fixes branches. With the ncurses-fixes branch (even with the last patch), when I launch sup I get a blank screen (with the status bar saying "Searching for threads...". -- Nicolas Pouillard http://nicolaspouillard.fr From bwalton@artsci.utoronto.ca Wed Aug 5 16:35:51 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Wed, 05 Aug 2009 16:35:51 -0400 Subject: [sup-talk] sup ignoring SIGTERM? In-Reply-To: <1249502171-sup-8079@masanjin.net> References: <1249481294-sup-9967@chistera.yi.org> <1249502171-sup-8079@masanjin.net> Message-ID: <1249504381-sup-8445@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Wed Aug 05 16:03:09 -0400 2009: > Good point. I've fixed that in branch ncurses-fixes, which I've merged > into next. Let me know if it works for you. I just pulled next and fired it up. It was _hoooooribly_, _bruuuutallly_ slow to load the index. I git bisected between my previous running ORIG_HEAD and HEAD. I came up with 75d9f5e3db as the offender. It seems to do what you intend but (for me, anyway) at the expense of really bad interactivity. [We're talking 10+ minutes to load the index part way...] This doesn't help identify the problem, but I'd be looking at the Ncurses.nodelay bits... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Wed Aug 5 17:24:49 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 05 Aug 2009 14:24:49 -0700 Subject: [sup-talk] sup ignoring SIGTERM? In-Reply-To: <1249503870-sup-1415@ausone.home> References: <1249481294-sup-9967@chistera.yi.org> <1249502171-sup-8079@masanjin.net> <1249503870-sup-1415@ausone.home> Message-ID: <1249507336-sup-7887@masanjin.net> Reformatted excerpts from Nicolas Pouillard's message of 2009-08-05: > With the ncurses-fixes branch (even with the last patch), when I > launch sup I get a blank screen (with the status bar saying "Searching > for threads...". Dammit. I see that too, on some computers. The problem is that Ncurses.getch is actually blocking the background threads from working. (You can tell because threads will start loading when you press lots of keys.) I've unmerged the branch from next for the time being. The problem is the removal of the select() in nonblocking_getch (buffer.rb circa line 25). With it in, resizes don't work right. With it removed, background threads are blocked on some computers. Not sure what makes the difference. Sigh... -- William From ezyang@MIT.EDU Wed Aug 5 17:28:43 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 05 Aug 2009 17:28:43 -0400 Subject: [sup-talk] sup ignoring SIGTERM? In-Reply-To: <1249502171-sup-8079@masanjin.net> References: <1249481294-sup-9967@chistera.yi.org> <1249502171-sup-8079@masanjin.net> Message-ID: <1249507702-sup-8439@javelin> Excerpts from William Morgan's message of Wed Aug 05 16:03:09 -0400 2009: > I'm also happy to report that I've finally managed to get Sup to deal > with screen resizes, which, oddly enough, was a related problem. Go me! > Steps closer to curses-induced insanity: 4! Sounds exciting. What was the fix? Cheers, Edward From igor.brkic@fer.hr Wed Aug 5 19:24:38 2009 From: igor.brkic@fer.hr (Igor Brkic) Date: Thu, 06 Aug 2009 01:24:38 +0200 Subject: [sup-talk] sup crashing after sending mail In-Reply-To: <1249486021-sup-1246@masanjin.net> References: <1249486021-sup-1246@masanjin.net> Message-ID: <1249514106-sup-9112@xps> Excerpts from William Morgan's message of Sri Kol 05 17:29:27 +0200 2009: > A few people have reported this and I'm trying to track it down. Would > you mind applying the following patch, and then running: > sup-sync -a sup://sent > > Hopefully that will generate a little debugging output I can use. Thanks! I (partially) solved/hacked the problem. The problem was (I think) in wrong set locale and Sup not being able to recognize and compare sending date (which had croatian tags for month and day of the week) and Time.now (which was whole in english/universal format). I solved the problem by commenting out the "Time.parse time, 0" (line 15 in file lib/sup/mbox.rb). It's not perfect solution (if that line should be commented out, it would be :D), but for me it works for now (I'm writing this mail from it). Cheers! Igor Brkic From wmorgan-sup@masanjin.net Thu Aug 6 10:40:08 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 06 Aug 2009 07:40:08 -0700 Subject: [sup-talk] sup crashing after sending mail In-Reply-To: <1249514106-sup-9112@xps> References: <1249486021-sup-1246@masanjin.net> <1249514106-sup-9112@xps> Message-ID: <1249568949-sup-3922@masanjin.net> Reformatted excerpts from Igor Brkic's message of 2009-08-05: > I solved the problem by commenting out the "Time.parse time, 0" (line > 15 in file lib/sup/mbox.rb). I'm glad that works, but I have a hard time understanding why. That line is for parsing the mbox "From " separator line (which has a date on it). It has nothing to do with the date field in the message, which is what isn't being set (and thus raising the exception). If the date parsing on that line is screwed up, then I would except to see an out-of-sync error raised by Sup, since it would be expecting an mbox "From " separator line and wouldn't detect the line as such. If you feel like it, send me a small mbox file (possible your ~/.sup/sent.mbox after being censored) and I can take a look. -- William From igor.brkic@fer.hr Thu Aug 6 12:57:03 2009 From: igor.brkic@fer.hr (Igor Brkic) Date: Thu, 06 Aug 2009 18:57:03 +0200 Subject: [sup-talk] sup crashing after sending mail In-Reply-To: <1249568949-sup-3922@masanjin.net> References: <1249486021-sup-1246@masanjin.net> <1249514106-sup-9112@xps> <1249568949-sup-3922@masanjin.net> Message-ID: <1249576777-sup-3885@xps> Excerpts from William Morgan's message of ?et Kol 06 16:40:08 +0200 2009: > > If you feel like it, send me a small mbox file (possible your > ~/.sup/sent.mbox after being censored) and I can take a look. This is weird... For the last hour and a half I've been trying to reproduce the error I was having - I uncommented the line in mbox.rb, returned locale settings to previous state - but everything is working flawless. Whatever I make, it won't crash. I'll keep trying, though :) I'm afraid I can't send you the mbox file that is causing sup to crash because I deleted all logs and sent.mbox files the moment all started to work. From wmorgan-sup@masanjin.net Thu Aug 6 13:45:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 06 Aug 2009 10:45:50 -0700 Subject: [sup-talk] sup crashing after sending mail In-Reply-To: <1249579173-sup-573@xps> References: <1249486021-sup-1246@masanjin.net> <1249514106-sup-9112@xps> <1249568949-sup-3922@masanjin.net> <1249576777-sup-3885@xps> <1249579173-sup-573@xps> Message-ID: <1249580716-sup-6413@masanjin.net> Reformatted excerpts from Igor Brkic's message of 2009-08-06: > I attached output of "sup-sync -a sup://sent" with patch you sent me > applyed (sync-log.txt). Awesome. This looks very juicy. Thanks! -- William From wmorgan-sup@masanjin.net Thu Aug 6 13:53:43 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 06 Aug 2009 10:53:43 -0700 Subject: [sup-talk] sup ignoring SIGTERM? In-Reply-To: <1249507336-sup-7887@masanjin.net> References: <1249481294-sup-9967@chistera.yi.org> <1249502171-sup-8079@masanjin.net> <1249503870-sup-1415@ausone.home> <1249507336-sup-7887@masanjin.net> Message-ID: <1249581215-sup-2548@masanjin.net> Reformatted excerpts from William Morgan's message of 2009-08-05: > The problem is the removal of the select() in nonblocking_getch > (buffer.rb circa line 25). With it in, resizes don't work right. With > it removed, background threads are blocked on some computers. Not sure > what makes the difference. Sigh... Ok, I've tracked this down. FWIW, this is a problem that's been around in ruby ncurses libraries since at least 2005, when I complained about it on ruby-core. In many ruby ncurses libraries, including the most recent gem, Ncurses.getch blocks all Ruby threads from running. That's a bug. The workaround is to wrap it in a select() call. But then you have to handle sigwinch manually (i.e via Kernel#trap), because getch won't return a resize "keystroke" until the user hits an actual key. The libncurses-ruby library on modern Ubuntu systems actually doesn't have this problem. You can set nodelay false, throw out the select call, and everything works the way it's supposed to: background threads run, and you get a resize keystroke when a sigwinch happens without you having to install your own handler. And that's the library I had been developing against, which is why everything worked on one computer but didn't work on the others. Anyways, for those who were having problems with this branch before, please try the most recent version and confirm that: 1. Email threads load as normal, i.e. in the background. 2. Resizing the terminal refreshes the screen without you having to press any keys. 3. Ctrl-l still works. 4. Ctrl-c still works (prompts you, and y/n do the right thing). 5. Killing Sup works. If everyone's happy, I'll merge this branch into next. If you're curious about whether you have a good or bad ncurses library, run this program: (But either should work correctly with Sup.) require 'rubygems' require 'ncurses' require 'thread' Ncurses.initscr Ncurses.noecho Ncurses.cbreak Ncurses.curs_set 0 Thread.new do sleep 0.1 Ncurses.stdscr.mvaddstr 0, 0, "ncurses library is GOOD." end begin Ncurses.stdscr.mvaddstr 0, 0, "ncurses library is BAD." Ncurses.getch ensure Ncurses.curs_set 1 Ncurses.endwin puts "bye" end -- William From nicolas.pouillard@gmail.com Thu Aug 6 14:09:35 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Thu, 06 Aug 2009 20:09:35 +0200 Subject: [sup-talk] sup ignoring SIGTERM? In-Reply-To: <1249581215-sup-2548@masanjin.net> References: <1249481294-sup-9967@chistera.yi.org> <1249502171-sup-8079@masanjin.net> <1249503870-sup-1415@ausone.home> <1249507336-sup-7887@masanjin.net> <1249581215-sup-2548@masanjin.net> Message-ID: <1249582142-sup-9952@ausone.home> Excerpts from William Morgan's message of Thu Aug 06 19:53:43 +0200 2009: > Reformatted excerpts from William Morgan's message of 2009-08-05: > > The problem is the removal of the select() in nonblocking_getch > > (buffer.rb circa line 25). With it in, resizes don't work right. With > > it removed, background threads are blocked on some computers. Not sure > > what makes the difference. Sigh... [...] > If everyone's happy, I'll merge this branch into next. Works just great! Thanks. -- Nicolas Pouillard http://nicolaspouillard.fr From dato@net.com.org.es Thu Aug 6 14:37:25 2009 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=) Date: Thu, 6 Aug 2009 20:37:25 +0200 Subject: [sup-talk] sup ignoring SIGTERM? In-Reply-To: <1249502171-sup-8079@masanjin.net> References: <1249481294-sup-9967@chistera.yi.org> <1249502171-sup-8079@masanjin.net> Message-ID: <20090806183725.GA8363@chistera.yi.org> + William Morgan (Wed, 05 Aug 2009 13:03:09 -0700): > Reformatted excerpts from Adeodato Sim?'s message of 2009-08-05: > > it is my impression that sup is ignoring SIGTERM, whereas I would be > > expecting for sup to clean up (including removal of the lock file) and > > exit normally upon receiving this signal. > Good point. I've fixed that in branch ncurses-fixes, which I've merged > into next. Let me know if it works for you. Everything seems to work fine as of 3478e40, including sup terminating upon SIGTERM. If I may, I'd suggest normal termination instead of raising an exception. IMHO, it is expected that programs that capture SIGTERM, will do cleanup and exit normally, rather than behave as if an error had happened. (Perhaps it'd be difficult to exit sup cleanly from the handler in any other way than an exception: that, I don't know.) Thanks, in any case. -- - Are you sure we're good? - Always. -- Rory and Lorelai From bwalton@artsci.utoronto.ca Thu Aug 6 19:56:51 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 06 Aug 2009 19:56:51 -0400 Subject: [sup-talk] sup ignoring SIGTERM? In-Reply-To: <1249581215-sup-2548@masanjin.net> References: <1249481294-sup-9967@chistera.yi.org> <1249502171-sup-8079@masanjin.net> <1249503870-sup-1415@ausone.home> <1249507336-sup-7887@masanjin.net> <1249581215-sup-2548@masanjin.net> Message-ID: <1249602985-sup-8547@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Thu Aug 06 13:53:43 -0400 2009: > Ok, I've tracked this down. FWIW, this is a problem that's been around > in ruby ncurses libraries since at least 2005, when I complained about > it on ruby-core. ...yup, looks like you stuck the landing this time! :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Thu Aug 6 21:38:53 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 06 Aug 2009 18:38:53 -0700 Subject: [sup-talk] sup ignoring SIGTERM? In-Reply-To: <20090806183725.GA8363@chistera.yi.org> References: <1249481294-sup-9967@chistera.yi.org> <1249502171-sup-8079@masanjin.net> <20090806183725.GA8363@chistera.yi.org> Message-ID: <1249609105-sup-5858@masanjin.net> Reformatted excerpts from Adeodato Sim?'s message of 2009-08-06: > Everything seems to work fine as of 3478e40, including sup terminating > upon SIGTERM. If I may, I'd suggest normal termination instead of > raising an exception. IMHO, it is expected that programs that capture > SIGTERM, will do cleanup and exit normally, rather than behave as if > an error had happened. Good idea. Try it now. -- William From dato@net.com.org.es Fri Aug 7 06:31:51 2009 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=) Date: Fri, 7 Aug 2009 12:31:51 +0200 Subject: [sup-talk] sup ignoring SIGTERM? In-Reply-To: <1249609105-sup-5858@masanjin.net> References: <1249481294-sup-9967@chistera.yi.org> <1249502171-sup-8079@masanjin.net> <20090806183725.GA8363@chistera.yi.org> <1249609105-sup-5858@masanjin.net> Message-ID: <20090807103151.GA20799@chistera.yi.org> + William Morgan (Thu, 06 Aug 2009 18:38:53 -0700): > Reformatted excerpts from Adeodato Sim?'s message of 2009-08-06: > > Everything seems to work fine as of 3478e40, including sup terminating > > upon SIGTERM. If I may, I'd suggest normal termination instead of > > raising an exception. IMHO, it is expected that programs that capture > > SIGTERM, will do cleanup and exit normally, rather than behave as if > > an error had happened. > Good idea. Try it now. Ah, excellent: works as suggested now. Regarding 57dea7a (refactor index locking interaction and replace suicidemanager), I'll note that at least on my system, and after having moved to Xapian, those codepaths no longer execute. That is, if a sup is running and a second one is started, it never gets to ask whether to suggest dieing to the first one, because this second one dies with: [Fri Aug 07 12:31:05 +0200 2009] using character set encoding "UTF-8" [Fri Aug 07 12:31:05 +0200 2009] using index Redwood::XapianIndex [Fri Aug 07 12:31:05 +0200 2009] dynamically loading setlocale() from libc.so.6 [Fri Aug 07 12:31:05 +0200 2009] setting locale... .../lib/sup/xapian_index.rb:24:in `initialize': Resource temporarily unavailable - /home/adeodato/.sup/entries.db (Errno::EAGAIN) from .../lib/sup/xapian_index.rb:24:in `new' from .../lib/sup/xapian_index.rb:24:in `initialize' from .../bin/sup:132:in `new' from .../bin/sup:132 Thanks! -- - Are you sure we're good? - Always. -- Rory and Lorelai From rlane@club.cc.cmu.edu Thu Aug 6 15:32:44 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 6 Aug 2009 12:32:44 -0700 Subject: [sup-talk] [PATCH] move xapian index loading into load_index Message-ID: <1249587164-14080-1-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/xapian_index.rb | 17 ++++++++--------- 1 files changed, 8 insertions(+), 9 deletions(-) diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index 5a5dfc1..861c2a3 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -20,14 +20,16 @@ class XapianIndex < BaseIndex super @index_mutex = Monitor.new + end - @entries = MarshalledGDBM.new File.join(dir, "entries.db") - @docids = MarshalledGDBM.new File.join(dir, "docids.db") - @thread_members = MarshalledGDBM.new File.join(dir, "thread_members.db") - @thread_ids = MarshalledGDBM.new File.join(dir, "thread_ids.db") - @assigned_docids = GDBM.new File.join(dir, "assigned_docids.db") + def load_index + @entries = MarshalledGDBM.new File.join(@dir, "entries.db") + @docids = MarshalledGDBM.new File.join(@dir, "docids.db") + @thread_members = MarshalledGDBM.new File.join(@dir, "thread_members.db") + @thread_ids = MarshalledGDBM.new File.join(@dir, "thread_ids.db") + @assigned_docids = GDBM.new File.join(@dir, "assigned_docids.db") - @xapian = Xapian::WritableDatabase.new(File.join(dir, "xapian"), Xapian::DB_CREATE_OR_OPEN) + @xapian = Xapian::WritableDatabase.new(File.join(@dir, "xapian"), Xapian::DB_CREATE_OR_OPEN) @term_generator = Xapian::TermGenerator.new() @term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE) @enquire = Xapian::Enquire.new @xapian @@ -35,9 +37,6 @@ class XapianIndex < BaseIndex @enquire.docid_order = Xapian::Enquire::ASCENDING end - def load_index - end - def save_index end -- 1.6.4 From rlane@club.cc.cmu.edu Fri Aug 7 12:40:18 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Fri, 07 Aug 2009 12:40:18 -0400 Subject: [sup-talk] sup ignoring SIGTERM? In-Reply-To: <20090807103151.GA20799@chistera.yi.org> References: <1249481294-sup-9967@chistera.yi.org> <1249502171-sup-8079@masanjin.net> <20090806183725.GA8363@chistera.yi.org> <1249609105-sup-5858@masanjin.net> <20090807103151.GA20799@chistera.yi.org> Message-ID: <1249662782-sup-638@pion.club.cc.cmu.edu> Excerpts from Adeodato Sim?'s message of Fri Aug 07 06:31:51 -0400 2009: > Regarding 57dea7a (refactor index locking interaction and replace > suicidemanager), I'll note that at least on my system, and after having > moved to Xapian, those codepaths no longer execute. That is, if a sup is > running and a second one is started, it never gets to ask whether to > suggest dieing to the first one, because this second one dies with: > > [Fri Aug 07 12:31:05 +0200 2009] using character set encoding "UTF-8" > [Fri Aug 07 12:31:05 +0200 2009] using index Redwood::XapianIndex > [Fri Aug 07 12:31:05 +0200 2009] dynamically loading setlocale() from libc.so.6 > [Fri Aug 07 12:31:05 +0200 2009] setting locale... > .../lib/sup/xapian_index.rb:24:in `initialize': Resource temporarily > unavailable - /home/adeodato/.sup/entries.db (Errno::EAGAIN) > from .../lib/sup/xapian_index.rb:24:in `new' > from .../lib/sup/xapian_index.rb:24:in `initialize' > from .../bin/sup:132:in `new' > from .../bin/sup:132 I've just posted a patch that should fix this. From ezyang@MIT.EDU Sat Aug 8 02:07:22 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Sat, 08 Aug 2009 02:07:22 -0400 Subject: [sup-talk] Odd bug with lazy-loaded messages In-Reply-To: <1249319474-sup-8322@masanjin.net> References: <1248716007-sup-5156@javelin> <1249319474-sup-8322@masanjin.net> Message-ID: <1249711570-sup-2277@javelin> Excerpts from William Morgan's message of Mon Aug 03 13:18:50 -0400 2009: > This is because we store a couple variants of the address in the index > (e.g. the email address to the left of the @), so that a search on any > of them will bring up the message. Without #load_from_source!, the > message is loaded from the index, so it reflects those fields. So it's > basically a hack at this point. You could further hack it by undoing > that transformation. Or we could add the original version of the fields > to the index in a separate, non-searchable field, incurring the > associated storage penalties. Great. I sprinkled a few extra load_from_source! calls and I think I made the weird behavior go away. It's kind of sketchy though. >From 6c539b9c0fb952b0cc10c121cb906b1aefd58c31 Mon Sep 17 00:00:00 2001 From: Edward Z. Yang Date: Mon, 8 Jun 2009 22:21:01 -0400 Subject: [PATCH 1/3] Remove message pre-loading; optimizes for the common case. There are some load_from_source! calls to flush away extra header info that we don't want displayed. We may need to add this in more/less places. Signed-off-by: Edward Z. Yang --- lib/sup/modes/thread-index-mode.rb | 1 - lib/sup/modes/thread-view-mode.rb | 2 ++ 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index b671119..5e58072 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -105,7 +105,6 @@ EOS t.each_with_index do |(m, *o), i| next unless m BufferManager.say "#{message} (#{i}/#{num})", sid if t.size > 1 - m.load_from_source! end end mode = ThreadViewMode.new t, @hidden_labels, self diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index 737f6f1..94e3ed7 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -124,6 +124,7 @@ EOS end end + latest.load_from_source! @layout[latest].state = :open if @layout[latest].state == :closed @layout[earliest].state = :detailed if earliest.has_label?(:unread) || @thread.size == 1 @@ -555,6 +556,7 @@ private def initial_state_for m if m.has_label?(:starred) || m.has_label?(:unread) + m.load_from_source! :open else :closed -- 1.6.3.3 From dato@net.com.org.es Sat Aug 8 05:23:25 2009 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=) Date: Sat, 8 Aug 2009 11:23:25 +0200 Subject: [sup-talk] sup ignoring SIGTERM? In-Reply-To: <1249662782-sup-638@pion.club.cc.cmu.edu> References: <1249481294-sup-9967@chistera.yi.org> <1249502171-sup-8079@masanjin.net> <20090806183725.GA8363@chistera.yi.org> <1249609105-sup-5858@masanjin.net> <20090807103151.GA20799@chistera.yi.org> <1249662782-sup-638@pion.club.cc.cmu.edu> Message-ID: <20090808092325.GA2392@chistera.yi.org> + Rich Lane (Fri, 07 Aug 2009 12:40:18 -0400): > > [Fri Aug 07 12:31:05 +0200 2009] using character set encoding "UTF-8" > > [Fri Aug 07 12:31:05 +0200 2009] using index Redwood::XapianIndex > > [Fri Aug 07 12:31:05 +0200 2009] dynamically loading setlocale() from libc.so.6 > > [Fri Aug 07 12:31:05 +0200 2009] setting locale... > > .../lib/sup/xapian_index.rb:24:in `initialize': Resource temporarily > > unavailable - /home/adeodato/.sup/entries.db (Errno::EAGAIN) > > from .../lib/sup/xapian_index.rb:24:in `new' > > from .../lib/sup/xapian_index.rb:24:in `initialize' > > from .../bin/sup:132:in `new' > > from .../bin/sup:132 > I've just posted a patch that should fix this. It works, thank you! -- - Are you sure we're good? - Always. -- Rory and Lorelai From ezyang@MIT.EDU Sun Aug 9 04:40:33 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Sun, 09 Aug 2009 04:40:33 -0400 Subject: [sup-talk] Odd bug with lazy-loaded messages In-Reply-To: <1249711570-sup-2277@javelin> References: <1248716007-sup-5156@javelin> <1249319474-sup-8322@masanjin.net> <1249711570-sup-2277@javelin> Message-ID: <1249807206-sup-55@javelin> Excerpts from Edward Z. Yang's message of Sat Aug 08 02:07:22 -0400 2009: > Great. I sprinkled a few extra load_from_source! calls and I think > I made the weird behavior go away. It's kind of sketchy though. It looks like it's still a problem in some sporadic cases. Going to submit a more thorough patch soon. Cheers, Edward From jstewart@fusionary.com Mon Aug 10 09:22:43 2009 From: jstewart@fusionary.com (Jason Stewart) Date: Mon, 10 Aug 2009 09:22:43 -0400 Subject: [sup-talk] Starring messages in a hook Message-ID: <1249910430-sup-4573@JasonsComputer-3.local> Hello, New sup user here and I have to say that I'm very impressed with it even though I've only been using it for a few days. I'm using a before-add-message to label messages, and was wondering if there's a way to star them in this hook? Looking at the source for message.rb I see an add_label, but no add_star. From ismith@MIT.EDU Mon Aug 10 11:07:38 2009 From: ismith@MIT.EDU (Ian Smith) Date: Mon, 10 Aug 2009 11:07:38 -0400 Subject: [sup-talk] Starring messages in a hook In-Reply-To: <1249910430-sup-4573@JasonsComputer-3.local> References: <1249910430-sup-4573@JasonsComputer-3.local> Message-ID: <1249916791-sup-4269@baad> Hi Jason, Starred messages are labeled "Starred"; presumably just adding this label to the message would do what you want. Ian Excerpts from Jason Stewart's message of Mon Aug 10 09:22:43 -0400 2009: > Hello, > > New sup user here and I have to say that I'm very impressed with it even > though I've only been using it for a few days. > > I'm using a before-add-message to label messages, and was wondering if > there's a way to star them in this hook? Looking at the source for > message.rb I see an add_label, but no add_star. -- Ian Smith ismith at mit.edu ismith at bostonaccess.org From wmorgan-sup@masanjin.net Tue Aug 11 16:14:44 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 11 Aug 2009 13:14:44 -0700 Subject: [sup-talk] some internal api refactors Message-ID: <1250021119-sup-4253@masanjin.net> Hi Rich, and others, In the branch various-api-refactors I've made a couple significant genotypic changes to the index and polling API that I want to make sure are in line with your evil plans. Commit 8aa1370d in particular replaces Index.sync_message with three methods, one for adding new messages, one for updating existing messages, and one for just tweaking the labels. The current implementation just calls the original sync_message implementation for all three. The rest of the changes are tweaks in the various consumers of these messages. The intention is that this will be useful both for Xapian and Sup the server, which may need to distinguish between these three methods of index access (or may simply want to for speed). -- William From wmorgan-sup@masanjin.net Tue Aug 11 16:18:15 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 11 Aug 2009 13:18:15 -0700 Subject: [sup-talk] [PATCH] move xapian index loading into load_index In-Reply-To: <1249587164-14080-1-git-send-email-rlane@club.cc.cmu.edu> References: <1249587164-14080-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1250021889-sup-3224@masanjin.net> Applied, thanks! -- William From wmorgan-sup@masanjin.net Tue Aug 11 16:22:30 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 11 Aug 2009 13:22:30 -0700 Subject: [sup-talk] Stack overflow in regexp matcher In-Reply-To: <92457f310908030116k146a901aleee95a09db907d97@mail.gmail.com> References: <92457f310908030116k146a901aleee95a09db907d97@mail.gmail.com> Message-ID: <1250021966-sup-933@masanjin.net> Hi Mark, Reformatted excerpts from Mark Drayton's message of 2009-08-03: > ## read 440m (about 52%) @ 2.2m/s. 0:03:19 elapsed, about 0:03:03 remaining > Stack overflow in regexp matcher: > /,\s*(?=(?:[^"]*"[^"]*")*(?![^"]*"))/ (RegexpError) Interesting. Looks like Sup is trying to split a header line into multiple email addresses and something's causing it to bomb. Are you able to identify the line that's causing this problem? That would be helpful to know. > This error seems to have cropped up in other software so I suspect > it's a problem with Ruby, not sup. Anyone able to confirm this? It's a problem with Ruby's regular expression implementation, I suppose, but we've never seen it before. The solution is to either tweak the regexp until it starts working, or implement a custom parsing solution, neither of which sounds that entertaining... -- William From wmorgan-sup@masanjin.net Tue Aug 11 16:28:46 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 11 Aug 2009 13:28:46 -0700 Subject: [sup-talk] [PATCH] run-mailcap fix In-Reply-To: <1249226521-sup-4719@localdomain> References: <1249226521-sup-4719@localdomain> Message-ID: <1250022259-sup-8328@masanjin.net> Hi Beno?t, Reformatted excerpts from Beno?t PIERRE's message of 2009-08-02: > The attached patch fix this by not redirecting stderr to /dev/null. > It also restores the correct ncurses state (including arrow > keypresses, thanks to Edward Z. Yang recent patch). Thanks! Not redirecting stderr to /dev/null is probably fine. But how about calling BufferManager.shell_out instead? If you want to submit a proper git commit via git-format-email, I will be happy to apply it and you can get your name in the illustrious Sup contributor roster. Otherwise I will make this change for you. -- William From benoit.pierre@gmail.com Tue Aug 11 18:09:40 2009 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt=20PIERRE?=) Date: Wed, 12 Aug 2009 00:09:40 +0200 Subject: [sup-talk] [PATCH run-mailcap 1/2] Don't redirect stderr to /dev/null when calling run-mailcap. In-Reply-To: <1250022259-sup-8328@masanjin.net> References: <1250022259-sup-8328@masanjin.net> Message-ID: <1250028581-15826-1-git-send-email-benoit.pierre@gmail.com> Some programs will fail to work correctly if this is done, like for example: w3m --dump, to view HTML files. --- lib/sup/message-chunks.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb index 0d742d9..4c947e1 100644 --- a/lib/sup/message-chunks.rb +++ b/lib/sup/message-chunks.rb @@ -131,7 +131,7 @@ 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}' 2>/dev/null" + cmd = "/usr/bin/run-mailcap --action=view '#{@content_type}:#{path}'" Redwood::log "running: #{cmd.inspect}" system cmd $? == 0 -- 1.6.3.3 From benoit.pierre@gmail.com Tue Aug 11 18:09:41 2009 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt=20PIERRE?=) Date: Wed, 12 Aug 2009 00:09:41 +0200 Subject: [sup-talk] [PATCH run-mailcap 2/2] Use BufferManager.shell_out to call run-mailcap instead of system. In-Reply-To: <1250028581-15826-1-git-send-email-benoit.pierre@gmail.com> References: <1250028581-15826-1-git-send-email-benoit.pierre@gmail.com> Message-ID: <1250028581-15826-2-git-send-email-benoit.pierre@gmail.com> This ensure ncurses state is correctly restored upon command completion. --- lib/sup/message-chunks.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb index 4c947e1..1910abd 100644 --- a/lib/sup/message-chunks.rb +++ b/lib/sup/message-chunks.rb @@ -133,7 +133,7 @@ EOS def view_default! path cmd = "/usr/bin/run-mailcap --action=view '#{@content_type}:#{path}'" Redwood::log "running: #{cmd.inspect}" - system cmd + BufferManager.shell_out(cmd) $? == 0 end -- 1.6.3.3 From rlane@club.cc.cmu.edu Wed Aug 12 01:26:53 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 12 Aug 2009 01:26:53 -0400 Subject: [sup-talk] some internal api refactors In-Reply-To: <1250021119-sup-4253@masanjin.net> References: <1250021119-sup-4253@masanjin.net> Message-ID: <1250054282-sup-9053@pion.club.cc.cmu.edu> It's worth noting that update_message_state needs to handle modified refs and snippets as well as labels. Maybe add a comment about this in BaseIndex? From mark@markdrayton.info Wed Aug 12 04:45:01 2009 From: mark@markdrayton.info (Mark Drayton) Date: Wed, 12 Aug 2009 09:45:01 +0100 Subject: [sup-talk] Stack overflow in regexp matcher In-Reply-To: <1250021966-sup-933@masanjin.net> References: <92457f310908030116k146a901aleee95a09db907d97@mail.gmail.com> <1250021966-sup-933@masanjin.net> Message-ID: <92457f310908120145n453d6639mf22fe68b62054392@mail.gmail.com> Hi William On Tue, Aug 11, 2009 at 9:22 PM, William Morgan wrote: > Interesting. Looks like Sup is trying to split a header line into > multiple email addresses and something's causing it to bomb. Are you > able to identify the line that's causing this problem? That would be > helpful to know. Sorry, I should have dug a bit deeper before reporting this. I was naively assuming it was a known problem (though Google didn't know, so I guess it's not) and that the answer would be "upgrade foo". The line it's choking on is 284058 bytes long and contains ~6400 addresses. (gotta love mail from "internal communications"). If I halve the number of addresses it works, so perhaps this isn't worth fixing at all. If you do want to tackle it I'm happy to help off-list. Cheers, Mark From ingmar@exherbo.org Wed Aug 12 09:05:35 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Wed, 12 Aug 2009 15:05:35 +0200 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1249056691-sup-9011@pion.club.cc.cmu.edu> References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> <20090723102325.GA4291@chistera.yi.org> <1248497184-sup-939@pion.club.cc.cmu.edu> <1248513425-sup-2484@chistera.yi.org> <1248550384-sup-74@pion.club.cc.cmu.edu> <1248709681-sup-4141@entry> <1248710432-sup-1734@pion.club.cc.cmu.edu> <1249056691-sup-9011@pion.club.cc.cmu.edu> Message-ID: <1250082297-sup-6018@cannonball> Excerpts from Rich Lane's message of Fri Jul 31 18:20:41 +0200 2009: > Excerpts from Rich Lane's message of Mon Jul 27 13:06:34 -0400 2009: > > Excerpts from William Morgan's message of Mon Jul 27 11:48:38 -0400 2009: > > > Reformatted excerpts from Rich Lane's message of 2009-07-25: > > > > One issue I've noticed is that removing labels from messages doesn't > > > > always immediately work. > > > > > > Is this true even after you sync changes to the index? What about if you > > > reload the label list buffer? ('@') > > > > Yes. This is looking like a Xapian bug - I've reproduced it without any > > Sup code. I'm working on a fix. > > I've fixed this, it should be released in Xapian 1.0.15. Or, grab Xapian > SVN and you can try out the Chert backend too (XAPIAN_PREFER_CHERT=1). Could you point me to the SVN revision containing the fix? I'd like to backport the fix to my Xapian 1.0.14 packages, pending 1.0.15 release. Thanks! -- Exherbo KDE, X.org maintainer From nicolas.pouillard@gmail.com Wed Aug 12 10:32:04 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Wed, 12 Aug 2009 16:32:04 +0200 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1250082297-sup-6018@cannonball> References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> <20090723102325.GA4291@chistera.yi.org> <1248497184-sup-939@pion.club.cc.cmu.edu> <1248513425-sup-2484@chistera.yi.org> <1248550384-sup-74@pion.club.cc.cmu.edu> <1248709681-sup-4141@entry> <1248710432-sup-1734@pion.club.cc.cmu.edu> <1249056691-sup-9011@pion.club.cc.cmu.edu> <1250082297-sup-6018@cannonball> Message-ID: <1250087467-sup-6888@ausone.inria.fr> Excerpts from Ingmar Vanhassel's message of Wed Aug 12 15:05:35 +0200 2009: > Excerpts from Rich Lane's message of Fri Jul 31 18:20:41 +0200 2009: > > Excerpts from Rich Lane's message of Mon Jul 27 13:06:34 -0400 2009: > > > Excerpts from William Morgan's message of Mon Jul 27 11:48:38 -0400 2009: > > > > Reformatted excerpts from Rich Lane's message of 2009-07-25: > > > > > One issue I've noticed is that removing labels from messages doesn't > > > > > always immediately work. > > > > > > > > Is this true even after you sync changes to the index? What about if you > > > > reload the label list buffer? ('@') > > > > > > Yes. This is looking like a Xapian bug - I've reproduced it without any > > > Sup code. I'm working on a fix. > > > > I've fixed this, it should be released in Xapian 1.0.15. Or, grab Xapian > > SVN and you can try out the Chert backend too (XAPIAN_PREFER_CHERT=1). BTW, does someone have successfully built Xapian under Mac OS X ? -- Nicolas Pouillard http://nicolaspouillard.fr From taruti@taruti.net Thu Aug 13 03:32:02 2009 From: taruti@taruti.net (Taru Karttunen) Date: Thu, 13 Aug 2009 10:32:02 +0300 Subject: [sup-talk] Sup crashing Message-ID: <1250148617-sup-6053@oz.taruti.net> Hello I am using Sup git master version and it started to crash today when viewing messages with a label. Any hints how to fix this? --- ArgumentError from thread: load threads for thread-index-mode :93349 is out of range [0..93204] for IndexReader#[] /usr/lib/ruby/1.8/ferret/index.rb:421:in `[]' /usr/lib/ruby/1.8/ferret/index.rb:421:in `[]' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib/ruby/1.8/ferret/index.rb:413:in `[]' ./lib/sup/ferret_index.rb:151:in `each_id_by_date' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' ./lib/sup/ferret_index.rb:151:in `each_id_by_date' ./lib/sup/ferret_index.rb:150:in `each' ./lib/sup/ferret_index.rb:150:in `each_id_by_date' ./lib/sup/thread.rb:328:in `load_n_threads' ./lib/sup/modes/thread-index-mode.rb:623:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' ./lib/sup/modes/thread-index-mode.rb:607: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:606:in `load_n_threads_background' ./lib/sup/modes/thread-index-mode.rb:676:in `__unprotected_load_threads' (eval):12:in `load_threads' ./lib/sup/modes/label-search-results-mode.rb:33:in `spawn_nicely' ./lib/sup/modes/label-list-mode.rb:93:in `select_label' ./lib/sup/mode.rb:50:in `send' ./lib/sup/mode.rb:50:in `handle_input' ./lib/sup/buffer.rb:249:in `handle_input' bin/sup:236 - Taru Karttunen From rlane@club.cc.cmu.edu Fri Aug 14 01:23:21 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Fri, 14 Aug 2009 01:23:21 -0400 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1250082297-sup-6018@cannonball> References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> <20090723102325.GA4291@chistera.yi.org> <1248497184-sup-939@pion.club.cc.cmu.edu> <1248513425-sup-2484@chistera.yi.org> <1248550384-sup-74@pion.club.cc.cmu.edu> <1248709681-sup-4141@entry> <1248710432-sup-1734@pion.club.cc.cmu.edu> <1249056691-sup-9011@pion.club.cc.cmu.edu> <1250082297-sup-6018@cannonball> Message-ID: <1250227281-sup-8626@pion.club.cc.cmu.edu> Excerpts from Ingmar Vanhassel's message of Wed Aug 12 09:05:35 -0400 2009: > Could you point me to the SVN revision containing the fix? I'd like to > backport the fix to my Xapian 1.0.14 packages, pending 1.0.15 release. Revision 13219. From guillaume.quintard@gmail.com Fri Aug 14 06:18:25 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Fri, 14 Aug 2009 12:18:25 +0200 Subject: [sup-talk] Poll delay and states not really saved Message-ID: <1250244850-sup-5869@altis> Hi, Two things: - I'm using xapian (git) and it seems that staates are only saved during exits. Meaning that if I clean my inbox with A, then save with $, and then refresh with @., all the messages are still here (as read, though). - Can we have a config options for the time between poll, currently it's hardcoded to 300s but I like to hammer my gmail box with requests. Apart from that, sup works pretty well with xapian. Cheers, -- Guillaume From ingmar@exherbo.org Fri Aug 14 07:12:04 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Fri, 14 Aug 2009 13:12:04 +0200 Subject: [sup-talk] Poll delay and states not really saved In-Reply-To: <1250244850-sup-5869@altis> References: <1250244850-sup-5869@altis> Message-ID: <1250248287-sup-2973@cannonball> Excerpts from Guillaume Quintard's message of Fri Aug 14 12:18:25 +0200 2009: > Hi, > Two things: > - I'm using xapian (git) and it seems that staates are only saved during > exits. Meaning that if I clean my inbox with A, then save with $, and > then refresh with @., all the messages are still here (as read, though). > > - Can we have a config options for the time between poll, currently it's > hardcoded to 300s but I like to hammer my gmail box with requests. > > Apart from that, sup works pretty well with xapian. > > Cheers, > See http://mid.gmane.org/1248710432-sup-1734 at pion.club.cc.cmu.edu -- Exherbo KDE, X.org maintainer From guillaume.quintard@gmail.com Fri Aug 14 07:18:44 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Fri, 14 Aug 2009 13:18:44 +0200 Subject: [sup-talk] Poll delay and states not really saved In-Reply-To: <1250248287-sup-2973@cannonball> References: <1250244850-sup-5869@altis> <1250248287-sup-2973@cannonball> Message-ID: <1250248660-sup-2819@altis> Excerpts from Ingmar Vanhassel's message of Fri Aug 14 13:12:04 +0200 2009: > See http://mid.gmane.org/1248710432-sup-1734 at pion.club.cc.cmu.edu > ah thanks, didn't remember that mail. but the poll delay still stands :-) -- Guillaume From wmorgan-sup@masanjin.net Fri Aug 14 16:17:38 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 14 Aug 2009 13:17:38 -0700 Subject: [sup-talk] [PATCH run-mailcap 2/2] Use BufferManager.shell_out to call run-mailcap instead of system. In-Reply-To: <1250028581-15826-2-git-send-email-benoit.pierre@gmail.com> References: <1250022259-sup-8328@masanjin.net> <1250028581-15826-2-git-send-email-benoit.pierre@gmail.com> Message-ID: <1250281039-sup-2788@masanjin.net> Reformatted excerpts from Beno?t PIERRE's message of 2009-08-11: > This ensure ncurses state is correctly restored upon command completion. Both patches applies to branch run-mailcap-fixes, merged into next. Thanks! -- William From wmorgan-sup@masanjin.net Fri Aug 14 16:20:28 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 14 Aug 2009 13:20:28 -0700 Subject: [sup-talk] Sup crashing In-Reply-To: <1250148617-sup-6053@oz.taruti.net> References: <1250148617-sup-6053@oz.taruti.net> Message-ID: <1250281208-sup-4199@masanjin.net> Reformatted excerpts from Taru Karttunen's message of 2009-08-13: > --- ArgumentError from thread: load threads for thread-index-mode > :93349 is out of range [0..93204] for IndexReader#[] Weird. Does sup-sync --optimize fix anything? -- William From benoit.pierre@gmail.com Fri Aug 14 18:37:21 2009 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=) Date: Sat, 15 Aug 2009 00:37:21 +0200 Subject: [sup-talk] [PATCH run-mailcap 2/2] Use BufferManager.shell_out to call run-mailcap instead of system. In-Reply-To: <1250281039-sup-2788@masanjin.net> References: <1250022259-sup-8328@masanjin.net> <1250028581-15826-2-git-send-email-benoit.pierre@gmail.com> <1250281039-sup-2788@masanjin.net> Message-ID: <1250289386-sup-7331@localdomain> Excerpts from William Morgan's message of Fri Aug 14 22:17:38 +0200 2009: > Reformatted excerpts from Beno?t PIERRE's message of 2009-08-11: > > This ensure ncurses state is correctly restored upon command completion. > > Both patches applies to branch run-mailcap-fixes, merged into next. Great! One problem though, I tested next, and 3478e400ae31b459b2875cc226796a6d4bba11f9 (rewrap getch in select, handle sigwinch manually) introduced a regression: I get some 'key not handled' errors after run-mail has been called when sup is getting back control if I press for example an arrow... ;( Arrows become usable again after I press a "normal" key (like 'a'). Cheers, -- A: Because it destroys the flow of conversation. Q: Why is top posting dumb? From benoit.pierre@gmail.com Fri Aug 14 19:08:48 2009 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=) Date: Sat, 15 Aug 2009 01:08:48 +0200 Subject: [sup-talk] [PATCH] Restore keypad mode after we force ncurses to refresh the whole screen. In-Reply-To: <1250289386-sup-7331@localdomain> References: <1250022259-sup-8328@masanjin.net> <1250028581-15826-2-git-send-email-benoit.pierre@gmail.com> <1250281039-sup-2788@masanjin.net> <1250289386-sup-7331@localdomain> Message-ID: <1250291137-sup-2796@localdomain> This also happen to fix a regression after a call to run-mailcap, since for some reason a screen resize event is triggered when we get control back... --- lib/sup/buffer.rb | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/lib/sup/buffer.rb b/lib/sup/buffer.rb index b3a256f..09281e9 100644 --- a/lib/sup/buffer.rb +++ b/lib/sup/buffer.rb @@ -270,6 +270,7 @@ EOS ## this magic makes Ncurses get the new size of the screen Ncurses.endwin + Ncurses.stdscr.keypad 1 Ncurses.refresh @sigwinch_mutex.synchronize { @sigwinch_happened = false } Redwood::log "new screen size is #{Ncurses.rows} x #{Ncurses.cols}" -- 1.6.3.3 -- 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 cworth@cworth.org Sat Aug 15 00:05:32 2009 From: cworth@cworth.org (Carl Worth) Date: Fri, 14 Aug 2009 21:05:32 -0700 Subject: [sup-talk] Introduction, thanks, and a tiny patch Message-ID: <1250307036-sup-8890@yoom> Hi. My name's Carl, and I've uh, been collecting email for 12 years. First off, I want to thank William and all contributors for sup! I just started using it this morning, and I'm amazed by it. I've long been frustrated by wrong-headed email systems, and also long been dreaming of one done right, (entirely label-and-search-based and focused on threads as the primary unit, bonus points if the UI is 100% keyboard-driven and integrates with emacs). What a dream come true to find sup! In my first use of sup, I was surprised by two things immediately: 1. Most text is white-on-white (invisible) if the default terminal background color is white. I would suggest that the default background color be changed from "default" to "black" to avoid this trap. 2. All of the mail I imported from various maildir folders was labelled as "unread", (in spite of the fact that a large majority of it had the 'S' tag for "seen" in the maildir filename). I tracked this down to my maildir filenames containing ',' characters to the left of the ':' like so: 1250158845.M979457P4354V000000000000FE01I001B8B56_0.yoom,S=46114:2,S I've attached a patch to fix this second issue, (a single-character change). As for my involvement with sup, here are a couple of things I'd like to help with: 1. I love the NewUserGuide, but I've needed a ReferenceManual for various issues already, (configuring colors, configuring SMTP, understanding the sources.yaml file well enough to be able to re-process mail that was mis-labelled the first time, etc.). The wiki has been useful for much of this already, but I'd like to have some of this information more cleanly organized, and perhaps distributed as plain-text in alongside the user guide. So I'd like to try pulling some existing information together, organizing things, and also identifying missing sections. One potential issue is that I don't see any explicit license terms on the wiki. Can I assume that any text on the wiki is suitable for putting into a document to be contributed to and distributed with sup? 2. I really like the ideas William has posted on his blog about separating the interface from the guts of sup, (to make the new STS). I'd be happy to help with that as well if possible. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-maildir-Allow-in-the-unique-name-portion-of-a-maildi.patch Type: application/octet-stream Size: 1097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: not available URL: From igor.brkic@fer.hr Sat Aug 15 06:18:33 2009 From: igor.brkic@fer.hr (Igor Brkic) Date: Sat, 15 Aug 2009 12:18:33 +0200 Subject: [sup-talk] Introduction, thanks, and a small patch In-Reply-To: <20090815041446.GA1249@yoom.home.cworth.org> References: <20090815041446.GA1249@yoom.home.cworth.org> Message-ID: <1250331013-sup-3083@xps> Excerpts from Carl Worth's message of Sub Kol 15 06:14:46 +0200 2009: > PS. I'm sending this message from mutt since sup crashed when I tried > to send the message (see exception output below). I think this is one Hi Carl! I had same problem with sup. Sup actually manages to send message before crashing and then it crashes when indexing sent messages. Solution that worked for me is to comment out line "Time.parse time, 0" in mbox.rb file. This is not good solution, more like a hack, but for some reason it works for me. Try it out. I tried to find out why this is happening, but I'm not so familiar with sup internals (and not so good in ruby too) and didn't come to any conclusion. Igor From marco-oweber@gmx.de Sat Aug 15 07:03:00 2009 From: marco-oweber@gmx.de (Marc Weber) Date: Sat, 15 Aug 2009 13:03:00 +0200 Subject: [sup-talk] Introduction, thanks, and a small patch In-Reply-To: <20090815041446.GA1249@yoom.home.cworth.org> References: <20090815041446.GA1249@yoom.home.cworth.org> Message-ID: <1250334013-sup-3733@nixos> > 1. Most text is white-on-white (invisible) if the default terminal > background color is white. I would suggest that the default > background color be changed from "default" to "black" to avoid > this trap. The bg colour is set to black somewhere but for some reason it doesn't work here. I've switched my terminal bg colour to light green so that I can still read all text. It's a little bit annoying though. So if you can tell me how to make sup background black I'd be happy. I haven't taken the time yet to investigate the issue. Sincerly Marc Weber From cworth@cworth.org Sat Aug 15 10:35:02 2009 From: cworth@cworth.org (Carl Worth) Date: Sat, 15 Aug 2009 07:35:02 -0700 Subject: [sup-talk] Introduction, thanks, and a small patch In-Reply-To: <1250331013-sup-3083@xps> References: <20090815041446.GA1249@yoom.home.cworth.org> <1250331013-sup-3083@xps> Message-ID: <1250346449-sup-6703@yoom> Excerpts from Igor Brkic's message of Sat Aug 15 03:18:33 -0700 2009: > Hi Carl! Hi Igor! > I had same problem with sup. Sup actually manages to send message before > crashing and then it crashes when indexing sent messages. Ah, yes. I did notice afterwards that my original message did make it to the list. So sorry for all the noise, (though my first send of the patch did have some debug junk in it, so I suppose it's good I sent a cleaner version). > Solution that worked for me is to comment out line "Time.parse time, 0" > in mbox.rb file. This is not good solution, more like a hack, but for > some reason it works for me. Try it out. Thanks. I gave this a try, but it didn't work for me. I'm also not much for debugging ruby so I haven't made much progress here yet. (Is there anything like gdb for ruby? If I could just march up the stack and more easily find where m.date should be initialized to non-nil then that might help). But thanks for describing the bug more accurately for mo. At least knowing that the crash is happening while indexing ~/.sup/sent.mb I was able to just move that out of the way for now, so I can at least run sup again. And actually, this brings up another point for that missing reference manual. How can I configure sup to deliver sent messages to a maildir instead of an mbox? (I'd prefer that anyway, and it just might workaround this bug.) Thanks for the warm welcome, -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Sat Aug 15 10:41:51 2009 From: cworth@cworth.org (Carl Worth) Date: Sat, 15 Aug 2009 07:41:51 -0700 Subject: [sup-talk] Introduction, thanks, and a small patch In-Reply-To: <1250334013-sup-3733@nixos> References: <20090815041446.GA1249@yoom.home.cworth.org> <1250334013-sup-3733@nixos> Message-ID: <1250346921-sup-8888@yoom> Excerpts from Marc Weber's message of Sat Aug 15 04:03:00 -0700 2009: > The bg colour is set to black somewhere but for some reason it doesn't > work here. I've switched my terminal bg colour to light green so that I > can still read all text. It's a little bit annoying though. So if you > can tell me how to make sup background black I'd be happy. > > I haven't taken the time yet to investigate the issue. I did my color configuration according to the following page: http://sup.rubyforge.org/wiki/wiki.pl?CustomizingColors That provides this very useful command which reads all the default color settings and puts them into a configuration file that you can easily edit: ruby -rubygems -rsup -e 'print Redwood::Colormap::DEFAULT_COLORS.to_yaml' > ~/.sup/colors.yaml You know, I don't think it would be a crazy idea for sup to automatically dump that there on its first run. Or perhaps better, sup-config could do it, (and could even ask if the user would prefer a black-on-white or a white-on-black default color scheme). -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rlane@club.cc.cmu.edu Sun Aug 16 15:35:30 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 16 Aug 2009 12:35:30 -0700 Subject: [sup-talk] [PATCH 1/2] move all GDBM data into Xapian Message-ID: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu> Keeping everything in Xapian means much better consistency in case of a crash. Thread killing is now supported. --- lib/sup/xapian_index.rb | 177 +++++++++++++++++++++++++++++------------------ 1 files changed, 110 insertions(+), 67 deletions(-) diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index 861c2a3..825e7a3 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -1,5 +1,4 @@ require 'xapian' -require 'gdbm' require 'set' module Redwood @@ -23,12 +22,6 @@ class XapianIndex < BaseIndex end def load_index - @entries = MarshalledGDBM.new File.join(@dir, "entries.db") - @docids = MarshalledGDBM.new File.join(@dir, "docids.db") - @thread_members = MarshalledGDBM.new File.join(@dir, "thread_members.db") - @thread_ids = MarshalledGDBM.new File.join(@dir, "thread_ids.db") - @assigned_docids = GDBM.new File.join(@dir, "assigned_docids.db") - @xapian = Xapian::WritableDatabase.new(File.join(@dir, "xapian"), Xapian::DB_CREATE_OR_OPEN) @term_generator = Xapian::TermGenerator.new() @term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE) @@ -48,19 +41,19 @@ class XapianIndex < BaseIndex end def contains_id? id - synchronize { @entries.member? id } + synchronize { find_docid(id) && true } end def source_for_id id - synchronize { @entries[id][:source_id] } + synchronize { get_entry(id)[:source_id] } end def delete id - synchronize { @xapian.delete_document @docids[id] } + synchronize { @xapian.delete_document mkterm(:msgid, id) } end def build_message id - entry = synchronize { @entries[id] } + entry = synchronize { get_entry id } return unless entry source = SourceManager[entry[:source_id]] @@ -88,7 +81,7 @@ class XapianIndex < BaseIndex end def sync_message m, opts={} - entry = synchronize { @entries[m.id] } + entry = synchronize { get_entry m.id } snippet = m.snippet entry ||= {} labels = m.labels @@ -113,9 +106,7 @@ class XapianIndex < BaseIndex m.labels.each { |l| LabelManager << l } synchronize do - index_message m, opts - union_threads([m.id] + m.refs + m.replytos) - @entries[m.id] = d + index_message m, d, opts end true end @@ -147,8 +138,26 @@ class XapianIndex < BaseIndex def each_message_in_thread_for m, opts={} # TODO thread by subject # TODO handle killed threads - ids = synchronize { @thread_members[@thread_ids[m.id]] } || [] - ids.select { |id| contains_id? id }.each { |id| yield id, lambda { build_message id } } + return unless doc = find_doc(m.id) + queue = doc.value(THREAD_VALUENO).split(',') + msgids = [m.id] + seen_threads = Set.new + seen_messages = Set.new [m.id] + while not queue.empty? + thread_id = queue.pop + next if seen_threads.member? thread_id + return false if thread_killed? thread_id + seen_threads << thread_id + docs = term_docids(mkterm(:thread, thread_id)).map { |x| @xapian.document x } + docs.each do |doc| + msgid = doc.value MSGID_VALUENO + next if seen_messages.member? msgid + msgids << msgid + seen_messages << msgid + queue.concat doc.value(THREAD_VALUENO).split(',') + end + end + msgids.each { |id| yield id, lambda { build_message id } } true end @@ -297,11 +306,16 @@ class XapianIndex < BaseIndex 'label' => 'L', 'source_id' => 'I', 'attachment_extension' => 'O', + 'msgid' => 'Q', + 'thread' => 'H', + 'ref' => 'R', } PREFIX = NORMAL_PREFIX.merge BOOLEAN_PREFIX - DATE_VALUENO = 0 + MSGID_VALUENO = 0 + THREAD_VALUENO = 1 + DATE_VALUENO = 2 MAX_TERM_LENGTH = 245 @@ -317,14 +331,48 @@ class XapianIndex < BaseIndex def assign_docid m, truncated_date t = (truncated_date.to_i - MIDDLE_DATE.to_i).to_f docid = (DOCID_SCALE - DOCID_SCALE/(Math::E**(-(t/TIME_SCALE)) + 1)).to_i + while docid > 0 and docid_exists? docid + docid -= 1 + end + docid > 0 ? docid : nil + end + + # XXX is there a better way? + def docid_exists? docid begin - while @assigned_docids.member? [docid].pack("N") - docid -= 1 - end - rescue + @xapian.doclength docid + true + rescue RuntimeError #Xapian::DocNotFoundError + raise unless $!.message =~ /DocNotFoundError/ + false end - @assigned_docids[[docid].pack("N")] = '' - docid + end + + def term_docids term + @xapian.postlist(term).map { |x| x.docid } + end + + def find_docid id + term_docids(mkterm(:msgid,id)).tap { |x| fail unless x.size <= 1 }.first + end + + def find_doc id + return unless docid = find_docid(id) + @xapian.document docid + end + + def get_id docid + return unless doc = @xapian.document(docid) + doc.value MSGID_VALUENO + end + + def get_entry id + return unless doc = find_doc(id) + Marshal.load doc.data + end + + def thread_killed? thread_id + not run_query(Q.new(Q::OP_AND, mkterm(:thread, thread_id), mkterm(:label, :Killed)), 0, 1).empty? end def synchronize &b @@ -340,7 +388,7 @@ class XapianIndex < BaseIndex def run_query_ids xapian_query, offset, limit matchset = run_query xapian_query, offset, limit - matchset.matches.map { |r| r.document.data } + matchset.matches.map { |r| r.document.value MSGID_VALUENO } end Q = Xapian::Query @@ -371,7 +419,7 @@ class XapianIndex < BaseIndex end end - def index_message m, opts + def index_message m, entry, opts terms = [] text = [] @@ -394,6 +442,7 @@ class XapianIndex < BaseIndex terms << mkterm(:date,m.date) if m.date m.labels.each { |t| terms << mkterm(:label,t) } terms << mkterm(:type, 'mail') + terms << mkterm(:msgid, m.id) terms << mkterm(:source_id, m.source.id) m.attachments.each do |a| a =~ /\.(\w+)$/ or next @@ -401,6 +450,23 @@ class XapianIndex < BaseIndex terms << t end + ## Thread membership + children = term_docids(mkterm(:ref, m.id)).map { |docid| @xapian.document docid } + parent_ids = m.refs + m.replytos + parents = parent_ids.map { |id| find_doc id }.compact + thread_members = SavingHash.new { [] } + (children + parents).each do |doc2| + thread_ids = doc2.value(THREAD_VALUENO).split ',' + thread_ids.each { |thread_id| thread_members[thread_id] << doc2 } + end + + thread_ids = thread_members.empty? ? [m.id] : thread_members.keys + + thread_ids.each { |thread_id| terms << mkterm(:thread, thread_id) } + parent_ids.each do |ref| + terms << mkterm(:ref, ref) + end + # Full text search content text << [subject_text, PREFIX['subject']] text << [subject_text, PREFIX['body']] @@ -424,17 +490,29 @@ class XapianIndex < BaseIndex Xapian.sortable_serialise 0 end - doc = Xapian::Document.new - docid = @docids[m.id] || assign_docid(m, truncated_date) + docid = nil + unless doc = find_doc(m.id) + doc = Xapian::Document.new + if not docid = assign_docid(m, truncated_date) + # Could be triggered by spam + Redwood::log "warning: docid underflow, dropping #{m.id.inspect}" + return + end + else + doc.clear_terms + doc.clear_values + docid = doc.docid + end @term_generator.document = doc text.each { |text,prefix| @term_generator.index_text text, 1, prefix } terms.each { |term| doc.add_term term if term.length <= MAX_TERM_LENGTH } + doc.add_value MSGID_VALUENO, m.id + doc.add_value THREAD_VALUENO, (thread_ids * ',') doc.add_value DATE_VALUENO, date_value - doc.data = m.id + doc.data = Marshal.dump entry @xapian.replace_document docid, doc - @docids[m.id] = docid end # Construct a Xapian term @@ -457,48 +535,13 @@ class XapianIndex < BaseIndex PREFIX['source_id'] + args[0].to_s.downcase when :attachment_extension PREFIX['attachment_extension'] + args[0].to_s.downcase + when :msgid, :ref, :thread + PREFIX[type.to_s] + args[0][0...(MAX_TERM_LENGTH-1)] else raise "Invalid term type #{type}" end end - # Join all the given message-ids into a single thread - def union_threads ids - seen_threads = Set.new - related = Set.new - - # Get all the ids that will be in the new thread - ids.each do |id| - related << id - thread_id = @thread_ids[id] - if thread_id && !seen_threads.member?(thread_id) - thread_members = @thread_members[thread_id] - related.merge thread_members - seen_threads << thread_id - end - end - - # Pick a leader and move all the others to its thread - a = related.to_a - best, *rest = a.sort_by { |x| x.hash } - @thread_members[best] = a - @thread_ids[best] = best - rest.each do |x| - @thread_members.delete x - @thread_ids[x] = best - end - end end end - -class MarshalledGDBM < GDBM - def []= k, v - super k, Marshal.dump(v) - end - - def [] k - v = super k - v ? Marshal.load(v) : nil - end -end -- 1.6.4 From rlane@club.cc.cmu.edu Sun Aug 16 15:35:31 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 16 Aug 2009 12:35:31 -0700 Subject: [sup-talk] [PATCH 2/2] xapian index format versioning In-Reply-To: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu> References: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/xapian_index.rb | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index 825e7a3..c4989e4 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -8,6 +8,7 @@ module Redwood # for searching due to precomputing thread membership. class XapianIndex < BaseIndex STEM_LANGUAGE = "english" + INDEX_VERSION = '1' ## dates are converted to integers for xapian, and are used for document ids, ## so we must ensure they're reasonably valid. this typically only affect @@ -22,7 +23,17 @@ class XapianIndex < BaseIndex end def load_index - @xapian = Xapian::WritableDatabase.new(File.join(@dir, "xapian"), Xapian::DB_CREATE_OR_OPEN) + path = File.join(@dir, 'xapian') + if File.exists? path + @xapian = Xapian::WritableDatabase.new(path, Xapian::DB_OPEN) + db_version = @xapian.get_metadata 'version' + if db_version != INDEX_VERSION + fail "Index version #{db_version.inspect} is different than Sup version #{INDEX_VERSION.inspect}" + end + else + @xapian = Xapian::WritableDatabase.new(path, Xapian::DB_CREATE) + @xapian.set_metadata 'version', INDEX_VERSION + end @term_generator = Xapian::TermGenerator.new() @term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE) @enquire = Xapian::Enquire.new @xapian -- 1.6.4 From rlane@club.cc.cmu.edu Sun Aug 16 15:35:59 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 16 Aug 2009 12:35:59 -0700 Subject: [sup-talk] [PATCH] skip system buffers when rolling Message-ID: <1250451359-16110-1-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/buffer.rb | 16 +++++++++++----- 1 files changed, 11 insertions(+), 5 deletions(-) diff --git a/lib/sup/buffer.rb b/lib/sup/buffer.rb index b3a256f..3fd2fe4 100644 --- a/lib/sup/buffer.rb +++ b/lib/sup/buffer.rb @@ -237,14 +237,20 @@ EOS ## have to change this. but it's not clear that we will ever actually ## do that. def roll_buffers - @buffers.last.force_to_top = false - raise_to_front @buffers.first + bufs = rollable_buffers + bufs.last.force_to_top = false + raise_to_front bufs.first end def roll_buffers_backwards - return unless @buffers.length > 1 - @buffers.last.force_to_top = false - raise_to_front @buffers[@buffers.length - 2] + bufs = rollable_buffers + return unless bufs.length > 1 + bufs.last.force_to_top = false + raise_to_front bufs[bufs.length - 2] + end + + def rollable_buffers + @buffers.select { |b| !b.system? || @buffers.last == b } end def handle_input c -- 1.6.4 From rlane@club.cc.cmu.edu Sun Aug 16 15:36:08 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 16 Aug 2009 12:36:08 -0700 Subject: [sup-talk] [PATCH] add 'I' keybinding to raise Inbox buffer Message-ID: <1250451368-16150-1-git-send-email-rlane@club.cc.cmu.edu> --- bin/sup | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/bin/sup b/bin/sup index a9f0b95..d1eb163 100755 --- a/bin/sup +++ b/bin/sup @@ -78,6 +78,7 @@ global_keymap = Keymap.new do |k| k.add :compose, "Compose new message", 'm', 'c' k.add :nothing, "Do nothing", :ctrl_g k.add :recall_draft, "Edit most recent draft message", 'R' + k.add :show_inbox, "Show the Inbox buffer", 'I' end ## the following magic enables wide characters when used with a ruby @@ -286,6 +287,8 @@ begin b, new = BufferManager.spawn_unless_exists("All drafts") { LabelSearchResultsMode.new [:draft] } b.mode.load_threads :num => b.content_height if new end + when :show_inbox + BufferManager.raise_to_front ibuf when :nothing, InputSequenceAborted when :redraw bm.completely_redraw_screen -- 1.6.4 From dato@net.com.org.es Sun Aug 16 16:01:16 2009 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=) Date: Sun, 16 Aug 2009 21:01:16 +0100 Subject: [sup-talk] [PATCH 2/2] xapian index format versioning In-Reply-To: <1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu> References: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu> <1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <20090816200116.GA17272@chistera.yi.org> + Rich Lane (Sun, 16 Aug 2009 12:35:31 -0700): > + fail "Index version #{db_version.inspect} is different than Sup > version #{INDEX_VERSION.inspect}" The second part of the sentence seems to refer to Sup's version itself, rather than what it really means (the index version expected by the running version of Sup). Maybe the following wording could work better? | This Sup version expects a v#{INDEX_VERSION.inspect} index, whereas | v#{db_version.inspect} is in the filesystem. (And, perhaps, suggesting what to do next would be grea too.) HTH, -- - Are you sure we're good? - Always. -- Rory and Lorelai From rlane@club.cc.cmu.edu Sun Aug 16 16:28:56 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 16 Aug 2009 16:28:56 -0400 Subject: [sup-talk] [PATCH 2/2] xapian index format versioning In-Reply-To: <20090816200116.GA17272@chistera.yi.org> References: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu> <1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu> <20090816200116.GA17272@chistera.yi.org> Message-ID: <1250453934-sup-9651@zyrg.net> --- How's this wording? I've been thinking about a label log that would store every label modification along with the timestamp, etc. This would make the awkward downgrade-dump-upgrade step unnecessary. We could also flush it to disk more often than the full index. lib/sup/xapian_index.rb | 14 +++++++++++++- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index 825e7a3..18b5050 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -8,6 +8,7 @@ module Redwood # for searching due to precomputing thread membership. class XapianIndex < BaseIndex STEM_LANGUAGE = "english" + INDEX_VERSION = '1' ## dates are converted to integers for xapian, and are used for document ids, ## so we must ensure they're reasonably valid. this typically only affect @@ -22,7 +23,18 @@ class XapianIndex < BaseIndex end def load_index - @xapian = Xapian::WritableDatabase.new(File.join(@dir, "xapian"), Xapian::DB_CREATE_OR_OPEN) + path = File.join(@dir, 'xapian') + if File.exists? path + @xapian = Xapian::WritableDatabase.new(path, Xapian::DB_OPEN) + db_version = @xapian.get_metadata 'version' + db_version = '0' if db_version.empty? + if db_version != INDEX_VERSION + fail "This Sup version expects a v#{INDEX_VERSION} index, but you have an existing v#{db_version} index. Please downgrade to your previous version and dump your labels before upgrading to this version (then run sup-sync --restore)." + end + else + @xapian = Xapian::WritableDatabase.new(path, Xapian::DB_CREATE) + @xapian.set_metadata 'version', INDEX_VERSION + end @term_generator = Xapian::TermGenerator.new() @term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE) @enquire = Xapian::Enquire.new @xapian -- 1.6.4 From wmorgan-sup@masanjin.net Sun Aug 16 17:22:56 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 16 Aug 2009 14:22:56 -0700 Subject: [sup-talk] Introduction, thanks, and a small patch In-Reply-To: <1250331013-sup-3083@xps> References: <20090815041446.GA1249@yoom.home.cworth.org> <1250331013-sup-3083@xps> Message-ID: <1250456575-sup-4326@masanjin.net> Reformatted excerpts from Igor Brkic's message of 2009-08-15: > Solution that worked for me is to comment out line "Time.parse time, > 0" in mbox.rb file. This is not good solution, more like a hack, but > for some reason it works for me. Try it out. I've think I've fixed this in master. Thanks for your log; that was helpful. The problem was that Sup was producing the date component of the From_ lines in the sent mail mbox using the current locale, and later on wouldn't necessarily recognize that as a date. (Particularly for people with "funny locales".) You will have to manually edit your ~/.sup/sent.mbox file and change all the From_ line dates that are not in UTC to UTC. If there are just a couple, you should be able to copy and paste from the Date: header a few lines below. Removing the Time.parse line you mention will work, but it has the side effect of potentially splitting mbox files in mid-message. E.g. if you ever have a line of text like "From xxx yyy\n", Sup will consider that a message delimiter. This is fallout from the great mbox From_ line misdesign of 1972. Please let me know if it works for you. -- William From wmorgan-sup@masanjin.net Sun Aug 16 17:38:31 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 16 Aug 2009 14:38:31 -0700 Subject: [sup-talk] Introduction, thanks, and a small patch In-Reply-To: <20090815041446.GA1249@yoom.home.cworth.org> References: <20090815041446.GA1249@yoom.home.cworth.org> Message-ID: <1250457809-sup-6784@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-14: > Hi. My name's Carl, and I've uh, been collecting email for 12 years. Hi Carl! Welcome. > 1. Most text is white-on-white (invisible) if the default terminal > background color is white. I would suggest that the default > background color be changed from "default" to "black" to avoid > this trap. Complaining about the colors already? You're fitting right in around here. We recently changed it from black to default in order to make it work for people with transparent terminals. Since there's clearly not a setting that works for everyone, I think the best solution is your suggestion in a later email: provide a few reasonable color schemes directly in sup-sync. > I've attached a patch to fix this second issue, (a single-character > change). Great, thanks. The patch looks good but I think you left a debugging puts call in there. If you want to resubmit, I will apply this. > I love the NewUserGuide, but I've needed a ReferenceManual for various > issues already, (configuring colors, configuring SMTP, understanding > the sources.yaml file well enough to be able to re-process mail that > was mis-labelled the first time, etc.). Agree. This would be very valuable and is currently a sore spot, IMO. > One potential issue is that I don't see any explicit license terms on > the wiki. Can I assume that any text on the wiki is suitable for > putting into a document to be contributed to and distributed with sup? I think it's fair to assume that anyone contributing to a wiki for an open-source product knows what they're getting into. So, yes. Of course, if anyone objects to their wiki content being distributed as part of Sup (which is currently distributed under GPL v2), please speak now! > I really like the ideas William has posted on his blog about > separating the interface from the guts of sup, (to make the new STS). > I'd be happy to help with that as well if possible. Although it's been over a year of vaporware promises, this is slowly happening. I have a protocol defined and a simple server written. Recent work on replacing Ferret with Xapian has actually been helpful in terms of moving us away from Ferretisms. Expect something "soon". > NoMethodError from thread: main > undefined method `to_indexable_s' for nil:NilClass This should now be fixed in git master; see my previous email in this thread. (You will have to manually edit your sent.mbox a bit.) -- William From wmorgan-sup@masanjin.net Sun Aug 16 17:43:03 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 16 Aug 2009 14:43:03 -0700 Subject: [sup-talk] Stack overflow in regexp matcher In-Reply-To: <92457f310908120145n453d6639mf22fe68b62054392@mail.gmail.com> References: <92457f310908030116k146a901aleee95a09db907d97@mail.gmail.com> <1250021966-sup-933@masanjin.net> <92457f310908120145n453d6639mf22fe68b62054392@mail.gmail.com> Message-ID: <1250458792-sup-9177@masanjin.net> Reformatted excerpts from Mark Drayton's message of 2009-08-12: > The line it's choking on is 284058 bytes long and contains ~6400 > addresses. (gotta love mail from "internal communications"). Wow! > If I halve the number of addresses it works, so perhaps this isn't > worth fixing at all. If you do want to tackle it I'm happy to help > off-list. Well... it's clearly a weird case, but it would be nice to do something besides barf. I suppose we could detect very long lines, emit a warning, and just parse the first few kb. What do you think? -- William From wmorgan-sup@masanjin.net Sun Aug 16 17:44:49 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 16 Aug 2009 14:44:49 -0700 Subject: [sup-talk] some internal api refactors In-Reply-To: <1250054282-sup-9053@pion.club.cc.cmu.edu> References: <1250021119-sup-4253@masanjin.net> <1250054282-sup-9053@pion.club.cc.cmu.edu> Message-ID: <1250459019-sup-6390@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-08-11: > It's worth noting that update_message_state needs to handle modified > refs and snippets as well as labels. Maybe add a comment about this in > BaseIndex? Different snippet, definitely. Good point. Modified refs: I'm tempted to replace this with another API call, since we don't really care about the refs; we just want the index to thread the messages together. Thoughts? -- William From wmorgan-sup@masanjin.net Sun Aug 16 18:00:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 16 Aug 2009 15:00:50 -0700 Subject: [sup-talk] [PATCH] Restore keypad mode after we force ncurses to refresh the whole screen. In-Reply-To: <1250291137-sup-2796@localdomain> References: <1250022259-sup-8328@masanjin.net> <1250028581-15826-2-git-send-email-benoit.pierre@gmail.com> <1250281039-sup-2788@masanjin.net> <1250289386-sup-7331@localdomain> <1250291137-sup-2796@localdomain> Message-ID: <1250460036-sup-9343@masanjin.net> Reformatted excerpts from Beno?t PIERRE's message of 2009-08-14: > This also happen to fix a regression after a call to run-mailcap, > since for some reason a screen resize event is triggered when we get > control back... Applied to ncurses-fixes, merged into next. Thanks! -- William From kevinr@free-dissociation.com Sun Aug 16 17:47:09 2009 From: kevinr@free-dissociation.com (Kevin Riggle) Date: Sun, 16 Aug 2009 17:47:09 -0400 Subject: [sup-talk] [PATCH] Add an after-add-message hook Message-ID: <1250459229-4500-1-git-send-email-kevinr@free-dissociation.com> From: Kevin Riggle I want to do some unrelated processing on each message I receive, but I don't want to block the message being added to the index. This patch adds a hook which runs /after/ the message is added to the index. --- lib/sup/poll.rb | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb index 8a9d218..e4b7e02 100644 --- a/lib/sup/poll.rb +++ b/lib/sup/poll.rb @@ -11,6 +11,12 @@ Variables: message: the new message EOS + HookManager.register "after-add-message", < m_new end rescue SourceError => e Redwood::log "problem getting messages from #{source}: #{e.message}" -- 1.6.0.4 From rlane@club.cc.cmu.edu Sun Aug 16 18:49:24 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 16 Aug 2009 18:49:24 -0400 Subject: [sup-talk] some internal api refactors In-Reply-To: <1250459019-sup-6390@masanjin.net> References: <1250021119-sup-4253@masanjin.net> <1250054282-sup-9053@pion.club.cc.cmu.edu> <1250459019-sup-6390@masanjin.net> Message-ID: <1250461358-sup-7209@zyrg.net> Excerpts from William Morgan's message of Sun Aug 16 17:44:49 -0400 2009: > Reformatted excerpts from Rich Lane's message of 2009-08-11: > > It's worth noting that update_message_state needs to handle modified > > refs and snippets as well as labels. Maybe add a comment about this in > > BaseIndex? > > Different snippet, definitely. Good point. Modified refs: I'm tempted to > replace this with another API call, since we don't really care about the > refs; we just want the index to thread the messages together. Thoughts? The ThreadSet still needs the ref to do the UI-level threading, right? Making it another API call is good as long as that's still taken care of. From igor.brkic@fer.hr Sun Aug 16 19:18:22 2009 From: igor.brkic@fer.hr (Igor Brkic) Date: Mon, 17 Aug 2009 01:18:22 +0200 Subject: [sup-talk] Introduction, thanks, and a small patch In-Reply-To: <1250456575-sup-4326@masanjin.net> References: <20090815041446.GA1249@yoom.home.cworth.org> <1250331013-sup-3083@xps> <1250456575-sup-4326@masanjin.net> Message-ID: <1250464611-sup-5505@xps> Excerpts from William Morgan's message of Sun Aug 16 23:22:56 +0200 2009: > I've think I've fixed this in master. Thanks for your log; that was > helpful. The problem was that Sup was producing the date component of > the From_ lines in the sent mail mbox using the current locale, and > later on wouldn't necessarily recognize that as a date. (Particularly > for people with "funny locales".) > > ... > > Please let me know if it works for you. I've made changes and for now it works like a charm. Thanks! Igor From rlane@club.cc.cmu.edu Mon Aug 17 02:38:43 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 16 Aug 2009 23:38:43 -0700 Subject: [sup-talk] [PATCH] index log Message-ID: <1250491123-19240-1-git-send-email-rlane@club.cc.cmu.edu> Add a YAML logfile that records changes to the index and modify sup-dump to use this rather than the normal database. The log is index format/version agnostic so that users can switch between incompatible Sup versions without running sup-dump first. This should also make automated backups easier. --- bin/sup-dump | 19 +++++++++++++------ lib/sup/ferret_index.rb | 7 +++++++ lib/sup/index.rb | 22 ++++++++++++++++++++++ lib/sup/xapian_index.rb | 7 ++++++- lib/sup/yaml_log.rb | 25 +++++++++++++++++++++++++ 5 files changed, 73 insertions(+), 7 deletions(-) create mode 100644 lib/sup/yaml_log.rb diff --git a/bin/sup-dump b/bin/sup-dump index ba36b21..531a30a 100755 --- a/bin/sup-dump +++ b/bin/sup-dump @@ -2,7 +2,8 @@ require 'rubygems' require 'trollop' -require "sup" +require 'sup' # Redwood::VERSION, Redwood::BASE_DIR +require "sup/yaml_log" $opts = Trollop::options do version "sup-dump (sup #{Redwood::VERSION})" @@ -21,10 +22,16 @@ No options. EOS end -index = Redwood::Index.new -Redwood::SourceManager.new -index.load +labels = {} -index.each_message :load_spam => true, :load_deleted => true, :load_killed => true do |m| - puts "#{m.id} (#{m.labels * ' '})" +Redwood::log "processing index log" +index_log = YamlLogReader.new File.join(Redwood::BASE_DIR, 'index_log.yaml') +index_log.each do |h| + case h['type'] + when 'add_message', 'update_message_state' + labels[h['id']] = h['labels'] + end end + +Redwood::log "dumping labels" +labels.each { |msgid,labels| puts "#{msgid} (#{labels * ' '})" } diff --git a/lib/sup/ferret_index.rb b/lib/sup/ferret_index.rb index 98ea9b5..2cb9759 100644 --- a/lib/sup/ferret_index.rb +++ b/lib/sup/ferret_index.rb @@ -57,6 +57,7 @@ EOS def sync_message m, opts={} entry = @index[m.id] + existed = !entry.nil? raise "no source info for message #{m.id}" unless m.source && m.source_info @@ -131,6 +132,12 @@ EOS } @index_mutex.synchronize do + if existed + @log.update_message_state m.id, m.labels + else + @log.add_message m.id, m.labels + end + @index.delete m.id @index.add_document d end diff --git a/lib/sup/index.rb b/lib/sup/index.rb index 54ec843..7360cf5 100644 --- a/lib/sup/index.rb +++ b/lib/sup/index.rb @@ -1,6 +1,7 @@ ## Index interface, subclassed by Ferret indexer. require 'fileutils' +require 'sup/yaml_log' begin require 'chronic' @@ -65,6 +66,7 @@ class BaseIndex def load SourceManager.load_sources + @log = IndexLogWriter.new File.join(@dir, 'index_log.yaml') load_index end @@ -176,6 +178,26 @@ class BaseIndex def parse_query s unimplemented end + + private + + class IndexLogWriter < YamlLogWriter + def update_message_state id, labels + write_entry 'update_message_state', 'id' => id, 'labels' => labels.map { |x| x.to_s } + end + + def add_message id, labels + write_entry 'add_message', 'id' => id, 'labels' => labels.map { |x| x.to_s } + end + + def remove_message id + write_entry 'remove_message', 'id' => id + end + + def write_entry type, hash + self << hash.merge('type' => type, 'time' => Time.now) + end + end end index_name = ENV['SUP_INDEX'] || $config[:index] || DEFAULT_INDEX diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index 18b5050..c4dbc5f 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -61,7 +61,10 @@ class XapianIndex < BaseIndex end def delete id - synchronize { @xapian.delete_document mkterm(:msgid, id) } + synchronize do + @log.remove_message id + @xapian.delete_document mkterm(:msgid, id) + end end def build_message id @@ -510,10 +513,12 @@ class XapianIndex < BaseIndex Redwood::log "warning: docid underflow, dropping #{m.id.inspect}" return end + @log.add_message m.id, m.labels else doc.clear_terms doc.clear_values docid = doc.docid + @log.update_message_state m.id, m.labels end @term_generator.document = doc diff --git a/lib/sup/yaml_log.rb b/lib/sup/yaml_log.rb new file mode 100644 index 0000000..325cca9 --- /dev/null +++ b/lib/sup/yaml_log.rb @@ -0,0 +1,25 @@ +class YamlLogReader + include Enumerable + + def initialize filename + @io = File.open(filename, 'r+') + end + + def each &b + @io.rewind + YAML.each_document @io, &b + end +end + +class YamlLogWriter + def initialize filename + @io = File.open(filename, 'a') + end + + def <<(o) + YAML.dump o, @io + + ## This only flushes to the OS. We may want to fsync occasionally too. + @io.flush + end +end -- 1.6.4 From rlane@club.cc.cmu.edu Mon Aug 17 02:39:11 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 16 Aug 2009 23:39:11 -0700 Subject: [sup-talk] [PATCH 1/5] console mode Message-ID: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu> --- bin/sup | 4 +++ lib/sup.rb | 1 + lib/sup/modes/console-mode.rb | 42 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 47 insertions(+), 0 deletions(-) create mode 100644 lib/sup/modes/console-mode.rb diff --git a/bin/sup b/bin/sup index a9f0b95..1dc322a 100755 --- a/bin/sup +++ b/bin/sup @@ -78,6 +78,7 @@ global_keymap = Keymap.new do |k| k.add :compose, "Compose new message", 'm', 'c' k.add :nothing, "Do nothing", :ctrl_g k.add :recall_draft, "Edit most recent draft message", 'R' + k.add :show_console, "Show the Console buffer", '~' end ## the following magic enables wide characters when used with a ruby @@ -286,6 +287,9 @@ begin b, new = BufferManager.spawn_unless_exists("All drafts") { LabelSearchResultsMode.new [:draft] } b.mode.load_threads :num => b.content_height if new end + when :show_console + b, new = bm.spawn_unless_exists("Console", :system => true) { ConsoleMode.new } + b.mode.run when :nothing, InputSequenceAborted when :redraw bm.completely_redraw_screen diff --git a/lib/sup.rb b/lib/sup.rb index cfa93fc..9e0c33a 100644 --- a/lib/sup.rb +++ b/lib/sup.rb @@ -295,6 +295,7 @@ require "sup/modes/buffer-list-mode" require "sup/modes/poll-mode" require "sup/modes/file-browser-mode" require "sup/modes/completion-mode" +require "sup/modes/console-mode" require "sup/sent" $:.each do |base| diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb new file mode 100644 index 0000000..d06d37b --- /dev/null +++ b/lib/sup/modes/console-mode.rb @@ -0,0 +1,42 @@ +require 'pp' + +module Redwood + +class Console + def initialize mode + @mode = mode + end +end + +class ConsoleMode < LogMode + def initialize + super + @binding = Console.new(self).instance_eval { binding } + end + + def execute cmd + begin + self << ">> #{cmd}\n" + ret = eval cmd, @binding + self << "=> #{ret.pretty_inspect}\n" + rescue Exception + self << "#{$!.class}: #{$!.message}\n" + clean_backtrace = [] + $!.backtrace.each { |l| break if l =~ /console-mode/; clean_backtrace << l } + clean_backtrace.each { |l| self << "#{l}\n" } + end + end + + def prompt + BufferManager.ask :console, "eval: " + end + + def run + while true + cmd = prompt or return + execute cmd + end + end +end + +end -- 1.6.4 From rlane@club.cc.cmu.edu Mon Aug 17 02:39:13 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 16 Aug 2009 23:39:13 -0700 Subject: [sup-talk] [PATCH 3/5] console: index internals accessor In-Reply-To: <1250491155-19281-2-git-send-email-rlane@club.cc.cmu.edu> References: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu> <1250491155-19281-2-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1250491155-19281-3-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/modes/console-mode.rb | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb index a91bbbf..c794a4c 100644 --- a/lib/sup/modes/console-mode.rb +++ b/lib/sup/modes/console-mode.rb @@ -18,6 +18,9 @@ class Console def remove_labels(query, *labels) query(query).each { |m| m.labels -= labels; m.save Index } end + + def xapian; Index.instance.instance_variable_get :@xapian; end + def ferret; Index.instance.instance_variable_get :@index; end end class ConsoleMode < LogMode -- 1.6.4 From rlane@club.cc.cmu.edu Mon Aug 17 02:39:12 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 16 Aug 2009 23:39:12 -0700 Subject: [sup-talk] [PATCH 2/5] console: add/remove labels In-Reply-To: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu> References: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1250491155-19281-2-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/modes/console-mode.rb | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb index d06d37b..a91bbbf 100644 --- a/lib/sup/modes/console-mode.rb +++ b/lib/sup/modes/console-mode.rb @@ -6,6 +6,18 @@ class Console def initialize mode @mode = mode end + + def query(query) + Enumerable::Enumerator.new(Index, :each_message, Index.parse_query(query)) + end + + def add_labels(query, *labels) + query(query).each { |m| m.labels += labels; m.save Index } + end + + def remove_labels(query, *labels) + query(query).each { |m| m.labels -= labels; m.save Index } + end end class ConsoleMode < LogMode -- 1.6.4 From rlane@club.cc.cmu.edu Mon Aug 17 02:39:14 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 16 Aug 2009 23:39:14 -0700 Subject: [sup-talk] [PATCH 4/5] console: reload In-Reply-To: <1250491155-19281-3-git-send-email-rlane@club.cc.cmu.edu> References: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu> <1250491155-19281-2-git-send-email-rlane@club.cc.cmu.edu> <1250491155-19281-3-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1250491155-19281-4-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/modes/console-mode.rb | 30 ++++++++++++++++++++++++++++++ 1 files changed, 30 insertions(+), 0 deletions(-) diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb index c794a4c..c344fa6 100644 --- a/lib/sup/modes/console-mode.rb +++ b/lib/sup/modes/console-mode.rb @@ -21,6 +21,36 @@ class Console def xapian; Index.instance.instance_variable_get :@xapian; end def ferret; Index.instance.instance_variable_get :@index; end + + ## files that won't cause problems when reloaded + ## TODO expand this list / convert to blacklist + RELOAD_WHITELIST = %w(sup/xapian_index.rb sup/modes/console-mode.rb) + + def reload + old_verbose = $VERBOSE + $VERBOSE = nil + old_features = $".dup + begin + fs = $".grep(/^sup\//) + fs.reject! { |f| not RELOAD_WHITELIST.member? f } + fs.each { |f| $".delete f } + fs.each do |f| + @mode << "reloading #{f}\n" + begin + require f + rescue LoadError => e + raise unless e.message =~ /no such file to load/ + end + end + rescue Exception + $".clear + $".concat old_features + raise + ensure + $VERBOSE = old_verbose + end + true + end end class ConsoleMode < LogMode -- 1.6.4 From rlane@club.cc.cmu.edu Mon Aug 17 02:39:15 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 16 Aug 2009 23:39:15 -0700 Subject: [sup-talk] [PATCH 5/5] console: clear_hooks In-Reply-To: <1250491155-19281-4-git-send-email-rlane@club.cc.cmu.edu> References: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu> <1250491155-19281-2-git-send-email-rlane@club.cc.cmu.edu> <1250491155-19281-3-git-send-email-rlane@club.cc.cmu.edu> <1250491155-19281-4-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1250491155-19281-5-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/hook.rb | 2 ++ lib/sup/modes/console-mode.rb | 5 +++++ 2 files changed, 7 insertions(+), 0 deletions(-) diff --git a/lib/sup/hook.rb b/lib/sup/hook.rb index 33a97b2..099158d 100644 --- a/lib/sup/hook.rb +++ b/lib/sup/hook.rb @@ -130,6 +130,8 @@ EOS def enabled? name; !hook_for(name).nil? end + def clear; @hooks.clear; end + private def hook_for name diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb index c344fa6..372a466 100644 --- a/lib/sup/modes/console-mode.rb +++ b/lib/sup/modes/console-mode.rb @@ -51,6 +51,11 @@ class Console end true end + + def clear_hooks + HookManager.clear + nil + end end class ConsoleMode < LogMode -- 1.6.4 From rlane@club.cc.cmu.edu Mon Aug 17 02:39:32 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 16 Aug 2009 23:39:32 -0700 Subject: [sup-talk] [PATCH] cache results of Person.from_address Message-ID: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu> The regexes in this function are very expensive, so caching improves performance significantly for queries and slightly for indexing. --- lib/sup/cache.rb | 46 ++++++++++++++++++++++++++++++++++++++++++++++ lib/sup/person.rb | 7 ++++++- 2 files changed, 52 insertions(+), 1 deletions(-) create mode 100644 lib/sup/cache.rb diff --git a/lib/sup/cache.rb b/lib/sup/cache.rb new file mode 100644 index 0000000..0836dbd --- /dev/null +++ b/lib/sup/cache.rb @@ -0,0 +1,46 @@ +class Cache + def initialize n=128, i=3 + @n = n + @i = i + @values = {} + @marks = {} + @delete_stack = [] + end + + def [](k) + if @values.member? k + @marks[k] = @i + @values[k] + else + nil + end + end + + def []=(k,v) + if @values.size < @n + @values[k] = v + @marks[k] = @i + else + if @delete_stack.empty? + sweep + else + k2 = @delete_stack.pop + @values.delete k2 + @marks.delete k2 + self[k] = v + end + end + end + + def sweep + @marks.each do |k,v| + v -= 1 + if v == 0 + @delete_stack.push k + @marks.delete k + else + @marks[k] = v + end + end + end +end diff --git a/lib/sup/person.rb b/lib/sup/person.rb index c4f40a5..046eedc 100644 --- a/lib/sup/person.rb +++ b/lib/sup/person.rb @@ -1,3 +1,5 @@ +require 'sup/cache' + module Redwood class Person @@ -73,8 +75,11 @@ class Person end.downcase end + ## This method is expensive, so memoize it. + @from_address_cache = Cache.new def self.from_address s return nil if s.nil? + @from_address_cache[s].tap { |x| return x if x } ## try and parse an email address and name name, email = case s @@ -102,7 +107,7 @@ class Person [nil, s] end - Person.new name, email + @from_address_cache[s] = Person.new name, email end def self.from_address_list ss -- 1.6.4 From taruti@taruti.net Mon Aug 17 03:22:35 2009 From: taruti@taruti.net (Taru Karttunen) Date: Mon, 17 Aug 2009 10:22:35 +0300 Subject: [sup-talk] Sup crashing In-Reply-To: 1250281208-sup-4199 <1250281208-sup-4199@masanjin.net> References: <1250148617-sup-6053@oz.taruti.net> <1250281208-sup-4199@masanjin.net> Message-ID: <1250493725-sup-5683@oz.taruti.net> Excerpts from William Morgan's message of Fri Aug 14 23:20:28 +0300 2009: > > Weird. Does sup-sync --optimize fix anything? Made things work again. Thanks. - Taru Karttunen From garoth@gmail.com Mon Aug 17 09:07:25 2009 From: garoth@gmail.com (Andrei Thorp) Date: Mon, 17 Aug 2009 09:07:25 -0400 Subject: [sup-talk] [PATCH] cache results of Person.from_address In-Reply-To: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu> References: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1250514421-sup-7564@Longbow> Just want to say thanks again for your seemingly unending amount of good work to improve Sup. -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From wmorgan-sup@masanjin.net Mon Aug 17 10:01:10 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 17 Aug 2009 07:01:10 -0700 Subject: [sup-talk] Sup crashing In-Reply-To: <1250493725-sup-5683@oz.taruti.net> References: <1250148617-sup-6053@oz.taruti.net> <1250281208-sup-4199@masanjin.net> <1250493725-sup-5683@oz.taruti.net> Message-ID: <1250517574-sup-940@masanjin.net> Reformatted excerpts from Taru Karttunen's message of 2009-08-17: > Made things work again. Thanks. Good. Let me know if it happens again. I'm not sure what would cause it to get in that state. -- William From dato@net.com.org.es Mon Aug 17 12:08:57 2009 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=) Date: Mon, 17 Aug 2009 17:08:57 +0100 Subject: [sup-talk] [PATCH 2/2] xapian index format versioning In-Reply-To: <1250453934-sup-9651@zyrg.net> References: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu> <1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu> <20090816200116.GA17272@chistera.yi.org> <1250453934-sup-9651@zyrg.net> Message-ID: <20090817160857.GA2496@chistera.yi.org> + Rich Lane (Sun, 16 Aug 2009 16:28:56 -0400): > How's this wording? > + fail "This Sup version expects a v#{INDEX_VERSION} index, but you > have an existing v#{db_version} index. Please downgrade to your > previous version and dump your labels before upgrading to this version > (then run sup-sync --restore)." Sounds much better, thanks! -- - Are you sure we're good? - Always. -- Rory and Lorelai From wmorgan-sup@masanjin.net Mon Aug 17 15:39:57 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 17 Aug 2009 12:39:57 -0700 Subject: [sup-talk] some internal api refactors In-Reply-To: <1250461358-sup-7209@zyrg.net> References: <1250021119-sup-4253@masanjin.net> <1250054282-sup-9053@pion.club.cc.cmu.edu> <1250459019-sup-6390@masanjin.net> <1250461358-sup-7209@zyrg.net> Message-ID: <1250537445-sup-4504@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-08-16: > The ThreadSet still needs the ref to do the UI-level threading, right? > Making it another API call is good as long as that's still taken care > of. I'm thinking about moving in the direction where the index is also responsible for threading (so maybe "index" is not the right term anymore), so the ThreadSet would just be a static representation of the thread structure of a set of messages as returned by the index. We'll see how it develops. -- William From wmorgan-sup@masanjin.net Mon Aug 17 15:50:52 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 17 Aug 2009 12:50:52 -0700 Subject: [sup-talk] logging and internal API changes in next Message-ID: <1250538107-sup-7121@masanjin.net> Dear Suppers, I've merged the aforementioned internal API changes, and a pretty big rewrite of the logging system (branch "logging"), into next. It works for me, but please report any problems you see. All logging messages are now categorized by level (debug, info, warn, error) and will only be output when the global logging level is <= the message level. The global logging level is determined by the environment variable SUP_LOG_LEVEL; when unset, the default is "info". You'll notice that the majority of the messages you saw before are now "debug" messages, so the log buffer is much quieter. This change also applies to the various sup-* scripts. If you use this code and then switch to a branch without these changes, you may encounter errors because labels are now represented on disk as Sets instead of arrays. The solution is to edit your sources.yaml file and manually change the Sets back to arrays; it should be obvious how to do this. I don't anticipate this affecting too many people. If it does, we can transform labels to arrays before storing to make this easier, but hopefully it's just a temporary issue. I would like to merge these changes down to master sooner rather than later, because they're so far-reaching. -- William From ezyang@MIT.EDU Mon Aug 17 15:54:45 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 17 Aug 2009 15:54:45 -0400 Subject: [sup-talk] ncurses hack Message-ID: <1250538875-sup-2195@javelin> Today, I decided to throw in the towel and patch my copy of ncurses to have the appropriate fix for international characters + tabs. Does anyone know of a list of instructions for carrying this out? Cheers, Edward From garoth@gmail.com Mon Aug 17 16:31:22 2009 From: garoth@gmail.com (Andrei Thorp) Date: Mon, 17 Aug 2009 16:31:22 -0400 Subject: [sup-talk] logging and internal API changes in next In-Reply-To: <1250538107-sup-7121@masanjin.net> References: <1250538107-sup-7121@masanjin.net> Message-ID: <1250541071-sup-7690@Longbow> Excerpts from William Morgan's message of Mon Aug 17 15:50:52 -0400 2009: > Dear Suppers, > > I've merged the aforementioned internal API changes, and a pretty big > rewrite of the logging system (branch "logging"), into next. It works > for me, but please report any problems you see. > > All logging messages are now categorized by level (debug, info, warn, > error) and will only be output when the global logging level is <= the > message level. The global logging level is determined by the environment > variable SUP_LOG_LEVEL; when unset, the default is "info". You'll notice > that the majority of the messages you saw before are now "debug" > messages, so the log buffer is much quieter. > > This change also applies to the various sup-* scripts. > > If you use this code and then switch to a branch without these changes, > you may encounter errors because labels are now represented on disk as > Sets instead of arrays. The solution is to edit your sources.yaml file > and manually change the Sets back to arrays; it should be obvious how to > do this. I don't anticipate this affecting too many people. If it does, > we can transform labels to arrays before storing to make this easier, > but hopefully it's just a temporary issue. > > I would like to merge these changes down to master sooner rather than > later, because they're so far-reaching. Looking forward to it, thanks. -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From wmorgan-sup@masanjin.net Mon Aug 17 22:43:18 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 17 Aug 2009 19:43:18 -0700 Subject: [sup-talk] ncurses hack In-Reply-To: <1250538875-sup-2195@javelin> References: <1250538875-sup-2195@javelin> Message-ID: <1250563136-sup-432@masanjin.net> Reformatted excerpts from Edward Z. Yang's message of 2009-08-17: > Today, I decided to throw in the towel and patch my copy of ncurses to > have the appropriate fix for international characters + tabs. Does > anyone know of a list of instructions for carrying this out? Try http://sup.rubyforge.org/wiki/wiki.pl?UTF8. If you're running Sup git, I've made a nice branch for this: $ git branch --track ncursesw origin/ncursesw $ git checkout ncursesw $ cd ncurses-0.9.1/ $ ./run-this-for-sup.sh Which will generate an ncurses.so file in lib/. You can then switch back to master or next and it should pick it up. This should fix many wide-character issues but it won't fix all of them, because there's still no way of determining the display width of a unicode character (e.g. Chinese characters take two columns to display). So the display still ends up funny. Ruby 1.9 has better encoding support but I don't know if it fixes this. -- William From ef_dva@yahoo.com Tue Aug 18 03:42:48 2009 From: ef_dva@yahoo.com (Dusan) Date: Tue, 18 Aug 2009 09:42:48 +0200 Subject: [sup-talk] ncurses hack In-Reply-To: <1250563136-sup-432@masanjin.net> References: <1250538875-sup-2195@javelin> <1250563136-sup-432@masanjin.net> Message-ID: <1250580593-sup-1346@archpc> Excerpts from William Morgan's message of Tue Aug 18 04:43:18 +0200 2009: > Reformatted excerpts from Edward Z. Yang's message of 2009-08-17: > > Today, I decided to throw in the towel and patch my copy of ncurses to > > have the appropriate fix for international characters + tabs. Does > > anyone know of a list of instructions for carrying this out? > > Try http://sup.rubyforge.org/wiki/wiki.pl?UTF8. If you're running Sup > git, I've made a nice branch for this: > > $ git branch --track ncursesw origin/ncursesw > $ git checkout ncursesw > $ cd ncurses-0.9.1/ > $ ./run-this-for-sup.sh > > Which will generate an ncurses.so file in lib/. You can then switch back > to master or next and it should pick it up. > > This should fix many wide-character issues but it won't fix all of them, > because there's still no way of determining the display width of a > unicode character (e.g. Chinese characters take two columns to display). > So the display still ends up funny. > > Ruby 1.9 has better encoding support but I don't know if it fixes this. I am new sup user and love it very much. Not being able to fix search/save and other edits is huge show-stopper. I do what I read somewhere: -start search, get garbage results -kill that buffer with 'x' -start another search but instead of typing search term again first repeat: press up, delete search garbage, press up, delete search garbage, repeat until there is nothing to delete -type another search term and search now works 100% This works for searches but edits like save still fail (or save X((%^1X file so if you can find it you can rename it). Looks like fixable bug to simulate what I did for searches? Repeat in code ten times 'up arrow', '50 x delete char'? Sorry if I am wrong. Using sup and not being able to properly search or save is too wrong. If there is any config/version I should report to get this fixed just let me know. Without waiting for new ruby of course -- I do have proper results when I repeat deleting ritual. Thanks From bwalton@artsci.utoronto.ca Tue Aug 18 12:58:57 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Tue, 18 Aug 2009 12:58:57 -0400 Subject: [sup-talk] xapian rpms Message-ID: <1250614640-sup-8983@ntdws12.chass.utoronto.ca> Hi All, I've built a set of rpms for xapian (1.0.14) for rhel5. If you're interested in them, I'll share. I have both 32 and 64 bit versions. The xapian site rpm collection doesn't offer the ruby bindings. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Tue Aug 18 13:33:33 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 18 Aug 2009 10:33:33 -0700 Subject: [sup-talk] [PATCH] maildir: Allow ', ' in the unique-name portion of a maildir filename. In-Reply-To: <20090815042943.GA2414@yoom.home.cworth.org> References: <20090815042943.GA2414@yoom.home.cworth.org> Message-ID: <1250616640-sup-2613@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-14: > A unique name can be anything that doesn't contain a colon (or slash) > and doesn't start with a dot. I've applied this patch directly to master. (The one I complained about was attached to your original email; I just noticed this one was different now.) > Argh! What's worse than Forgotten Attachment Syndrome (FAS), > (especially on my first post to a list)? Since Sup should now work for you, you'll be happy to know that it warns you if you use the word "attachment" without attaching anything. :) -- William From bwalton@artsci.utoronto.ca Tue Aug 18 13:35:35 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Tue, 18 Aug 2009 13:35:35 -0400 Subject: [sup-talk] crash when sup-syncing to xapian Message-ID: <1250616603-sup-5612@ntdws12.chass.utoronto.ca> I just tried to import my index to xapian and it crashed part way through the import. I then discovered that I couldn't use ferret either. There is something wonky with label handling, as per attached exception log. I haven't had a chance to look at the code yet, but I'll poke at it tonight. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sup-exception-log.txt URL: From wmorgan-sup@masanjin.net Tue Aug 18 13:36:27 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 18 Aug 2009 10:36:27 -0700 Subject: [sup-talk] [PATCH] skip system buffers when rolling In-Reply-To: <1250451359-16110-1-git-send-email-rlane@club.cc.cmu.edu> References: <1250451359-16110-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1250616971-sup-7888@masanjin.net> Nice idea. Branch buffer-rolling, merged into next. -- William From wmorgan-sup@masanjin.net Tue Aug 18 13:38:58 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 18 Aug 2009 10:38:58 -0700 Subject: [sup-talk] [PATCH] add 'I' keybinding to raise Inbox buffer In-Reply-To: <1250451368-16150-1-git-send-email-rlane@club.cc.cmu.edu> References: <1250451368-16150-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1250617129-sup-4194@masanjin.net> Applied to master, thanks! -- William From cworth@cworth.org Tue Aug 18 13:49:05 2009 From: cworth@cworth.org (Carl Worth) Date: Tue, 18 Aug 2009 10:49:05 -0700 Subject: [sup-talk] [PATCH] maildir: Allow ', ' in the unique-name portion of a maildir filename. In-Reply-To: <1250616640-sup-2613@masanjin.net> References: <20090815042943.GA2414@yoom.home.cworth.org> <1250616640-sup-2613@masanjin.net> Message-ID: <1250617174-sup-2755@yoom> Excerpts from William Morgan's message of Tue Aug 18 10:33:33 -0700 2009: > I've applied this patch directly to master. (The one I complained about > was attached to your original email; I just noticed this one was > different now.) Thanks for catching this. > > Argh! What's worse than Forgotten Attachment Syndrome (FAS), > > (especially on my first post to a list)? > > Since Sup should now work for you, you'll be happy to know that it warns > you if you use the word "attachment" without attaching anything. :) If it's just the word "attachment" I don't think it will affect me at all. The wording I generally use is something like: I've attached a test case to demonstrate the bug. But in general this should be a nice feature, (except for a mail like this one that will cause a false warning from the check). ;-) Thanks again for all your work on sup, -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Tue Aug 18 13:54:20 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 18 Aug 2009 10:54:20 -0700 Subject: [sup-talk] [PATCH] maildir: Allow ', ' in the unique-name portion of a maildir filename. In-Reply-To: <1250617174-sup-2755@yoom> References: <20090815042943.GA2414@yoom.home.cworth.org> <1250616640-sup-2613@masanjin.net> <1250617174-sup-2755@yoom> Message-ID: <1250617985-sup-2416@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-18: > If it's just the word "attachment" I don't think it will affect me at > all. Don't worry, Sup uses sophisticated natural language technology to induce message semantics. -- William From wmorgan-sup@masanjin.net Tue Aug 18 13:56:15 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 18 Aug 2009 10:56:15 -0700 Subject: [sup-talk] [PATCH] Add an after-add-message hook In-Reply-To: <1250459229-4500-1-git-send-email-kevinr@free-dissociation.com> References: <1250459229-4500-1-git-send-email-kevinr@free-dissociation.com> Message-ID: <1250618123-sup-8797@masanjin.net> Reformatted excerpts from Kevin Riggle's message of 2009-08-16: > I want to do some unrelated processing on each message I receive, but > I don't want to block the message being added to the index. This > patch adds a hook which runs /after/ the message is added to the > index. Won't this block subsequent emails from being added to the index, when Sup gets multiple new emails during a poll? -- William From benoit.pierre@gmail.com Tue Aug 18 14:20:41 2009 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=) Date: Tue, 18 Aug 2009 20:20:41 +0200 Subject: [sup-talk] crash when sup-syncing to xapian In-Reply-To: <1250616603-sup-5612@ntdws12.chass.utoronto.ca> References: <1250616603-sup-5612@ntdws12.chass.utoronto.ca> Message-ID: <1250619511-sup-2827@localdomain> Excerpts from Ben Walton's message of Tue Aug 18 19:35:35 +0200 2009: > > I just tried to import my index to xapian and it crashed part way > through the import. I then discovered that I couldn't use ferret > either. There is something wonky with label handling, as per attached > exception log. I haven't had a chance to look at the code yet, but > I'll poke at it tonight. I think I just ran into the same problem! For now I fixed it with the following small patch: diff --git a/lib/sup/label.rb b/lib/sup/label.rb index 67474c2..59c0c0f 100644 --- a/lib/sup/label.rb +++ b/lib/sup/label.rb @@ -61,6 +61,7 @@ class LabelManager end def << t + t = t.to_sym if t.is_a? String raise ArgumentError, "expecting a symbol" unless t.is_a? Symbol unless @labels.member?(t) || RESERVED_LABELS.member?(t) @labels[t] = true -- 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: 289 bytes Desc: not available URL: From benoit.pierre@gmail.com Tue Aug 18 14:24:45 2009 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=) Date: Tue, 18 Aug 2009 20:24:45 +0200 Subject: [sup-talk] ncurses hack In-Reply-To: <1250580593-sup-1346@archpc> References: <1250538875-sup-2195@javelin> <1250563136-sup-432@masanjin.net> <1250580593-sup-1346@archpc> Message-ID: <1250619721-sup-91@localdomain> Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009: > > [...] > > Not being able to fix search/save and other edits is huge show-stopper. > I do what I read somewhere: > > -start search, get garbage results > -kill that buffer with 'x' > -start another search but instead of typing search term again first > repeat: press up, delete search garbage, press up, delete search > garbage, repeat until there is nothing to delete > -type another search term and search now works 100% > > This works for searches but edits like save still fail (or save X((%^1X file > so if you can find it you can rename it). > > Looks like fixable bug to simulate what I did for searches? Repeat in > code ten times 'up arrow', '50 x delete char'? Sorry if I am wrong. > > Using sup and not being able to properly search or save is too wrong. > > If there is any config/version I should report to get this fixed just > let me know. Without waiting for new ruby of course -- I do have proper > results when I repeat deleting ritual. Hi, can you try the following patch and tell me if it fix the problem? diff --git a/lib/sup/textfield.rb b/lib/sup/textfield.rb index b8dec59..ccc8533 100644 --- a/lib/sup/textfield.rb +++ b/lib/sup/textfield.rb @@ -36,8 +36,9 @@ class TextField @field = Ncurses::Form.new_field 1, @width - question.length, @y, @x + question.length, 256, 0 @form = Ncurses::Form.new_form [@field] @value = default + @value ||= '' Ncurses::Form.post_form @form - set_cursed_value default if default + set_cursed_value @value end def position_cursor -- A: Because it destroys the flow of conversation. Q: Why is top posting dumb? From alex@chmrr.net Tue Aug 18 14:30:00 2009 From: alex@chmrr.net (Alex Vandiver) Date: Tue, 18 Aug 2009 14:30:00 -0400 Subject: [sup-talk] [PATCH] Fix a thread merging bug introduced by refactoring in 59f8fc2 Message-ID: <1250620200-24319-1-git-send-email-alex@chmrr.net> Signed-off-by: Alex Vandiver --- lib/sup/thread.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/thread.rb b/lib/sup/thread.rb index d395c35..3ff4e7f 100644 --- a/lib/sup/thread.rb +++ b/lib/sup/thread.rb @@ -357,7 +357,7 @@ class ThreadSet return if threads.size < 2 containers = threads.map do |t| - c = @messages.member?(c) ? @messages[t.first.id] : nil + c = @messages.member?(t.first.id) ? @messages[t.first.id] : nil raise "not in threadset: #{t.first.id}" unless c && c.message c end -- 1.6.3.3 From wmorgan-sup@masanjin.net Tue Aug 18 14:37:38 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 18 Aug 2009 11:37:38 -0700 Subject: [sup-talk] [PATCH 1/5] console mode In-Reply-To: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu> References: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1250620017-sup-3445@masanjin.net> Cool idea. Branch console-mode, merged into next. -- William From rlane@club.cc.cmu.edu Tue Aug 18 14:42:13 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Tue, 18 Aug 2009 14:42:13 -0400 Subject: [sup-talk] crash when sup-syncing to xapian In-Reply-To: <1250619511-sup-2827@localdomain> References: <1250616603-sup-5612@ntdws12.chass.utoronto.ca> <1250619511-sup-2827@localdomain> Message-ID: <1250620771-sup-1373@zyrg.net> Excerpts from Beno?t PIERRE's message of Tue Aug 18 14:20:41 -0400 2009: > Excerpts from Ben Walton's message of Tue Aug 18 19:35:35 +0200 2009: > > > > I just tried to import my index to xapian and it crashed part way > > through the import. I then discovered that I couldn't use ferret > > either. There is something wonky with label handling, as per attached > > exception log. I haven't had a chance to look at the code yet, but > > I'll poke at it tonight. > > I think I just ran into the same problem! For now I fixed it with > the following small patch: That's odd because the Xapian code passes the labels straight through from the message to LabelManager. Try instrumenting Message#labels= to raise an exception if any member of the set is not a Symbol. From ef_dva@yahoo.com Tue Aug 18 14:46:52 2009 From: ef_dva@yahoo.com (Dusan) Date: Tue, 18 Aug 2009 20:46:52 +0200 Subject: [sup-talk] ncurses hack In-Reply-To: <1250619721-sup-91@localdomain> References: <1250538875-sup-2195@javelin> <1250563136-sup-432@masanjin.net> <1250580593-sup-1346@archpc> <1250619721-sup-91@localdomain> Message-ID: <1250620908-sup-7463@archpc> Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:24:45 +0200 2009: > Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009: > > > > [...] > > > > Not being able to fix search/save and other edits is huge show-stopper. > > I do what I read somewhere: > > > > -start search, get garbage results > > -kill that buffer with 'x' > > -start another search but instead of typing search term again first > > repeat: press up, delete search garbage, press up, delete search > > garbage, repeat until there is nothing to delete > > -type another search term and search now works 100% > > > > This works for searches but edits like save still fail (or save X((%^1X file > > so if you can find it you can rename it). > > > > Looks like fixable bug to simulate what I did for searches? Repeat in > > code ten times 'up arrow', '50 x delete char'? Sorry if I am wrong. > > > > Using sup and not being able to properly search or save is too wrong. > > > > If there is any config/version I should report to get this fixed just > > let me know. Without waiting for new ruby of course -- I do have proper > > results when I repeat deleting ritual. > > Hi, can you try the following patch and tell me if it fix the problem? > > diff --git a/lib/sup/textfield.rb b/lib/sup/textfield.rb > index b8dec59..ccc8533 100644 > --- a/lib/sup/textfield.rb > +++ b/lib/sup/textfield.rb > @@ -36,8 +36,9 @@ class TextField > @field = Ncurses::Form.new_field 1, @width - question.length, @y, > @x + question.length, 256, 0 > @form = Ncurses::Form.new_form [@field] > @value = default > + @value ||= '' > Ncurses::Form.post_form @form > - set_cursed_value default if default > + set_cursed_value @value > end > > def position_cursor I will, just give me day or two. I am using gem version, not svn or git. I did some stuff with them but never with ruby. Can you give me two lines help what to install and where? Latest svn? Sorry I am not _that_ helpful but ruby is new thing to me. I should be able to test this soon enough with some help. Thanks, Dusan From benoit.pierre@gmail.com Tue Aug 18 14:59:20 2009 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=) Date: Tue, 18 Aug 2009 20:59:20 +0200 Subject: [sup-talk] ncurses hack In-Reply-To: <1250620908-sup-7463@archpc> References: <1250538875-sup-2195@javelin> <1250563136-sup-432@masanjin.net> <1250580593-sup-1346@archpc> <1250619721-sup-91@localdomain> <1250620908-sup-7463@archpc> Message-ID: <1250621614-sup-5683@localdomain> Excerpts from Dusan's message of Tue Aug 18 20:46:52 +0200 2009: > Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:24:45 +0200 2009: > > Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009: > > [...] > > I will, just give me day or two. I am using gem version, not svn or git. > I did some stuff with them but never with ruby. Can you give me two > lines help what to install and where? Latest svn? You can probably directly patch the sources in the gem. For example on Ubuntu, the sources should be somewhere in /var/lib/gems/1.8/gems/sup-xxx. Use 'gem environment' to get the installation directory. Another option is to follow the wiki to get the latest git version: http://sup.rubyforge.org/wiki/wiki.pl?Contributing -- 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 ef_dva@yahoo.com Tue Aug 18 15:04:16 2009 From: ef_dva@yahoo.com (Dusan) Date: Tue, 18 Aug 2009 21:04:16 +0200 Subject: [sup-talk] ncurses hack In-Reply-To: <1250621614-sup-5683@localdomain> References: <1250538875-sup-2195@javelin> <1250563136-sup-432@masanjin.net> <1250580593-sup-1346@archpc> <1250619721-sup-91@localdomain> <1250620908-sup-7463@archpc> <1250621614-sup-5683@localdomain> Message-ID: <1250622060-sup-324@archpc> Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:59:20 +0200 2009: > Excerpts from Dusan's message of Tue Aug 18 20:46:52 +0200 2009: > > Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:24:45 +0200 2009: > > > Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009: > > > > [...] > > > > I will, just give me day or two. I am using gem version, not svn or git. > > I did some stuff with them but never with ruby. Can you give me two > > lines help what to install and where? Latest svn? > > You can probably directly patch the sources in the gem. For example on > Ubuntu, the sources should be somewhere in /var/lib/gems/1.8/gems/sup-xxx. > > Use 'gem environment' to get the installation directory. > > Another option is to follow the wiki to get the latest git version: > http://sup.rubyforge.org/wiki/wiki.pl?Contributing Everything but git, thanks :) Of course, ruby is interpreter, I keep forgetting that. I am using ArchLinux and should be fairly skilled to do some changing. Reporting back tomorrow. From benoit.pierre@gmail.com Tue Aug 18 15:17:03 2009 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=) Date: Tue, 18 Aug 2009 21:17:03 +0200 Subject: [sup-talk] crash when sup-syncing to xapian In-Reply-To: <1250620771-sup-1373@zyrg.net> References: <1250616603-sup-5612@ntdws12.chass.utoronto.ca> <1250619511-sup-2827@localdomain> <1250620771-sup-1373@zyrg.net> Message-ID: <1250622911-sup-2815@localdomain> Excerpts from Rich Lane's message of Tue Aug 18 20:42:13 +0200 2009: > Excerpts from Beno?t PIERRE's message of Tue Aug 18 14:20:41 -0400 2009: > > Excerpts from Ben Walton's message of Tue Aug 18 19:35:35 +0200 2009: > > > > > > I just tried to import my index to xapian and it crashed part way > > > through the import. I then discovered that I couldn't use ferret > > > either. There is something wonky with label handling, as per attached > > > exception log. I haven't had a chance to look at the code yet, but > > > I'll poke at it tonight. > > > > I think I just ran into the same problem! For now I fixed it with > > the following small patch: > > That's odd because the Xapian code passes the labels straight through > from the message to LabelManager. Try instrumenting Message#labels= to > raise an exception if any member of the set is not a Symbol. I applied the following patch: diff --git a/lib/sup/message.rb b/lib/sup/message.rb index 965c10e..9156c02 100644 --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -1,4 +1,5 @@ require 'time' +require 'pp' module Redwood @@ -183,6 +184,7 @@ class Message def labels= l raise ArgumentError, "not a set" unless l.is_a?(Set) return if @labels == l + warn "labels=#{l.pretty_inspect}" @labels = l @dirty = true end And get this in the logs: [Tue Aug 18 21:12:39 +0200 2009] WARNING: labels=# [Tue Aug 18 21:12:39 +0200 2009] WARNING: labels=# -- 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 ef_dva@yahoo.com Tue Aug 18 15:24:44 2009 From: ef_dva@yahoo.com (Dusan) Date: Tue, 18 Aug 2009 21:24:44 +0200 Subject: [sup-talk] ncurses hack In-Reply-To: <1250621614-sup-5683@localdomain> References: <1250538875-sup-2195@javelin> <1250563136-sup-432@masanjin.net> <1250580593-sup-1346@archpc> <1250619721-sup-91@localdomain> <1250620908-sup-7463@archpc> <1250621614-sup-5683@localdomain> Message-ID: <1250623031-sup-6731@archpc> Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:59:20 +0200 2009: > Excerpts from Dusan's message of Tue Aug 18 20:46:52 +0200 2009: > > Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:24:45 +0200 2009: > > > Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009: > > > > [...] > > > > I will, just give me day or two. I am using gem version, not svn or git. > > I did some stuff with them but never with ruby. Can you give me two > > lines help what to install and where? Latest svn? > > You can probably directly patch the sources in the gem. For example on > Ubuntu, the sources should be somewhere in /var/lib/gems/1.8/gems/sup-xxx. > > Use 'gem environment' to get the installation directory. > > Another option is to follow the wiki to get the latest git version: > http://sup.rubyforge.org/wiki/wiki.pl?Contributing Bah, I could not wait till tomorrow and it's not _that_ late... This fix WORKS :) Every time so far. Please include this into release asap, this is what prevents a lot of people from using sup. I patched source with vim, diff is too automatic :) Here is func that works: activate window, y, x, width, question, default=nil, &block @w, @y, @x, @width = window, y, x, width @question = question @completion_block = block @field = Ncurses::Form.new_field 1, @width - question.length, @y, @x + question.length, 256, 0 @form = Ncurses::Form.new_form [@field] @value = default @value ||= '' Ncurses::Form.post_form @form # set_cursed_value default if default set_cursed_value @value end Probably @value=default can go too, not sure since I don't know ruby? Thanks a lot! From bachjh@googlemail.com Tue Aug 18 15:31:35 2009 From: bachjh@googlemail.com (=?UTF-8?B?SsO2cmctSGVuZHJpayBCYWNo?=) Date: Tue, 18 Aug 2009 21:31:35 +0200 Subject: [sup-talk] ncurses hack In-Reply-To: <1250619721-sup-91@localdomain> References: <1250538875-sup-2195@javelin> <1250563136-sup-432@masanjin.net> <1250580593-sup-1346@archpc> <1250619721-sup-91@localdomain> Message-ID: <91de50e10908181231h2f8f4cbdr6ab546aa4a3466ca@mail.gmail.com> 2009/8/18 Beno?t PIERRE : > Hi, can you try the following patch and tell me if it fix the problem? > > diff --git a/lib/sup/textfield.rb b/lib/sup/textfield.rb > index b8dec59..ccc8533 100644 > --- a/lib/sup/textfield.rb > +++ b/lib/sup/textfield.rb > @@ -36,8 +36,9 @@ class TextField > ? ? @field = Ncurses::Form.new_field 1, @width - question.length, @y, > @x + question.length, 256, 0 > ? ? @form = Ncurses::Form.new_form [@field] > ? ? @value = default > + ? ?@value ||= '' > ? ? Ncurses::Form.post_form @form > - ? ?set_cursed_value default if default > + ? ?set_cursed_value @value > ? end > > ? def position_cursor Thanks a lot. I don't know what this does exactly, but the first added line of that patch was sufficient to get searches with utf-8 running well from startup, without the need to go for a dummy search each time i restarted sup. The full patch (including the replacement at line 41) broke searching altogether, on hitting '\' it throws: --- TypeError from thread: main can't convert nil into String /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/textfield.rb:159:in `set_field_buffer' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/textfield.rb:159:in `set_cursed_value' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/textfield.rb:42:in `activate' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/buffer.rb:537:in `ask' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/buffer.rb:26:in `synchronize' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/buffer.rb:26:in `sync' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/buffer.rb:536:in `ask' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:268 /usr/bin/sup:19:in `load' /usr/bin/sup:19 - J?rg-Hendrik From rlane@club.cc.cmu.edu Tue Aug 18 15:52:12 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Tue, 18 Aug 2009 15:52:12 -0400 Subject: [sup-talk] crash when sup-syncing to xapian In-Reply-To: <1250622911-sup-2815@localdomain> References: <1250616603-sup-5612@ntdws12.chass.utoronto.ca> <1250619511-sup-2827@localdomain> <1250620771-sup-1373@zyrg.net> <1250622911-sup-2815@localdomain> Message-ID: <1250624577-sup-4801@zyrg.net> Excerpts from Beno?t PIERRE's message of Tue Aug 18 15:17:03 -0400 2009: > Excerpts from Rich Lane's message of Tue Aug 18 20:42:13 +0200 2009: > > Excerpts from Beno?t PIERRE's message of Tue Aug 18 14:20:41 -0400 2009: > > > Excerpts from Ben Walton's message of Tue Aug 18 19:35:35 +0200 2009: > > > > > > > > I just tried to import my index to xapian and it crashed part way > > > > through the import. I then discovered that I couldn't use ferret > > > > either. There is something wonky with label handling, as per attached > > > > exception log. I haven't had a chance to look at the code yet, but > > > > I'll poke at it tonight. > > > > > > I think I just ran into the same problem! For now I fixed it with > > > the following small patch: > > > > That's odd because the Xapian code passes the labels straight through > > from the message to LabelManager. Try instrumenting Message#labels= to > > raise an exception if any member of the set is not a Symbol. > > I applied the following patch: > > diff --git a/lib/sup/message.rb b/lib/sup/message.rb > index 965c10e..9156c02 100644 > --- a/lib/sup/message.rb > +++ b/lib/sup/message.rb > @@ -1,4 +1,5 @@ > require 'time' > +require 'pp' > > module Redwood > > @@ -183,6 +184,7 @@ class Message > def labels= l > raise ArgumentError, "not a set" unless l.is_a?(Set) > return if @labels == l > + warn "labels=#{l.pretty_inspect}" > @labels = l > @dirty = true > end > > And get this in the logs: > > [Tue Aug 18 21:12:39 +0200 2009] WARNING: labels=# "aquarius", "music"}> > [Tue Aug 18 21:12:39 +0200 2009] WARNING: labels=# "metalblade", "music"}> > It'd be nice to get a backtrace including the offending caller. I'd just replace the warn with a fail. From benoit.pierre@gmail.com Tue Aug 18 16:14:49 2009 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=) Date: Tue, 18 Aug 2009 22:14:49 +0200 Subject: [sup-talk] crash when sup-syncing to xapian In-Reply-To: <1250624577-sup-4801@zyrg.net> References: <1250616603-sup-5612@ntdws12.chass.utoronto.ca> <1250619511-sup-2827@localdomain> <1250620771-sup-1373@zyrg.net> <1250622911-sup-2815@localdomain> <1250624577-sup-4801@zyrg.net> Message-ID: <1250626302-sup-2408@localdomain> Excerpts from Rich Lane's message of Tue Aug 18 21:52:12 +0200 2009: > Excerpts from Beno?t PIERRE's message of Tue Aug 18 15:17:03 -0400 2009: > > [...] > > It'd be nice to get a backtrace including the offending caller. I'd just > replace the warn with a fail. The problem comes from my ~/.sup/sources.yaml file, the labels for a source are not symbols: hash: relapse: true music: true After converting them to symbols it works: hash: :relapse: true :music: true -- 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 cworth@cworth.org Tue Aug 18 17:02:05 2009 From: cworth@cworth.org (Carl Worth) Date: Tue, 18 Aug 2009 14:02:05 -0700 Subject: [sup-talk] What's your sup workflow (and a spew of ideas) Message-ID: <1250629282-sup-8521@yoom> I'm now a few days into using sup, and it's clearly helped me to be more productive at processing mail, (inbox is down to 0 from *lots* of messages), so thanks! However, I still don't feel like I'm experiencing the zen of sup yet. So I'm interested in hearing from others: What is your typical workflow with sup? That is: What different modes of task do you find yourself doing with sup? Precisely what keystrokes do you use for those tasks? Where, if anywhere, does sup get in your way rather than help? What follows is my (rather long) answer to those questions, and more or less a todo list of things I'd like to help improve in sup. My desired workflow =================== I think there's a basic two-level approach I take to processing new email. Fortunately, these two modes correspond well with sup's inbox-mode and thread-view-mode. Here's what I'd like to do: Identify "unimportant" threads (no need to read) ------------------------------------------------ This is a quick scan of the thread titles in my inbox. The goal here is to identify as quickly as possible threads that I will never need to read at all, (so that they can be immediately removed from my inbox). Ideally, I will make a decision in one or two seconds, and issue a single character command to indicate the decision. Dealing with remaining "important" threads ------------------------------------------ After having eliminated as many threads as possible during the scan of the inbox, I now switch to a mode where I'm actually looking at mail messages. The goal here is to identify whether I need to do anything, and how much time that will take. There are three possible outcomes: * No action needed * Quick action, (less than two minutes) * Longer action required (to assign to some project) (Any similarity to a method proposed by David Allen in Getting Things Done is not accidental, and he deserves credit as such.) Regardless of the three results, I will be quickly archiving the thread so that it's gone from my inbox. That will be either immediate archiving, archiving after a quick action (such as a reply), or archiving after tagging the thread with a label for the appropriate project. How sup could support my workflow better ======================================== So sup obviously fits in quite well with the above model---which is why I immediately fell in love with it. So first of all I have to again say thank you. And I apologize that I will go into more detail on the things I'd like to change in sup as opposed to the things that already work so well. This isn't a criticism of the tool, just an expression of my desire to improve it. I'll phrase the list below as feature requests. Some of these things may already exist in sup, and I just missed them. In such cases, I'll be glad to hear pointers to the things I missed. Otherwise, I plan to work on developing patches for these, and I'll be glad for any help. I'll give each feature a name in [square-brackets] for easy reference in followup messages. inbox-mode ----------- * [black-on-white-color-scheme] We've talked in another thread about adding support for a black-text-on-white-background color scheme to sup-config. Before I can write a patch for that, does somebody have an example black-on-white color scheme that works well? I've been trying to come up with one but I've been unable to find how to change some colors, specifically: + [change-color-of-thread-selector] The selector for the current thread in thread-mode appears as black-foreground-on-cyan right now. I haven't been able to find the setting to make that a more easy-to-read background color, and this is the only line in the view that isn't bold when unread, (which is not ideal since it's the only line I'm trying to read and process). + [change-color-of-tag-markers] The tag markers are yellow, which is hard to see on white. I also couldn't find the setting to change this. * [import-read-messages-as-archived-from-initial-sup-config-based-sync] When I very first started using sup, (running sup-config which setup sources and ran sup-sync) I was surprised to find my inbox with thousands of unread messages in it. Now that I'm using sup more I love that sup treats inbox and unread as separate labels, (far too many email programs fail to separate those notions). But for that initial import, I think it would have been much more useful to have only given the inbox tag to unread messages. * [sort-priority-labels-before-date] The default sorting for the inbox is reverse-chronological which is a reasonable-enough default, (and works fine for me when I keep my inbox small). But when I get behind and my inbox gets large, (say after a few days away from email), I do have some tags that I would like to be sorted to the top, regardless of date. How about support for a configurable list of "priority" tags that would provide a primary sort before the date-based sort? * [save-all-state-changes-immediately] The 'a' and 'd' commands do almost exactly what I expect, (by immediately making the current thread disappear and advancing the selector to the next thread). That's perfect for fast processing. One thing missing here is that they don't actually save this state, (requiring me to hit '$' at some point). Perhaps that safety feature was more important before undo was implemented, but now that it exists, would immediate state saving make sense? The two bad side effects I've experienced due to lack of immediate saving are: 1. Seeing confusingly inconsistent results after processing a bunch of my inbox and then doing a search based on label:unread or label:inbox (Why am I seeing all these messages again?). 2. Losing a bunch of processing state due to crashes. (The crashes have been due to the mbox-processing bug which has since been fixed, but being immune to state loss for any future crashes would be beneficial.) search-results-mode ------------------- * [provide-commands-to-refine-the-current-search] I mentioned above wanting to sort priority labels before date. Similarly, when processing a very large email I sometimes want to process related messages together, (to reduce mental context switches). So I want variants of both "\, F: Search all messages" and "L: list labels" search commands that refine the current search rather than doing a new global search. That is, the new commands would simply append new search terms to the current search rather than starting a new search. * [allow-for-inbox-mode-magic-elsewhere] Another way to reword this one would be to "eliminate any magic of inbox mode". My question is, "What makes inbox-mode different than search-results-mode and how can I get the behavior of inbox-mode in my searches?". Without commands to refine the current search as described above, I've been trying to achieve results like "inbox refined to label:foo" with a search as follows: label:inbox -label:killed label:foo This gives me the set of threads that I want, but now my standard processing commands no longer work. For example, the 'a' key still removes the inbox label, but it doesn't make the tag then disappear immediately. One approach to fix this would be that when adding the commands to refine the inbox search, the new search results would also be in inbox-mode with all necessary magic. A more general fix would be to process the current thread after any changes, (such as the addition or removal of a label), and removing it from the current search results if it no longer meets those criteria. * [fix-handling-of-kill-thread-outside-inbox] The handling of the "&: kill thread" command when applied outside of the inbox, (such as in search-results-mode), is currently very confusing. What it currently seems to do is to add the killed label and make the thread disappear from the current view. But then, running "@: Refresh view" will make it reappear, (whereupon one can make it disappear again with &, ad infinitum). The removal of the thread from the current view seems to be magic associated with the kill-thread command, (leading to inconsistent behavior). I would again suggest to instead implement the general fix described above, (always reprocessing a thread after label changes to see if it still meets the current search). That way, trying to kill a thread without -label:killed in the current search would simply add the "killed" label and the user would learn to add the necessary search terms, (or to do searches based on refining the searches of existing views to inherit this term). thread-view-mode ---------------- * [override-arrow-keys-to-jump-to-next-actionable-line] In thread-view-mode the up and down arrows currently advance a selector by one line at a time, (inherited from line-cursor-mode), all the way into message bodies. As far as I can tell, this is not a useful behavior. I propose that the down arrow key should instead advance the selector to the next line which would cause a context change for the various operations that can be performed based on the selector, (or scroll to the next page if there are no such lines on the current or next page). * [be-less-overzealous-in-moving-text-to-the-left-column] I tend to use sup in a very wide terminal, (200+ columns). And I'm glad to see that the inbox-mode takes advantage of this by showing a preview of the message body (that's a nice touch!) where many console-based clients just cut things off at 80 columns. However, in thread-view-mode, sup always pushes the current message all the way over to the left-hand column. This does mean that the "current" message is visible, but I have a tendency to read much more than the current message, (even before advancing), and subsequent messages are often scrolled such that the first several columns of text are scrolled off to the left. Meanwhile, I have acres of terminal real-estate to the right that sup isn't using. I would propose that messages only be scrolled to the left if necessary to avoid the 80th column of the message body not being visible, (assuming the terminal is at least 80 columns wide). compose-mode ------------ * [repeated-postponing-shouldnt-make-additional-drafts] I find that while composing a message I often want to go look at some other messages for reference. This is currently quite awkward with sup. It would be easier if sup could be run multiple times. It would also be easier if sup could somehow fire off an editor as an external process, while still allowing for sup to be operated. As it stands, instead, I have to save and quit from my editor, postpone the message within sup, and then later come back to edit it again, and find where I was in the editor. It's an expensive context switch with a lot of keystrokes and lost state, (such as where point was inside emacs, my kill ring, etc.). I'm currently finding myself sometimes just drafting messages in emacs sessions unrelated to sup, and then doing "M-x insert-file" once sup has launched emacs for me. (This does relate a bit to the point I made in a previous thread where I would love to find a way to keep all the mail-composition tasks very separate from sup, but not lose things like replied-to bits.) Anyway, the current misfeature I'm hitting is that if I do postpone a draft, then return to edit it more, then postpone it again, etc. eventually when I send the message I'll have several partially-composed drafts in various states that I need to go and manually clean up. It seems like most email programs avoid this problem by removing the draft as soon as its selected for editing again, and I propose that sup do the same. Anyway, I've probably run into several other little things that I didn't capture in this email, but I'll hopefully remember them later. If anyone has feedback on any of the above, (and actually read this far!), then I'll appreciate getting it. Otherwise, like I said, I hope to start trying to implement some of these ideas, and when I do, I'll of course come back with separate new threads for each. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pioto@pioto.org Tue Aug 18 13:30:34 2009 From: pioto@pioto.org (Mike Kelly) Date: Tue, 18 Aug 2009 13:30:34 -0400 Subject: [sup-talk] Crash w/ current 'next' Message-ID: Hi, I just built from the current next branch, and now whenever I load sup, it gives me the attached crash. I'm guessing this is related to the Set thing William mentioned, but I have just gone from an older 'next' to a newer one, which I thought was supposed to not have this problem. Any suggestions? -- Mike Kelly -------------- next part -------------- --- ArgumentError from thread: poll after loading inbox expecting a symbol /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/label.rb:64:in `<<' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:149:in `each_message_from' /usr/local/lib/ruby/1.8/set.rb:195:in `each' /usr/local/lib/ruby/1.8/set.rb:195:in `each_key' /usr/local/lib/ruby/1.8/set.rb:195:in `each' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:149:in `each_message_from' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/source.rb:104:in `each' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `send' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:140:in `each_message_from' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:93:in `do_poll' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:81:in `each' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:81:in `do_poll' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:80:in `synchronize' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:80:in `do_poll' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:48:in `poll' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup:190 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `initialize' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `new' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup:190 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:666:in `call' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:666:in `__unprotected_load_threads' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in `call' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `initialize' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `new' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:606:in `load_n_threads_background' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:676:in `__unprotected_load_threads' (eval):12:in `load_threads' /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup:190 /usr/home/staff/mike/lib/ruby/gems/1.8/bin/sup:19:in `load' /usr/home/staff/mike/lib/ruby/gems/1.8/bin/sup:19 From cworth@cworth.org Tue Aug 18 17:46:41 2009 From: cworth@cworth.org (Carl Worth) Date: Tue, 18 Aug 2009 14:46:41 -0700 Subject: [sup-talk] What's your sup workflow (and a spew of ideas) In-Reply-To: <1250629282-sup-8521@yoom> References: <1250629282-sup-8521@yoom> Message-ID: <1250631221-sup-8993@yoom> Excerpts from Carl Worth's message of Tue Aug 18 14:02:05 -0700 2009: > Anyway, I've probably run into several other little things that I > didn't capture in this email, but I'll hopefully remember them > later. And of course, here are a few: inbox-mode ---------- * [dont-perturb-selected-thread-when-new-mail-arrives] I think I just saw the following race condition: 1. I have the top-most thread selected and I identify it as spam 2. I start moving to press the d key to delete it 3. Before I get their, new mail arrives and becomes selected 4. I delete mail I really care about I propose that new mail arriving should not cause the selector to move from the thread currently selected. label-list-mode --------------- * [allow-for-limiting-to-interesting-labels] In the workflow I described earlier, I process all mail mercilessly and get it archived and out of my inbox as quickly as possible. But some of those threads I identified as needing some significant time to deal with, so I labelled them to assign them to a particular "project". So, later, I'd like to look at my list of projects, choose one, and then choose the first task to be done. The label-list-mode is *almost* the perfect thing for this. The only problem is that it displays several labels, (with *lots* of messages each) that are not interesting to me at all in this sense. For example, killed and unread, for example, as well as several other labels that I use in ways other than my "project" labels. What I'd like here is a feature much like 'u' which toggles to display of only labels with unread messages, but insteads toggles to display only the labels that I've somehow marked as my "project" labels. (I'm not sure exactly how to name this feature for general use. The "project" sense is something personal to my usage. Maybe, "todo" or something?) inbox-mode/search-result-mode ----------------------------- * [display-number-of-unread-messages] In my ruthless scan while processing new messages, I want to be able to make split-second, yet accurate, decisions on whether I need to read messages, (and if so, how much time it will take). The current thread display shows a total number of messages within a thread, but that leads to me making an inaccurate estimate of how "expensive" it would be to read a thread. I'd much rather see the number of unread messages in the thread. Perhaps best would be to diplay both numbers such as: (1/64) with the 1 in bold to indicate that a thread with 64 total messages has 1 unread message. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From garoth@gmail.com Tue Aug 18 18:07:28 2009 From: garoth@gmail.com (Andrei Thorp) Date: Tue, 18 Aug 2009 18:07:28 -0400 Subject: [sup-talk] What's your sup workflow (and a spew of ideas) In-Reply-To: <1250629282-sup-8521@yoom> References: <1250629282-sup-8521@yoom> Message-ID: <1250632714-sup-9910@Longbow> Excerpts from Carl Worth's message of Tue Aug 18 17:02:05 -0400 2009: > * [sort-priority-labels-before-date] > > The default sorting for the inbox is reverse-chronological which is > a reasonable-enough default, (and works fine for me when I keep my > inbox small). But when I get behind and my inbox gets large, (say > after a few days away from email), I do have some tags that I would > like to be sorted to the top, regardless of date. How about support > for a configurable list of "priority" tags that would provide a > primary sort before the date-based sort? Yeah, I'd really really like this also. This has been discussed, and in general, it'd be lovely to be able to sort by hook or something. I think grouping by labels first and then by time would be a good default. > * [save-all-state-changes-immediately] > > The 'a' and 'd' commands do almost exactly what I expect, (by > immediately making the current thread disappear and advancing the > selector to the next thread). That's perfect for fast > processing. One thing missing here is that they don't actually save > this state, (requiring me to hit '$' at some point). Perhaps that > safety feature was more important before undo was implemented, but > now that it exists, would immediate state saving make sense? > > The two bad side effects I've experienced due to lack of immediate > saving are: 1. Seeing confusingly inconsistent results after > processing a bunch of my inbox and then doing a search based on > label:unread or label:inbox (Why am I seeing all these messages > again?). 2. Losing a bunch of processing state due to crashes. (The > crashes have been due to the mbox-processing bug which has since > been fixed, but being immune to state loss for any future crashes > would be beneficial.) I assume here that part of the problem is the time it takes to write changes. If I read all my morning e-mails and then press $, it usually takes a few seconds for this to finish. If it's just one e-mail, there is still usually a noticeable-ish delay. However, perhaps Xapian will improve this speed also, and if this is the case, I'd love an "autosave" option at least in the config. > * [repeated-postponing-shouldnt-make-additional-drafts] > > I find that while composing a message I often want to go look at > some other messages for reference. This is currently quite awkward > with sup. It would be easier if sup could be run multiple times. It > would also be easier if sup could somehow fire off an editor as an > external process, while still allowing for sup to be operated. > > As it stands, instead, I have to save and quit from my editor, > postpone the message within sup, and then later come back to edit it > again, and find where I was in the editor. It's an expensive context > switch with a lot of keystrokes and lost state, (such as where point > was inside emacs, my kill ring, etc.). I'm currently finding myself > sometimes just drafting messages in emacs sessions unrelated to sup, > and then doing "M-x insert-file" once sup has launched emacs for > me. (This does relate a bit to the point I made in a previous thread > where I would love to find a way to keep all the mail-composition > tasks very separate from sup, but not lose things like replied-to > bits.) > > Anyway, the current misfeature I'm hitting is that if I do postpone > a draft, then return to edit it more, then postpone it again, > etc. eventually when I send the message I'll have several > partially-composed drafts in various states that I need to go and > manually clean up. It seems like most email programs avoid this > problem by removing the draft as soon as its selected for editing > again, and I propose that sup do the same. I think I agree there, and vaguely recall someone attempting to implement being able to switch buffers even when an external editor is in effect. Anyway, impressive post there. You seem to really abuse your e-mail client and know what you're on about. Good stuff. -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From cworth@cworth.org Tue Aug 18 18:16:08 2009 From: cworth@cworth.org (Carl Worth) Date: Tue, 18 Aug 2009 15:16:08 -0700 Subject: [sup-talk] What's your sup workflow (and a spew of ideas) In-Reply-To: <1250632714-sup-9910@Longbow> References: <1250629282-sup-8521@yoom> <1250632714-sup-9910@Longbow> Message-ID: <1250633501-sup-3981@yoom> Excerpts from Andrei Thorp's message of Tue Aug 18 15:07:28 -0700 2009: > Excerpts from Carl Worth's message of Tue Aug 18 17:02:05 -0400 2009: > > Anyway, the current misfeature I'm hitting is that if I do postpone > > a draft, then return to edit it more, then postpone it again, > > etc. eventually when I send the message I'll have several > > partially-composed drafts in various states that I need to go and > > manually clean up. It seems like most email programs avoid this > > problem by removing the draft as soon as its selected for editing > > again, and I propose that sup do the same. > > I think I agree there, and vaguely recall someone attempting to > implement being able to switch buffers even when an external editor is > in effect. That would be nice. In the meantime, I have realized that I don't need to actually postpone my messages to do what I want---I can just exit the editor and then switch buffers from compose-mode/reply-mode. So that at least avoids the multiple-drafts issue, (but still leaves the I-lose-my-state-when-I-quit-the-editor issue). > Anyway, impressive post there. You seem to really abuse your e-mail > client and know what you're on about. Good stuff. Thanks. I have had a lot of ideas cooking for years about what my dream email-system would look like. I think the impressive bit is that of the half-dozen programs I've used in the last decade, sup is the first one to get me to write up a post like that. (All other programs were so far away from what I wanted as to make it infeasible to fix them incrementally.) -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rlane@club.cc.cmu.edu Tue Aug 18 19:02:01 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Tue, 18 Aug 2009 19:02:01 -0400 Subject: [sup-talk] What's your sup workflow (and a spew of ideas) In-Reply-To: <1250629282-sup-8521@yoom> References: <1250629282-sup-8521@yoom> Message-ID: <1250634897-sup-4631@zyrg.net> provide-commands-to-refine-the-current-search: '|' exists for search-results-mode (and it should be implemented for label-results-mode if it doesn't exist there). sort-priority-labels-before-date: This isn't entirely easy for large numbers of messages. We've optimized the index (especially Xapian) for reverse chronological order. You could either do the sorting entirely in the UI, but just on the subset of results currently loaded, or you could create a new mode that merges and prioritizes the results of multiple queries. allow-for-limiting-to-interesting-labels: I have a hack for this. I reopen Redwood::Mode in the startup hook, then add a keybinding to spawn a SearchResultsMode for a set of interesting labels. Same for starred messages. A better solution would be good. save-all-state-changes-immediately, allow-for-inbox-mode-magic-elsewhere, fix-handling-of-kill-thread-outside-inbox: These are related - saving label changes immediately means we can use the index to decide which threads are relevant. The new index api methods unblock this, and now that they're in next I plan to implement this soon. be-less-overzealous-in-moving-text-to-the-left-column, dont-perturb-selected-thread-when-new-mail-arrives: +1 to these. From kevinr@free-dissociation.com Tue Aug 18 19:36:15 2009 From: kevinr@free-dissociation.com (Kevin Riggle) Date: Tue, 18 Aug 2009 19:36:15 -0400 Subject: [sup-talk] [PATCH] Add an after-add-message hook In-Reply-To: <1250618123-sup-8797@masanjin.net> References: <1250459229-4500-1-git-send-email-kevinr@free-dissociation.com> <1250618123-sup-8797@masanjin.net> Message-ID: <1250638381-sup-2952@black-opal.mit.edu> Excerpts from William Morgan's message of Tue Aug 18 13:56:15 -0400 2009: > Reformatted excerpts from Kevin Riggle's message of 2009-08-16: > > I want to do some unrelated processing on each message I receive, but > > I don't want to block the message being added to the index. This > > patch adds a hook which runs /after/ the message is added to the > > index. > > Won't this block subsequent emails from being added to the index, when > Sup gets multiple new emails during a poll? I don't /think/ so, unless I misunderstand the way hooks work. I assumed the hook would execute and then execution of the loop would resume, and I don't think I throw anything in the hook which should cause that either. - Kevin -- Kevin Riggle (kevinr at free-dissociation.com) http://free-dissociation.com From bwalton@artsci.utoronto.ca Tue Aug 18 20:03:49 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Tue, 18 Aug 2009 20:03:49 -0400 Subject: [sup-talk] crash when sup-syncing to xapian In-Reply-To: <1250626302-sup-2408@localdomain> References: <1250616603-sup-5612@ntdws12.chass.utoronto.ca> <1250619511-sup-2827@localdomain> <1250620771-sup-1373@zyrg.net> <1250622911-sup-2815@localdomain> <1250624577-sup-4801@zyrg.net> <1250626302-sup-2408@localdomain> Message-ID: <1250640188-sup-7551@ntdws12.chass.utoronto.ca> Excerpts from Beno?t PIERRE's message of Tue Aug 18 16:14:49 -0400 2009: > After converting them to symbols it works: > > hash: > :relapse: true > :music: true I have labels setup to import as an array (of strings)...is this not the way it's supposed to be? -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Tue Aug 18 20:49:03 2009 From: cworth@cworth.org (Carl Worth) Date: Tue, 18 Aug 2009 17:49:03 -0700 Subject: [sup-talk] Exception trying to run git source Message-ID: <1250642676-sup-2244@yoom> Until now I've been running sup 0.8.1 from a Debian package. But in an effort to get to where I can actually start implementing some of the features I want, (and to get to where I can actually send a message without triggering sent.mbox crashes), I'm trying to move to running sup from a git checkout. But whenever I try, I get the following exception: --- NoMethodError from thread: main undefined method `source_uri' for # ./lib/sup/util.rb:519:in `send' ./lib/sup/util.rb:519:in `method_missing' bin/sup:171 I bisected this down to the following commit: commit 5057149d9c3b57c6b5c4d0964a0aae9d490aaa38 Author: Ben Walton Date: Wed May 6 22:44:24 2009 -0400 SentManager: rework handling to allow for user specified source That looks like an awfully nice commit since I'd like my sent messages to go into a maildir anyway. So I tried configuring this by adding a line to my ~/.sup/config.yaml as follows: :sent_source: maildir:/home/cworth/mail/sent That didn't actually help too much, it just changed the stack trace slightly: --- NoMethodError from thread: main undefined method `source_uri' for # ./lib/sup/util.rb:519:in `send' ./lib/sup/util.rb:519:in `method_missing' bin/sup:171 So what am I actually missing here? -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Tue Aug 18 21:58:55 2009 From: cworth@cworth.org (Carl Worth) Date: Tue, 18 Aug 2009 18:58:55 -0700 Subject: [sup-talk] What's your sup workflow (and a spew of ideas) In-Reply-To: <1250634897-sup-4631@zyrg.net> References: <1250629282-sup-8521@yoom> <1250634897-sup-4631@zyrg.net> Message-ID: <1250646478-sup-4064@yoom> Excerpts from Rich Lane's message of Tue Aug 18 16:02:01 -0700 2009: > provide-commands-to-refine-the-current-search: > > '|' exists for search-results-mode (and it should be implemented for > label-results-mode if it doesn't exist there). Ah, thanks for pointing this out. I totally missed it somehow. This doesn't exist for inbox-mode, which is where I think I would like it the most. And conceptually, the inbox is just a search, right? It seems to me that inbox-mode should be at most a very slight tweak of search-results-mode. I'll go digging in the code to see how far away that would be. For what it's worth, | doesn't exist for search-results mode. And also, the shortcuts to refine the search by adding a label would be nice too, (so one wouldn't need to type "label:"). So now I at least know what already exists. > sort-priority-labels-before-date: > > This isn't entirely easy for large numbers of messages. We've optimized > the index (especially Xapian) for reverse chronological order. You could > either do the sorting entirely in the UI, but just on the subset of > results currently loaded, or you could create a new mode that merges and > prioritizes the results of multiple queries. I think the former would be fine. The UI encourages only a small number of results to be loaded already, so just sorting there should work find I thin. > allow-for-limiting-to-interesting-labels: > > I have a hack for this. I reopen Redwood::Mode in the startup hook, then > add a keybinding to spawn a SearchResultsMode for a set of interesting > labels. Same for starred messages. A better solution would be good. While waiting for a better solution, would you mind sharing your code for this? I'm quite new to ruby, so even if what you described should be trivial for me to replicate, it's not yet. :-) Maybe a page on the wiki? > save-all-state-changes-immediately, > allow-for-inbox-mode-magic-elsewhere, > fix-handling-of-kill-thread-outside-inbox: > > These are related - saving label changes immediately means we can use > the index to decide which threads are relevant. The new index api > methods unblock this, and now that they're in next I plan to implement > this soon. Excellent. It did seem that things were moving this direction, and I'm glad to hear that they are. > be-less-overzealous-in-moving-text-to-the-left-column, > dont-perturb-selected-thread-when-new-mail-arrives: > > +1 to these. Great. And those don't sound too complicated, so maybe I'll try cutting my teeth on those first. Meanwhile, I thought of another race condition. If new mail arrives for the current thread when in thread-view-mode, does it get added to the view? It might seem nice for it to show up, but it might also lead to it getting accidentally archived away if I "knew" that there were only 4 messages, say, when I entered the thread view, then I hit ".a" and archived away 5 messages. It seems a silly thing, but it's the kind of thing that makes me start distrusting ".a" and instead using "x", double-checking, then "a" which is obviously less efficient. (Oh, and there's another place where the current selector needs to not be perturbed. After I hit "x" from thread-view-mode I find that a different thread can be selected than the one I was just viewing if new mail arrived.) -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Tue Aug 18 22:47:40 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Tue, 18 Aug 2009 22:47:40 -0400 Subject: [sup-talk] Exception trying to run git source In-Reply-To: <1250642676-sup-2244@yoom> References: <1250642676-sup-2244@yoom> Message-ID: <1250649988-sup-9079@ntdws12.chass.utoronto.ca> Excerpts from Carl Worth's message of Tue Aug 18 20:49:03 -0400 2009: > > --- NoMethodError from thread: main > undefined method `source_uri' for # @source=nil, @fn="sup://sent"> > ./lib/sup/util.rb:519:in `send' > ./lib/sup/util.rb:519:in `method_missing' > bin/sup:171 Hmm...I think that's likely an easy fix. I'll look tomorrow morning. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rlane@club.cc.cmu.edu Tue Aug 18 23:02:57 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Tue, 18 Aug 2009 23:02:57 -0400 Subject: [sup-talk] What's your sup workflow (and a spew of ideas) In-Reply-To: <1250646478-sup-4064@yoom> References: <1250629282-sup-8521@yoom> <1250634897-sup-4631@zyrg.net> <1250646478-sup-4064@yoom> Message-ID: <1250649270-sup-2166@zyrg.net> Excerpts from Carl Worth's message of Tue Aug 18 21:58:55 -0400 2009: > > allow-for-limiting-to-interesting-labels: > > > > I have a hack for this. I reopen Redwood::Mode in the startup hook, then > > add a keybinding to spawn a SearchResultsMode for a set of interesting > > labels. Same for starred messages. A better solution would be good. > > While waiting for a better solution, would you mind sharing your code > for this? I'm quite new to ruby, so even if what you described should > be trivial for me to replicate, it's not yet. :-) > > Maybe a page on the wiki? Sure, I added an example to the end of the Hooks page. > Meanwhile, I thought of another race condition. If new mail arrives > for the current thread when in thread-view-mode, does it get added to > the view? It might seem nice for it to show up, but it might also lead > to it getting accidentally archived away if I "knew" that there were > only 4 messages, say, when I entered the thread view, then I hit ".a" > and archived away 5 messages. > > It seems a silly thing, but it's the kind of thing that makes me start > distrusting ".a" and instead using "x", double-checking, then "a" > which is obviously less efficient. (Oh, and there's another place > where the current selector needs to not be perturbed. After I hit "x" > from thread-view-mode I find that a different thread can be selected > than the one I was just viewing if new mail arrived.) I'm glad to know there are other people annoyed by UI race conditions :). Even after a quick look at the code I'm not sure what ThreadViewMode will do when a thread is added to. It might actually archive/read/etc new messages but not display them. I'd like a keybinding to reload/redisplay the thread and a status bar note if there are new messages. Any label changes should only affect messages that have been displayed. What do you think? From garoth@gmail.com Wed Aug 19 10:03:49 2009 From: garoth@gmail.com (Andrei Thorp) Date: Wed, 19 Aug 2009 10:03:49 -0400 Subject: [sup-talk] What's your sup workflow (and a spew of ideas) In-Reply-To: <1250649270-sup-2166@zyrg.net> References: <1250629282-sup-8521@yoom> <1250634897-sup-4631@zyrg.net> <1250646478-sup-4064@yoom> <1250649270-sup-2166@zyrg.net> Message-ID: <1250690604-sup-4154@Longbow> Excerpts from Rich Lane's message of Tue Aug 18 23:02:57 -0400 2009: > I'm glad to know there are other people annoyed by UI race conditions :). > Even after a quick look at the code I'm not sure what ThreadViewMode > will do when a thread is added to. It might actually archive/read/etc > new messages but not display them. > > I'd like a keybinding to reload/redisplay the thread and a status bar > note if there are new messages. Any label changes should only affect > messages that have been displayed. What do you think? Ooh, I like it. I guess gmail does this. -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From bwalton@artsci.utoronto.ca Wed Aug 19 11:59:12 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Wed, 19 Aug 2009 11:59:12 -0400 Subject: [sup-talk] Exception trying to run git source In-Reply-To: <1250642676-sup-2244@yoom> References: <1250642676-sup-2244@yoom> Message-ID: <1250697503-sup-1083@ntdws12.chass.utoronto.ca> Excerpts from Carl Worth's message of Tue Aug 18 20:49:03 -0400 2009: > line to my ~/.sup/config.yaml as follows: > > :sent_source: maildir:/home/cworth/mail/sent Here is my configuration: maildir:///u/bwalton/Maildir/.sent-mail/ I think you just need to fix the URI. I'm looking into the code though to see why it bombed out on you. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Wed Aug 19 12:19:44 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 19 Aug 2009 09:19:44 -0700 Subject: [sup-talk] Exception trying to run git source In-Reply-To: <1250642676-sup-2244@yoom> References: <1250642676-sup-2244@yoom> Message-ID: <1250698636-sup-6732@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-18: > --- NoMethodError from thread: main > undefined method `source_uri' for # @source=nil, @fn="sup://sent"> Very curious. SentManager most definitely has a source_uri method. If you look at lib/sup/sent.rb, does it include the line "attr_reader :source, :source_uri"? If so, is there a line in the log that says "SentManager initialized with source uri: xxx"? -- William From cworth@cworth.org Wed Aug 19 12:33:10 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 19 Aug 2009 09:33:10 -0700 Subject: [sup-talk] Exception trying to run git source In-Reply-To: <1250698636-sup-6732@masanjin.net> References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net> Message-ID: <1250699408-sup-9579@yoom> Excerpts from William Morgan's message of Wed Aug 19 09:19:44 -0700 2009: > Reformatted excerpts from Carl Worth's message of 2009-08-18: > > --- NoMethodError from thread: main > > undefined method `source_uri' for # > @source=nil, @fn="sup://sent"> > > Very curious. SentManager most definitely has a source_uri method. If > you look at lib/sup/sent.rb, does it include the line "attr_reader > :source, :source_uri"? Yes, that is there. > If so, is there a line in the log that says > "SentManager initialized with source uri: xxx"? No, I don't think so. At least, that is, if I'm looking at the right place. Is the "log" anything other than the output on stdout/err when I run sup? Do I need to turn on any additional verbosity somehow? Below you can see the entire output I get when running sup from git master. -Carl (wishing he had any skills for debugging ruby...) 0:~/src/sup:(master)$ ruby -I lib -w bin/sup ./lib/sup/util.rb:8: warning: method redefined; discarding old gen_lock_id ./lib/sup/util.rb:19: warning: method redefined; discarding old dump_lock_id [Wed Aug 19 09:22:55 -0700 2009] using character set encoding "UTF-8" ./lib/sup/message-chunks.rb:36: warning: method redefined; discarding old make_tmpname ./lib/sup/imap.rb:117: warning: ambiguous first argument; put parentheses or even spaces /usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:13: warning: useless use of > in void context /usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:19: warning: useless use of > in void context /usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:25: warning: useless use of < in void context [Wed Aug 19 09:22:55 -0700 2009] using index Redwood::FerretIndex Warning: $KCODE is NONE. [Wed Aug 19 09:22:55 -0700 2009] dynamically loading setlocale() from libc.so.6 [Wed Aug 19 09:22:55 -0700 2009] setting locale... [Wed Aug 19 09:22:55 -0700 2009] locking /home/cworth/.sup/lock... [Wed Aug 19 09:22:55 -0700 2009] crypto: detected gpg binary in /usr/bin/gpg [Wed Aug 19 09:22:55 -0700 2009] loading index... [Wed Aug 19 09:22:55 -0700 2009] loaded index of 557361 messages ./lib/sup/index.rb:53: warning: instance variable @lock_update_thread not initialized bin/sup:126: warning: global variable `$cursing' not initialized [Wed Aug 19 09:22:55 -0700 2009] stopped cursing [Wed Aug 19 09:22:55 -0700 2009] oh crap, an exception [Wed Aug 19 09:22:55 -0700 2009] unlocking /home/cworth/.sup/lock... ---------------------------------------------------------------- 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 address this problem. Thank you! Sincerely, William ---------------------------------------------------------------- --- NoMethodError from thread: main undefined method `source_uri' for # ./lib/sup/util.rb:519:in `send' ./lib/sup/util.rb:519:in `method_missing' bin/sup:171 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Wed Aug 19 12:34:09 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Wed, 19 Aug 2009 12:34:09 -0400 Subject: [sup-talk] Exception trying to run git source In-Reply-To: <1250698636-sup-6732@masanjin.net> References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net> Message-ID: <1250699596-sup-8133@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Wed Aug 19 12:19:44 -0400 2009: > Reformatted excerpts from Carl Worth's message of 2009-08-18: > > --- NoMethodError from thread: main > > undefined method `source_uri' for # > @source=nil, @fn="sup://sent"> > > Very curious. SentManager most definitely has a source_uri method. If > you look at lib/sup/sent.rb, does it include the line "attr_reader > :source, :source_uri"? If so, is there a line in the log that says > "SentManager initialized with source uri: xxx"? Also, is bin/sup part of your git checkout (meaning it lines up with the rest of your lib/, etc)? Are you running from the next branch? I'm looking at bin/sup here (5f393122), and the line numbers don't "add up." Line 152 is where I see the call into SentManager.source_uri, not 171. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Wed Aug 19 13:53:54 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 19 Aug 2009 10:53:54 -0700 Subject: [sup-talk] Exception trying to run git source In-Reply-To: <1250699596-sup-8133@ntdws12.chass.utoronto.ca> References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net> <1250699596-sup-8133@ntdws12.chass.utoronto.ca> Message-ID: <1250704257-sup-3308@yoom> Excerpts from Ben Walton's message of Wed Aug 19 09:34:09 -0700 2009: > Also, is bin/sup part of your git checkout (meaning it lines up with > the rest of your lib/, etc)? Yes. > Are you running from the next branch? > I'm looking at bin/sup here (5f393122), and the line numbers don't > "add up." Line 152 is where I see the call into > SentManager.source_uri, not 171. No, I was running from master, (so line 171 does make sense there). I tried running from next and got a different failure (see below). I suspected I might have something just broken in my configuration, so I moved ~/.sup away for the run below, (which didn't seem to change anything). This new failure seems to be occurring earlier, so I bisected, (labelling the previous source_uri exception as "good" and the new no-SentManager-instance as "bad"), and that pointed at the following commit: 9dd4f50b9f62ab5642241359bf6f7c291ccfa738 is first bad commit commit 9dd4f50b9f62ab5642241359bf6f7c291ccfa738 Author: William Morgan Date: Wed Aug 12 13:14:34 2009 -0400 rewrite Singleton to not require i_am_the_instance The flip side is that you have to use .init instead of .new. I'm really wondering why I'm getting what appear to be unique crashes compared to others. Is it my ruby version: $ ruby --version ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux] Any ideas? -Carl 0:~/src/sup:(next)$ ruby -I lib -w ./bin/sup ./lib/sup/util.rb:9: warning: method redefined; discarding old gen_lock_id ./lib/sup/util.rb:20: warning: method redefined; discarding old dump_lock_id ./lib/sup/message-chunks.rb:36: warning: method redefined; discarding old make_tmpname ./lib/sup/imap.rb:118: warning: ambiguous first argument; put parentheses or even spaces /usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:13: warning: useless use of > in void context /usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:19: warning: useless use of > in void context /usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:25: warning: useless use of < in void context [Wed Aug 19 10:26:50 -0700 2009] WARNING: Warning: $KCODE is NONE. ./lib/sup/index.rb:54: warning: instance variable @lock_update_thread not initialized ./bin/sup:127: warning: global variable `$cursing' not initialized ./bin/sup:329: warning: global variable `$die' not initialized [Wed Aug 19 10:26:50 -0700 2009] ERROR: oh crap, an exception ---------------------------------------------------------------- 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 address this problem. Thank you! Sincerely, William ---------------------------------------------------------------- --- RuntimeError from thread: main no Redwood::SentManager instance defined in method call to i_am_the_instance! ./lib/sup/util.rb:512:in `method_missing' /usr/lib/ruby/1.8/sup/sent.rb:10:in `initialize' ./lib/sup/util.rb:524:in `new' ./lib/sup/util.rb:524:in `init' ./lib/sup.rb:110:in `start' ./bin/sup:138 From bwalton@artsci.utoronto.ca Wed Aug 19 14:08:19 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Wed, 19 Aug 2009 14:08:19 -0400 Subject: [sup-talk] Exception trying to run git source In-Reply-To: <1250704257-sup-3308@yoom> References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net> <1250699596-sup-8133@ntdws12.chass.utoronto.ca> <1250704257-sup-3308@yoom> Message-ID: <1250705105-sup-7923@ntdws12.chass.utoronto.ca> Excerpts from Carl Worth's message of Wed Aug 19 13:53:54 -0400 2009: > $ ruby --version > ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux] I'm running the (now fossilized): $ ruby --version ruby 1.8.5 (2006-08-25) [i386-linux] (as shipped with rhel5). > Any ideas? Not right now, but I'll think about it. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Wed Aug 19 14:39:56 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 19 Aug 2009 11:39:56 -0700 Subject: [sup-talk] crash when sup-syncing to xapian In-Reply-To: <1250616603-sup-5612@ntdws12.chass.utoronto.ca> References: <1250616603-sup-5612@ntdws12.chass.utoronto.ca> Message-ID: <1250707129-sup-7698@masanjin.net> Reformatted excerpts from Ben Walton's message of 2009-08-18: > There is something wonky with label handling, as per attached > exception log. This should be fixed in next. It was a result of some of the API refactoring I've been doing recently. Everyone's source.yaml should now automagically revert to the format from the good ol' days. -- William From wmorgan-sup@masanjin.net Wed Aug 19 14:52:26 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 19 Aug 2009 11:52:26 -0700 Subject: [sup-talk] Exception trying to run git source In-Reply-To: <1250704257-sup-3308@yoom> References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net> <1250699596-sup-8133@ntdws12.chass.utoronto.ca> <1250704257-sup-3308@yoom> Message-ID: <1250707794-sup-6173@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-19: > ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux] Fine. > no Redwood::SentManager instance defined in method call to i_am_the_instance! > ./lib/sup/util.rb:512:in `method_missing' > /usr/lib/ruby/1.8/sup/sent.rb:10:in `initialize' > ./lib/sup/util.rb:524:in `new' > ./lib/sup/util.rb:524:in `init' > ./lib/sup.rb:110:in `start' > ./bin/sup:138 Do you get this error in next head, and in the "first bad commit" you reported? Neither of those should have any calls to i_am_the_instance! anywhere in the code. -- William From wmorgan-sup@masanjin.net Wed Aug 19 14:52:56 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 19 Aug 2009 11:52:56 -0700 Subject: [sup-talk] Crash w/ current 'next' In-Reply-To: References: Message-ID: <1250707961-sup-5229@masanjin.net> Reformatted excerpts from Mike Kelly's message of 2009-08-18: > I just built from the current next branch, and now whenever I load > sup, it gives me the attached crash. Should be fixed. Sorry about that. -- William From wmorgan-sup@masanjin.net Wed Aug 19 14:55:03 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 19 Aug 2009 11:55:03 -0700 Subject: [sup-talk] [PATCH] Add an after-add-message hook In-Reply-To: <1250638381-sup-2952@black-opal.mit.edu> References: <1250459229-4500-1-git-send-email-kevinr@free-dissociation.com> <1250618123-sup-8797@masanjin.net> <1250638381-sup-2952@black-opal.mit.edu> Message-ID: <1250707991-sup-5429@masanjin.net> Reformatted excerpts from Kevin Riggle's message of 2009-08-18: > I don't /think/ so, unless I misunderstand the way hooks work. I > assumed the hook would execute and then execution of the loop would > resume, and I don't think I throw anything in the hook which should > cause that either. What I'm saying is that this hook will execute *after* each message is added to the index, so if Sup found several new messages, all except the first one will wait on this hook to execute before being added to the index. Or do you mean block in some sense besides "wait for completion"? -- William From cworth@cworth.org Wed Aug 19 15:40:15 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 19 Aug 2009 12:40:15 -0700 Subject: [sup-talk] Exception trying to run git source In-Reply-To: <1250707794-sup-6173@masanjin.net> References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net> <1250699596-sup-8133@ntdws12.chass.utoronto.ca> <1250704257-sup-3308@yoom> <1250707794-sup-6173@masanjin.net> Message-ID: <1250710221-sup-925@yoom.home.cworth.org> Excerpts from William Morgan's message of Wed Aug 19 11:52:26 -0700 2009: > > no Redwood::SentManager instance defined in method call to i_am_the_instance! > > ./lib/sup/util.rb:512:in `method_missing' > > /usr/lib/ruby/1.8/sup/sent.rb:10:in `initialize' > > ./lib/sup/util.rb:524:in `new' > > ./lib/sup/util.rb:524:in `init' > > ./lib/sup.rb:110:in `start' > > ./bin/sup:138 > > Do you get this error in next head, and in the "first bad commit" you > reported? Yes. > Neither of those should have any calls to i_am_the_instance! > anywhere in the code. Thanks. That confirms that I'm not running the code I think I am, and the above stack trace makes that obvious, (see /usr/lib/ruby/1.8/sup/sent.rb). So I was running some unholy mixture of the installed Debian sup and the from-git sup and it worked no better than one would expect. My previously reported crashes didn't happen to fail in a way that made /usr/lib show up in the stack trace, but both crashes are fixed by just moving /usr/lib/ruby/1.8/sup out of the way. So I'm glad to have things working now, but I'm still curious to know why ruby goes digging into /usr/lib/ruby/1.8 to find sup/sent.rb when there's a ./lib/sub/sent.rb present and I've passed a "-I ./lib" option to ruby, (and plainly, ruby is interpreting other files from ./lib). And I'd be glad if someone could recommend a ruby-esque way to debug a situation like this. I mean, I could obviously have just run ruby under strace and looked for the paths of various *.rb files getting loaded, but surely there's some more ruby-specific way to list files that are being used? -Carl PS. I'm intrigued by the following mention: You?ve got the same sort of command-line debugger available. [http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/to-ruby-from-c-and-c-/] so that's clearly something I'm going to have to learn to use. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Wed Aug 19 16:02:26 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 19 Aug 2009 13:02:26 -0700 Subject: [sup-talk] Exception trying to run git source In-Reply-To: <1250710221-sup-925@yoom.home.cworth.org> References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net> <1250699596-sup-8133@ntdws12.chass.utoronto.ca> <1250704257-sup-3308@yoom> <1250707794-sup-6173@masanjin.net> <1250710221-sup-925@yoom.home.cworth.org> Message-ID: <1250712045-sup-3506@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-19: > Thanks. That confirms that I'm not running the code I think I am, Good, that explains a lot. > So I'm glad to have things working now, but I'm still curious to know > why ruby goes digging into /usr/lib/ruby/1.8 to find sup/sent.rb when > there's a ./lib/sub/sent.rb present and I've passed a "-I ./lib" > option to ruby, (and plainly, ruby is interpreting other files from > ./lib). I find it surprising too. I haven't seen taht behavior before. FWIW, Sup does try and detect if bin/sup and lib/sup have mismatched versions, and that didn't fire... I wonder if it's just sent.rb that's been loaded. Did you somehow delete sent.rb from your git directory, or something like that? -- William From benoit.pierre@gmail.com Wed Aug 19 16:56:55 2009 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=) Date: Wed, 19 Aug 2009 22:56:55 +0200 Subject: [sup-talk] [PATCH] fix garbaged text in textfield when using ncursesw Message-ID: <1250715278-sup-1941@localdomain> Apparently, field_buffer content is not initialized to blanks when using the wide-character version of ncurses. Forcing a call to set_field_buffer fix the problem. --- lib/sup/textfield.rb | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/sup/textfield.rb b/lib/sup/textfield.rb index b8dec59..76803bf 100644 --- a/lib/sup/textfield.rb +++ b/lib/sup/textfield.rb @@ -35,9 +35,9 @@ class TextField @completion_block = block @field = Ncurses::Form.new_field 1, @width - question.length, @y, @x + question.length, 256, 0 @form = Ncurses::Form.new_form [@field] - @value = default + @value = default || '' Ncurses::Form.post_form @form - set_cursed_value default if default + set_cursed_value @value end def position_cursor -- 1.6.3.3 -- 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 dato@net.com.org.es Wed Aug 19 17:22:09 2009 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=) Date: Wed, 19 Aug 2009 22:22:09 +0100 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset" variable with the attachment charset In-Reply-To: <20090730155656.GA20442@chistera.yi.org> References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es> <20090723093543.GA2265@chistera.yi.org> <1248713434-sup-4961@entry> <20090730155656.GA20442@chistera.yi.org> Message-ID: <20090819212209.GA10883@chistera.yi.org> Ping? + Adeodato Sim? (Thu, 30 Jul 2009 17:56:56 +0200): > + William Morgan (Mon, 27 Jul 2009 09:51:17 -0700): > > Reformatted excerpts from Adeodato Sim?'s message of 2009-07-23: > > > + Adeodato Sim? (Fri, 10 Jul 2009 17:00:29 +0200): > > > > + :charset => encoded_content.charset, > > > Hm, so apparently encoded_content doesn't always have a charset > > > member... > > In which case that value of that variable is nil, right? Is that a > > problem? The patch still seems useful. > Yes, I took a closer look and you're right the result of > encoded_content.charset is nil in that case. I also saw (I think) where > the traceback I was seeing is coming from: apparently it's not possible > to pass to HookContext a local that is nil, since then "super" will get > called in HookContext::method_missing() as far as I can see. > So, perhaps, to fix this patch, one could do: > :charset => encoded_content.charset || '' > But then, I think it would be better to fix HookContext to allow for > @__locals to contain nil. I'm not very familiar with that class, but it > seems easy enough to fix, see upcoming patch (also found in > ~dato/sup/sup-dato:fixes at Gitorious, if you prefer that). With it, > this improvement to mime-decode seems to work without any further > trouble. > Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai From cworth@cworth.org Wed Aug 19 17:37:15 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 19 Aug 2009 14:37:15 -0700 Subject: [sup-talk] Exception trying to run git source In-Reply-To: <1250712045-sup-3506@masanjin.net> References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net> <1250699596-sup-8133@ntdws12.chass.utoronto.ca> <1250704257-sup-3308@yoom> <1250707794-sup-6173@masanjin.net> <1250710221-sup-925@yoom.home.cworth.org> <1250712045-sup-3506@masanjin.net> Message-ID: <1250717434-sup-4489@yoom.home.cworth.org> Excerpts from William Morgan's message of Wed Aug 19 13:02:26 -0700 2009: > I find it surprising too. I haven't seen taht behavior before. FWIW, Sup > does try and detect if bin/sup and lib/sup have mismatched versions, and > that didn't fire... I wonder if it's just sent.rb that's been loaded. > Did you somehow delete sent.rb from your git directory, or something > like that? Nope. The git checkout is entirely intact, and it was quite a large number of modules getting misloaded. I ran an strace on the ruby process[*] and was able to plainly see that modules were being correctly loaded from ./lib until after /usr/lib/ruby/1.8/chronic.rb was loaded. After that, ruby would look for modules in /usr/lib/ruby/1.8 before ./lib. And sure enough, the first line of my chronic.rb has: $:.unshift File.dirname(__FILE__) # For use/testing when no gem is installed I'll go ahead and find the right place to file that bug, but at least the mystery is solved now. -Carl [*] http://cworth.org/~cworth/tmp/ruby-sup.strace -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wirtwolff@gmail.com Wed Aug 19 16:41:54 2009 From: wirtwolff@gmail.com (Wirt Wolff) Date: Wed, 19 Aug 2009 14:41:54 -0600 Subject: [sup-talk] In next: thread-view-mode labelling No method join for Set Message-ID: <1250714501-sup-3033@chigamba> Lots of great improvements in next. Love the utf8. When I try to 'l'abel in thread view mode, however, sup crashes with --- NoMethodError from thread: main undefined method `join' for # ./lib/sup/buffer.rb:506:in `ask_for_labels' ./lib/sup/util.rb:520:in `send' ./lib/sup/util.rb:520:in `method_missing' ./lib/sup/modes/thread-view-mode.rb:253:in `edit_labels' ./lib/sup/mode.rb:50:in `send' ./lib/sup/mode.rb:50:in `handle_input' ./lib/sup/buffer.rb:260:in `handle_input' ---------------------------------------- Most recent commit is Merge branch 'various-api-refactors' into next commit 3de96fb9b308afe600c7ccfcee75913f039ef4f6 run with % ruby -Ilib bin/sup ---------------------------------------- Advice how to fix? thanks, -- wmw From cworth@cworth.org Wed Aug 19 19:21:08 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 19 Aug 2009 16:21:08 -0700 Subject: [sup-talk] What's your sup workflow (and a spew of ideas) In-Reply-To: <1250649270-sup-2166@zyrg.net> References: <1250629282-sup-8521@yoom> <1250634897-sup-4631@zyrg.net> <1250646478-sup-4064@yoom> <1250649270-sup-2166@zyrg.net> Message-ID: <1250723746-sup-4632@yoom.home.cworth.org> Excerpts from Rich Lane's message of Tue Aug 18 20:02:57 -0700 2009: > Excerpts from Carl Worth's message of Tue Aug 18 21:58:55 -0400 2009: > > Maybe a page on the wiki? > > Sure, I added an example to the end of the Hooks page. Excellent. That looks very helpful. And looking closer at the hooks wiki page, I see that it shows me how to label incoming mail with ruby code, (which I've been wanting to switch to instead of using maildrop to deliver mail to different maildirs, and sup adding labels based on the source). The hooks page also shows me how to display the number of unread messages in a thread like I wanted, (though I'll still propose that for sup itself rather than relying on a user hook for this). So thanks for the encouragement to take a closer look at this page. > I'm glad to know there are other people annoyed by UI race conditions :). > Even after a quick look at the code I'm not sure what ThreadViewMode > will do when a thread is added to. It might actually archive/read/etc > new messages but not display them. That was definitely my fear. > I'd like a keybinding to reload/redisplay the thread and a status bar > note if there are new messages. Any label changes should only affect > messages that have been displayed. What do you think? Only affecting messages that have been displayed is the critical piece, yes. Adding a status bar notice would be a nice addition. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Wed Aug 19 20:31:12 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 19 Aug 2009 17:31:12 -0700 Subject: [sup-talk] In next: thread-view-mode labelling No method join for Set In-Reply-To: <1250714501-sup-3033@chigamba> References: <1250714501-sup-3033@chigamba> Message-ID: <1250727630-sup-3112@yoom.home.cworth.org> Excerpts from Wirt Wolff's message of Wed Aug 19 13:41:54 -0700 2009: > Lots of great improvements in next. Love the utf8. Agreed. These are very nice. > When I try to 'l'abel in thread view mode, however, sup crashes with > > --- NoMethodError from thread: main > undefined method `join' for # > ./lib/sup/buffer.rb:506:in `ask_for_labels' I'm getting that too. It bisected down to the following which is not so surprising: commit 7aea418a8a62b7070eee764475fcfc0bdd8d58dd Author: William Morgan Date: Tue Aug 11 16:00:52 2009 -0400 maintain labels as Sets rather than arrays I've attached a patch that at least makes the crashes I was able ro reproduce go away. But I have no idea if I got them all of course[*]. And please let me know if I'm doing anything wrong. I'm new to ruby as well as sup here, so go easy on me, please! :-) -Carl [*] Totally off-topic: This is one of the things about "dynamically typed" languages that I've never been able to wrap my brain around. I really like that with static typing I can trust the compiler to help me be very thorough if I make a type change like this, (and catch all the cases before shipping any code). Instead, here, there's a hard task of exercising every possible code path (at run time) before we know if there are any type errors still lingering. I've seen some proponents of dynamically-typed languages argue that unit testing should provide the same coverage that a statically-typed compiler would, but I haven't seen that in practice. You all definitely have a lot more experience with ruby than I do, so I'm honestly interested in learning form your experience. What do you do to deal with cases like this? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Convert-a-couple-of-arrays-to-sets-for-labels.patch Type: application/octet-stream Size: 1685 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Wed Aug 19 22:57:25 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Wed, 19 Aug 2009 22:57:25 -0400 Subject: [sup-talk] In next: thread-view-mode labelling No method join for Set In-Reply-To: <1250727630-sup-3112@yoom.home.cworth.org> References: <1250714501-sup-3033@chigamba> <1250727630-sup-3112@yoom.home.cworth.org> Message-ID: <1250734085-sup-2162@ntdws12.chass.utoronto.ca> Excerpts from Carl Worth's message of Wed Aug 19 20:31:12 -0400 2009: > [*] Totally off-topic: This is one of the things about "dynamically > typed" languages that I've never been able to wrap my brain around. I > really like that with static typing I can trust the compiler to help > me be very thorough if I make a type change like this, (and catch all > the cases before shipping any code). Instead, here, there's a hard > task of exercising every possible code path (at run time) before we > know if there are any type errors still lingering. I've seen some > proponents of dynamically-typed languages argue that unit testing > should provide the same coverage that a statically-typed compiler > would, but I haven't seen that in practice. The term you'll see bandied about in ruby circles/books/etc is 'duck typing' which coming from strongly typed languages is definitely something that takes some getting used to. Basically, instead of caring about the type of the object, you case about what the object does. If it walks like a duck and quacks like a duck, treat it like a duck. A very simple example is a function that expects to append data to another object. You could pass it a string (which uses << to append) or an array (which uses << to push elements on the end). If you originally passed a string, but found performance (memory -> realloc()) issues, you could swap the string object for an array object and do array.join when everything is collected into array elements. Then, you'll see many examples where there is code like: raise SomeException, "blah" unless someobject.respond_to?(:somemethod) Your code doesn't care _what kind_ of object it gets as long as it knows _how_ to talk to it. Personally, I really like this. Ruby isn't perfect by any stretch, but of all the languages I've used, it's hands down the most fun to write. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Thu Aug 20 00:03:08 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 19 Aug 2009 21:03:08 -0700 Subject: [sup-talk] In next: thread-view-mode labelling No method join for Set In-Reply-To: <1250734085-sup-2162@ntdws12.chass.utoronto.ca> References: <1250714501-sup-3033@chigamba> <1250727630-sup-3112@yoom.home.cworth.org> <1250734085-sup-2162@ntdws12.chass.utoronto.ca> Message-ID: <1250740488-sup-1624@yoom.home.cworth.org> Excerpts from Ben Walton's message of Wed Aug 19 19:57:25 -0700 2009: > Excerpts from Carl Worth's message of Wed Aug 19 20:31:12 -0400 2009: > > > [*] Totally off-topic: This is one of the things about "dynamically > > typed" languages that I've never been able to wrap my brain around. I > > really like that with static typing I can trust the compiler to help > > me be very thorough if I make a type change like this, (and catch all > > the cases before shipping any code). ... > The term you'll see bandied about in ruby circles/books/etc is 'duck > typing' which coming from strongly typed languages is definitely > something that takes some getting used to. Basically, instead of > caring about the type of the object, you case about what the object > does. If it walks like a duck and quacks like a duck, treat it like a > duck. Yes, I understand that just fine. But two points: 1. That's not actually helping in the current case where we're trying to do simple things like '+' and the distinction between Set and Array is causing problems. (See the patch where we're having to add .to_a and Set.new to coerce things.) So, here, at least things are falling down. So somehow something in ruby isn't living up to the concept here. > Then, you'll see many examples where there is code like: > > raise SomeException, "blah" unless someobject.respond_to?(:somemethod) > > Your code doesn't care _what kind_ of object it gets as long as it > knows _how_ to talk to it. 2. Even with the "duck typing" I'd still like to express this constraint in a way that is decidable statically. I've definitely failed as a programmer if a user sees a runtime exception like that. Sytems with sophisticated runtimes are very interesting to me. It's just discouraging to me that so many such systems fail to actually help me avoid problems like this before the user is running my code. > Personally, I really like this. Ruby isn't perfect by any stretch, > but of all the languages I've used, it's hands down the most fun to > write. That could still be the case for me here. I haven't tried much with it yet, so I don't have any strong opinion there yet. :-) -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Thu Aug 20 01:25:39 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 19 Aug 2009 22:25:39 -0700 Subject: [sup-talk] [PATCH] Make SUP_LOG_LEVEL self-documenting. Message-ID: <1250745799-sup-6607@yoom.home.cworth.org> The idea here is that if someone is looking at the log and not seeing the information of interest, then the log itself should tell them how to get more information, (by suggesting to set SUP_LOG_LEVEL to the next lower level). --- I'm probably still off as far as standard ruby idioms, (and I'm probably committing some sup layer violations as well). But hopefully you get the idea. I went to the log looking for details, couldn't find them, and had to resort to searching the mailing list for the exact name of the SUP_LOG_LEVEL variable. bin/sup | 3 +++ lib/sup/logger.rb | 2 ++ 2 files changed, 5 insertions(+), 0 deletions(-) diff --git a/bin/sup b/bin/sup index 3d5b6c1..afe2233 100755 --- a/bin/sup +++ b/bin/sup @@ -169,6 +169,9 @@ begin lmode.on_kill { Logger.clear! } Logger.add_sink lmode Logger.force_message "Welcome to Sup! Log level is set to #{Logger.level}." + if Logger.LEVELS.index(Logger.level) > 0 + Logger.force_message "For more verbose logging, restart with SUP_LOG_LEVEL=#{Logger.LEVELS[Logger.LEVELS.index(Logger.level)-1]}." + end debug "initializing inbox buffer" imode = InboxMode.new diff --git a/lib/sup/logger.rb b/lib/sup/logger.rb index ccaeae0..8567174 100644 --- a/lib/sup/logger.rb +++ b/lib/sup/logger.rb @@ -12,6 +12,8 @@ class Logger LEVELS = %w(debug info warn error) # in order! + def LEVELS; LEVELS end + def initialize level=nil level ||= ENV["SUP_LOG_LEVEL"] || "info" @level = LEVELS.index(level) or raise ArgumentError, "invalid log level #{level.inspect}: should be one of #{LEVELS * ', '}" -- 1.6.3.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Thu Aug 20 02:31:25 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 19 Aug 2009 23:31:25 -0700 Subject: [sup-talk] [PATCH] Be less overzealous in moving text to the left column Message-ID: <1250749447-sup-1744@yoom.home.cworth.org> Specifically, scroll as little as possible to get the current message to just fit on the right side. --- This seems to work quite nicely and I think is ready to be comitted as is. It's still not perfect in a few ways though, which I think we can leave for subsequent commits: 1. I *think* that with this change the loose_alignment mode is unnecessary. But I confess that I didn't totally understand the calculation it is making, so I tried to just preserve its behavior rather than ripping it out. 2. In deep threads of short messages, (so that lots of nesting is visible in one screenful), it's easier than it was before for messages other than the current message to be scrolled off to the right, (though the current message is always made to fit if possible). I can imagine someone finding the current patch unacceptable based on this. The fix for this would be to consider the total width of all visible messages when making the calculation made here, rather than just the width of the current message. I'm not sure how readily available that number is. 3. It's still easy to get stuff scrolled off to the left, (which was a symptom of the original bug I'm trying to fix), when doing something like (E: Expand all messages). This command should recompute a left column, so perhaps we should abstract the left-column calculation out to some shared place. Anyway, all feedback is quite welcome, -Carl (happy to finally be running code from git and contributing patches) lib/sup/modes/thread-view-mode.rb | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index dfe30ff..678b841 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -423,6 +423,9 @@ EOS 0 end + ## scroll as little as possible to make the message fit + ideal_left = (-(buffer.content_width - l.width - left - 1)).clamp(0, ideal_left) + jump_to_col [ideal_left, 0].max ## either way, move the cursor to the first line -- 1.6.3.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Thu Aug 20 13:07:16 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 20 Aug 2009 10:07:16 -0700 Subject: [sup-talk] On making kill-thread easier Message-ID: <1250785604-sup-5488@yoom.home.cworth.org> I wrote a long post that started out talking about workflows, but then went on into just a dump of feature requests. I'd like to get back to talking about workflows again a bit. I find that when processing my mail in inbox-mode I do a first pass with one of two different actions on each thread: 1. 'a' to archive the thread without reading or: 2. to leave the thread in my inbox for reading on a later pass. But this misses out on the killer-feature that was one of the things that made me most interested in sup: kill-thread. So I can currently decide to kill a thread instead of archiving it, but this requires extra effort on my part, (deciding that I need to do something more than just archiving it, and then using a different key---currently with a keybinding that requires two keys). What I find is that I end up using kill-thread much less frequently than I should. Basically what ends up happening is that when a thread comes up several times (and I keep just archiving it) before I finally make the mental effort to kill it instead of just archiving it. And I keep trying to train myself to not be afraid to use kill-thread more frequently. But then thought occurs to me, "Shouldn't sup just see that I'm not ever reading this thread when it reappears?". So I think what I actually want is a single keybinding that either archives or kills a thread based on whether I've actually read any of it or not. Does anybody else agree that that would be useful? Perhaps even as the default? I think a first pass that only does kill-thread if the entire thread is unread will likely be enough. I can imagine a more clever version that kills a thread even if it's partially read but no new messages have been read since the last time this thread was labelled as inbox. But that's perhaps more complexity than appropriate[*] and an explicit kill-thread command will work just fine here. -Carl [*] By the way, my concern with complexity has nothing to do with the state management in the code---that shouldn't be bad. It's more a matter of making the user-interface easy to explain and understand. If a tool violates that, then it can lose a user's trust, (which can be quite fatal for a mail client). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From garoth@gmail.com Thu Aug 20 14:19:19 2009 From: garoth@gmail.com (Andrei Thorp) Date: Thu, 20 Aug 2009 14:19:19 -0400 Subject: [sup-talk] On making kill-thread easier In-Reply-To: <1250785604-sup-5488@yoom.home.cworth.org> References: <1250785604-sup-5488@yoom.home.cworth.org> Message-ID: <1250792255-sup-4740@Longbow> Excerpts from Carl Worth's message of Thu Aug 20 13:07:16 -0400 2009: > I wrote a long post that started out talking about workflows, but then > went on into just a dump of feature requests. I'd like to get back to > talking about workflows again a bit. > > I find that when processing my mail in inbox-mode I do a first pass > with one of two different actions on each thread: > > 1. 'a' to archive the thread without reading > or: > 2. to leave the thread in my inbox for reading on > a later pass. > > But this misses out on the killer-feature that was one of the things > that made me most interested in sup: kill-thread. > > So I can currently decide to kill a thread instead of archiving it, > but this requires extra effort on my part, (deciding that I need to do > something more than just archiving it, and then using a different > key---currently with a keybinding that requires two keys). > > What I find is that I end up using kill-thread much less frequently > than I should. Basically what ends up happening is that when a thread > comes up several times (and I keep just archiving it) before I finally > make the mental effort to kill it instead of just archiving it. And I > keep trying to train myself to not be afraid to use kill-thread more > frequently. > > But then thought occurs to me, "Shouldn't sup just see that I'm not > ever reading this thread when it reappears?". > > So I think what I actually want is a single keybinding that either > archives or kills a thread based on whether I've actually read any of > it or not. Does anybody else agree that that would be useful? Perhaps > even as the default? > > I think a first pass that only does kill-thread if the entire thread > is unread will likely be enough. I can imagine a more clever version > that kills a thread even if it's partially read but no new messages > have been read since the last time this thread was labelled as > inbox. But that's perhaps more complexity than appropriate[*] and an > explicit kill-thread command will work just fine here. > > -Carl > > [*] By the way, my concern with complexity has nothing to do with the > state management in the code---that shouldn't be bad. It's more a > matter of making the user-interface easy to explain and understand. If > a tool violates that, then it can lose a user's trust, (which can be > quite fatal for a mail client). Seems like making it the default is a bit cavalier. It's not good to assume what the user wants, I think. Maybe a separate key if we want to spare it, but I think the better solution is "learn to kill threads already and use an explicit command for it." -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From chris@chris-wilson.co.uk Thu Aug 20 16:01:10 2009 From: chris@chris-wilson.co.uk (Chris Wilson) Date: Thu, 20 Aug 2009 21:01:10 +0100 Subject: [sup-talk] On making kill-thread easier In-Reply-To: <1250785604-sup-5488@yoom.home.cworth.org> References: <1250785604-sup-5488@yoom.home.cworth.org> Message-ID: <1250797598-sup-5105@tiger.alporthouse.com> Hi everybody! I've just started using sup after Carl told me he'd found a fantastic new mail client. And, as usual, he was right. Excerpts from Carl Worth's message of Thu Aug 20 18:07:16 +0100 2009: > But then thought occurs to me, "Shouldn't sup just see that I'm not > ever reading this thread when it reappears?". I have a very similar inbox pattern to Carl, a quick pass to remove uninteresting material before acting upon the rest. To this end, I use '&' far less frequently than I should, because it's an awkward key combination to use in conjunction with scrolling + archiving, and so I am irritated by repeatedly archiving a thread which I have never read. The behaviour I would like here is exactly: "Shouldn't sup just see that I'm not ever reading this thread when it reappears?". I'd be happy to have sup automatically kill a thread that I have archived twice without reading. -ickle From garoth@gmail.com Thu Aug 20 16:36:15 2009 From: garoth@gmail.com (Andrei Thorp) Date: Thu, 20 Aug 2009 16:36:15 -0400 Subject: [sup-talk] On making kill-thread easier In-Reply-To: <1250797598-sup-5105@tiger.alporthouse.com> References: <1250785604-sup-5488@yoom.home.cworth.org> <1250797598-sup-5105@tiger.alporthouse.com> Message-ID: <1250800492-sup-136@Longbow> Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009: > Hi everybody! I've just started using sup after Carl told me he'd found > a fantastic new mail client. And, as usual, he was right. If you're half as verbose as he is, I'll never have time to read it all! ;) -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From bwalton@artsci.utoronto.ca Thu Aug 20 16:43:08 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 20 Aug 2009 16:43:08 -0400 Subject: [sup-talk] On making kill-thread easier In-Reply-To: <1250797598-sup-5105@tiger.alporthouse.com> References: <1250785604-sup-5488@yoom.home.cworth.org> <1250797598-sup-5105@tiger.alporthouse.com> Message-ID: <1250800965-sup-4218@ntdws12.chass.utoronto.ca> Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009: > I have a very similar inbox pattern to Carl, a quick pass to remove > uninteresting material before acting upon the rest. To this end, I use > '&' far less frequently than I should, because it's an awkward key > combination to use in conjunction with scrolling + archiving, and so I > am irritated by repeatedly archiving a thread which I have never read. > The behaviour I would like here is exactly: "Shouldn't sup just see that > I'm not ever reading this thread when it reappears?". I have a similar pattern where there are lots of list messages that I don't care about (based on subject). I skim the inbox using 't' to tag all messages I don't care about. When I've tagged a bunch of items, after the scan, I simply to '=' followed by either 'A' (archive, mark read) or '&'. It saves lots of shift key use and allows me to quickly tackle a lot of mail. > I'd be happy to have sup automatically kill a thread that I have > archived twice without reading. I think this kind of heuristic is a) hard to get right b) not required if you do batch operations as described above. Part b) is subject to personal opinion, of course! :) HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Thu Aug 20 17:07:28 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 20 Aug 2009 14:07:28 -0700 Subject: [sup-talk] On making kill-thread easier In-Reply-To: <1250800492-sup-136@Longbow> References: <1250785604-sup-5488@yoom.home.cworth.org> <1250797598-sup-5105@tiger.alporthouse.com> <1250800492-sup-136@Longbow> Message-ID: <1250802401-sup-2516@yoom.home.cworth.org> Excerpts from Andrei Thorp's message of Thu Aug 20 13:36:15 -0700 2009: > Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009: > > Hi everybody! I've just started using sup after Carl told me he'd found > > a fantastic new mail client. And, as usual, he was right. > > If you're half as verbose as he is, I'll never have time to read it all! > ;) Yeah, sorry about that. I will try to be terse when I can. :-) Welcome, Chris! -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Thu Aug 20 17:11:49 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 20 Aug 2009 14:11:49 -0700 Subject: [sup-talk] On making kill-thread easier In-Reply-To: <1250800965-sup-4218@ntdws12.chass.utoronto.ca> References: <1250785604-sup-5488@yoom.home.cworth.org> <1250797598-sup-5105@tiger.alporthouse.com> <1250800965-sup-4218@ntdws12.chass.utoronto.ca> Message-ID: <1250802452-sup-4348@yoom.home.cworth.org> Excerpts from Ben Walton's message of Thu Aug 20 13:43:08 -0700 2009: > Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009: > I have a similar pattern where there are lots of list messages that I > don't care about (based on subject). I skim the inbox using 't' to > tag all messages I don't care about. When I've tagged a bunch of > items, after the scan, I simply to '=' followed by either 'A' > (archive, mark read) or '&'. It saves lots of shift key use and > allows me to quickly tackle a lot of mail. Thanks, Ben! This is just the kind of workflow report I've been hoping to read. I wonder, though, what happens when you want to archive some and kill others. Do you end up making two passes? Executing the '=' operation partway through and then start tagging again? A quick, non-tag 'A' or '&' for the exceptional thread? Or maybe just let a few slip by the "wrong" direction. > > I'd be happy to have sup automatically kill a thread that I have > > archived twice without reading. > > I think this kind of heuristic is a) hard to get right b) not required > if you do batch operations as described above. Part b) is subject to > personal opinion, of course! :) I plan to try a single keybinding for archive-or-kill-if-unread for a while and see how I like it, (I'll obviously share it when I code it up).. Of course, the failure mode is hiding messages from me, so it might be hard for me to know if it fails. :-) -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Thu Aug 20 18:56:52 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 20 Aug 2009 18:56:52 -0400 Subject: [sup-talk] On making kill-thread easier In-Reply-To: <1250802452-sup-4348@yoom.home.cworth.org> References: <1250785604-sup-5488@yoom.home.cworth.org> <1250797598-sup-5105@tiger.alporthouse.com> <1250800965-sup-4218@ntdws12.chass.utoronto.ca> <1250802452-sup-4348@yoom.home.cworth.org> Message-ID: <1250808931-sup-3198@ntdws12.chass.utoronto.ca> Excerpts from Carl Worth's message of Thu Aug 20 17:11:49 -0400 2009: > I wonder, though, what happens when you want to archive some and kill > others. Do you end up making two passes? Executing the '=' operation > partway through and then start tagging again? A quick, non-tag 'A' or > '&' for the exceptional thread? Or maybe just let a few slip by the > "wrong" direction. I typically do a big pass to 'A' or '&' large numbers of things. That knocks the list to a point where I can either do another smaller pass where I'll apply labels and skim things. My last pass is for things I actually read, many of which get archived right away too. I don't completely practice 'inbox 0' but I do follow many of its tenets. My own personal habits are such that an archived thread has to really bug me before I kill it, so much of the first (morning) pass is for 'A.' Part of this is because while I don't want to necessarily follow a thread, there is potential for interesting things to pop in late in the game (many of these are on the git ml)...so, after I see a lot of activity on it, I may scan the thread or possibly read it. Bike shedding gets killed quickly! :) > I plan to try a single keybinding for archive-or-kill-if-unread for a > while and see how I like it, (I'll obviously share it when I code it > up).. Of course, the failure mode is hiding messages from me, so it > might be hard for me to know if it fails. :-) If you get into adding code, consider writing it such that there is an available Hook that overrides the default behaviour. This may get you the best of all outcomes. It'd be useful for you and more likely to be useful for others. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Thu Aug 20 20:09:30 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 20 Aug 2009 17:09:30 -0700 Subject: [sup-talk] On making kill-thread easier In-Reply-To: <1250808931-sup-3198@ntdws12.chass.utoronto.ca> References: <1250785604-sup-5488@yoom.home.cworth.org> <1250797598-sup-5105@tiger.alporthouse.com> <1250800965-sup-4218@ntdws12.chass.utoronto.ca> <1250802452-sup-4348@yoom.home.cworth.org> <1250808931-sup-3198@ntdws12.chass.utoronto.ca> Message-ID: <1250812689-sup-2614@yoom.home.cworth.org> Excerpts from Ben Walton's message of Thu Aug 20 15:56:52 -0700 2009: > My own personal habits are such that an archived thread has to really > bug me before I kill it, so much of the first (morning) pass is for > 'A.' Part of this is because while I don't want to necessarily follow > a thread, there is potential for interesting things to pop in late in > the game (many of these are on the git ml)...so, after I see a lot of > activity on it, I may scan the thread or possibly read it. Thanks. Those are good points. I've definitely seen some interesting stuff on the git mailing list where threads start off looking worthless, but then Linus comes in with some gem of insight and things take off again. See Joey's post on thread patterns for some examples here: http://joey.kitenet.net/blog/entry/thread_patterns/ > Bike shedding gets killed quickly! :) Yes! Bike shedding without kill-thread available is a lot more painful. I guess part of what I'm getting at with the idea of merging "archive" and "kill-thread" is that I think the distinction between these two commands forces the user to get a little too chummy with details of the mail store. I wrote a long post about sup and mail in general here: http://cworth.org/sup/a-mail-client-for-geeks/ [*] and one of the ideas I start talking about there is that I'd like my mail client to present me with "Here's what you should find most interesting right now", and I can implicitly give the system feedback by either reading it or not. So "archive" vs. "kill" feels like manual tuning of what would ideally be an automated process. Of course, getting that process automated and working well is likely an open research topic. I'd love for the system to take tags into account, authors of messages, my history of reading (or not) posts by given authors, etc. Obviously, sup's not going to acquire that kind of functionality instantly, but it likely makes a good basis already for someone who wants to explore that kind of thing. So, ideas of mine like "sort certain tags before sorting by date", and "merge archive and thread into a single key" I think are both just baby steps toward the Big Idea I'd love to see someone tackle. Anyone looking for a good M.S. thesis around here? (So much research has been dedicated to spam, but has there been as much to sorting out the ham? I should ask my C.S-professor-friend---he'd be up on the current state of the literature here.) -Carl [*] See, I'm keeping some of my verbosity off the list at least. ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Thu Aug 20 20:16:23 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 20 Aug 2009 20:16:23 -0400 Subject: [sup-talk] In next: thread-view-mode labelling No method join for Set In-Reply-To: <1250740488-sup-1624@yoom.home.cworth.org> References: <1250714501-sup-3033@chigamba> <1250727630-sup-3112@yoom.home.cworth.org> <1250734085-sup-2162@ntdws12.chass.utoronto.ca> <1250740488-sup-1624@yoom.home.cworth.org> Message-ID: <1250813245-sup-6519@ntdws12.chass.utoronto.ca> Excerpts from Carl Worth's message of Thu Aug 20 00:03:08 -0400 2009: > 1. That's not actually helping in the current case where we're trying > to do simple things like '+' and the distinction between Set and > Array is causing problems. (See the patch where we're having to add > .to_a and Set.new to coerce things.) So, here, at least things are > falling down. So somehow something in ruby isn't living up to the > concept here. You're correct. The difference between fixing this in Ruby vs fixing this in a strongly typed language though is that you could implement Set#join such that the code expecting an array wouldn't know the difference _or_ you could have that code use kind_of?(Array) to ensure it was getting the type of argument it was expecting. Both are technically correct. In a strongly typed language, you'd have to modify the acceptable arguments (function definition) and ensure everything that called the function passed something acceptable or provide an overloaded version (if you're working with a language that supports it). Those are correct solutions too. > > Your code doesn't care _what kind_ of object it gets as long as it > > knows _how_ to talk to it. > > 2. Even with the "duck typing" I'd still like to express this > constraint in a way that is decidable statically. I've definitely > failed as a programmer if a user sees a runtime exception like > that. Sytems with sophisticated runtimes are very interesting to > me. It's just discouraging to me that so many such systems fail to > actually help me avoid problems like this before the user is > running my code. Bugs are bugs! :) Static typing only goes so far to prevent some of this stuff...just look what you can make a C compiler do with funky casts. I take your point though. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Thu Aug 20 21:36:28 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 20 Aug 2009 18:36:28 -0700 Subject: [sup-talk] On making kill-thread easier In-Reply-To: <1250800965-sup-4218@ntdws12.chass.utoronto.ca> References: <1250785604-sup-5488@yoom.home.cworth.org> <1250797598-sup-5105@tiger.alporthouse.com> <1250800965-sup-4218@ntdws12.chass.utoronto.ca> Message-ID: <1250817987-sup-7256@yoom.home.cworth.org> Excerpts from Ben Walton's message of Thu Aug 20 13:43:08 -0700 2009: > Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009: > > > I'd be happy to have sup automatically kill a thread that I have > > archived twice without reading. > > I think this kind of heuristic is a) hard to get right b) not required > if you do batch operations as described above. Part b) is subject to > personal opinion, of course! :) [Here's one last thought from me in this thread before I come back next time with actual code and maybe some experience in using it.] Since, by nature of being a heuristic, this kind of thing can't be perfect, and since the cost of a false positive is high, (an important message being killed and never seen), here's another idea: First, leave killing to the user as an explicit action. Second, use the heuristics not for killing messages, but merely for prioritizing them in the inbox. But since the inbox might often be small, it's not adequate to move the "uninteresting" messages to the bottom. Instead threads that the heuristic identifies as "likely uninteresting" could have a delay attached to them before they are presented again in the inbox, (not too unlike throttling proposed for mailing-list servers to keep flamewars in check). This way instead of pestering the user with the bikeshedding until the user finally kills the thread in frustration, the bikeshedding could get delayed until the next morning's sweep where a day's worth of bikeshedding would be easy to identify and easy to kill. So maybe something like "Once I archive a thread twice without reading, don't show it to me again until tomorrow" or so. That might be interesting to try out. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevinr@free-dissociation.com Thu Aug 20 21:57:42 2009 From: kevinr@free-dissociation.com (Kevin Riggle) Date: Thu, 20 Aug 2009 21:57:42 -0400 Subject: [sup-talk] [PATCH] Add an after-add-message hook In-Reply-To: <1250707991-sup-5429@masanjin.net> References: <1250707991-sup-5429@masanjin.net> Message-ID: <1250819862-4858-1-git-send-email-kevinr@free-dissociation.com> This time the loop stores messages in an array as they're added to the index, and passes that array to the hook. I want to do some unrelated processing on each message I receive, but I don't want to block the message being added to the index. This patch adds a hook which runs /after/ the message is added to the index. --- lib/sup/poll.rb | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb index 8a9d218..fb3aacf 100644 --- a/lib/sup/poll.rb +++ b/lib/sup/poll.rb @@ -11,6 +11,12 @@ Variables: message: the new message EOS + HookManager.register "after-add-message", < messages + rescue SourceError => e Redwood::log "problem getting messages from #{source}: #{e.message}" Redwood::report_broken_sources :force_to_top => true -- 1.6.0.4 From kevinr@free-dissociation.com Thu Aug 20 22:07:17 2009 From: kevinr@free-dissociation.com (Kevin Riggle) Date: Thu, 20 Aug 2009 22:07:17 -0400 Subject: [sup-talk] [PATCH] Add an after-add-message hook In-Reply-To: <1250707991-sup-5429@masanjin.net> References: <1250459229-4500-1-git-send-email-kevinr@free-dissociation.com> <1250618123-sup-8797@masanjin.net> <1250638381-sup-2952@black-opal.mit.edu> <1250707991-sup-5429@masanjin.net> Message-ID: <1250820245-sup-2250@black-opal.mit.edu> Excerpts from William Morgan's message of Wed Aug 19 14:55:03 -0400 2009: > Reformatted excerpts from Kevin Riggle's message of 2009-08-18: > > I don't /think/ so, unless I misunderstand the way hooks work. I > > assumed the hook would execute and then execution of the loop would > > resume, and I don't think I throw anything in the hook which should > > cause that either. > > What I'm saying is that this hook will execute *after* each message is > added to the index, so if Sup found several new messages, all except the > first one will wait on this hook to execute before being added to the > index. Or do you mean block in some sense besides "wait for completion"? Oh, duh. I take your point -- I've sent a new patch. - Kevin -- Kevin Riggle (kevinr at free-dissociation.com) http://free-dissociation.com From cworth@cworth.org Thu Aug 20 22:09:15 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 20 Aug 2009 19:09:15 -0700 Subject: [sup-talk] 'next' crash: wrong id called on nil (thread.rb:264:in `thread_for') Message-ID: <1250820431-sup-8159@yoom.home.cworth.org> I'm running sup next, (3de96fb9b308afe600c7ccfcee75913f039ef4f6 + 3 patches that I've posted to this list, but which I hope are not relevant here), and I got the following crash. My best recollection is that I had just sent a reply, and then hit ".a". Anything here look like an obvious fix for someone? -Carl --- RuntimeError from thread: main wrong id called on nil ./lib/sup.rb:17:in `id' ./lib/sup/thread.rb:264:in `thread_for' ./lib/sup/modes/thread-index-mode.rb:702:in `thread_containing' ./lib/sup/modes/thread-index-mode.rb:702:in `synchronize' ./lib/sup/modes/thread-index-mode.rb:702:in `thread_containing' ./lib/sup/modes/thread-index-mode.rb:173:in `handle_simple_update' ./lib/sup/modes/thread-index-mode.rb:180:in `handle_archived_update' ./lib/sup/update.rb:26:in `send' ./lib/sup/update.rb:26:in `relay' ./lib/sup/update.rb:26:in `each' ./lib/sup/update.rb:26:in `relay' ./lib/sup/util.rb:520:in `send' ./lib/sup/util.rb:520:in `method_missing' ./lib/sup/modes/thread-view-mode.rb:481:in `archive_and_then' ./lib/sup/modes/thread-view-mode.rb:515:in `dispatch' ./lib/sup/modes/thread-view-mode.rb:525:in `call' ./lib/sup/modes/thread-view-mode.rb:525:in `dispatch' ./lib/sup/modes/thread-view-mode.rb:479:in `archive_and_then' ./lib/sup/modes/thread-view-mode.rb:461:in `archive_and_kill' ./lib/sup/mode.rb:50:in `send' ./lib/sup/mode.rb:50:in `handle_input' ./lib/sup/buffer.rb:260:in `handle_input' ./bin/sup:237 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chris@chris-wilson.co.uk Fri Aug 21 11:16:26 2009 From: chris@chris-wilson.co.uk (Chris Wilson) Date: Fri, 21 Aug 2009 16:16:26 +0100 Subject: [sup-talk] On making kill-thread easier In-Reply-To: <1250800965-sup-4218@ntdws12.chass.utoronto.ca> References: <1250785604-sup-5488@yoom.home.cworth.org> <1250797598-sup-5105@tiger.alporthouse.com> <1250800965-sup-4218@ntdws12.chass.utoronto.ca> Message-ID: <1250867140-sup-2558@tiger.alporthouse.com> Excerpts from Ben Walton's message of Thu Aug 20 21:43:08 +0100 2009: > I skim the inbox using 't' to > tag all messages I don't care about. When I've tagged a bunch of > items, after the scan, I simply to '=' followed by either 'A' > (archive, mark read) or '&'. This works very nicely, thanks. Though I miss the subtly of why you use 'A' rather than 'a'. Could you explain the difference this makes? -ickle From ezyang@MIT.EDU Fri Aug 21 11:19:35 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Fri, 21 Aug 2009 11:19:35 -0400 Subject: [sup-talk] On making kill-thread easier In-Reply-To: <1250867140-sup-2558@tiger.alporthouse.com> References: <1250785604-sup-5488@yoom.home.cworth.org> <1250797598-sup-5105@tiger.alporthouse.com> <1250800965-sup-4218@ntdws12.chass.utoronto.ca> <1250867140-sup-2558@tiger.alporthouse.com> Message-ID: <1250867926-sup-4258@javelin> Excerpts from Chris Wilson's message of Fri Aug 21 11:16:26 -0400 2009: > This works very nicely, thanks. Though I miss the subtly of why you > use 'A' rather than 'a'. Could you explain the difference this makes? > -ickle A -> mark as read and archive a -> just archive This means you can have unread messages that are archived. I use this to great effect with my mailing list messages (which I have filters to archive but not to mark read). Cheers, Edward From bwalton@artsci.utoronto.ca Fri Aug 21 11:20:23 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Fri, 21 Aug 2009 11:20:23 -0400 Subject: [sup-talk] On making kill-thread easier In-Reply-To: <1250867140-sup-2558@tiger.alporthouse.com> References: <1250785604-sup-5488@yoom.home.cworth.org> <1250797598-sup-5105@tiger.alporthouse.com> <1250800965-sup-4218@ntdws12.chass.utoronto.ca> <1250867140-sup-2558@tiger.alporthouse.com> Message-ID: <1250867933-sup-5786@ntdws12.chass.utoronto.ca> Excerpts from Chris Wilson's message of Fri Aug 21 11:16:26 -0400 2009: > This works very nicely, thanks. Though I miss the subtly of why you > use 'A' rather than 'a'. Could you explain the difference this makes? 'A' marks the mail as read in addition to archiving it. This makes 'U' (unread view) mode better for my use. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From guillaume.quintard@gmail.com Fri Aug 21 12:00:29 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Fri, 21 Aug 2009 18:00:29 +0200 Subject: [sup-talk] Crashing ssh + sup, bad combo Message-ID: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com> Sooooo, here's what happened: I was running sup through ssh, minding my own business, when suddenly, my local machine crashed. I reboot, reconnect, sup is somehow still running, I kill it (with a good ol' kill, because the lock file was empty so sup could ask for a seppuku), and no I have this: [Fri Aug 21 17:54:54 +0200 2009] ERROR: oh crap, an exception ---------------------------------------------------------------- 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 address this problem. Thank you! Sincerely, William ---------------------------------------------------------------- --- RuntimeError from thread: load threads for thread-index-mode wrong id called on nil ./lib/sup.rb:17:in `id' ./lib/sup/xapian_index.rb:155:in `each_message_in_thread_for' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' ./lib/sup/xapian_index.rb:336:in `synchronize' ./lib/sup/xapian_index.rb:155: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:149:in `each_id_by_date' ./lib/sup/xapian_index.rb:142:in `each_id' ./lib/sup/xapian_index.rb:142:in `each' ./lib/sup/xapian_index.rb:142:in `each_id' ./lib/sup/xapian_index.rb:149:in `each_id_by_date' ./lib/sup/thread.rb:328:in `load_n_threads' ./lib/sup/modes/thread-index-mode.rb:623:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' ./lib/sup/modes/thread-index-mode.rb:607: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:606:in `load_n_threads_background' ./lib/sup/modes/thread-index-mode.rb:676:in `__unprotected_load_threads' (eval):12:in `load_threads' bin/sup:192 me no likey :-( -- Guillaume From marka@pobox.com Fri Aug 21 14:57:10 2009 From: marka@pobox.com (Mark Alexander) Date: Fri, 21 Aug 2009 14:57:10 -0400 Subject: [sup-talk] Crashing ssh + sup, bad combo In-Reply-To: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com> References: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com> Message-ID: This isn't directly related, and you may already know about this, and apologies if that's the case... but I highly recommend running screen on the machine where you're running sup. That way you don't lose any work when your ssh connection drops for any reason. From guillaume.quintard@gmail.com Fri Aug 21 15:29:22 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Fri, 21 Aug 2009 21:29:22 +0200 Subject: [sup-talk] Crashing ssh + sup, bad combo In-Reply-To: References: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com> Message-ID: <1e5fdab70908211229w2f11d11h4db7500a340b923b@mail.gmail.com> On Fri, Aug 21, 2009 at 8:57 PM, Mark Alexander wrote: > This isn't directly related, and you may already know about this, and > apologies if that's the case... but I highly recommend running screen > on the machine where you're running sup. ?That way you don't lose any > work when your ssh connection drops for any reason. > Yup, I know, but screen isn't yet natural to me, and I tend to forgot to use it :-) -- Guillaume From rlane@club.cc.cmu.edu Fri Aug 21 16:57:55 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Fri, 21 Aug 2009 16:57:55 -0400 Subject: [sup-talk] Crashing ssh + sup, bad combo In-Reply-To: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com> References: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com> Message-ID: <1250887753-sup-7844@zyrg.net> Excerpts from Guillaume Quintard's message of Fri Aug 21 12:00:29 -0400 2009: > Sooooo, here's what happened: I was running sup through ssh, minding > my own business, when suddenly, my local machine crashed. I reboot, > reconnect, sup is somehow still running, I kill it (with a good ol' > kill, because the lock file was empty so sup could ask for a seppuku), > and no I have this: I'm guessing this is an inconsistency between your xapian and entries.db databases. A sup-sync -a might fix it. I posted a patch a few days ago that moves all index data into Xapian to prevent this sort of issue. William, could you take a look at / merge that patch? From lcontzen@gmail.com Sat Aug 22 05:45:18 2009 From: lcontzen@gmail.com (Contzen Laurent) Date: Sat, 22 Aug 2009 11:45:18 +0200 Subject: [sup-talk] Sup crashed at launch Message-ID: <49454bf60908220245w52764765rdbd111dfd446896f@mail.gmail.com> Hello, I've heard about sup and it sounded great so I decided to give it a try following http://www.brainyautomation.com/blog/post/Reading-Gmail-with-Sup.aspx . I installed everything, configured ssmtp and got it working, etc. I then launched sup for a first time to let it create my ~/.sup and exit whithout any troubles. I then configured my .sup/sources.yaml as shown in the webpage mentionned above and then launched sup. It crashed with that output : [Sat Aug 22 11:41:56 +0200 2009] using character set encoding "utf8" [Sat Aug 22 11:41:56 +0200 2009] dynamically loading setlocale() from libc.so.6 [Sat Aug 22 11:41:56 +0200 2009] setting locale... [Sat Aug 22 11:41:56 +0200 2009] locking /home/laurent/.sup/lock... [Sat Aug 22 11:41:56 +0200 2009] crypto: detected gpg binary in /usr/bin/gpg [Sat Aug 22 11:41:56 +0200 2009] stopped cursing [Sat Aug 22 11:41:56 +0200 2009] oh crap, an exception [Sat Aug 22 11:41:56 +0200 2009] unlocking /home/laurent/.sup/lock... ---------------------------------------------------------------- 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 address this problem. Thank you! Sincerely, William ---------------------------------------------------------------- --- ArgumentError from thread: main username and password must be specified /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/imap.rb:60:in `initialize' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:30:in `new' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:30:in `yaml_properties' /usr/lib/ruby/1.8/yaml.rb:133:in `call' /usr/lib/ruby/1.8/yaml.rb:133:in `transfer' /usr/lib/ruby/1.8/yaml.rb:133:in `node_import' /usr/lib/ruby/1.8/yaml.rb:133:in `load' /usr/lib/ruby/1.8/yaml.rb:133:in `load' /usr/lib/ruby/1.8/yaml.rb:144:in `load_file' /usr/lib/ruby/1.8/yaml.rb:143:in `open' /usr/lib/ruby/1.8/yaml.rb:143:in `load_file' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:98:in `load_yaml_obj' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:473:in `load_sources' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:121:in `load' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:162 /usr/bin/sup:19:in `load' /usr/bin/sup:19 The ouput asked to send this mail so I decided to try to help you by doing it. Don't hesitate to ask for details, ... Laurent From ulrik.sverdrup@gmail.com Fri Aug 21 19:04:15 2009 From: ulrik.sverdrup@gmail.com (Ulrik Sverdrup) Date: Sat, 22 Aug 2009 01:04:15 +0200 Subject: [sup-talk] Bug: Log printing with encoding problems Message-ID: My locale is sv_SE.UTF-8, log is truncated since the date string is longer than expected. The date should print "l?r" (from L?rdag = Saturday) Sat Aug 22 00:55:52 +0200 2009: using character set encoding "UTF-8" Sat Aug 22 00:55:52 +0200 2009: dynamically loading setlocale() from libc.so.6 Sat Aug 22 00:55:52 +0200 2009: setting locale... lM-CM-6r aug 22 00:55:52 +0200 2009: locking /home/ulrik/.sup/lo lM-CM-6r aug 22 00:55:52 +0200 2009: crypto: detected gpg binary in /usr/bi lM-CM-6r aug 22 00:55:52 +0200 2009: loading ind lM-CM-6r aug 22 00:55:52 +0200 2009: loaded index of 0 mes lM-CM-6r aug 22 00:55:52 +0200 2009: starting c Regards, ulrik From ulrik.sverdrup@gmail.com Fri Aug 21 19:08:30 2009 From: ulrik.sverdrup@gmail.com (Ulrik Sverdrup) Date: Sat, 22 Aug 2009 01:08:30 +0200 Subject: [sup-talk] Bug: Quits on unbound(?) keys Message-ID: Sup seems to crash if you press a key not bound(?) Sup version: 0.8.1 (debian unstable) start sup-mail. press 'c' sup will crash with following message: uby: symbol lookup error: /usr/lib/ruby/1.8/powerpc-linux/ncurses_bin.so: undefined symbol: funcall Regards, ulrik From wmorgan-sup@masanjin.net Sat Aug 22 09:46:27 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 22 Aug 2009 06:46:27 -0700 Subject: [sup-talk] [PATCH] index log In-Reply-To: <1250491123-19240-1-git-send-email-rlane@club.cc.cmu.edu> References: <1250491123-19240-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1250948551-sup-2052@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-08-16: > Add a YAML logfile that records changes to the index and modify > sup-dump to use this rather than the normal database. I like this. I'm going to wait to apply it until the api refactoring stuff is merged down to master though. Should be soon. -- William From wmorgan-sup@masanjin.net Sat Aug 22 10:10:04 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 22 Aug 2009 07:10:04 -0700 Subject: [sup-talk] [PATCH] cache results of Person.from_address In-Reply-To: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu> References: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1250949615-sup-1773@masanjin.net> This looks good. Two minor questions before I apply: Reformatted excerpts from Rich Lane's message of 2009-08-16: > The regexes in this function are very expensive, so caching improves > performance significantly for queries and slightly for indexing. When you say this affects query performance, is it just the contact-list query, or is there some other mechanism by which this is slowing down regular queries? Also in this method: > + def []=(k,v) > + if @values.size < @n > + @values[k] = v > + @marks[k] = @i > + else > + if @delete_stack.empty? > + sweep > + else > + k2 = @delete_stack.pop > + @values.delete k2 > + @marks.delete k2 > + self[k] = v > + end > + end > + end Wouldn't it be better to do this? else if @delete_stack.empty? sweep end unless @delete_stack.empty? k2 = @delete_stack.pop @values.delete k2 @marks.delete k2 self[k] = v end So we check the delete stack even after calling sweep, and we allow for the value to be nil. Thanks! -- William From wmorgan-sup@masanjin.net Sat Aug 22 10:10:20 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 22 Aug 2009 07:10:20 -0700 Subject: [sup-talk] [PATCH] cache results of Person.from_address In-Reply-To: <1250514421-sup-7564@Longbow> References: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu> <1250514421-sup-7564@Longbow> Message-ID: <1250950211-sup-1042@masanjin.net> Reformatted excerpts from Andrei Thorp's message of 2009-08-17: > Just want to say thanks again for your seemingly unending amount of > good work to improve Sup. Agreed! -- William From wmorgan-sup@masanjin.net Sat Aug 22 10:35:37 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 22 Aug 2009 07:35:37 -0700 Subject: [sup-talk] [PATCH 2/2] xapian index format versioning In-Reply-To: <1250453934-sup-9651@zyrg.net> References: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu> <1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu> <20090816200116.GA17272@chistera.yi.org> <1250453934-sup-9651@zyrg.net> Message-ID: <1250951723-sup-3859@masanjin.net> Branch xapian-updates, merged into next. Thanks! -- William From wmorgan-sup@masanjin.net Sat Aug 22 10:50:58 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 22 Aug 2009 07:50:58 -0700 Subject: [sup-talk] [PATCH] Fix a thread merging bug introduced by refactoring in 59f8fc2 In-Reply-To: <1250620200-24319-1-git-send-email-alex@chmrr.net> References: <1250620200-24319-1-git-send-email-alex@chmrr.net> Message-ID: <1250952651-sup-2682@masanjin.net> Applied to master. Thanks! -- William From wmorgan-sup@masanjin.net Sat Aug 22 11:01:30 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 22 Aug 2009 08:01:30 -0700 Subject: [sup-talk] [PATCH] fix garbaged text in textfield when using ncursesw In-Reply-To: <1250715278-sup-1941@localdomain> References: <1250715278-sup-1941@localdomain> Message-ID: <1250952979-sup-9364@masanjin.net> Reformatted excerpts from Beno?t PIERRE's message of 2009-08-19: > Apparently, field_buffer content is not initialized to blanks when > using the wide-character version of ncurses. Forcing a call to > set_field_buffer fix the problem. Awesome. Applied to master. I hope this clears up the problems that people have been having with newer ncurses ruby libraries and utf8. If you've been seeing garbage characters when searching, please let us know if this fixes it. -- William From carlos_franke@gmx.de Sat Aug 22 10:49:17 2009 From: carlos_franke@gmx.de (Carlos Franke) Date: Sat, 22 Aug 2009 16:49:17 +0200 Subject: [sup-talk] sup crash Message-ID: <20090822164917.0a84a749@gmx.de> Hi! sup 0.8.1 crashed being started after sup-config and sup-sync. Mail source: Local IMAP server (Courier) that works with other clients. sup's output asked me to send you the appended file. Have fun with it! Carlos -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: exception-log.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Sat Aug 22 12:26:36 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 22 Aug 2009 09:26:36 -0700 Subject: [sup-talk] Sup crashed at launch In-Reply-To: <49454bf60908220245w52764765rdbd111dfd446896f@mail.gmail.com> References: <49454bf60908220245w52764765rdbd111dfd446896f@mail.gmail.com> Message-ID: <1250958276-sup-9140@masanjin.net> Reformatted excerpts from Contzen Laurent's message of 2009-08-22: > username and password must be specified Sounds like your sources.yaml file doesn't have a username and password for that entry, or isn't have the correct format. You may want to delete it and run sup-add (or sup-config) instead to generate it automatically. -- William From wmorgan-sup@masanjin.net Sat Aug 22 12:31:47 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 22 Aug 2009 09:31:47 -0700 Subject: [sup-talk] sup crash In-Reply-To: <20090822164917.0a84a749@gmx.de> References: <20090822164917.0a84a749@gmx.de> Message-ID: <1250958467-sup-381@masanjin.net> Reformatted excerpts from Carlos Franke's message of 2009-08-22: > invalid source 1 Sup is saying it has messages in its index that claim they're from source 1, but your sources.yaml doesn't have such a source. Did you remove something from sources.yaml? The easiest way to fix this is to delete your ~/.sup/ferret/ directory and run sup-sync --all --all-sources to rebuild the index, but you'll lose all messages state. If that's not acceptable, you can re-add source 1, or you can delete all such messages from the index with some effort and devel/console.sh. -- William From wmorgan-sup@masanjin.net Sat Aug 22 12:34:40 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 22 Aug 2009 09:34:40 -0700 Subject: [sup-talk] Sup crashed at launch In-Reply-To: <1250958276-sup-9140@masanjin.net> References: <49454bf60908220245w52764765rdbd111dfd446896f@mail.gmail.com> <1250958276-sup-9140@masanjin.net> Message-ID: <1250958837-sup-947@masanjin.net> Reformatted excerpts from William Morgan's message of 2009-08-22: > Sounds like your sources.yaml file doesn't have a username and password > for that entry, or isn't have the correct format. In particular, that webpage doesn't preserve spacing for its example sources.yaml, and yaml is space-sensitive. -- William From wmorgan-sup@masanjin.net Sat Aug 22 14:15:15 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 22 Aug 2009 11:15:15 -0700 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset" variable with the attachment charset In-Reply-To: <20090819212209.GA10883@chistera.yi.org> References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es> <20090723093543.GA2265@chistera.yi.org> <1248713434-sup-4961@entry> <20090730155656.GA20442@chistera.yi.org> <20090819212209.GA10883@chistera.yi.org> Message-ID: <1250964880-sup-7106@masanjin.net> Reformatted excerpts from Adeodato Sim?'s message of 2009-08-19: > Ping? Sorry, working on a fix for the hook variables issue. Bug me again in a few days if I haven't gotten to this. -- William From rlane@club.cc.cmu.edu Sat Aug 22 14:28:15 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 22 Aug 2009 11:28:15 -0700 Subject: [sup-talk] [PATCH] add Message#load_from_index! shortcut Message-ID: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu> Message#parse_header is slow, taking up to 2/3 of the time spent loading threads in thread-index-mode. This patch adds a shortcut method that the index can use to efficiently initialize a message. --- lib/sup/message.rb | 25 +++++++++++++++++++++++++ lib/sup/xapian_index.rb | 30 +++++++++++------------------- 2 files changed, 36 insertions(+), 19 deletions(-) diff --git a/lib/sup/message.rb b/lib/sup/message.rb index 965c10e..56e66de 100644 --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -127,6 +127,31 @@ class Message @list_unsubscribe = header["list-unsubscribe"] end + ## Expected index entry format: + ## :message_id, :subject => String + ## :date => Time + ## :refs, :replytos => Array of String + ## :from => Person + ## :to, :cc, :bcc => Array of Person + def load_from_index! entry + @id = entry[:message_id] + @from = entry[:from] + @date = entry[:date] + @subj = entry[:subject] + @to = entry[:to] + @cc = entry[:cc] + @bcc = entry[:bcc] + @refs = (@refs + entry[:refs]).uniq + @replytos = entry[:replytos] + + @replyto = nil + @list_address = nil + @recipient_email = nil + @source_marked_read = false + @list_subscribe = nil + @list_unsubscribe = nil + end + def add_ref ref @refs << ref @dirty = true diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index 85f6ef0..c260728 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -71,25 +71,17 @@ class XapianIndex < BaseIndex source = SourceManager[entry[:source_id]] raise "invalid source #{entry[:source_id]}" unless source - mk_addrs = lambda { |l| l.map { |e,n| "#{n} <#{e}>" } * ', ' } - mk_refs = lambda { |l| l.map { |r| "<#{r}>" } * ' ' } - fake_header = { - 'message-id' => entry[:message_id], - 'date' => Time.at(entry[:date]), - 'subject' => entry[:subject], - 'from' => mk_addrs[[entry[:from]]], - 'to' => mk_addrs[entry[:to]], - 'cc' => mk_addrs[entry[:cc]], - 'bcc' => mk_addrs[entry[:bcc]], - 'reply-tos' => mk_refs[entry[:replytos]], - 'references' => mk_refs[entry[:refs]], - } - - m = Message.new :source => source, :source_info => entry[:source_info], - :labels => entry[:labels], - :snippet => entry[:snippet] - m.parse_header fake_header - m + m = Message.new :source => source, :source_info => entry[:source_info], + :labels => entry[:labels], :snippet => entry[:snippet] + + mk_person = lambda { |x| Person.new(*x.reverse!) } + entry[:from] = mk_person[entry[:from]] + entry[:to].map!(&mk_person) + entry[:cc].map!(&mk_person) + entry[:bcc].map!(&mk_person) + + m.load_from_index! entry + m end def add_message m; sync_message m end -- 1.6.4 From rlane@club.cc.cmu.edu Sat Aug 22 14:28:39 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 22 Aug 2009 14:28:39 -0400 Subject: [sup-talk] [PATCH] cache results of Person.from_address In-Reply-To: <1250949615-sup-1773@masanjin.net> References: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu> <1250949615-sup-1773@masanjin.net> Message-ID: <1250964897-sup-2990@zyrg.net> Excerpts from William Morgan's message of Sat Aug 22 10:10:04 -0400 2009: > This looks good. Two minor questions before I apply: > > Reformatted excerpts from Rich Lane's message of 2009-08-16: > > The regexes in this function are very expensive, so caching improves > > performance significantly for queries and slightly for indexing. > > When you say this affects query performance, is it just the contact-list > query, or is there some other mechanism by which this is slowing down > regular queries? Actually, your question prompted me to wonder why we're calling Person.from_address on this path at all. With a little support from Message we can completely avoid Message#parse_header. I've just sent in a patch that does this. Please apply that rather than the from_address cache. The performance improvement from the new patch is slightly better than that of the cache. Depending on the benchmark I see the time taken by ThreadIndexMode#load_n_threads decrease by 1/2 to 2/3. From rlane@club.cc.cmu.edu Sat Aug 22 14:54:23 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 22 Aug 2009 11:54:23 -0700 Subject: [sup-talk] [PATCH] add xapian-specific hack to quickly create a Person In-Reply-To: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu> References: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1250967263-31292-1-git-send-email-rlane@club.cc.cmu.edu> Another 10% query performance boost. --- lib/sup/xapian_index.rb | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index c260728..3a23951 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -74,7 +74,7 @@ class XapianIndex < BaseIndex m = Message.new :source => source, :source_info => entry[:source_info], :labels => entry[:labels], :snippet => entry[:snippet] - mk_person = lambda { |x| Person.new(*x.reverse!) } + mk_person = lambda { |x| QuickPerson.new(*x) } entry[:from] = mk_person[entry[:from]] entry[:to].map!(&mk_person) entry[:cc].map!(&mk_person) @@ -84,6 +84,14 @@ class XapianIndex < BaseIndex m end + class QuickPerson < Person + def initialize email, name + raise ArgumentError, "email can't be nil" unless email + @email = email + @name = name + end + end + def add_message m; sync_message m end def update_message m; sync_message m end def update_message_state m; sync_message m end -- 1.6.4 From ingmar@exherbo.org Sat Aug 22 15:12:30 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Sat, 22 Aug 2009 21:12:30 +0200 Subject: [sup-talk] Bug: Quits on unbound(?) keys In-Reply-To: References: Message-ID: <1250968143-sup-3847@cannonball> Excerpts from Ulrik Sverdrup's message of Sat Aug 22 01:08:30 +0200 2009: > sup will crash with following message: > ruby: symbol lookup error: > /usr/lib/ruby/1.8/powerpc-linux/ncurses_bin.so: undefined symbol: > funcall I bet you're using ncurses-ruby-1.2.2? What you're seeing is an ncurses-ruby bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532431 Update to 1.2.3 or 1.2.4 & you'll be find. If that's not an option, downgrade to a 1.1 release. -- Exherbo KDE, X.org maintainer From dato@net.com.org.es Sat Aug 22 15:16:17 2009 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=) Date: Sat, 22 Aug 2009 20:16:17 +0100 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset" variable with the attachment charset In-Reply-To: <1250964880-sup-7106@masanjin.net> References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es> <20090723093543.GA2265@chistera.yi.org> <1248713434-sup-4961@entry> <20090730155656.GA20442@chistera.yi.org> <20090819212209.GA10883@chistera.yi.org> <1250964880-sup-7106@masanjin.net> Message-ID: <20090822191617.GA26897@chistera.yi.org> + William Morgan (Sat, 22 Aug 2009 11:15:15 -0700): > Reformatted excerpts from Adeodato Sim?'s message of 2009-08-19: > > Ping? > Sorry, working on a fix for the hook variables issue. Bug me again in a > few days if I haven't gotten to this. Only in case it needs saying: you mean a fix other than the patch I sent for that as well? (Perhaps my proposed fix was not completed, I just want to make sure the patch got noticed.) Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai From wmorgan-sup@masanjin.net Sat Aug 22 16:23:17 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 22 Aug 2009 13:23:17 -0700 Subject: [sup-talk] Exception trying to run git source In-Reply-To: <1250717434-sup-4489@yoom.home.cworth.org> References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net> <1250699596-sup-8133@ntdws12.chass.utoronto.ca> <1250704257-sup-3308@yoom> <1250707794-sup-6173@masanjin.net> <1250710221-sup-925@yoom.home.cworth.org> <1250712045-sup-3506@masanjin.net> <1250717434-sup-4489@yoom.home.cworth.org> Message-ID: <1250964942-sup-8625@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-19: > I ran an strace on the ruby process[*] and was able to plainly see > that modules were being correctly loaded from ./lib until after > /usr/lib/ruby/1.8/chronic.rb was loaded. After that, ruby would look > for modules in /usr/lib/ruby/1.8 before ./lib. And sure enough, the > first line of my chronic.rb has: > > $:.unshift File.dirname(__FILE__) # For use/testing when no gem is installed I'd call that a bug in chronic. It shouldn't be screwing with the load path. Nice debug work. -- William From wmorgan-sup@masanjin.net Sat Aug 22 16:25:22 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 22 Aug 2009 13:25:22 -0700 Subject: [sup-talk] [PATCH] Make SUP_LOG_LEVEL self-documenting. In-Reply-To: <1250745799-sup-6607@yoom.home.cworth.org> References: <1250745799-sup-6607@yoom.home.cworth.org> Message-ID: <1250972634-sup-6871@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-19: > I'm probably still off as far as standard ruby idioms, (and I'm > probably committing some sup layer violations as well). It all looks good except you can use Logger::LEVELS to access the constants. Then there's no need to write a LEVELS method. If you fix that I will apply. Thanks! -- William From chris@chris-wilson.co.uk Sun Aug 23 08:44:29 2009 From: chris@chris-wilson.co.uk (Chris Wilson) Date: Sun, 23 Aug 2009 13:44:29 +0100 Subject: [sup-talk] How to edit attachments in reply? Message-ID: <1251031062-sup-4617@tiger.alporthouse.com> Just a simple plea to make my life easier... Given an email with a couple of attached patches, what is the easiest way to reply including inline comments on the attached patches? At the moment I'm saving the attachments to /tmp and then manually including them whilst replying. Can anyone give me any clues on how to automatically include the attachments in a reply? Thanks. -Chris From wmorgan-sup@masanjin.net Sun Aug 23 13:34:10 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 23 Aug 2009 10:34:10 -0700 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset" variable with the attachment charset In-Reply-To: <20090822191617.GA26897@chistera.yi.org> References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es> <20090723093543.GA2265@chistera.yi.org> <1248713434-sup-4961@entry> <20090730155656.GA20442@chistera.yi.org> <20090819212209.GA10883@chistera.yi.org> <1250964880-sup-7106@masanjin.net> <20090822191617.GA26897@chistera.yi.org> Message-ID: <1251048347-sup-5075@masanjin.net> Reformatted excerpts from Adeodato Sim?'s message of 2009-08-22: > Only in case it needs saying: you mean a fix other than the patch I > sent for that as well? (Perhaps my proposed fix was not completed, I > just want to make sure the patch got noticed.) Hm, I don't remember seeing it and can't find it now. Can you resend, please? I do see a previous patch that did miss from you, about a crypto+mime fix. Is that still something that should be applied? It looks good to me. Anyways, I just merged my hook changes into next, on the branch hook-local-vars. Take a look and tell me what you think. This should also fix Edward Z. Yang's problems with hook locals not being useable in statements like "x = x.foo()". -- William From wmorgan-sup@masanjin.net Sun Aug 23 13:55:59 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 23 Aug 2009 10:55:59 -0700 Subject: [sup-talk] [PATCH] Be less overzealous in moving text to the left column In-Reply-To: <1250749447-sup-1744@yoom.home.cworth.org> References: <1250749447-sup-1744@yoom.home.cworth.org> Message-ID: <1251050007-sup-9740@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-19: > Specifically, scroll as little as possible to get the current message > to just fit on the right side. Is this the same as setting loose_alignment to true, and the IDEAL_*_CONTENTs to 0? -- William From rlane@club.cc.cmu.edu Sun Aug 23 14:36:59 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 23 Aug 2009 11:36:59 -0700 Subject: [sup-talk] [PATCH] sup-sync: restore state on messages that dont already exist Message-ID: <1251052619-9915-1-git-send-email-rlane@club.cc.cmu.edu> --- bin/sup-sync | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/bin/sup-sync b/bin/sup-sync index 2aa00c3..003a72d 100755 --- a/bin/sup-sync +++ b/bin/sup-sync @@ -174,7 +174,12 @@ begin ## decide what to do based on message labels and the operation we're performing dothis, new_labels = case when (op == :restore) && restored_state[m.id] && old_m && (old_m.labels != restored_state[m.id]) + num_restored += 1 [:update_message_state, restored_state[m.id]] + when (op == :restore) && restored_state[m.id] && !old_m + num_restored += 1 + m.labels = restored_state[m.id] + :add_message when op == :discard if old_m && (old_m.labels != m.labels) [:update_message_state, m.labels] -- 1.6.4 From rlane@club.cc.cmu.edu Sun Aug 23 14:46:10 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 23 Aug 2009 11:46:10 -0700 Subject: [sup-talk] [PATCH 1/2] preemptively load messages when scrolling Message-ID: <1251053171-11450-1-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/modes/line-cursor-mode.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/modes/line-cursor-mode.rb b/lib/sup/modes/line-cursor-mode.rb index 246f2b5..0b1fd1d 100644 --- a/lib/sup/modes/line-cursor-mode.rb +++ b/lib/sup/modes/line-cursor-mode.rb @@ -77,7 +77,7 @@ protected end def cursor_down - call_load_more_callbacks buffer.content_height if @curpos == lines - 1 + call_load_more_callbacks buffer.content_height if @curpos >= lines - [buffer.content_height/2,1].max return false unless @curpos < lines - 1 if @curpos >= botline - 1 -- 1.6.4 From rlane@club.cc.cmu.edu Sun Aug 23 14:46:11 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 23 Aug 2009 11:46:11 -0700 Subject: [sup-talk] [PATCH 2/2] ui responsiveness tweaks In-Reply-To: <1251053171-11450-1-git-send-email-rlane@club.cc.cmu.edu> References: <1251053171-11450-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1251053171-11450-2-git-send-email-rlane@club.cc.cmu.edu> --- bin/sup | 1 + lib/sup/modes/thread-index-mode.rb | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/bin/sup b/bin/sup index 3d5b6c1..f3c6771 100755 --- a/bin/sup +++ b/bin/sup @@ -58,6 +58,7 @@ if $opts[:list_hooks] end Thread.abort_on_exception = true # make debugging possible +Thread.current.priority = 1 # keep ui responsive module Redwood diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index fb6b2ce..177431b 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -76,8 +76,7 @@ EOS @last_load_more_size = nil to_load_more do |size| next if @last_load_more_size == 0 - load_threads :num => 1, :background => false - load_threads :num => (size - 1), + load_threads :num => size, :when_done => lambda { |num| @last_load_more_size = num } end end @@ -627,6 +626,7 @@ EOS BufferManager.draw_screen last_update = Time.now end + ::Thread.pass break if @interrupt_search end @ts.threads.each { |th| th.labels.each { |l| LabelManager << l } } -- 1.6.4 From rlane@club.cc.cmu.edu Sun Aug 23 14:49:02 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 23 Aug 2009 11:49:02 -0700 Subject: [sup-talk] [PATCH] reply all keybindings Message-ID: <1251053342-11859-1-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/modes/reply-mode.rb | 6 ++++-- lib/sup/modes/thread-index-mode.rb | 7 +++++-- lib/sup/modes/thread-view-mode.rb | 7 +++++-- 3 files changed, 14 insertions(+), 6 deletions(-) diff --git a/lib/sup/modes/reply-mode.rb b/lib/sup/modes/reply-mode.rb index 700dfc1..3d39a8a 100644 --- a/lib/sup/modes/reply-mode.rb +++ b/lib/sup/modes/reply-mode.rb @@ -40,7 +40,7 @@ Return value: The reply mode you desire, or nil to use the default behavior. EOS - def initialize message + def initialize message, type_arg=nil @m = message ## it's important to put this early because it forces a read of @@ -138,7 +138,9 @@ EOS hook_reply = HookManager.run "reply-to", :modes => types @type_selector.set_to( - if types.include? hook_reply + if types.include? type_arg + type_arg + elsif types.include? hook_reply hook_reply elsif @m.is_list_message? :list diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index fb6b2ce..d1b7fdb 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -40,6 +40,7 @@ EOS k.add :save, "Save changes now", '$' k.add :jump_to_next_new, "Jump to next new thread", :tab k.add :reply, "Reply to latest message in a thread", 'r' + k.add :reply_all, "Reply to all participants of the latest message in a thread", 'G' k.add :forward, "Forward latest message in a thread", 'f' k.add :toggle_tagged, "Tag/untag selected thread", 't' k.add :toggle_tagged_all, "Tag/untag all threads", 'T' @@ -584,15 +585,17 @@ EOS end end - def reply + def reply type_arg=nil t = cursor_thread or return m = t.latest_message return if m.nil? # probably won't happen m.load_from_source! - mode = ReplyMode.new m + mode = ReplyMode.new m, type_arg BufferManager.spawn "Reply to #{m.subj}", mode end + def reply_all; reply :all; end + def forward t = cursor_thread or return m = t.latest_message diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index bac4792..98145cc 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -53,6 +53,7 @@ EOS k.add :toggle_new, "Toggle unread/read status of message", 'N' # k.add :collapse_non_new_messages, "Collapse all but unread messages", 'N' k.add :reply, "Reply to a message", 'r' + k.add :reply_all, "Reply to all participants of this message", 'G' k.add :forward, "Forward a message or attachment", 'f' k.add :bounce, "Bounce message to other recipient(s)", '!' k.add :alias, "Edit alias/nickname for a person", 'i' @@ -161,12 +162,14 @@ EOS update end - def reply + def reply type_arg=nil m = @message_lines[curpos] or return - mode = ReplyMode.new m + mode = ReplyMode.new m, type_arg BufferManager.spawn "Reply to #{m.subj}", mode end + def reply_all; reply :all; end + def subscribe_to_list m = @message_lines[curpos] or return if m.list_subscribe && m.list_subscribe =~ // -- 1.6.4 From nicolas.pouillard@gmail.com Mon Aug 24 08:20:20 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 24 Aug 2009 14:20:20 +0200 Subject: [sup-talk] [PATCH] index log In-Reply-To: <1250948551-sup-2052@masanjin.net> References: <1250491123-19240-1-git-send-email-rlane@club.cc.cmu.edu> <1250948551-sup-2052@masanjin.net> Message-ID: <1251116226-sup-1373@peray> Excerpts from William Morgan's message of Sat Aug 22 15:46:27 +0200 2009: > Reformatted excerpts from Rich Lane's message of 2009-08-16: > > Add a YAML logfile that records changes to the index and modify > > sup-dump to use this rather than the normal database. > > I like this. I'm going to wait to apply it until the api refactoring > stuff is merged down to master though. Should be soon. I'm wondering if a simpler format would not be better, I've patch in my sup copy do feed a file called ~/.sup/labels-mapping.log with lines like those: 000e0cd20f80143822047118693d at google.com (unread inbox -> ) 20090813213654.GA30223 at community.haskell.org (unread inbox patch -> patch) 1250148617-sup-6053 at oz.taruti.net (unread inbox sup -> sup) 1250281208-sup-4199 at masanjin.net (unread inbox sup -> sup) Their are in the style of sup-dump output and there are pretty easy to manage by any tools. Not to say that I don't like YAML, I am a pretty big fan of it; but here it seems overkill. Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr From nicolas.pouillard@gmail.com Mon Aug 24 08:41:03 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 24 Aug 2009 14:41:03 +0200 Subject: [sup-talk] [PATCH 2/2] xapian index format versioning In-Reply-To: <1250951723-sup-3859@masanjin.net> References: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu> <1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu> <20090816200116.GA17272@chistera.yi.org> <1250453934-sup-9651@zyrg.net> <1250951723-sup-3859@masanjin.net> Message-ID: <1251117610-sup-9144@peray> Excerpts from William Morgan's message of Sat Aug 22 16:35:37 +0200 2009: > Branch xapian-updates, merged into next. Thanks! What is the updating procedure please ? -- Nicolas Pouillard http://nicolaspouillard.fr From wmorgan-sup@masanjin.net Mon Aug 24 14:13:43 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 24 Aug 2009 11:13:43 -0700 Subject: [sup-talk] In next: thread-view-mode labelling No method join for Set In-Reply-To: <1250727630-sup-3112@yoom.home.cworth.org> References: <1250714501-sup-3033@chigamba> <1250727630-sup-3112@yoom.home.cworth.org> Message-ID: <1251137007-sup-3974@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-19: > I've attached a patch that at least makes the crashes I was able ro > reproduce go away. Applied, thanks! > [*] Totally off-topic: This is one of the things about "dynamically > typed" languages that I've never been able to wrap my brain around. I > really like that with static typing I can trust the compiler to help > me be very thorough if I make a type change like this, (and catch all > the cases before shipping any code). Instead, here, there's a hard > task of exercising every possible code path (at run time) before we > know if there are any type errors still lingering. I've seen some > proponents of dynamically-typed languages argue that unit testing > should provide the same coverage that a statically-typed compiler > would, but I haven't seen that in practice. You're right, this is a classic example of the type of bug that would be caught with static typing. Unit tests are the canonical answer. I'd argue that unit tests provide better error checking than static typing, since they allow you to capture the exact set of errors you're interested in, rather than the set of type mismatches that a type-checker can detect. (IMO the two sets rarely have more than a very small overlap.) Unit tests are only useful, of course, if you write them. Sup doesn't have very many. I've made an explicit choice to spend my oh-so-limited Sup time adding new features rather than ensuring a rock-solid platform. The occasional bug like this is the price we all pay. But it's a matter of tradeoffs---I do believe that if I were using a statically-typed language, development would be significantly slower, and Sup would be nowhere near the point it is now. I have no proof of this statement, of course. And if anyone wants to retrofit some unit tests, I'm more than happy to accept them! -- William From lists@larsko.org Mon Aug 24 16:54:35 2009 From: lists@larsko.org (Lars Kotthoff) Date: Mon, 24 Aug 2009 21:54:35 +0100 Subject: [sup-talk] Encrypted password in configuration file Message-ID: <20090824215435.182e0007@ronin.larsko.net> Hi list, is it possible to store the account password encrypted in the configuration file? Thanks, Lars From wmorgan-sup@masanjin.net Mon Aug 24 18:38:42 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 24 Aug 2009 15:38:42 -0700 Subject: [sup-talk] Bug: Quits on unbound(?) keys In-Reply-To: <1250968143-sup-3847@cannonball> References: <1250968143-sup-3847@cannonball> Message-ID: <1251153498-sup-1707@masanjin.net> Reformatted excerpts from Ingmar Vanhassel's message of 2009-08-22: > I bet you're using ncurses-ruby-1.2.2? What you're seeing is an > ncurses-ruby bug: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532431 Wow, Sup is really giving the ncurses-ruby maintainer a workout. Nice! -- William From wmorgan-sup@masanjin.net Mon Aug 24 18:44:58 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 24 Aug 2009 15:44:58 -0700 Subject: [sup-talk] [PATCH] Add an after-add-message hook In-Reply-To: <1250819862-4858-1-git-send-email-kevinr@free-dissociation.com> References: <1250707991-sup-5429@masanjin.net> <1250819862-4858-1-git-send-email-kevinr@free-dissociation.com> Message-ID: <1251153881-sup-1538@masanjin.net> Reformatted excerpts from Kevin Riggle's message of 2009-08-20: > I want to do some unrelated processing on each message I receive, but > I don't want to block the message being added to the index. This > patch adds a hook which runs /after/ the message is added to the > index. Branch after-add-message-hook, merged into next. Thanks! -- William From wmorgan-sup@masanjin.net Mon Aug 24 18:45:37 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 24 Aug 2009 15:45:37 -0700 Subject: [sup-talk] 'next' crash: wrong id called on nil (thread.rb:264:in `thread_for') In-Reply-To: <1250820431-sup-8159@yoom.home.cworth.org> References: <1250820431-sup-8159@yoom.home.cworth.org> Message-ID: <1251153912-sup-5105@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-20: > --- RuntimeError from thread: main > wrong id called on nil I think this should be fixed in recent nexts. Can you confirm? -- William From wmorgan-sup@masanjin.net Mon Aug 24 18:46:12 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 24 Aug 2009 15:46:12 -0700 Subject: [sup-talk] Crashing ssh + sup, bad combo In-Reply-To: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com> References: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com> Message-ID: <1251153959-sup-7992@masanjin.net> Reformatted excerpts from Guillaume Quintard's message of 2009-08-21: > --- RuntimeError from thread: load threads for thread-index-mode > wrong id called on nil Let me know if this is still a problem. -- William From wmorgan-sup@masanjin.net Mon Aug 24 18:48:05 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 24 Aug 2009 15:48:05 -0700 Subject: [sup-talk] Bug: Log printing with encoding problems In-Reply-To: References: Message-ID: <1251154017-sup-4599@masanjin.net> Reformatted excerpts from Ulrik Sverdrup's message of 2009-08-21: > My locale is sv_SE.UTF-8, log is truncated since the date string is > longer than expected. Are you running with the ncursesw-enabled ncurses.so? If so, this should work, assuming your terminal is otherwise capable of displaying utf8. -- William From wmorgan-sup@masanjin.net Mon Aug 24 19:23:32 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 24 Aug 2009 16:23:32 -0700 Subject: [sup-talk] [PATCH] add Message#load_from_index! shortcut In-Reply-To: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu> References: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1251156117-sup-2313@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-08-22: > Message#parse_header is slow, taking up to 2/3 of the time spent > loading threads in thread-index-mode. This patch adds a shortcut > method that the index can use to efficiently initialize a message. Yes, great catch. I've applied this to xapian-updates branch and remerged into next. BTW can you base your patches off master instead of next? It will save me a couple keystrokes. -- William From wmorgan-sup@masanjin.net Mon Aug 24 19:24:19 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 24 Aug 2009 16:24:19 -0700 Subject: [sup-talk] [PATCH] add xapian-specific hack to quickly create a Person In-Reply-To: <1250967263-31292-1-git-send-email-rlane@club.cc.cmu.edu> References: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu> <1250967263-31292-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1251156216-sup-5563@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-08-22: > - mk_person = lambda { |x| Person.new(*x.reverse!) } > + mk_person = lambda { |x| QuickPerson.new(*x) } What about lambda { |x| Person.new x[1], x[0] }. Surely that must be even faster? -- William From wmorgan-sup@masanjin.net Mon Aug 24 19:29:40 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 24 Aug 2009 16:29:40 -0700 Subject: [sup-talk] How to edit attachments in reply? In-Reply-To: <1251031062-sup-4617@tiger.alporthouse.com> References: <1251031062-sup-4617@tiger.alporthouse.com> Message-ID: <1251156446-sup-143@masanjin.net> Reformatted excerpts from Chris Wilson's message of 2009-08-23: > Can anyone give me any clues on how to automatically include the > attachments in a reply? There's no way to do this currently. The best option might be to add a hook that sets the reply body at the beginning of reply-mode. Then you could add the attachments (if the mime type were appropriate) and do whatever other transformations you wanted on the message. -- William From rlane@club.cc.cmu.edu Mon Aug 24 21:03:29 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Mon, 24 Aug 2009 21:03:29 -0400 Subject: [sup-talk] [PATCH 2/2] xapian index format versioning In-Reply-To: <1251117610-sup-9144@peray> References: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu> <1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu> <20090816200116.GA17272@chistera.yi.org> <1250453934-sup-9651@zyrg.net> <1250951723-sup-3859@masanjin.net> <1251117610-sup-9144@peray> Message-ID: <1251161843-sup-2990@zyrg.net> Excerpts from Nicolas Pouillard's message of Mon Aug 24 08:41:03 -0400 2009: > Excerpts from William Morgan's message of Sat Aug 22 16:35:37 +0200 2009: > > Branch xapian-updates, merged into next. Thanks! > > What is the updating procedure please ? > sup-dump and sup-sync. Sorry for the inconvenience, but I don't currently have plans to break compatibility again so you should be safe for a while. From nicolas.pouillard@gmail.com Tue Aug 25 03:44:11 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Tue, 25 Aug 2009 09:44:11 +0200 Subject: [sup-talk] In next: thread-view-mode labelling No method join for Set In-Reply-To: <1251137007-sup-3974@masanjin.net> References: <1250714501-sup-3033@chigamba> <1250727630-sup-3112@yoom.home.cworth.org> <1251137007-sup-3974@masanjin.net> Message-ID: <1251185965-sup-6316@peray> Excerpts from William Morgan's message of Mon Aug 24 20:13:43 +0200 2009: > Reformatted excerpts from Carl Worth's message of 2009-08-19: > > I've attached a patch that at least makes the crashes I was able ro > > reproduce go away. > > Applied, thanks! > > > [*] Totally off-topic: This is one of the things about "dynamically > > typed" languages that I've never been able to wrap my brain around. I > > really like that with static typing I can trust the compiler to help > > me be very thorough if I make a type change like this, (and catch all > > the cases before shipping any code). Instead, here, there's a hard > > task of exercising every possible code path (at run time) before we > > know if there are any type errors still lingering. I've seen some > > proponents of dynamically-typed languages argue that unit testing > > should provide the same coverage that a statically-typed compiler > > would, but I haven't seen that in practice. [...] > I do believe that if I were using a statically-typed > language, development would be significantly slower, and Sup would be > nowhere near the point it is now. I have no proof of this statement, of > course. I don't really want to start troll on this subject... However it depends on what kind of statically-typed language to talk about, if you mean Java or C++ then I agree with you, the development would be much sloooower. Although if we take a language like Haskell (or OCaml, or Scala...) the development become really competitive. Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr From israel.herraiz@gmail.com Tue Aug 25 05:29:01 2009 From: israel.herraiz@gmail.com (Israel Herraiz) Date: Tue, 25 Aug 2009 11:29:01 +0200 Subject: [sup-talk] [PATCH] Add UTF-8 encoding string for ArchLinux systems Message-ID: <1251192382-sup-2350@elly> Hi, in ArchLinux, UTF-8 encoding is identified by "utf8" instead of "UTF-8". Cheers, Israel --- lib/sup/util.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/util.rb b/lib/sup/util.rb index 068ce6b..f99e1c1 100644 --- a/lib/sup/util.rb +++ b/lib/sup/util.rb @@ -177,7 +177,7 @@ class String ## nasty multibyte hack for ruby 1.8. if it's utf-8, split into chars using ## the utf8 regex and count those. otherwise, use the byte length. def display_length - if $encoding == "UTF-8" + if $encoding == "UTF-8" || $encoding == "utf8" scan(/./u).size else size -- 1.6.4 From israel.herraiz@gmail.com Tue Aug 25 05:31:55 2009 From: israel.herraiz@gmail.com (Israel Herraiz) Date: Tue, 25 Aug 2009 11:31:55 +0200 Subject: [sup-talk] [PATCH] Identify list messages by list-id if list-post is not present Message-ID: <1251192579-sup-1849@elly> Hi, I am subscribed to some lists that do not fill the list-post header, but have a list-id header. I am not sure how standard-compliant is that, but it would nice if Sup could identify those messages as list messages. Cheers, Israel --- lib/sup/message.rb | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/lib/sup/message.rb b/lib/sup/message.rb index 56e66de..67f928c 100644 --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -34,7 +34,7 @@ class Message attr_reader :id, :date, :from, :subj, :refs, :replytos, :to, :source, :cc, :bcc, :labels, :attachments, :list_address, :recipient_email, :replyto, - :source_info, :list_subscribe, :list_unsubscribe + :source_info, :list_subscribe, :list_unsubscribe, :list_id bool_reader :dirty, :source_marked_read, :snippet_contains_encrypted_content @@ -120,6 +120,13 @@ class Message else nil end + + @list_id = + if header["list-id"] + @list_id = header["list-id"].gsub(/^<|>$/, "") + else + nil + end @recipient_email = header["envelope-to"] || header["x-original-to"] || header["delivered-to"] @source_marked_read = header["status"] == "RO" @@ -162,7 +169,7 @@ class Message end def snippet; @snippet || (chunks && @snippet); end - def is_list_message?; !@list_address.nil?; end + def is_list_message?; !@list_address.nil? || !@list_id.nil?; end def is_draft?; @source.is_a? DraftLoader; end def draft_filename raise "not a draft" unless is_draft? -- 1.6.4 From wmorgan-sup@masanjin.net Tue Aug 25 10:16:44 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 25 Aug 2009 07:16:44 -0700 Subject: [sup-talk] lots of branches merged down to master Message-ID: <1251209432-sup-766@masanjin.net> Just FYI, I've merged the following branches down to master: buffer-rolling, run-mailcap-fixes, locking-refactor, logging, various-api-tweaks, and ncurses-fixes. If you're running master, you should see some fun improvements. -- William From rlane@club.cc.cmu.edu Tue Aug 25 21:50:48 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Tue, 25 Aug 2009 21:50:48 -0400 Subject: [sup-talk] [PATCH] add xapian-specific hack to quickly create a Person In-Reply-To: <1251156216-sup-5563@masanjin.net> References: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu> <1250967263-31292-1-git-send-email-rlane@club.cc.cmu.edu> <1251156216-sup-5563@masanjin.net> Message-ID: <1251250991-sup-3593@zyrg.net> Excerpts from William Morgan's message of Mon Aug 24 19:24:19 -0400 2009: > Reformatted excerpts from Rich Lane's message of 2009-08-22: > > - mk_person = lambda { |x| Person.new(*x.reverse!) } > > + mk_person = lambda { |x| QuickPerson.new(*x) } > > What about lambda { |x| Person.new x[1], x[0] }. Surely that must be > even faster? The slow part is the processing in Person#initialize, which QuickPerson overrides. You might also be able to avoid that by moving the initialize() code into Person.from_address. From cworth@cworth.org Wed Aug 26 16:26:34 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 26 Aug 2009 13:26:34 -0700 Subject: [sup-talk] 'next' crash: wrong id called on nil (thread.rb:264:in `thread_for') In-Reply-To: <1251153912-sup-5105@masanjin.net> References: <1250820431-sup-8159@yoom.home.cworth.org> <1251153912-sup-5105@masanjin.net> Message-ID: <1251318332-sup-4953@yoom.home.cworth.org> Excerpts from William Morgan's message of Mon Aug 24 15:45:37 -0700 2009: > Reformatted excerpts from Carl Worth's message of 2009-08-20: > > --- RuntimeError from thread: main > > wrong id called on nil > > I think this should be fixed in recent nexts. Can you confirm? I don't think I'll be able to, (since I don't have a good recipe for reproducing the bug). But I'll certainly start running rom newer next and I'll let you know if I run into any further problems. Thanks for everything, -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Wed Aug 26 17:15:36 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 26 Aug 2009 14:15:36 -0700 Subject: [sup-talk] [PATCH 2/2] ui responsiveness tweaks In-Reply-To: <1251053171-11450-2-git-send-email-rlane@club.cc.cmu.edu> References: <1251053171-11450-1-git-send-email-rlane@club.cc.cmu.edu> <1251053171-11450-2-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1251318620-sup-3031@yoom.home.cworth.org> My message here really has nothing to do with Rich's patches specifically, (so sorry about that), but his patches happened to provide the perfect context for an issue I wanted to bring up. As is typical of git-formatted patches, Rich's emails have subject lines from his commit messages: [sup-talk] [PATCH 1/2] preemptively load messages when scrolling [sup-talk] [PATCH 2/2] ui responsiveness tweaks As far as the git commits go, this subject line is one of the most essential pieces of metadata to accompany the patch. Yet by default sup doesn't display it at all, (requiring keypresses to display the header and find the subject line). I think what I would like is for sup to display the subject line everytime it changes significantly in a thread, (specifically not regarding things like an initial "Re: " getting added as significant). I think I'd be willing to spend an entire line's worth of screen real estate for this information---it's quite useful when people do meaningful subject changes for sub-threads. -Carl Excerpts from Rich Lane's message of Sun Aug 23 11:46:11 -0700 2009: > --- > bin/sup | 1 + > lib/sup/modes/thread-index-mode.rb | 4 ++-- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/bin/sup b/bin/sup > index 3d5b6c1..f3c6771 100755 > --- a/bin/sup > +++ b/bin/sup > @@ -58,6 +58,7 @@ if $opts[:list_hooks] > end > > Thread.abort_on_exception = true # make debugging possible > +Thread.current.priority = 1 # keep ui responsive > > module Redwood > > diff --git a/lib/sup/modes/thread-index-mode.rb > b/lib/sup/modes/thread-index-mode.rb > index fb6b2ce..177431b 100644 > --- a/lib/sup/modes/thread-index-mode.rb > +++ b/lib/sup/modes/thread-index-mode.rb > @@ -76,8 +76,7 @@ EOS > @last_load_more_size = nil > to_load_more do |size| > next if @last_load_more_size == 0 > - load_threads :num => 1, :background => false > - load_threads :num => (size - 1), > + load_threads :num => size, > :when_done => lambda { |num| @last_load_more_size = num } > end > end > @@ -627,6 +626,7 @@ EOS > BufferManager.draw_screen > last_update = Time.now > end > + ::Thread.pass > break if @interrupt_search > end > @ts.threads.each { |th| th.labels.each { |l| LabelManager << l } } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Wed Aug 26 17:26:18 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 26 Aug 2009 14:26:18 -0700 Subject: [sup-talk] Exception trying to run git source In-Reply-To: <1250964942-sup-8625@masanjin.net> References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net> <1250699596-sup-8133@ntdws12.chass.utoronto.ca> <1250704257-sup-3308@yoom> <1250707794-sup-6173@masanjin.net> <1250710221-sup-925@yoom.home.cworth.org> <1250712045-sup-3506@masanjin.net> <1250717434-sup-4489@yoom.home.cworth.org> <1250964942-sup-8625@masanjin.net> Message-ID: <1251321606-sup-7393@yoom.home.cworth.org> Reformatted excerpts from William Morgan's message of Sat Aug 22 13:23:17 -0700 2009: > Reformatted excerpts from Carl Worth's message of 2009-08-19: > > $:.unshift File.dirname(__FILE__) # For use/testing when no gem is installed > > I'd call that a bug in chronic. It shouldn't be screwing with the load > path. That's what I thought too. I filed a Debian bug against the libchronic-ruby package here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542491 But I reall only did that because I didn't find any contact information for how to submit an upstream bug against chronic (http://chronic.rubyforge.net didn't have any details that I could find). So if someone knows a better place to file the bug, I'd be glad to do that. > Nice debug work. Thanks. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Wed Aug 26 17:35:25 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 26 Aug 2009 14:35:25 -0700 Subject: [sup-talk] [PATCH] Make SUP_LOG_LEVEL self-documenting. In-Reply-To: <1250972634-sup-6871@masanjin.net> References: <1250745799-sup-6607@yoom.home.cworth.org> <1250972634-sup-6871@masanjin.net> Message-ID: <1251322427-sup-9184@yoom.home.cworth.org> The idea here is that if someone is looking at the log and not seeing the information of interest, then the log itself should tell them how to get more information, (by suggesting to set SUP_LOG_LEVEL to the next lower level). --- Excerpts from William Morgan's message of Sat Aug 22 13:25:22 -0700 2009: > It all looks good except you can use Logger::LEVELS to access the > constants. Then there's no need to write a LEVELS method. If you fix > that I will apply. Thanks! Thanks. I had the distinct feeling I was doing something wrong there. Here's a corrected version. -Carl bin/sup | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/bin/sup b/bin/sup index 3d5b6c1..cdf1ff2 100755 --- a/bin/sup +++ b/bin/sup @@ -169,6 +169,9 @@ begin lmode.on_kill { Logger.clear! } Logger.add_sink lmode Logger.force_message "Welcome to Sup! Log level is set to #{Logger.level}." + if Logger::LEVELS.index(Logger.level) > 0 + Logger.force_message "For more verbose logging, restart with SUP_LOG_LEVEL=#{Logger::LEVELS[Logger::LEVELS.index(Logger.level)-1]}." + end debug "initializing inbox buffer" imode = InboxMode.new -- 1.6.3.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Wed Aug 26 17:53:32 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 26 Aug 2009 14:53:32 -0700 Subject: [sup-talk] [PATCH] Be less overzealous in moving text to the left column In-Reply-To: <1251050007-sup-9740@masanjin.net> References: <1250749447-sup-1744@yoom.home.cworth.org> <1251050007-sup-9740@masanjin.net> Message-ID: <1251323127-sup-5162@yoom.home.cworth.org> Excerpts from William Morgan's message of Sun Aug 23 10:55:59 -0700 2009: > Reformatted excerpts from Carl Worth's message of 2009-08-19: > > Specifically, scroll as little as possible to get the current message > > to just fit on the right side. > > Is this the same as setting loose_alignment to true, and the > IDEAL_*_CONTENTs to 0? I don't think so. Doing that, (at least as in the below patch, for example), always puts the current message flush left. And that can result in later messages in the threads, (not descendants of the current thread though), being cut off on the left. (And all this with dozens of empty columns on the right of my terminal.) That's precisely the behavior I was getting before my patch and which I'm trying to change. What I want instead is for the message to appear in its "natural" position (according to the threading), unless that would cause the message to be cut off on the right. In which case, we jump to the minimum column such that: 1. We don't cut any of the current message off on the left 2. We display all of the message on the right, (if possible without violating point 1). I believe that what I've coded achieves that. The two open questions I still have are: A. Is there some simpler way to achieve the result I want with some of the existing code? B. If not, is some of the existing code rendered obsolete with my code in place? As for (B), for example, with my code in place I don't think there's any need for a notion of "ideal context". The ideal context is the natural position of the thread. And I still haven't figured out what loose_alignment means and which actions will cause loose vs. non-loose layout. -Carl diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index dfe30ff..b7bbc7c 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -401,9 +401,9 @@ EOS end end - IDEAL_TOP_CONTEXT = 3 # try and give 3 rows of top context - IDEAL_LEFT_CONTEXT = 4 # try and give 4 columns of left context - def jump_to_message m, loose_alignment=false + IDEAL_TOP_CONTEXT = 0 # don't bother trying to give any rows of top context + IDEAL_LEFT_CONTEXT = 0 # don't bother trying to give any columns of left context + def jump_to_message m, loose_alignment=true l = @layout[m] left = l.depth * INDENT_SPACES right = left + l.width -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Wed Aug 26 18:24:36 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 26 Aug 2009 15:24:36 -0700 Subject: [sup-talk] On making inbox-mode and search-results-mode more similar Message-ID: <1251323747-sup-1595@yoom.home.cworth.org> [Argh! I ended up getting really verbose again with this one. Thanks to anyone patient enough to wade through all of this. There is a patch here for one issue at least. See below.] I spent about 4 days away from email which gave me my first case of a large inbox after switching to sup. And there are definitely a few things I'd like to convince sup to do to make it easier for me to deal with this. Most important, with a large inbox, my mail falls into different "classes", some of which are more important than others, and I'd like to deal with the most important things first. I also often want to deal with a single "class" of mail as a whole to avoid mental context switches. Fortunately, I've got sup labels capturing these classes quite well. I've got some future ideas for having a prioritized (partial order) list of labels so that inbox-mode will present messages according to that priority. But for now, it would be good enough to be able to easily filter my inbox down to just a single class of messages at a time. To this end, I started using the patch below, which adds a refine_search keybinding to inbox-mode much like the same function in search-result-mode. This is useful already and might be considered for inclusion as is, (another feature I'd like for both modes is "restrict to label" which would act like refine-search but save me from having to type "label:" much like the 'L' command avoids having to type "label:" compared to the 'F' command). Beyond this patch as is, though, I'd like to talk a bit about how to better achieve what I want. There's obviously some code duplication in this patch which is not ideal. It would be better if InboxMode could be a derived class from SearchResultsMode. Not only would this reduce code-duplication, but there are features currently in InboxMode that I think belong in all searches. For example, if I use the refine_search command below to get a view of my inbox restricted to a particular label, it no longer acts like my inbox does. One of the most noticeable cases is the archive command[*]. In both inbox-mode and search-result-mode this command removes the "inbox" label from a thread, but in inbox-mode the thread is immediately removed from the results, while in search-results-mode the thread remains in the results. One annoying side effect of this is that when I'm reading and archiving many threads in some class, then I happen to reply to one thread, that thread gets bumped to the top of my search so when I navigate to the "next" thread I start cycling through threads that I just got finished reading and archiving. To fix this I end up having to notice I'm seeing repeated messages, remember why, then save my current changes and refresh the search. And I have to do this after every reply. [Note: Even if archiving messages made them immediately disappear from my search results, there could still be problems with "next" causing me to re-cycle through messages I had already read but decided to leave in my inbox. I think this is just another general race-condition bug. I think the fix would be for the transition from search-results-mode to thread-view-mode to somehow snapshot the current search results so that future modifications due to newly arriving messages don't modify the meaning of "next thread" within thread-view-mode.] So what I want is for anytime a message is changed such that it no longer meets the current search criteria, it is immediately removed from the search results. I think that means simply implementing the is_relevant? method for SearcResultsMode where there is currently just the following comment: ## a proper is_relevant? method requires some way of asking ferret ## if an in-memory object satisfies a query. i'm not sure how to do ## that yet. in the worst case i can make an in-memory index, add ## the message, and search against it to see if i have > 0 results, ## but that seems pretty insane. That single-message index and search sounds exactly like what I want, and not insane at all. Has someone attempted this and found a performance issue? (In which case, I would think we just need to fix that performance bug.) Or is it simply a matter of nobody having tried to code this up yet? (In which case, I'll try, and I'll be glad for any pointers that anyone can give me on how to go about creating an in-memory index and searching on it.) Thanks, -Carl [*] I'll ignore for now the fact that 'a' is a toggle of the inbox label in SearchResultsMode and a one-way removal of the label in InboxMode. I haven't found any need to ever put a thread _back_ into the inbox, (except perhaps in the case of accidental archiving, and there an immediate undo works fine). So I would imagine the use is rare enough to not need a single-character command. The command I would find natural for putting a thread back into the inbox would be to simply add the inbox label to the thread. Oddly this is currently not allowed as "inbox" is a reserved label. I don't >From d37eca31aaddee80f05357d6a4ed896f39bbad16 Mon Sep 17 00:00:00 2001 From: Carl Worth Date: Wed, 26 Aug 2009 10:17:20 -0700 Subject: [PATCH] Add a refine_search command to InboxMode 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. --- lib/sup/modes/inbox-mode.rb | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/lib/sup/modes/inbox-mode.rb b/lib/sup/modes/inbox-mode.rb index ba095da..c8072cd 100644 --- a/lib/sup/modes/inbox-mode.rb +++ b/lib/sup/modes/inbox-mode.rb @@ -7,6 +7,7 @@ class InboxMode < ThreadIndexMode ## overwrite toggle_archived with archive k.add :archive, "Archive thread (remove from inbox)", 'a' k.add :read_and_archive, "Archive thread (remove from inbox) and mark read", 'A' + k.add :refine_search, "Refine search", '|' end def initialize @@ -17,6 +18,12 @@ class InboxMode < ThreadIndexMode def is_relevant? m; (m.labels & [:spam, :deleted, :killed, :inbox]) == Set.new([:inbox]) end + def refine_search + text = BufferManager.ask :search, "refine query: ", "label:inbox -label:spam -label:deleted -label:killed " + return unless text && text !~ /^\s*$/ + SearchResultsMode.spawn_from_query text + end + ## label-list-mode wants to be able to raise us if the user selects ## the "inbox" label, so we need to keep our singletonness around def self.instance; @@instance; end -- 1.6.3.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Wed Aug 26 18:40:34 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 26 Aug 2009 15:40:34 -0700 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to thread-view-mode to archive/delete current thread Message-ID: <1251325542-sup-3105@yoom.home.cworth.org> These behave identically to the existing ",a" and ",d" commands, (that is they archive or delete the current thread and then view the next). --- I appreciate that within thread-view-mode, sup already supports explicitly selecting one of three different actions for what do after the user is done with a thread. And the choice is determined by one of three different prefix characters. For example: . -> return to previous buffer (likely something like inbox-mode/search-result-mode) , -> advance to next thread (into thread-view-mode) ] -> advance to previous thread (into thread-view-mode) I'm lazy enough to want a single-character command for efficient processing of mail in thread-view-mode, (just like I already have while in inbox-mode and search-results-mode). And for two of the different actions, (archive and delete), the obvious/consistent keybinding is available. So this patch assigns those, ('a' as a shortcut for ',a' and 'd' as a shortcut for ',d'). If I seem too lazy here, and it doesn't seem sane to add these keybindingd by default, just let me know. In that case I'll consign myself to just using a hook to setup these keybindings for myself personally. The perhaps-not-as-obvious piece is what the exit action should be for these shortcut commands. For my own use, I've found it best to advance to the next thread. (This supports a workflow where there's one pass through the inbox to archive as much as possible without reading, and then another pass through thread-view-mode for everything that's left.) One thing this patch doesn't provide is shortcuts for the other three exit actions, (',s' for mark-as-spam-then-next, ',N' for mark-as-unread-then-next, and ',n' for simply advancing to the next thread without changing the current thread). Of those, the only one I really care about personally is ',n'. It's obviously not a simple matter of just making 'n' a shortcut for ',n' since the 'n' keybinding is already used. But actually, I think I would like the 'n' keybinding to advance to the next thread once I'm viewing the last open message in the current thread. This would make for very efficient sessions of just reading mail, where I'd only need to keep hitting 'n', (and I could hit 'a' whenever bored with any particular thread). So perhaps I'll look into coding that up next. lib/sup/modes/thread-view-mode.rb | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index 678b841..0706757 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -64,6 +64,9 @@ EOS k.add :unsubscribe_from_list, "Subscribe to/unsubscribe from mailing list", ")" k.add :pipe_message, "Pipe message or attachment to a shell command", '|' + k.add :archive_and_next, "Archive this thread, kill buffer, and view next", 'a' + k.add :delete_and_next, "Delete this thread, kill buffer, and view next", 'd' + k.add_multi "(a)rchive/(d)elete/mark as (s)pam/mark as u(N)read:", '.' do |kk| kk.add :archive_and_kill, "Archive this thread and kill buffer", 'a' kk.add :delete_and_kill, "Delete this thread and kill buffer", 'd' -- 1.6.3.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Wed Aug 26 18:47:54 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 26 Aug 2009 15:47:54 -0700 Subject: [sup-talk] Should '/' trigger the loading of more messages? Message-ID: <1251326494-sup-2328@yoom.home.cworth.org> It seems to me that the "search in current buffer" command should automatically trigger the loading of additional messages when no results are found so that it can continue searching. What just happened to me is that I *knew* my inbox contained a message with a particular string in the subject, but I couldn't find it with '/'. The problem was that enough new threads had arrived that the message of interest wasn't loaded yet. The fact that the various ThreadIndexModes don't load all relevant threads is just an optimization, but I don't think it should change the semantics of a search operation. (My thread *is* still in my inbox even if it hasn't been loaded.) Of course, for the feature I want to work well there needs to be an easy way to interrupt the searching and loading if it's going on too long, (say, I mistyped the search string and I know it's likely to load a million messages without ever finding the string I typed). Does sup already have a notion like emacs' "C-g" which is used to cancel or interrupt any ongoing command? -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth@cworth.org Wed Aug 26 18:52:38 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 26 Aug 2009 15:52:38 -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: <1251327030-sup-7342@yoom.home.cworth.org> Excerpts from Carl Worth's message of Wed Aug 26 15:24:36 -0700 2009: > + text = BufferManager.ask :search, "refine query: ", "label:inbox > -label:spam -label:deleted -label:killed " Is that even the right syntax for searching for threads with the inbox label but excluding threades with the spam, deleted, or killed labels? I took a guess at the syntax and I thought I saw it working, but it doesn't appear to be now. Can someone tell me the actual syntax? (Or better, is there a writeup somewhere of the general search syntax accepted by sup?) -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ingmar@exherbo.org Wed Aug 26 22:37:57 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Thu, 27 Aug 2009 04:37:57 +0200 Subject: [sup-talk] Should '/' trigger the loading of more messages? In-Reply-To: <1251326494-sup-2328@yoom.home.cworth.org> References: <1251326494-sup-2328@yoom.home.cworth.org> Message-ID: <1251340454-sup-3773@cannonball> Excerpts from Carl Worth's message of Thu Aug 27 00:47:54 +0200 2009: > It seems to me that the "search in current buffer" command should > automatically trigger the loading of additional messages when no > results are found so that it can continue searching. I'd expect a "search in current buffer" to do exactly that, no more no less. > What just happened to me is that I *knew* my inbox contained a message > with a particular string in the subject, but I couldn't find it with > '/'. The problem was that enough new threads had arrived that the > message of interest wasn't loaded yet. If you know it's in your inbox, why not search with '\', for 'label:inbox foo'? > The fact that the various ThreadIndexModes don't load all relevant > threads is just an optimization, but I don't think it should change > the semantics of a search operation. (My thread *is* still in my inbox > even if it hasn't been loaded.) > > Of course, for the feature I want to work well there needs to be an > easy way to interrupt the searching and loading if it's going on too > long, (say, I mistyped the search string and I know it's likely to > load a million messages without ever finding the string I typed). > > Does sup already have a notion like emacs' "C-g" which is used to > cancel or interrupt any ongoing command? Try C-g. :-) (Documented as ^G on the help page) > -Carl -- Exherbo KDE, X.org maintainer From ingmar@exherbo.org Wed Aug 26 22:54:36 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Thu, 27 Aug 2009 04:54:36 +0200 Subject: [sup-talk] [PATCH 2/2] ui responsiveness tweaks In-Reply-To: <1251318620-sup-3031@yoom.home.cworth.org> References: <1251053171-11450-1-git-send-email-rlane@club.cc.cmu.edu> <1251053171-11450-2-git-send-email-rlane@club.cc.cmu.edu> <1251318620-sup-3031@yoom.home.cworth.org> Message-ID: <1251341498-sup-428@cannonball> Excerpts from Carl Worth's message of Wed Aug 26 23:15:36 +0200 2009: > My message here really has nothing to do with Rich's patches > specifically, (so sorry about that), but his patches happened to > provide the perfect context for an issue I wanted to bring up. As is > typical of git-formatted patches, Rich's emails have subject lines > from his commit messages: > > [sup-talk] [PATCH 1/2] preemptively load messages when scrolling > [sup-talk] [PATCH 2/2] ui responsiveness tweaks > > As far as the git commits go, this subject line is one of the most > essential pieces of metadata to accompany the patch. Yet by default > sup doesn't display it at all, (requiring keypresses to display the > header and find the subject line). I think what I would like is for > sup to display the subject line everytime it changes significantly in > a thread, (specifically not regarding things like an initial "Re: " > getting added as significant). > > I think I'd be willing to spend an entire line's worth of screen real > estate for this information---it's quite useful when people do > meaningful subject changes for sub-threads. Yeah, I completely agree. That would make sup even better for me. Maybe this could be implemented as a 3-way toggle, toggling between - don't show subjects (current default?) - only show interesting subject changes - always show subject in a threadview. -Ingmar -- Exherbo KDE, X.org maintainer From rlane@club.cc.cmu.edu Thu Aug 27 02:50:29 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 27 Aug 2009 02:50:29 -0400 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: <1251341286-sup-9400@zyrg.net> Excerpts from Carl Worth's message of Wed Aug 26 18:24:36 -0400 2009: > So what I want is for anytime a message is changed such that it no > longer meets the current search criteria, it is immediately removed > from the search results. I think that means simply implementing the > is_relevant? method for SearcResultsMode where there is currently just > the following comment: > > ## a proper is_relevant? method requires some way of asking ferret > ## if an in-memory object satisfies a query. i'm not sure how to do > ## that yet. in the worst case i can make an in-memory index, add > ## the message, and search against it to see if i have > 0 results, > ## but that seems pretty insane. > > That single-message index and search sounds exactly like what I want, > and not insane at all. Has someone attempted this and found a > performance issue? (In which case, I would think we just need to fix > that performance bug.) Or is it simply a matter of nobody having tried > to code this up yet? (In which case, I'll try, and I'll be glad for > any pointers that anyone can give me on how to go about creating an > in-memory index and searching on it.) We had a thread a while back about applying label changes immediately and I think the consensus was that that's a good idea. Doing this could simplify a great deal of thread-index-mode code because a fast is_relevant? could be implemented using existing index operations without the special cases for archiving/etc and without creating an inmemory database. I have a patch I plan to mail out soon that makes changing labels with Xapian much quicker, so that should help. It'd be great if you decide to tackle this. From marcus-sup@bar-coded.net Thu Aug 27 05:05:13 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Thu, 27 Aug 2009 10:05:13 +0100 Subject: [sup-talk] Should '/' trigger the loading of more messages? In-Reply-To: <1251340454-sup-3773@cannonball> References: <1251326494-sup-2328@yoom.home.cworth.org> <1251340454-sup-3773@cannonball> Message-ID: <1251363903-sup-2197@bar-coded.net> On 27.8.2009, Ingmar Vanhassel wrote: > > What just happened to me is that I *knew* my inbox contained a message > > with a particular string in the subject, but I couldn't find it with > > '/'. The problem was that enough new threads had arrived that the > > message of interest wasn't loaded yet. > > If you know it's in your inbox, why not search with '\', for > 'label:inbox foo'? ... coupled with '!!' to load all threads in the search (ctrl-g works to stop search) this would do what you want. HTH Marcus From cworth@cworth.org Thu Aug 27 08:17:12 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 27 Aug 2009 05:17:12 -0700 Subject: [sup-talk] Should '/' trigger the loading of more messages? In-Reply-To: <1251340454-sup-3773@cannonball> References: <1251326494-sup-2328@yoom.home.cworth.org> <1251340454-sup-3773@cannonball> Message-ID: <1251375048-sup-403@yoom.home.cworth.org> Excerpts from Ingmar Vanhassel's message of Wed Aug 26 19:37:57 -0700 2009: > Excerpts from Carl Worth's message of Thu Aug 27 00:47:54 +0200 2009: > > It seems to me that the "search in current buffer" command should > > automatically trigger the loading of additional messages when no > > results are found so that it can continue searching. > > I'd expect a "search in current buffer" to do exactly that, no more no > less. You obviously know well what the current buffer is doing, (incrementally loading threads only as you page down to them). But I don't think it's reasonable to expect all users to understand things that well in order to use sup correctly. Imagine the near future where we get the thread-loading performance bugs all worked out, (see nearby threads making good progress). If a user starts sup and sees a screenful of threads instantly, hits page down a couple of times and sees another couple of screensful instantly, then wouldn't it be reasonable for such a user to expect that all of that instantly-appearing content does exist in the current buffer? > If you know it's in your inbox, why not search with '\', for > 'label:inbox foo'? I'm searching locally, because I already performed a global search and don't want to repeat the terms of it. Or else why does sup have a local search command independent of the global search? > Try C-g. :-) > (Documented as ^G on the help page) Ah, thanks. Now this one was just me being stupid. (I think I was already using this in sup naturally.) -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From guillaume.quintard@gmail.com Thu Aug 27 08:18:53 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Thu, 27 Aug 2009 14:18:53 +0200 Subject: [sup-talk] Nobody told me Message-ID: <1e5fdab70908270518k3f349191jb5e780e0e0555461@mail.gmail.com> Playing the dumb newbie here, but when did that happened? ./lib/sup/xapian_index.rb:32:in `load_index': This Sup version expects a v1 index, but you have an existing v0 index. Please downgrade to your previous version and dump your labels before upgrading to this version (then run sup-sync --restore). (RuntimeError) from ./lib/sup/index.rb:67:in `load' from bin/sup-sync:117 -- Guillaume From ezyang@MIT.EDU Thu Aug 27 11:36:28 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Thu, 27 Aug 2009 11:36:28 -0400 Subject: [sup-talk] Ignore killed messages in U screen Message-ID: <1251387376-sup-7180@javelin> >From e01820e5914c4fb8deb5836473aa37553e5a6234 Mon Sep 17 00:00:00 2001 From: Edward Z. Yang Date: Wed, 26 Aug 2009 10:45:26 -0400 Subject: [PATCH] Do not display killed messages in unread screen. Signed-off-by: Edward Z. Yang --- bin/sup | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/bin/sup b/bin/sup index bbb6c17..645a9a1 100755 --- a/bin/sup +++ b/bin/sup @@ -263,7 +263,7 @@ begin next unless query && query !~ /^\s*$/ SearchResultsMode.spawn_from_query query when :search_unread - SearchResultsMode.spawn_from_query "is:unread" + SearchResultsMode.spawn_from_query "is:unread !label:killed" when :list_labels labels = LabelManager.all_labels.map { |l| LabelManager.string_for l } user_label = bm.ask_with_completions :label, "Show threads with label (enter for listing): ", labels -- 1.6.4 From bwalton@artsci.utoronto.ca Thu Aug 27 11:50:08 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 27 Aug 2009 11:50:08 -0400 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1251387376-sup-7180@javelin> References: <1251387376-sup-7180@javelin> Message-ID: <1251388133-sup-2253@ntdws12.chass.utoronto.ca> Excerpts from Edward Z. Yang's message of Thu Aug 27 11:36:28 -0400 2009: > Subject: [PATCH] Do not display killed messages in unread screen. +1 for this. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ezyang@MIT.EDU Thu Aug 27 11:56:32 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Thu, 27 Aug 2009 11:56:32 -0400 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1251387376-sup-7180@javelin> References: <1251387376-sup-7180@javelin> Message-ID: <1251388546-sup-7744@javelin> Excerpts from Edward Z. Yang's message of Thu Aug 27 11:36:28 -0400 2009: > - SearchResultsMode.spawn_from_query "is:unread" > + SearchResultsMode.spawn_from_query "is:unread !label:killed" I might have one legitimate objection to this patch, which is that searches should ignore killed tags unless explicitly told not to. Cheers, Edward From joe@joeshaw.org Thu Aug 27 15:44:02 2009 From: joe@joeshaw.org (Joe Shaw) Date: Thu, 27 Aug 2009 15:44:02 -0400 Subject: [sup-talk] sent and draft sources Message-ID: Hi, I'd like to use existing maildir folders I have for Sup's sent and draft folders, but I couldn't find a way how. Is this possible? I am surprised this is not a FAQ. :) Apologies for the total noob question. I'm liking what I see in Sup so far. Thanks, Joe From bwalton@artsci.utoronto.ca Thu Aug 27 15:49:17 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 27 Aug 2009 15:49:17 -0400 Subject: [sup-talk] sent and draft sources In-Reply-To: References: Message-ID: <1251402318-sup-4655@ntdws12.chass.utoronto.ca> Excerpts from Joe Shaw's message of Thu Aug 27 15:44:02 -0400 2009: > I'd like to use existing maildir folders I have for Sup's sent and > draft folders, but I couldn't find a way how. Is this possible? I am > surprised this is not a FAQ. :) For sent, yes. For drafts, not yet. Using sup-config you can select the sent source, or you could edit config.yaml by hand. The line in my config is this: :sent_source: maildir:///u/bwalton/Maildir/.sent-mail/ I defined a source with that URI and then set the value in config.yaml. My outbound mail is then stored in that Maildir folder. Only some sources work for mail storage. These are mbox, Maildir and IMAP. I'd advise against having anything else write to the same mbox (eg: don't have new mail delivered to the same source) if you go with an mbox URI. I'm not sure whether the official release includes this functionality yet or not as I run from git:next. I _think_ 0.8.1 included it, but would have to actually check. HTH -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From joe@joeshaw.org Thu Aug 27 15:58:29 2009 From: joe@joeshaw.org (Joe Shaw) Date: Thu, 27 Aug 2009 15:58:29 -0400 Subject: [sup-talk] sent and draft sources In-Reply-To: <1251402318-sup-4655@ntdws12.chass.utoronto.ca> References: <1251402318-sup-4655@ntdws12.chass.utoronto.ca> Message-ID: Hi, Thanks for the info. On Thu, Aug 27, 2009 at 3:49 PM, Ben Walton wrote: > I'm not sure whether the official release includes this functionality > yet or not as I run from git:next. ?I _think_ 0.8.1 included it, but > would have to actually check. It doesn't appear to. At least, setting sup-config didn't give me any option to, and setting it in my config.yaml didn't seem to work either. How safe is building and running from git master? Is there a general philosophy about its stability? I'm a hacker, but I'm not strong in Ruby and I am not sure yet that I want to hack on my mailer. ;) Joe From sean.escriva@gmail.com Thu Aug 27 16:03:17 2009 From: sean.escriva@gmail.com (Sean Escriva) Date: Thu, 27 Aug 2009 13:03:17 -0700 Subject: [sup-talk] sup crashed: NoMethodError Message-ID: <20090827200317.GA3065@gmail.com> I broke my sup! I wanted to play with the git version so I did: git pull, rake gem, gem install pkg/sup-999.gem well that broke it all, and I don't know how to fix it. so far I have tried a gem cleanup, gem uninstall sup, gem install -r sup, all to no avail. It still always crashes with the following: --- NoMethodError from thread: main undefined method `[]' for false:FalseClass /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:107:in `start' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:161 /usr/bin/sup:19:in `load' /usr/bin/sup:19 Any tips on how to fix/figure out what I did wrong are greatly appreciated! -sme From dato@net.com.org.es Thu Aug 27 16:00:53 2009 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=) Date: Thu, 27 Aug 2009 21:00:53 +0100 Subject: [sup-talk] sent and draft sources In-Reply-To: <1251402318-sup-4655@ntdws12.chass.utoronto.ca> References: <1251402318-sup-4655@ntdws12.chass.utoronto.ca> Message-ID: <20090827200053.GA17416@chistera.yi.org> + Ben Walton (Thu, 27 Aug 2009 15:49:17 -0400): > For sent, yes. For drafts, not yet. Using sup-config you can select > the sent source, or you could edit config.yaml by hand. The line in > my config is this: > :sent_source: maildir:///u/bwalton/Maildir/.sent-mail/ I tried that, but then all messages got tagged "sent", even old ones and threads in which I didn't participate. > I'd advise against having anything else write to the same mbox > (eg: don't have new mail delivered to the same source) if you go with > an mbox URI. Why? Would sup not lock the mbox properly? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai From bwalton@artsci.utoronto.ca Thu Aug 27 19:39:20 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 27 Aug 2009 19:39:20 -0400 Subject: [sup-talk] sent and draft sources In-Reply-To: <20090827200053.GA17416@chistera.yi.org> References: <1251402318-sup-4655@ntdws12.chass.utoronto.ca> <20090827200053.GA17416@chistera.yi.org> Message-ID: <1251416206-sup-4808@ntdws12.chass.utoronto.ca> Excerpts from Adeodato Sim?'s message of Thu Aug 27 16:00:53 -0400 2009: > > I'd advise against having anything else write to the same mbox > > (eg: don't have new mail delivered to the same source) if you go with > > an mbox URI. > > Why? Would sup not lock the mbox properly? No, it wouldn't. I've got a half-baked LockManager branch sitting around, but I haven't touched it for some time now. I don't use any mbox here myself so it's not a personal itch. As it stands, the LockManager code has the basic ability to do locking using three lock types. I haven't worked out the nicest way to stack them (ala dovecot) though in a way that will play nicely with threads _and_ allow for non-block-wrapped calling. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Thu Aug 27 20:43:56 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 27 Aug 2009 20:43:56 -0400 Subject: [sup-talk] sent and draft sources In-Reply-To: <20090827200053.GA17416@chistera.yi.org> References: <1251402318-sup-4655@ntdws12.chass.utoronto.ca> <20090827200053.GA17416@chistera.yi.org> Message-ID: <1251420193-sup-4823@ntdws12.chass.utoronto.ca> Excerpts from Adeodato Sim?'s message of Thu Aug 27 16:00:53 -0400 2009: > > :sent_source: maildir:///u/bwalton/Maildir/.sent-mail/ > > I tried that, but then all messages got tagged "sent", even old ones and > threads in which I didn't participate. This is interesting. It might have happened to me too, but since all of the mail in that folder was historically sent, I either didn't notice (since it was already archived) or this is a new issue. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jim@gonzul.net Thu Aug 27 22:37:48 2009 From: jim@gonzul.net (Jim Cheetham) Date: Fri, 28 Aug 2009 14:37:48 +1200 Subject: [sup-talk] Encrypted password in configuration file In-Reply-To: <20090824215435.182e0007@ronin.larsko.net> References: <20090824215435.182e0007@ronin.larsko.net> Message-ID: On Tue, Aug 25, 2009 at 8:54 AM, Lars Kotthoff wrote: > Hi list, > > ?is it possible to store the account password encrypted in the configuration > file? It's possible, but slightly pointless. Have a read of Eric Raymond's discussions about Fetchmail, which has the same configuration data :- http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s09.html "Another lesson is about security by obscurity. Some fetchmail users asked me to change the software to store passwords encrypted in the rc file, so snoopers wouldn't be able to casually see them. I didn't do it, because this doesn't actually add protection. Anyone who's acquired permissions to read your rc file will be able to run fetchmail as you anyway?and if it's your password they're after, they'd be able to rip the necessary decoder out of the fetchmail code itself to get it. All .fetchmailrc password encryption would have done is give a false sense of security to people who don't think very hard. The general rule here is: 17. A security system is only as secure as its secret. Beware of pseudo-secrets." -jim From jim@gonzul.net Fri Aug 28 03:07:02 2009 From: jim@gonzul.net (Jim Cheetham) Date: Fri, 28 Aug 2009 19:07:02 +1200 Subject: [sup-talk] Encrypted password in configuration file In-Reply-To: <20090828012502.15484x8musndy5mo@webmail.seas.upenn.edu> References: <20090824215435.182e0007@ronin.larsko.net> <20090828012502.15484x8musndy5mo@webmail.seas.upenn.edu> Message-ID: On Fri, Aug 28, 2009 at 5:25 PM, wrote: > I can imagine all kinds of situations with "benevolent" attackers. ?For > example, what about a girlfriend that pokes around your hard drive looking > for lolcats when she's bored? ?One glance at .fetchmailrc would show it's > not a lolcat; but that same glance could show a password that you don't > really want her to know. It took over 7 years before I would even tell my wife my login password; I've since changed it and won't share it. And I trust her implicitly with my machine -- there is nothing on there that I'm not happy for her to see :-) So, how does the putative bored girlfriend poke around your hard-drive in the first place, in this scenario? If you are letting her use your account and poke around your machine in the first place, how does her seeing a password cause a problem? If you don't want someone to know something, don't put them is a situation where they might find it. You shouldn't expect a program to employ a pointless encryption/obscuration scheme just because you don't look after your other data. You are increasing the complexity of the code, increasing the complexity of the testing environment, increasing the opportunity for bugs to occur (possibly causing data loss?), and protecting against nothing. Now, there is an approach used by mutt that sup doesn't seem to use, which is to prompt the user at the beginning of a session for the various source passwords; this way they are only held in memory (and swap files, probably). That may be a way out of the situation; as a mail client is inherently an interactive program, there's no harm in prompting for things missing from the config, I think. -jim From jim@gonzul.net Fri Aug 28 05:28:28 2009 From: jim@gonzul.net (Jim Cheetham) Date: Fri, 28 Aug 2009 21:28:28 +1200 Subject: [sup-talk] Encrypted password in configuration file In-Reply-To: <20090828082349.61bfc91b@ronin.larsko.net> References: <20090824215435.182e0007@ronin.larsko.net> <20090828082349.61bfc91b@ronin.larsko.net> Message-ID: On Fri, Aug 28, 2009 at 7:23 PM, Lars Kotthoff wrote: >> It's possible, but slightly pointless. > > Not if the user supplies the passphrase, e.g. it could be encrypted with the > user's GPG key and ask for the passphrase at startup. Why not just ask for the IMAP password itself? There's no functional difference between that secret, and the secret that unlocks the secret ... indeed, if sup were to accidentally expose the passphrase you provided, would you rather lose your GPG key or your IMAP key? If you are really determined to allow others to read your private files, why not just encrypt the whole .sup directory with a separate tool (TrueCrypt, loopback, rot13, encfs, ecryptfs, or whatever else your distribution provides). That way, you are also protecting the ferret index collection, and the default sent box, which all contain data of the same level of sensitivity as your mailbox. Given your concern, I assume that you will be remembering to terminate sup and dismount the .sup directory every time you walk away from the keyboard. (Many schemes these days encrypt the whole of $HOME, which makes the whole screensaver/away from the keyboard thing even more difficult). Security must be appropriate to be actual security. Otherwise it's just an expensive fa?ade. -jim From stan@stanheckman.com Wed Aug 26 15:59:46 2009 From: stan@stanheckman.com (Stan Heckman) Date: Wed, 26 Aug 2009 19:59:46 +0000 Subject: [sup-talk] an error occurred in Sup Message-ID: <1251316321-sup-8091@clover.schedar.com> While setting up sup I received the error below. I attach the exception-log requested. I had told sup-config about my existing maildirs. This produced a large inbox. I attempted to archive all but 15 recent messages from this inbox by loading all messages with "!!" and archiving them all by holding down the "a" key for several seconds. After several minutes of archiving, I received the error below. [Wed Aug 26 19:38:08 +0000 2009] stopped cursing [Wed Aug 26 19:38:08 +0000 2009] oh crap, an exception [Wed Aug 26 19:38:08 +0000 2009] unlocking /home/stan/.sup/lock... ---------------------------------------------------------------- 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 address this problem. Thank you! Sincerely, William ---------------------------------------------------------------- --- NoMethodError from thread: periodic poll undefined method `+' for nil:NilClass /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/maildir.rb:141:in `end_offset' /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/source.rb:87:in `done?' /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:552:in `send' /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:552:in `__pass' /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:539:in `method_missing' /usr/lib/ruby/1.8/sup/poll.rb:89: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' /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send' /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/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/poll.rb:70:in `start' /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup.rb:71:in `reporting_thread' /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `initialize' /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `new' /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `reporting_thread' /usr/lib/ruby/1.8/sup/poll.rb:67:in `start' /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send' /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing' /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/bin/sup:213 /home/stan/.gem/ruby/1.8/bin/sup:19:in `load' /home/stan/.gem/ruby/1.8/bin/sup:19 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: exception-log.txt URL: From lars@larsko.org Fri Aug 28 03:23:49 2009 From: lars@larsko.org (Lars Kotthoff) Date: Fri, 28 Aug 2009 08:23:49 +0100 Subject: [sup-talk] Encrypted password in configuration file In-Reply-To: References: <20090824215435.182e0007@ronin.larsko.net> Message-ID: <20090828082349.61bfc91b@ronin.larsko.net> > It's possible, but slightly pointless. Not if the user supplies the passphrase, e.g. it could be encrypted with the user's GPG key and ask for the passphrase at startup. Lars From wmorgan-sup@masanjin.net Fri Aug 28 16:29:03 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 28 Aug 2009 13:29:03 -0700 Subject: [sup-talk] Encrypted password in configuration file In-Reply-To: <20090824215435.182e0007@ronin.larsko.net> References: <20090824215435.182e0007@ronin.larsko.net> Message-ID: <1251491240-sup-1148@masanjin.net> Reformatted excerpts from Lars Kotthoff's message of 2009-08-24: > is it possible to store the account password encrypted in the > configuration file? Despite generally agreeing with Jim's argument, I'm happy to accept a patch to do this. -- William From wmorgan-sup@masanjin.net Fri Aug 28 16:31:26 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 28 Aug 2009 13:31:26 -0700 Subject: [sup-talk] sent and draft sources In-Reply-To: References: <1251402318-sup-4655@ntdws12.chass.utoronto.ca> Message-ID: <1251491386-sup-7354@masanjin.net> Reformatted excerpts from Joe Shaw's message of 2009-08-27: > How safe is building and running from git master? Pretty safe. I merge all changes into next first, which is where people see breakage, and only merge them into master when they've baked long enough. > Is there a general philosophy about its stability? "Stability is good". :) -- William From wmorgan-sup@masanjin.net Fri Aug 28 16:35:06 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 28 Aug 2009 13:35:06 -0700 Subject: [sup-talk] sent and draft sources In-Reply-To: <20090827200053.GA17416@chistera.yi.org> References: <1251402318-sup-4655@ntdws12.chass.utoronto.ca> <20090827200053.GA17416@chistera.yi.org> Message-ID: <1251491567-sup-2126@masanjin.net> Reformatted excerpts from Adeodato Sim?'s message of 2009-08-27: > Why? Would sup not lock the mbox properly? Sup doesn't lock the sent mbox currently. It wouldn't be too hard to add. I'm still waiting for Ben to provide a nice refactoring patch for me. :) -- William From wmorgan-sup@masanjin.net Fri Aug 28 16:37:12 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 28 Aug 2009 13:37:12 -0700 Subject: [sup-talk] Nobody told me In-Reply-To: <1e5fdab70908270518k3f349191jb5e780e0e0555461@mail.gmail.com> References: <1e5fdab70908270518k3f349191jb5e780e0e0555461@mail.gmail.com> Message-ID: <1251491725-sup-284@masanjin.net> Reformatted excerpts from Guillaume Quintard's message of 2009-08-27: > Playing the dumb newbie here, but when did that happened? If anyone else has this problem (and anyone who's running next with the Xapian index will): after the dump and before sup-sync, I believe you need to remove your ~/.sup/xapian directory and ~/.sup/*.db. Life on the bleeding edge! > ./lib/sup/xapian_index.rb:32:in `load_index': This Sup version expects > a v1 index, but you have an existing v0 index. Please downgrade to > your previous version and dump your labels before upgrading to this > version (then run sup-sync --restore). (RuntimeError) > from ./lib/sup/index.rb:67:in `load' > from bin/sup-sync:117 > -- William From wmorgan-sup@masanjin.net Fri Aug 28 16:38:59 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 28 Aug 2009 13:38:59 -0700 Subject: [sup-talk] an error occurred in Sup In-Reply-To: <1251316321-sup-8091@clover.schedar.com> References: <1251316321-sup-8091@clover.schedar.com> Message-ID: <1251491856-sup-4902@masanjin.net> Reformatted excerpts from Stan Heckman's message of 2009-08-26: > I had told sup-config about my existing maildirs. This produced a > large inbox. I attempted to archive all but 15 recent messages from > this inbox by loading all messages with "!!" and archiving them all by > holding down the "a" key for several seconds. Definitely the slow an painful way to do this, and also the way to trigger one of the display threading heisenbugs. I recommend instead using sup-tweak-labels, or starting over and using --archive when you sup-add the source (and then just adding the inbox label back to the first 15). -- William From wmorgan-sup@masanjin.net Fri Aug 28 16:41:41 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 28 Aug 2009 13:41:41 -0700 Subject: [sup-talk] sup crashed: NoMethodError In-Reply-To: <20090827200317.GA3065@gmail.com> References: <20090827200317.GA3065@gmail.com> Message-ID: <1251492008-sup-6128@masanjin.net> Reformatted excerpts from Sean Escriva's message of 2009-08-27: > so far I have tried a gem cleanup, gem uninstall sup, gem install -r > sup, all to no avail. It still always crashes with the following: > > --- NoMethodError from thread: main > undefined method `[]' for false:FalseClass > /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:107:in `start' > /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:161 > /usr/bin/sup:19:in `load' > /usr/bin/sup:19 > > Any tips on how to fix/figure out what I did wrong are greatly > appreciated! Hm, is your ~/.sup/config.yaml file empty for some reason? If so, delete it and retry, and I will add some code to catch this case. -- William From guillaume.quintard@gmail.com Fri Aug 28 17:01:04 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Fri, 28 Aug 2009 23:01:04 +0200 Subject: [sup-talk] Nobody told me In-Reply-To: <1251491725-sup-284@masanjin.net> References: <1e5fdab70908270518k3f349191jb5e780e0e0555461@mail.gmail.com> <1251491725-sup-284@masanjin.net> Message-ID: <1e5fdab70908281401k7f0b59ectb38ce7dfe7280569@mail.gmail.com> On Fri, Aug 28, 2009 at 10:37 PM, William Morgan wrote: arg, when I try to restore, I get this: ./lib/sup/crypto.rb:157:in ``': Cannot allocate memory - /usr/bin/gpg --quiet --batch --no-verbose --logger-fd 1 --use-agent --verify /tmp/31666-0-redwood.signature /tmp/31666-0-redwood.payload 2> /dev/null (Errno::ENOMEM) from ./lib/sup/crypto.rb:157:in `run_gpg' from ./lib/sup/crypto.rb:92:in `verify' from ./lib/sup/util.rb:520:in `send' from ./lib/sup/util.rb:520:in `method_missing' from ./lib/sup/message.rb:385:in `multipart_signed_to_chunks' from ./lib/sup/message.rb:421:in `message_to_chunks' from ./lib/sup/message.rb:236:in `load_from_source!' from ./lib/sup/message.rb:332:in `build_from_source' from ./lib/sup/poll.rb:153:in `each_message_from' from ./lib/sup/source.rb:104:in `each' from ./lib/sup/util.rb:560:in `send' from ./lib/sup/util.rb:560:in `__pass' from ./lib/sup/util.rb:547:in `method_missing' from ./lib/sup/poll.rb:147:in `each_message_from' from ./lib/sup/util.rb:520:in `send' from ./lib/sup/util.rb:520:in `method_missing' from bin/sup-sync:146 from bin/sup-sync:141:in `each' from bin/sup-sync:141 is it leaking, or is my huge mbox just too big for it? cheers -- Guillaume From sean.escriva@gmail.com Fri Aug 28 18:50:41 2009 From: sean.escriva@gmail.com (Sean Escriva) Date: Fri, 28 Aug 2009 15:50:41 -0700 Subject: [sup-talk] sup crashed: NoMethodError In-Reply-To: <1251492008-sup-6128@masanjin.net> References: <20090827200317.GA3065@gmail.com> <1251492008-sup-6128@masanjin.net> Message-ID: <20090828225041.GA22963@gmail.com> On Fri, Aug 28, 2009 at 01:41:41PM -0700, William Morgan wrote: > Reformatted excerpts from Sean Escriva's message of 2009-08-27: > > so far I have tried a gem cleanup, gem uninstall sup, gem install -r > > sup, all to no avail. It still always crashes with the following: > > > > --- NoMethodError from thread: main > > undefined method `[]' for false:FalseClass > > /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:107:in `start' > > /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:161 > > /usr/bin/sup:19:in `load' > > /usr/bin/sup:19 > > > > Any tips on how to fix/figure out what I did wrong are greatly > > appreciated! > > Hm, is your ~/.sup/config.yaml file empty for some reason? If so, delete > it and retry, and I will add some code to catch this case. That may have been it. I just clobbered my whole setup and started over, now it's working Although now I'm using the gem and not the git next branch. I don't want to loose my 8K+ message index again. was my install process wrong for switching to the git -next branch? -sme ps: i'll consider switching fully to sup as soon as I figure out how to manage multiple email accounts :) From pioto@pioto.org Fri Aug 28 18:48:59 2009 From: pioto@pioto.org (Mike Kelly) Date: Fri, 28 Aug 2009 18:48:59 -0400 Subject: [sup-talk] Encrypted password in configuration file In-Reply-To: <20090824215435.182e0007@ronin.larsko.net> References: <20090824215435.182e0007@ronin.larsko.net> Message-ID: <20090828184859.59b7f825@aether.home.pioto.org> On Mon, 24 Aug 2009 21:54:35 +0100 Lars Kotthoff wrote: > is it possible to store the account password encrypted in the > configuration file? Along the lines of what Jim said, doing any sort of two-way encryption on the password is a wasted effort. There are other sort of authentication mechanisms which are probably more appropriate (certificate-based, Kerberos/GSSAPI, ...). -- Mike Kelly From nicolas.pouillard@gmail.com Sat Aug 29 05:18:52 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Sat, 29 Aug 2009 11:18:52 +0200 Subject: [sup-talk] Crash while syncing Message-ID: Hello, While doing a from scratch sup-sync to benefit for the new version of the xapian index, sup-sync crashed like this: /usr/lib/ruby/site_ruby/1.8/xapian.rb:240:in `doclength': DocNotFoundError: Document 3318104838 not found (RuntimeError) from /usr/lib/ruby/site_ruby/1.8/xapian.rb:240:in `postlist' from /usr/lib/ruby/site_ruby/1.8/xapian.rb:60:in `_safelyIterate' from /usr/lib/ruby/site_ruby/1.8/xapian.rb:238:in `postlist' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:365:in `term_docids' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:369:in `find_docid' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:373:in `find_doc' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:469:in `index_message' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:469:in `map' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:469:in `index_message' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:118:in `sync_message' from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:392:in `synchronize' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:117:in `sync_message' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:87:in `add_message' from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:202 from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:152:in `each_message_from' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/source.rb:104:in `each' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `send' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:140:in `each_message_from' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:146 from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:141:in `each' from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:141 from /usr/bin/sup-sync:19:in `load' from /usr/bin/sup-sync:19 The last status message was: ## read 9996m (about 30%) @ 11.1m/s. 0:15:03 elapsed, about 0:35:00 remaining And it was processing a 500MB mbox. I would like to know what are my options from here? Best regards, -- Nicolas Pouillard aka Ertai From nicolas.pouillard@gmail.com Sat Aug 29 08:03:04 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Sat, 29 Aug 2009 14:03:04 +0200 Subject: [sup-talk] Crash while syncing In-Reply-To: References: Message-ID: On Sat, Aug 29, 2009 at 11:18 AM, Nicolas Pouillard wrote: > Hello, > > While doing a from scratch sup-sync to benefit for the new version of > the xapian index, sup-sync > crashed like this: > I've lauched sup-sync on another bunch of mboxes and got this crash at the end: Deleting missing messages from the index... /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:17:in `id': wrong id called on nil (RuntimeError) from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:237 from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:150:in `each_message' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in `each_id' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in `each' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in `each_id' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:149:in `each_message' from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:235 from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:233:in `each' from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:233 from /usr/bin/sup-sync:19:in `load' from /usr/bin/sup-sync:19 -- Nicolas Pouillard aka Ertai From rlane@club.cc.cmu.edu Sat Aug 29 12:25:33 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 29 Aug 2009 12:25:33 -0400 Subject: [sup-talk] Crash while syncing In-Reply-To: References: Message-ID: <1251563082-sup-3525@zyrg.net> Excerpts from Nicolas Pouillard's message of Sat Aug 29 08:03:04 -0400 2009: > On Sat, Aug 29, 2009 at 11:18 AM, Nicolas > Pouillard wrote: > > Hello, > > > > While doing a from scratch sup-sync to benefit for the new version of > > the xapian index, sup-sync > > crashed like this: > > > > I've lauched sup-sync on another bunch of mboxes and got this crash at the end: > > Deleting missing messages from the index... > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:17:in `id': wrong id > called on nil (RuntimeError) > from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:237 > from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:150:in > `each_message' > from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in > `each_id' > from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in > `each' > from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in > `each_id' > from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:149:in > `each_message' > from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:235 > from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:233:in `each' > from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:233 > from /usr/bin/sup-sync:19:in `load' > from /usr/bin/sup-sync:19 > Are you using the Flint or Chert Xapian backend? From nicolas.pouillard@gmail.com Sat Aug 29 12:45:29 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Sat, 29 Aug 2009 18:45:29 +0200 Subject: [sup-talk] Crash while syncing In-Reply-To: <1251563082-sup-3525@zyrg.net> References: <1251563082-sup-3525@zyrg.net> Message-ID: On Sat, Aug 29, 2009 at 6:25 PM, Rich Lane wrote: > Excerpts from Nicolas Pouillard's message of Sat Aug 29 08:03:04 -0400 2009: >> On Sat, Aug 29, 2009 at 11:18 AM, Nicolas Pouillard wrote: >> > Hello, >> > >> > While doing a from scratch sup-sync to benefit for the new version of >> > the xapian index, sup-sync >> > crashed like this: >> > [...] > Are you using the Flint or Chert Xapian backend? The Chert one. -- Nicolas Pouillard aka Ertai From rlane@club.cc.cmu.edu Sat Aug 29 12:59:59 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 29 Aug 2009 12:59:59 -0400 Subject: [sup-talk] Crash while syncing In-Reply-To: References: <1251563082-sup-3525@zyrg.net> Message-ID: <1251564961-sup-5855@zyrg.net> Excerpts from Nicolas Pouillard's message of Sat Aug 29 12:45:29 -0400 2009: > > Are you using the Flint or Chert Xapian backend? > > The Chert one. Could you try it with Flint? I've seen this (nondeterministic) bug when using Chert. From nicolas.pouillard@gmail.com Sat Aug 29 13:05:33 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Sat, 29 Aug 2009 19:05:33 +0200 Subject: [sup-talk] Crash while syncing In-Reply-To: <1251564961-sup-5855@zyrg.net> References: <1251563082-sup-3525@zyrg.net> <1251564961-sup-5855@zyrg.net> Message-ID: On Sat, Aug 29, 2009 at 6:59 PM, Rich Lane wrote: > Excerpts from Nicolas Pouillard's message of Sat Aug 29 12:45:29 -0400 2009: >> > Are you using the Flint or Chert Xapian backend? >> >> The Chert one. > > Could you try it with Flint? I've seen this (nondeterministic) bug when > using Chert. I was currently running it again with no problems so far. Are the nondeterministic bugs only during sync? Chert is supposed to faster? Thanks for your help, -- Nicolas Pouillard From bwalton@artsci.utoronto.ca Sat Aug 29 14:35:03 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sat, 29 Aug 2009 14:35:03 -0400 Subject: [sup-talk] exception while importing to xapian Message-ID: <1251570765-sup-4265@ntdws12.chass.utoronto.ca> I just tried again to switch to xapian and I got the following: $ SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore ~/.sup/dumpfile Loading state dump from /cquest/roger/staff0/systems/bwalton/.sup/dumpfile... Read 72360 entries from dump file. Scanning maildir:///u/bwalton/Maildir/... [Sat Aug 29 14:29:11 -0400 2009] hook: read 'before-add-message' from /cquest/roger/staff0/systems/bwalton/.sup/hooks/before-add-message.rb ./lib/sup/xapian_index.rb:365:in `find_docid': undefined method `tap' for []:Array (NoMethodError) from ./lib/sup/xapian_index.rb:369:in `find_doc' from ./lib/sup/xapian_index.rb:379:in `get_entry' from ./lib/sup/xapian_index.rb:68:in `build_message' from /usr/lib/ruby/1.8/monitor.rb:238:in `synchronize' from ./lib/sup/xapian_index.rb:388:in `synchronize' from ./lib/sup/xapian_index.rb:68:in `build_message' from bin/sup-sync:149 from ./lib/sup/poll.rb:160:in `each_message_from' ... 8 levels... from ./lib/sup/util.rb:520:in `method_missing' from bin/sup-sync:146 from bin/sup-sync:141:in `each' from bin/sup-sync:141 This happened with 806a067 (the current tip of next). Exception log attached. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sup-exception-log.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rlane@club.cc.cmu.edu Sat Aug 29 20:22:15 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 29 Aug 2009 20:22:15 -0400 Subject: [sup-talk] Crash while syncing In-Reply-To: References: <1251563082-sup-3525@zyrg.net> <1251564961-sup-5855@zyrg.net> Message-ID: <1251565999-sup-7892@zyrg.net> Excerpts from Nicolas Pouillard's message of Sat Aug 29 13:05:33 -0400 2009: > Are the nondeterministic bugs only during sync? I've only seen it during sup-sync, but I'd guess if you ran sup long enough you'd see it there too (after changing labels / polling). > Chert is supposed to faster? Yes, and more space efficient. From bburky@bburky.com Sun Aug 30 16:14:56 2009 From: bburky@bburky.com (Blake Burkhart) Date: Sun, 30 Aug 2009 15:14:56 -0500 Subject: [sup-talk] exception while importing to xapian In-Reply-To: <1251570765-sup-4265@ntdws12.chass.utoronto.ca> References: <1251570765-sup-4265@ntdws12.chass.utoronto.ca> Message-ID: <1251662840-sup-4363@Backspace.local> Excerpts from Ben Walton's message of Sat Aug 29 13:35:03 -0500 2009: > > I just tried again to switch to xapian and I got the following: > > $ SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore > ~/.sup/dumpfile > Loading state dump from /cquest/roger/staff0/systems/bwalton/.sup/dumpfile... > Read 72360 entries from dump file. > Scanning maildir:///u/bwalton/Maildir/... > [Sat Aug 29 14:29:11 -0400 2009] hook: read 'before-add-message' from > /cquest/roger/staff0/systems/bwalton/.sup/hooks/before-add-message.rb > ./lib/sup/xapian_index.rb:365:in `find_docid': undefined method `tap' > for []:Array (NoMethodError) > > [...] > I am getting this same error myself. I'm running Mac OS 10.5 with ruby 1.8.6. Are you also using ruby 1.8.6? I think the tap method is in ruby 1.8.7 and later. Actually a quick google shows it may even be ruby 1.9 only, or 1.9 and backported from there. Is it necessary to use this method? Is there an alternate way to do this? -- Blake Burkhart From bwalton@artsci.utoronto.ca Sun Aug 30 16:21:30 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sun, 30 Aug 2009 16:21:30 -0400 Subject: [sup-talk] exception while importing to xapian In-Reply-To: <1251662840-sup-4363@Backspace.local> References: <1251570765-sup-4265@ntdws12.chass.utoronto.ca> <1251662840-sup-4363@Backspace.local> Message-ID: <1251663644-sup-5538@ntdws12.chass.utoronto.ca> Excerpts from Blake Burkhart's message of Sun Aug 30 16:14:56 -0400 2009: > I am getting this same error myself. I'm running Mac OS 10.5 with ruby 1.8.6. > Are you also using ruby 1.8.6? I think the tap method is in ruby 1.8.7 and > later. Actually a quick google shows it may even be ruby 1.9 only, or 1.9 and > backported from there. Actually, I'm on 1.8.5 (the version shipped with rhel5). Sup may finally force me to update it though. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rlane@club.cc.cmu.edu Sun Aug 30 16:28:55 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 30 Aug 2009 13:28:55 -0700 Subject: [sup-talk] [PATCH] remove use of Object#tap Message-ID: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/xapian_index.rb | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index c260728..1395601 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -362,7 +362,9 @@ class XapianIndex < BaseIndex end def find_docid id - term_docids(mkterm(:msgid,id)).tap { |x| fail unless x.size <= 1 }.first + docids = term_docids(mkterm(:msgid,id)) + fail unless docids.size <= 1 + docids.first end def find_doc id -- 1.6.0.4 From bburky@bburky.com Sun Aug 30 16:45:48 2009 From: bburky@bburky.com (Blake Burkhart) Date: Sun, 30 Aug 2009 15:45:48 -0500 Subject: [sup-talk] [PATCH] remove use of Object#tap In-Reply-To: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu> References: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1251664798-sup-8169@Backspace.local> Excerpts from Rich Lane's message of Sun Aug 30 15:28:55 -0500 2009: > --- > lib/sup/xapian_index.rb | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb > index c260728..1395601 100644 > --- a/lib/sup/xapian_index.rb > +++ b/lib/sup/xapian_index.rb > @@ -362,7 +362,9 @@ class XapianIndex < BaseIndex > end > > def find_docid id > - term_docids(mkterm(:msgid,id)).tap { |x| fail unless x.size <= 1 }.first > + docids = term_docids(mkterm(:msgid,id)) > + fail unless docids.size <= 1 > + docids.first > end > > def find_doc id After applying this on next in hopes it lets me run sup on ruby 1.8.6, it doesn't work. It crashed with this log: $ SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore ~/dumpfile Loading state dump from /Users/blake/dumpfile... Read 6790 entries from dump file. Scanning maildir:/Users/blake/Mail/bburky/INBOX... [Sun Aug 30 15:38:57 -0500 2009] hook: read 'before-add-message' from /Users/blake/.sup/hooks/before-add-message.rb [Sun Aug 30 15:38:57 -0500 2009] hook[before-add-message]: Marking message 1234774373-sup-1128 at zo as suptalk, subject is 'Re: [sup-talk] (no subject)' ./lib/sup/label.rb:64:in `<<': expecting a symbol (ArgumentError) from ./lib/sup/util.rb:520:in `send' from ./lib/sup/util.rb:520:in `method_missing' from ./lib/sup/xapian_index.rb:114:in `sync_message' from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:189:in `each' from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:189:in `each_key' from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:189:in `each' from ./lib/sup/xapian_index.rb:114:in `sync_message' from ./lib/sup/xapian_index.rb:87:in `add_message' ... 10 levels... from ./lib/sup/util.rb:520:in `method_missing' from bin/sup-sync:146 from bin/sup-sync:141:in `each' from bin/sup-sync:141 However, I'm having other odd problems too with labels anyway. On the ferret version of sup, I'm not able to apply labels with the 'l' command. However, I have a hook for applying a label from the List-ID that does still work. So this patch may or may not work, I think I'm possibly having problems of my own. Actually, I haven't tried to restore from a dumpfile for ferret. I'll do that later and see if it works. -- Blake Burkhart From rlane@club.cc.cmu.edu Sun Aug 30 16:47:59 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 30 Aug 2009 16:47:59 -0400 Subject: [sup-talk] exception while importing to xapian In-Reply-To: <1251662840-sup-4363@Backspace.local> References: <1251570765-sup-4265@ntdws12.chass.utoronto.ca> <1251662840-sup-4363@Backspace.local> Message-ID: <1251664201-sup-9803@zyrg.net> Excerpts from Blake Burkhart's message of Sun Aug 30 16:14:56 -0400 2009: > I am getting this same error myself. I'm running Mac OS 10.5 with ruby 1.8.6. > Are you also using ruby 1.8.6? I think the tap method is in ruby 1.8.7 and > later. Actually a quick google shows it may even be ruby 1.9 only, or 1.9 and > backported from there. > > Is it necessary to use this method? Is there an alternate way to do this? Yeah, this was just a 1.8.7-ism. I've sent a patch to fix it. From bburky@bburky.com Sun Aug 30 17:50:09 2009 From: bburky@bburky.com (Blake Burkhart) Date: Sun, 30 Aug 2009 16:50:09 -0500 Subject: [sup-talk] [PATCH] remove use of Object#tap In-Reply-To: <1251664798-sup-8169@Backspace.local> References: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu> <1251664798-sup-8169@Backspace.local> Message-ID: <1251668806-sup-7253@Backspace.local> Excerpts from Blake Burkhart's message of Sun Aug 30 15:45:48 -0500 2009: > After applying this on next in hopes it lets me run sup on ruby 1.8.6, it > doesn't work. > > It crashed with this log: > $ SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore > ~/dumpfile > Loading state dump from /Users/blake/dumpfile... > Read 6790 entries from dump file. > Scanning maildir:/Users/blake/Mail/bburky/INBOX... > [Sun Aug 30 15:38:57 -0500 2009] hook: read 'before-add-message' from > /Users/blake/.sup/hooks/before-add-message.rb > [Sun Aug 30 15:38:57 -0500 2009] hook[before-add-message]: Marking message > 1234774373-sup-1128 at zo as suptalk, subject is 'Re: [sup-talk] (no subject)' > ./lib/sup/label.rb:64:in `<<': expecting a symbol (ArgumentError) > from ./lib/sup/util.rb:520:in `send' > from ./lib/sup/util.rb:520:in `method_missing' > from ./lib/sup/xapian_index.rb:114:in `sync_message' > from > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:1 > 89:in `each' > from > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:1 > 89:in `each_key' > from > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:1 > 89:in `each' > from ./lib/sup/xapian_index.rb:114:in `sync_message' > from ./lib/sup/xapian_index.rb:87:in `add_message' > ... 10 levels... > from ./lib/sup/util.rb:520:in `method_missing' > from bin/sup-sync:146 > from bin/sup-sync:141:in `each' > from bin/sup-sync:141 > > However, I'm having other odd problems too with labels anyway. On the ferret > version of sup, I'm not able to apply labels with the 'l' command. However, I > have a hook for applying a label from the List-ID that does still work. So > this patch may or may not work, I think I'm possibly having problems of my > own. I got it to work. Mostly a least. What does a sup-dump file actually store? I lost all read/unread statuses and all labels (including the spam label thing, I assume it's just a normal label). To get it to work, I removed my before-add-message hook. It has worked for a long time, through different versions of sup, etc. However, It doesn't seem to be working with xapian. I don't actually know where this code came from, possibly this list, or maybe else where. I may have even modified it, I don't really remember. The hook is this: listIdMatch = message.raw_header.match(/List-Id:.*?<(.*?)>\s*$/i) if(listIdMatch) listIdLabel = listIdMatch[1].split(/\./).first.sub(/[^0-9A-Za-z]/, "") message.add_label listIdLabel log "Marking message #{message.id} as #{listIdLabel}, subject is '#{message.subj}'" end > Actually, I haven't tried to restore from a dumpfile for ferret. I'll do that > later and see if it works. I did try a restore from dumpfile with ferret. It worked except it didn't remember the labels the same way xapian didn't. However, the hook did work, and created labels on all mailing list messages. I think this isn't a xapian problem, because ferret is acting the same. If I want to recreate the sup files from scratch, what do I need to have? My config.yaml, sources.yaml, sent.mbox and a dumpfile? Is that all? From bwalton@artsci.utoronto.ca Sun Aug 30 19:55:56 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sun, 30 Aug 2009 19:55:56 -0400 Subject: [sup-talk] [PATCH] remove use of Object#tap In-Reply-To: <1251668806-sup-7253@Backspace.local> References: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu> <1251664798-sup-8169@Backspace.local> <1251668806-sup-7253@Backspace.local> Message-ID: <1251676342-sup-7038@ntdws12.chass.utoronto.ca> Excerpts from Blake Burkhart's message of Sun Aug 30 17:50:09 -0400 2009: > I got it to work. Mostly a least. What does a sup-dump file actually store? I > lost all read/unread statuses and all labels (including the spam label thing, > I assume it's just a normal label). I also lost labels on my first attempt at switching to xapian. I gave up for a few days as there were other issues with labels at the time. Losing labels during the switch would be a deal breaker, but I assume this isn't intended (as that would be madness, madness, I say)...is there a step I'm missing in the following (assuming HEAD of next)? 4. cp ~/.sup/sources.yaml{,.bak} 5. ruby -Ilib bin/sup-dump > dumpfile 6. SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore dumpfile 7. SUP_INDEX=xapian ruby -Ilib bin/sup -o Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rlane@club.cc.cmu.edu Sun Aug 30 20:50:34 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 30 Aug 2009 17:50:34 -0700 Subject: [sup-talk] [PATCH] sup-sync: restore state on messages that dont already exist Message-ID: <1251679834-5313-1-git-send-email-rlane@club.cc.cmu.edu> --- bin/sup-sync | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/bin/sup-sync b/bin/sup-sync index 2aa00c3..003a72d 100755 --- a/bin/sup-sync +++ b/bin/sup-sync @@ -174,7 +174,12 @@ begin ## decide what to do based on message labels and the operation we're performing dothis, new_labels = case when (op == :restore) && restored_state[m.id] && old_m && (old_m.labels != restored_state[m.id]) + num_restored += 1 [:update_message_state, restored_state[m.id]] + when (op == :restore) && restored_state[m.id] && !old_m + num_restored += 1 + m.labels = restored_state[m.id] + :add_message when op == :discard if old_m && (old_m.labels != m.labels) [:update_message_state, m.labels] -- 1.6.4 From rlane@club.cc.cmu.edu Sun Aug 30 20:50:46 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 30 Aug 2009 20:50:46 -0400 Subject: [sup-talk] [PATCH] remove use of Object#tap In-Reply-To: <1251676342-sup-7038@ntdws12.chass.utoronto.ca> References: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu> <1251664798-sup-8169@Backspace.local> <1251668806-sup-7253@Backspace.local> <1251676342-sup-7038@ntdws12.chass.utoronto.ca> Message-ID: <1251677009-sup-2661@zyrg.net> Excerpts from Ben Walton's message of Sun Aug 30 19:55:56 -0400 2009: > Excerpts from Blake Burkhart's message of Sun Aug 30 17:50:09 -0400 2009: > > > I got it to work. Mostly a least. What does a sup-dump file actually store? I > > lost all read/unread statuses and all labels (including the spam label thing, > > I assume it's just a normal label). > > I also lost labels on my first attempt at switching to xapian. I gave > up for a few days as there were other issues with labels at the time. > Losing labels during the switch would be a deal breaker, but I assume > this isn't intended (as that would be madness, madness, I say)...is > there a step I'm missing in the following (assuming HEAD of next)? > > 4. cp ~/.sup/sources.yaml{,.bak} > 5. ruby -Ilib bin/sup-dump > dumpfile > 6. SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources > --restore dumpfile > 7. SUP_INDEX=xapian ruby -Ilib bin/sup -o > > Thanks > -Ben > This is an issue that was introduced in 906ab35e. I've just resent a patch for it. -------------- next part -------------- A non-text attachment was scrubbed... Name: restore-state-fix Type: application/octet-stream Size: 3534 bytes Desc: not available URL: From bburky@bburky.com Sun Aug 30 21:48:50 2009 From: bburky@bburky.com (Blake Burkhart) Date: Sun, 30 Aug 2009 20:48:50 -0500 Subject: [sup-talk] [PATCH] sup-sync: restore state on messages that dont already exist In-Reply-To: <1251679834-5313-1-git-send-email-rlane@club.cc.cmu.edu> References: <1251679834-5313-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1251683226-sup-7685@Backspace.local> Excerpts from Rich Lane's message of Sun Aug 30 19:50:34 -0500 2009: > --- > bin/sup-sync | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/bin/sup-sync b/bin/sup-sync > index 2aa00c3..003a72d 100755 > --- a/bin/sup-sync > +++ b/bin/sup-sync > @@ -174,7 +174,12 @@ begin > ## decide what to do based on message labels and the operation we're > performing > dothis, new_labels = case > when (op == :restore) && restored_state[m.id] && old_m && (old_m.labels > != restored_state[m.id]) > + num_restored += 1 > [:update_message_state, restored_state[m.id]] > + when (op == :restore) && restored_state[m.id] && !old_m > + num_restored += 1 > + m.labels = restored_state[m.id] > + :add_message > when op == :discard > if old_m && (old_m.labels != m.labels) > [:update_message_state, m.labels] Yay, thank you. Everything works now I think. I now have xapian working correctly I think. From rlane@club.cc.cmu.edu Mon Aug 31 00:16:03 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Mon, 31 Aug 2009 00:16:03 -0400 Subject: [sup-talk] [PATCH] index log In-Reply-To: <1251116226-sup-1373@peray> References: <1250491123-19240-1-git-send-email-rlane@club.cc.cmu.edu> <1250948551-sup-2052@masanjin.net> <1251116226-sup-1373@peray> Message-ID: <1251691269-sup-246@zyrg.net> Excerpts from Nicolas Pouillard's message of Mon Aug 24 08:20:20 -0400 2009: > Excerpts from William Morgan's message of Sat Aug 22 15:46:27 +0200 2009: > > Reformatted excerpts from Rich Lane's message of 2009-08-16: > > > Add a YAML logfile that records changes to the index and modify > > > sup-dump to use this rather than the normal database. > > > > I like this. I'm going to wait to apply it until the api refactoring > > stuff is merged down to master though. Should be soon. > > I'm wondering if a simpler format would not be better, I've patch > in my sup copy do feed a file called ~/.sup/labels-mapping.log with > lines like those: > > 000e0cd20f80143822047118693d at google.com (unread inbox -> ) > 20090813213654.GA30223 at community.haskell.org (unread inbox patch -> patch) > 1250148617-sup-6053 at oz.taruti.net (unread inbox sup -> sup) > 1250281208-sup-4199 at masanjin.net (unread inbox sup -> sup) > > Their are in the style of sup-dump output and there are pretty easy to manage > by any tools. > > Not to say that I don't like YAML, I am a pretty big fan of it; but here it > seems overkill. > > Best regards, > I agree that YAML is overkill for what we're currently storing in the log. The intention was to make this as foolproof for future expansion as possible, but after some time thinking about it I haven't come up with more fields to add (not that there still couldn't be, but I think it's unlikely). I'll submit a simpler patch. What do people think about replacing the current undo system with one based on the label log? This would only be possible once we have immediate label changes. I think it would simplify a lot of code. From bwalton@artsci.utoronto.ca Mon Aug 31 07:42:21 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 31 Aug 2009 07:42:21 -0400 Subject: [sup-talk] [PATCH] index log In-Reply-To: <1251691269-sup-246@zyrg.net> References: <1250491123-19240-1-git-send-email-rlane@club.cc.cmu.edu> <1250948551-sup-2052@masanjin.net> <1251116226-sup-1373@peray> <1251691269-sup-246@zyrg.net> Message-ID: <1251718898-sup-2772@ntdws12.chass.utoronto.ca> Excerpts from Rich Lane's message of Mon Aug 31 00:16:03 -0400 2009: > What do people think about replacing the current undo system with one > based on the label log? This would only be possible once we have > immediate label changes. I think it would simplify a lot of code. +1 for this. I find that more often than not, undo doesn't work as expected anyway. It's been suggested that this is a threading bug, which is quite likely... -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Mon Aug 31 22:41:06 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 31 Aug 2009 19:41:06 -0700 Subject: [sup-talk] [PATCH] sup-sync: restore state on messages that dont already exist In-Reply-To: <1251052619-9915-1-git-send-email-rlane@club.cc.cmu.edu> References: <1251052619-9915-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1251772852-sup-5207@masanjin.net> Applied, thanks! -- William From wmorgan-sup@masanjin.net Mon Aug 31 22:51:20 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 31 Aug 2009 19:51:20 -0700 Subject: [sup-talk] [PATCH] reply all keybindings In-Reply-To: <1251053342-11859-1-git-send-email-rlane@club.cc.cmu.edu> References: <1251053342-11859-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1251773465-sup-3081@masanjin.net> Branch reply-all-keybindings, merged into next. Thanks! -- William From wmorgan-sup@masanjin.net Mon Aug 31 22:57:54 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 31 Aug 2009 19:57:54 -0700 Subject: [sup-talk] [PATCH] Add UTF-8 encoding string for ArchLinux systems In-Reply-To: <1251192382-sup-2350@elly> References: <1251192382-sup-2350@elly> Message-ID: <1251773862-sup-2194@masanjin.net> Reformatted excerpts from Israel Herraiz's message of 2009-08-25: > in ArchLinux, UTF-8 encoding is identified by "utf8" instead of > "UTF-8". Applied to master. Thanks! -- William From wmorgan-sup@masanjin.net Mon Aug 31 22:58:47 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 31 Aug 2009 19:58:47 -0700 Subject: [sup-talk] [PATCH] Identify list messages by list-id if list-post is not present In-Reply-To: <1251192579-sup-1849@elly> References: <1251192579-sup-1849@elly> Message-ID: <1251773879-sup-5227@masanjin.net> Reformatted excerpts from Israel Herraiz's message of 2009-08-25: > I am subscribed to some lists that do not fill the list-post header, > but have a list-id header. I am not sure how standard-compliant is > that, but it would nice if Sup could identify those messages as list > messages. Does this patch work for you? diff --git a/lib/sup/message.rb b/lib/sup/message.rb index ed27d3d..472b9dc 100644 --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -114,12 +114,11 @@ class Message @replytos = (header["in-reply-to"] || "").scan(/<(.+?)>/).map { |x| sanitize_me @replyto = Person.from_address header["reply-to"] - @list_address = - if header["list-post"] - @list_address = Person.from_address header["list-post"].gsub(/^$/ - else - nil - end + @list_address = if header["list-post"] + Person.from_address header["list-post"].gsub(/^$/, "") + elsif header["list-id"] + Person.from_address header["list-id"].gsub(/^<:|>$/, "") + end @recipient_email = header["envelope-to"] || header["x-original-to"] || header[" @source_marked_read = header["status"] == "RO" -- William From wmorgan-sup@masanjin.net Mon Aug 31 23:06:05 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 31 Aug 2009 20:06:05 -0700 Subject: [sup-talk] [PATCH] Make SUP_LOG_LEVEL self-documenting. In-Reply-To: <1251322427-sup-9184@yoom.home.cworth.org> References: <1250745799-sup-6607@yoom.home.cworth.org> <1250972634-sup-6871@masanjin.net> <1251322427-sup-9184@yoom.home.cworth.org> Message-ID: <1251774349-sup-4067@masanjin.net> Applied, thanks! -- William From wmorgan-sup@masanjin.net Mon Aug 31 23:17:36 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 31 Aug 2009 20:17:36 -0700 Subject: [sup-talk] [PATCH] remove use of Object#tap In-Reply-To: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu> References: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1251774958-sup-5853@masanjin.net> Applied. Sup does define a #returning function which is equivalent to #tap, FWIW. -- William