From wmorgan-sup@masanjin.net Sun Nov 1 09:39:25 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 01 Nov 2009 06:39:25 -0800 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1256987483-sup-338@tilus.net> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net> Message-ID: <1257086191-sup-1136@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2009-10-31: > How about setting up a loose team which would handle the incoming bug > reports (for you), track/sort all of them and fix what they feel like > fixing and maybe upon request/occasionally report somewhere the > current status (how many minors and majors open). As far as I'm concerned, that would be great. I'm open to suggestions about how to organize this. At this point I'm pretty convinced I will never actually like a bug tracker, and I don't have the energy to write another one, so for someone else to take the initiative would be awesome. -- William From wmorgan-sup@masanjin.net Sun Nov 1 09:45:05 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 01 Nov 2009 06:45:05 -0800 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1256940689-sup-888@arrakis.es.net> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> <1256940689-sup-888@arrakis.es.net> Message-ID: <1257086690-sup-9036@masanjin.net> [resend to list] Reformatted excerpts from Jon Dugan's message of 2009-10-30: > I've attached a patch that just make the BASE_DIR tweak. I'll leave > changing the instructions to you... Applied to master. (Had to tweak it to make the path actually correct, but no worries.) Thanks! -- William From wmorgan-sup@masanjin.net Sun Nov 1 09:53:31 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 01 Nov 2009 06:53:31 -0800 Subject: [sup-talk] Recovering a busted ferret db? In-Reply-To: References: <1256939095-sup-4201@masanjin.net> Message-ID: <1257087035-sup-2014@masanjin.net> Reformatted excerpts from Steven Walter's message of 2009-10-30: > I am able to Ctrl-C sup-dump when it hangs. Here's the ruby backtrace: > > /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:206:in `split': Interrupt > from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:206:in > `split_on_commas' It looks like you have some crazy long recipient email in some list that's triggering worst-case behavior in a regexp. Can you try again after applying this patch, please? (And I'd be curious how long the address list was, if you find out what message is triggering this.) diff --git a/lib/sup/person.rb b/lib/sup/person.rb index 4b1c80b..dbedc79 100644 --- a/lib/sup/person.rb +++ b/lib/sup/person.rb @@ -105,6 +105,10 @@ class Person def self.from_address_list ss return [] if ss.nil? + ## #split_on_commas has some bad behavior for long strings. so here we do + ## something nasty and just truncate the string at the nearest comma <= 500 + ## characters. + ss = ss[0, ss.rindex(",", 500)] if ss.length > 500 ss.split_on_commas.map { |s| self.from_address s } end -- William From nicolas.pouillard@gmail.com Sun Nov 1 10:24:22 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Sun, 01 Nov 2009 16:24:22 +0100 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1257086191-sup-1136@masanjin.net> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net> <1257086191-sup-1136@masanjin.net> Message-ID: <1257088992-sup-5165@peray> Excerpts from William Morgan's message of Sun Nov 01 15:39:25 +0100 2009: > Reformatted excerpts from Tero Tilus's message of 2009-10-31: > > How about setting up a loose team which would handle the incoming bug > > reports (for you), track/sort all of them and fix what they feel like > > fixing and maybe upon request/occasionally report somewhere the > > current status (how many minors and majors open). > > As far as I'm concerned, that would be great. I'm open to suggestions > about how to organize this. At this point I'm pretty convinced I will > never actually like a bug tracker, and I don't have the energy to write > another one, so for someone else to take the initiative would be > awesome. Have strong points against Ditz or this is also a lake of energy? -- Nicolas Pouillard http://nicolaspouillard.fr From wmorgan-sup@masanjin.net Sun Nov 1 11:19:23 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 01 Nov 2009 08:19:23 -0800 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1257088992-sup-5165@peray> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net> <1257086191-sup-1136@masanjin.net> <1257088992-sup-5165@peray> Message-ID: <1257091305-sup-4606@masanjin.net> Reformatted excerpts from Nicolas Pouillard's message of 2009-11-01: > Have strong points against Ditz or this is also a lake of energy? Both, really. Ditz was an experiment, and after using it for a while I decided it was more trouble than it was worth. I also realized that I *did* want a centralized web site after all, and not necessarily a complicated distributed thing, both because I want non-technical users to be able to submit bug reports, and because development, in reality, *is* centralized. (I had been doing some work on Sheila, which would've provided a web frontent that people could use to submit bug reports, but even that wouldn't be quite what I wanted.) Having thought about it for a while, I think what I *really* want for Sup is something that tracks bugs/feature requests at the feature branch level (i.e. assumes that each feature branch provides a new feature or a bugfix), has a web interface for non-technical users to submit bug reports and for developers to browse/modify state on bugs, and which uses email for discussion, like I did with Whisper. (And I would be fine with it being git-specific.) I am now spending all my energy trying to keep myself from building such a thing. -- William From wmorgan-sup@masanjin.net Sun Nov 1 11:23:03 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 01 Nov 2009 08:23:03 -0800 Subject: [sup-talk] Arch Linux Sup Package (Ruby 1.9.1 + Sup 0.9) In-Reply-To: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com> References: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com> Message-ID: <1257092475-sup-4321@masanjin.net> Reformatted excerpts from Andrei Thorp's message of 2009-10-18: > - I've applyed Lloyd's patch for fixing the UTF-8 check. Which patch was this? The only "Lloyd patch" one I'm aware of is: http://github.com/lloyd/sup/commit/d07986419b87053b41f7ed4bd7b6d1e537704864 which a) I don't quite understand, and b) isn't about utf8. -- William From wmorgan-sup@masanjin.net Sun Nov 1 11:32:35 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 01 Nov 2009 08:32:35 -0800 Subject: [sup-talk] Can't search without crashing In-Reply-To: <1256588053-sup-8922@sgoldmanlinux.tower-research.com> References: <1256588053-sup-8922@sgoldmanlinux.tower-research.com> Message-ID: <1257093136-sup-2762@masanjin.net> Reformatted excerpts from Steve Goldman's message of 2009-10-26: > Wow, I guess I haven't tried to search in a while... I can't search > for *anything* without it crashing hard. Every time. I'm on master. In ~/.sup/sources.yaml, do you have a source with "id: 4"? -- William From nicolas.pouillard@gmail.com Sun Nov 1 11:48:16 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Sun, 01 Nov 2009 17:48:16 +0100 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1257091305-sup-4606@masanjin.net> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net> <1257086191-sup-1136@masanjin.net> <1257088992-sup-5165@peray> <1257091305-sup-4606@masanjin.net> Message-ID: <1257093429-sup-8020@peray> Excerpts from William Morgan's message of Sun Nov 01 17:19:23 +0100 2009: > Reformatted excerpts from Nicolas Pouillard's message of 2009-11-01: > > Have strong points against Ditz or this is also a lake of energy? > > Both, really. Ditz was an experiment, and after using it for a while I > decided it was more trouble than it was worth. I also realized that I > *did* want a centralized web site after all, and not necessarily a > complicated distributed thing, both because I want non-technical users > to be able to submit bug reports, and because development, in reality, > *is* centralized. I think I see your point, however I think there is no less no more to centralize in a bugtracker than in a source code management tool. Indeed in most projects using a DVCS, they have a central repository, this does not reduce the benefits of distributed tools. Distributed bugtrackers does not necessary exclude having a central point. What I found cool about distributed bugtrackers is that the bug-closing action can follow the code that fixes the bug. Being in a branch, or being reviewed... About non-technical users, I think that just a mail (thread) on the mailing-list could suffice. Of course some web app can make things clearer. > (I had been doing some work on Sheila, which would've provided a web > frontent that people could use to submit bug reports, but even that > wouldn't be quite what I wanted.) > Having thought about it for a while, I think what I *really* want for > Sup is something that tracks bugs/feature requests at the feature branch > level (i.e. assumes that each feature branch provides a new feature or a > bugfix), has a web interface for non-technical users to submit bug > reports and for developers to browse/modify state on bugs, and which > uses email for discussion, like I did with Whisper. (And I would be fine > with it being git-specific.) Maybe Ditz is not very far from that. > I am now spending all my energy trying to keep myself from building such > a thing. Good luck on this :) -- Nicolas Pouillard http://nicolaspouillard.fr From sgoldman@tower-research.com Sun Nov 1 11:48:38 2009 From: sgoldman@tower-research.com (Steve Goldman) Date: Sun, 01 Nov 2009 11:48:38 -0500 Subject: [sup-talk] Can't search without crashing In-Reply-To: <1257093136-sup-2762@masanjin.net> References: <1256588053-sup-8922@sgoldmanlinux.tower-research.com> <1257093136-sup-2762@masanjin.net> Message-ID: <1257094049-sup-1250@sgoldmanlinux.tower-research.com> Excerpts from William Morgan's message of Sun Nov 01 11:32:35 -0500 2009: > Reformatted excerpts from Steve Goldman's message of 2009-10-26: > > Wow, I guess I haven't tried to search in a while... I can't search > > for *anything* without it crashing hard. Every time. I'm on master. > > In ~/.sup/sources.yaml, do you have a source with "id: 4"? No. Although a few weeks ago I cleared out a bunch of sources that I thought were defunct from that file. I'm replacing those sources (at least I backed up the sources.yaml file) and will see how that goes. And now I'm feeling stupid... -- Steve Goldman sgoldman at tower-research.com T: 212.219.6014 F: 212.219.6007 Tower Research Capital, LLC 377 Broadway, 11th Fl. New York, NY 10013 From sgoldman@tower-research.com Sun Nov 1 11:49:54 2009 From: sgoldman@tower-research.com (Steve Goldman) Date: Sun, 01 Nov 2009 11:49:54 -0500 Subject: [sup-talk] What happened to the log buffer? Message-ID: <1257094144-sup-8318@sgoldmanlinux.tower-research.com> I'm somewhere near the next branch. Formerly, when I started sup I could cycle through a few buffers with 'b', two of which were some sort of log buffers. These are gone now. Anyone know? Thanks. -- Steve Goldman sgoldman at tower-research.com T: 212.219.6014 F: 212.219.6007 Tower Research Capital, LLC 377 Broadway, 11th Fl. New York, NY 10013 From wmorgan-sup@masanjin.net Sun Nov 1 12:15:56 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 01 Nov 2009 09:15:56 -0800 Subject: [sup-talk] What happened to the log buffer? In-Reply-To: <1257094144-sup-8318@sgoldmanlinux.tower-research.com> References: <1257094144-sup-8318@sgoldmanlinux.tower-research.com> Message-ID: <1257095673-sup-5988@masanjin.net> Reformatted excerpts from Steve Goldman's message of 2009-11-01: > Formerly, when I started sup I could cycle through a few buffers with > 'b', two of which were some sort of log buffers. These are gone now. 'b' now skips over "system" buffers. If you hit ';' you will get the full list and you can select it that way. You may want to restart with the environment variable SUP_LOG_LEVEL=debug for all the verbiage you were used to. -- William From wmorgan-sup@masanjin.net Sun Nov 1 12:23:49 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 01 Nov 2009 09:23:49 -0800 Subject: [sup-talk] Can't search without crashing In-Reply-To: <1257094049-sup-1250@sgoldmanlinux.tower-research.com> References: <1256588053-sup-8922@sgoldmanlinux.tower-research.com> <1257093136-sup-2762@masanjin.net> <1257094049-sup-1250@sgoldmanlinux.tower-research.com> Message-ID: <1257095945-sup-1972@masanjin.net> Reformatted excerpts from Steve Goldman's message of 2009-11-01: > I'm replacing those sources (at least I backed up the sources.yaml > file) and will see how that goes. If you're really done with a source, you can remove it from sources.yaml, but you also need to remove all messages from the index. You should be able do something like: $ sh devel/console.sh >> q = Index.parse_query "source_id:4" => # ... >> Index.each_id(q) { |id| Index.delete id } => nil >> Index.save -- William From wmorgan-sup@masanjin.net Sun Nov 1 12:30:04 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 01 Nov 2009 09:30:04 -0800 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1257093429-sup-8020@peray> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net> <1257086191-sup-1136@masanjin.net> <1257088992-sup-5165@peray> <1257091305-sup-4606@masanjin.net> <1257093429-sup-8020@peray> Message-ID: <1257096395-sup-2011@masanjin.net> Reformatted excerpts from Nicolas Pouillard's message of 2009-11-01: > What I found cool about distributed bugtrackers is that the > bug-closing action can follow the code that fixes the bug. Being in a > branch, or being reviewed... > > About non-technical users, I think that just a mail (thread) on the > mailing-list could suffice. Of course some web app can make things > clearer. It's funny, the two things that I found irritating do were a) close the bug as part of the commit (because I kept forgetting, and also because I like reading commits with git log -p and the ditz stuff was additional noise), and b) translating a user's bug report email into an issue. :) -- William From nicolas.pouillard@gmail.com Sun Nov 1 12:49:11 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Sun, 01 Nov 2009 18:49:11 +0100 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1257096395-sup-2011@masanjin.net> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net> <1257086191-sup-1136@masanjin.net> <1257088992-sup-5165@peray> <1257091305-sup-4606@masanjin.net> <1257093429-sup-8020@peray> <1257096395-sup-2011@masanjin.net> Message-ID: <1257097118-sup-8031@peray> Excerpts from William Morgan's message of Sun Nov 01 18:30:04 +0100 2009: > Reformatted excerpts from Nicolas Pouillard's message of 2009-11-01: > > What I found cool about distributed bugtrackers is that the > > bug-closing action can follow the code that fixes the bug. Being in a > > branch, or being reviewed... > > > > About non-technical users, I think that just a mail (thread) on the > > mailing-list could suffice. Of course some web app can make things > > clearer. > > It's funny, the two things that I found irritating do were a) close the > bug as part of the commit (because I kept forgetting, and also because I > like reading commits with git log -p and the ditz stuff was additional > noise), and I think some habits are needed in each model... > b) translating a user's bug report email into an issue. :) Yes this translating job can really be boring. In fact I consider every bugtracker related task to be boring... And yes the nice part of web based bugtracker is to put this burden on the user. -- Nicolas Pouillard http://nicolaspouillard.fr From wmorgan-sup@masanjin.net Sun Nov 1 13:46:33 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 01 Nov 2009 10:46:33 -0800 Subject: [sup-talk] mbox date fail In-Reply-To: <2aeb4e149305569502f106c7e54ae107@localhost> References: <2aeb4e149305569502f106c7e54ae107@localhost> Message-ID: <1257101109-sup-4117@masanjin.net> Reformatted excerpts from Mike Kelly's message of 2009-10-23: > Is there much of anything that I can do to mitigate this problem, > aside from manually altering every offending message? I've fixed this in master. Can you try again, please? > It seems like the messages' Content-Length header should be used to > skip past the body and ignore the offending Froms? This is an option, but I'm avoiding it, because Content-Length is not guaranteed to be there, and not guaranteed to be correct. > Or, at least, if that sort of > ArgumentError is thrown, maybe it should be caught and handled better? Yep, that's what I've done. I couldn't get my local system to throw ArgumentError, even with your example, but if it's possible, it's possible, and should be caught. -- William From rick.tessner@gmail.com Sun Nov 1 15:30:21 2009 From: rick.tessner@gmail.com (rick.tessner) Date: Sun, 01 Nov 2009 12:30:21 -0800 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1257086191-sup-1136@masanjin.net> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net> <1257086191-sup-1136@masanjin.net> Message-ID: <1257107371-sup-3361@onnadayr.ca> Excerpts from William Morgan's message of Sun Nov 01 06:39:25 -0800 2009: > Reformatted excerpts from Tero Tilus's message of 2009-10-31: > > How about setting up a loose team which would handle the incoming bug > > reports (for you), track/sort all of them and fix what they feel like > > fixing and maybe upon request/occasionally report somewhere the > > current status (how many minors and majors open). > > As far as I'm concerned, that would be great. I'm open to suggestions > about how to organize this. At this point I'm pretty convinced I will > never actually like a bug tracker, and I don't have the energy to write > another one, so for someone else to take the initiative would be > awesome. Would a move to github be considered since they now have an issue tracker. It provides tagging of issues and voting. As an example, take a look at http://github.com/justinfrench/formtastic/ and clicky the Issues tab. (I chose this project simply because I was watching the railscast for it and noticed the Issues tab) -- Rick Tessner rick.tessner at gmail.com From nicolas.pouillard@gmail.com Sun Nov 1 16:52:08 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Sun, 01 Nov 2009 22:52:08 +0100 Subject: [sup-talk] Choosing a bug tracker for Sup Message-ID: <1257111816-sup-4397@peray> Hi, I would like to discuss more the issue of choosing a bug tracker for sup. (I've made a new thread for clarity) (This is a cross post of a post[1] on my blog) OK lets forget Ditz[2] as an option. Note also that I would make no objection to using a traditional bug tracker. It seems that we do not find a tool we really like. A simple question I asked me was: "Do we really need to invent this (big) tool?" And more and more the answer I see is that we do not need yet another big tool. Especially for a bug tracker we need recipes, protocols more than a nice interface. And generally I think we better need thinking on how to split the problem in small issues than writing the tool that tackles all of them in one go. Again the UNIX philosophy can help us to simplify all this mess! So we need a web interface for non technical users, great. What about a pre-formatted email explained on a single web-page for reporting bugs. This simple web-page will also have a form to fill which will send the email for them. This micro web app is really simple and does a very clear job. So we now have issues as emails. Thus the mailing-list is our bug tracker as before. However issues are now in a proper format. A bot will receive emails on the mailing-list and process those which are in the right format. I think that the bot will not have a lot of information to store: (correct me if you find something else) * Issue type, severity, priority, category, person assigned, progress status, incriminated version and platform, planned milestone/released. * Issue details, discussion, answers, attachments. All those of the first category can be easily handled in a very flexible way either with labels, or a simple mapping: Labels (like the Google bug tracker on code.google.com): Type-Defect Priority-Critical Component-UI Mapping: type: defect priority: critical component: UI This is very flexible because this set of labels/attributes is chosen by the project maintainer to match the complexity of the project. I would store and manage the first category using a simple YAML file. The bot acknowledges its updates by simply answering to the discussion. Those of the second category can be managed using a single email discussion. Since the discussion is central to the issue, tracking the original message-ID could be used as the unique identifier. About the issues identifier I see two options, either we try to allocate simple integers like most of the trackers or we just keep the unique (long) identifier. Then, optionally a simple set of HTML pages can be generated using the YAML file. About storage of the YAML file I would simply store it in the repository. If we make the bot accessible, we just have to periodically pull from it. I don't know yet how many issues I've forgotten, and if this design is really as simple and lightweight as I claim it to be. I look forward to your answers on that. Best regards, [1]: http://blog.nicolaspouillard.fr/entries/2009-11-01-bug-tracker-design-issues.html [2]: http://ditz.rubyforge.org/ -- Nicolas Pouillard http://nicolaspouillard.fr From wmorgan-sup@masanjin.net Sun Nov 1 17:57:44 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 01 Nov 2009 14:57:44 -0800 Subject: [sup-talk] A fix for the joining threads bug with Ferret In-Reply-To: <1256297205-sup-683@sam.mediasupervision.de> References: <1256297205-sup-683@sam.mediasupervision.de> Message-ID: <1257115167-sup-6013@masanjin.net> Reformatted excerpts from Gregor Hoffleit's message of 2009-10-23: > I managed to track down the problem until the following line in > FerretIndex#sync_message in lib/sup/ferret_index.rb. > > d = { ... :refs => (entry[:refs] || (m.refs + m.replytos).uniq.join(" ")) } Great catch. Thank you! > For me, it always evaluates to "entry[:refs]" (even if that's an empty > string!), losing the reference in the modified message m, which was > added by add_ref. Therefore the manual join is always lost. Yep, that's the problem. In general all those fields are ||= in order to save the work of computing them again when we're updating a message (because the way Ferret works is we have to rewrite the entire record every time we change the labels, so we want that to be as fast as possible). But for certain fields, including refs, we should regenerate them because that data can change. > Btw, the code in xapian_index.rb looks much different. Still, I'd like > to see this fixed for Xapian. I believe that the fix for both is simply to set the entry[:refs] every time, and not bother with ||=. (In fact I think the empty string check won't work for threads that already have refs set, i.e. joining threads of size >1.) I've put this fix on branch thread-joining-fix and merged into next. Check it out. -- William From pioto@pioto.org Sun Nov 1 18:30:07 2009 From: pioto@pioto.org (Mike Kelly) Date: Sun, 1 Nov 2009 18:30:07 -0500 Subject: [sup-talk] mbox date fail In-Reply-To: <1257101109-sup-4117@masanjin.net> References: <2aeb4e149305569502f106c7e54ae107@localhost> <1257101109-sup-4117@masanjin.net> Message-ID: <20091101183007.0b90de33@aether.home.pioto.org> On Sun, 01 Nov 2009 10:46:33 -0800 William Morgan wrote: > Yep, that's what I've done. I couldn't get my local system to throw > ArgumentError, even with your example, but if it's possible, it's > possible, and should be caught. Yep, that seems to help. Thanks! (I altered the example slightly for anonymity reasons, that might have invalidated it as a test case). -- Mike Kelly From rlane@club.cc.cmu.edu Sun Nov 1 18:42:38 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 01 Nov 2009 18:42:38 -0500 Subject: [sup-talk] updated xapian experimental branch Message-ID: <1257118189-sup-7392@zyrg.net> I've pushed a few more commits to http://github.com/rlane/sup/tree/experimental The major feature on this branch is the immediate label updates I've mentioned before on the list. The bulk of the actual changes are basically consequences of this feature: Use of Xapian for thread relevance checks - Instead of hardcoding the policy into InboxMode - New 'z' key to clear irrelevant threads - Not strictly necessary, but removing messages in response to index events is difficult with the current UI code - Saves us from (half of the) adding/removing threads changes cursor_thread problem - Relevant messages added to thread-index-modes without reload Async message state saving - Keeps the UI responsive - Prepares us for a sup-server future Fallout from async message saving - UpdateManager messages handled in main event loop - Avoids many races but can lag UI unless we're careful New, simpler undo implementation - Still needs work at a few use-sites to be completely correct Let me know what you all think of these changes. I'll need to do a lot of rebasing before this branch is clean enough to be merged. A couple of bugs I know about: - Discarding drafts is disabled - Occasionally, new messages in an existing undisplayed thread fail to get added to the ThreadSet. I haven't been able to come up with a test case for this, so if someone wants to give that a shot it would be very helpful. From kevinr@free-dissociation.com Sun Nov 1 20:17:31 2009 From: kevinr@free-dissociation.com (Kevin Riggle) Date: Sun, 01 Nov 2009 20:17:31 -0500 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257111816-sup-4397@peray> References: <1257111816-sup-4397@peray> Message-ID: <1257124377-sup-199@black-opal.mit.edu> Excerpts from Nicolas Pouillard's message of Sun Nov 01 16:52:08 -0500 2009: (snip) (snip) > > I would store and manage the first category using a simple YAML file. > > The bot acknowledges its updates by simply answering to the discussion. > > Those of the second category can be managed using a single email discussion. > > Since the discussion is central to the issue, tracking the original message-ID > could be used as the unique identifier. > > About the issues identifier I see two options, either we try to allocate > simple integers like most of the trackers or we just keep the unique (long) > identifier. > > Then, optionally a simple set of HTML pages can be generated using the YAML > file. > > About storage of the YAML file I would simply store it in the repository. > If we make the bot accessible, we just have to periodically pull > from it. > This portion of your proposed system sounds to me a lot like SD (http://syncwith.us), against which writing your proposed bot would be fairly straightforward. - Kevin -- Kevin Riggle (kevinr at free-dissociation.com) MIT Class of 2010, Course VI-2 (EECS) http://free-dissociation.com From tero@tilus.net Mon Nov 2 02:01:31 2009 From: tero@tilus.net (Tero Tilus) Date: Mon, 02 Nov 2009 09:01:31 +0200 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257111816-sup-4397@peray> References: <1257111816-sup-4397@peray> Message-ID: <1257143690-sup-7839@tilus.net> Requirements collected: - Store/track - Formal attributes: Issue type, severity, priority, category, person assigned, progress status, incriminated version and platform, planned milestone/released - Informal meta: Issue details, discussion, answers, attachments - Web-interface (at least for issue submission, searching and displaying) - Issue submission, commenting, attachments and editing attributes by email - Notifications by email Nicolas Pouillard, 2009-11-01 23:52: > OK lets forget Ditz[2] as an option. Why? (not that i have any reason why not, i've never used diz) > Note also that I would make no objection to using a traditional bug > tracker. > > It seems that we do not find a tool we really like. Looks like this is a issue you have discussed in depth before. Any pointers to list archives? > A simple question I asked me was: > "Do we really need to invent this (big) tool?" Well... if somebody invented it for us already. :) > Especially for a bug tracker we need recipes, protocols more than a > nice interface. Now we are talking! ...and when trying to choose a tool, we need to think about what we need it to do for us. I tried to pick the requirements you used. > So we need a web interface for non technical users, great. OK, this seems reasonable requirement. > What about a pre-formatted email explained on a single web-page for > reporting bugs. ... > A bot will receive emails on the mailing-list and process those > which are in the right format. Requirement: Bug submission by email? I'd say we need that. > I think that the bot will not have a lot of information to store: > > (correct me if you find something else) > > * Issue type, severity, priority, category, person assigned, > progress status, incriminated version and platform, planned > milestone/released. > > * Issue details, discussion, answers, attachments. This is pretty traditional. I'd still want to challenge a bit. Why do we need severity and priority? What would they be used for? > I would store and manage the first category using a simple YAML > file. The bot acknowledges its updates by simply answering to the > discussion. Requirement: Email notifications to ticket "subscribers"? That's reasonable. > Those of the second category can be managed using a single email > discussion. Requirement: Issue comments/attachments and status changes by email? > I don't know yet how many issues I've forgotten I can't figure out anything really necessary you would have missed. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From tero@tilus.net Mon Nov 2 02:19:58 2009 From: tero@tilus.net (Tero Tilus) Date: Mon, 02 Nov 2009 09:19:58 +0200 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1257107371-sup-3361@onnadayr.ca> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net> <1257086191-sup-1136@masanjin.net> <1257107371-sup-3361@onnadayr.ca> Message-ID: <1257146346-sup-1154@tilus.net> rick.tessner, 2009-11-01 22:30: > Would a move to github be considered since they now have an issue > tracker. I'd be comfortable with github too. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From tero@tilus.net Mon Nov 2 02:25:38 2009 From: tero@tilus.net (Tero Tilus) Date: Mon, 02 Nov 2009 09:25:38 +0200 Subject: [sup-talk] Sup Issues Task Force (SITF) In-Reply-To: <1257086191-sup-1136@masanjin.net> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net> <1257086191-sup-1136@masanjin.net> Message-ID: <1257146404-sup-9768@tilus.net> William Morgan, 2009-11-01 16:39: > Reformatted excerpts from Tero Tilus's message of 2009-10-31: >> How about setting up a loose team which would handle the incoming >> bug reports (for you), track/sort all of them and fix what they >> feel like fixing and maybe upon request/occasionally report >> somewhere the current status (how many minors and majors open). > > As far as I'm concerned, that would be great. I'm open to > suggestions about how to organize this. How about SITF responsible of the boring suff - First line processing of inbound issues (relevance, duplication, ...) - Issue overview - Supervise that fixed/handled issues get closed appropriately - Draw attention to triaged "bad" bugs I'm in. Who else? -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From tero@tilus.net Mon Nov 2 02:29:41 2009 From: tero@tilus.net (Tero Tilus) Date: Mon, 02 Nov 2009 09:29:41 +0200 Subject: [sup-talk] slowly catching up In-Reply-To: <1256997213-sup-2725@masanjin.net> References: <1256997213-sup-2725@masanjin.net> Message-ID: <1257146774-sup-9810@tilus.net> William Morgan, 2009-10-31 16:03: > We just had our first baby so it's been a busy few weeks. Congratulations! Take your time. Your family needs it now. I've got two lovely kids, having the first one is a very special thing. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From nicolas.pouillard@gmail.com Mon Nov 2 03:30:03 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 02 Nov 2009 09:30:03 +0100 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257124377-sup-199@black-opal.mit.edu> References: <1257111816-sup-4397@peray> <1257124377-sup-199@black-opal.mit.edu> Message-ID: <1257150469-sup-7051@peray> Excerpts from Kevin Riggle's message of Mon Nov 02 02:17:31 +0100 2009: > Excerpts from Nicolas Pouillard's message of Sun Nov 01 16:52:08 -0500 2009: > (snip) > (snip) > > > > I would store and manage the first category using a simple YAML file. > > > > The bot acknowledges its updates by simply answering to the discussion. > > > > Those of the second category can be managed using a single email discussion. > > > > Since the discussion is central to the issue, tracking the original message-ID > > could be used as the unique identifier. > > > > About the issues identifier I see two options, either we try to allocate > > simple integers like most of the trackers or we just keep the unique (long) > > identifier. > > > > Then, optionally a simple set of HTML pages can be generated using the YAML > > file. > > > > About storage of the YAML file I would simply store it in the repository. > > If we make the bot accessible, we just have to periodically pull > > from it. > > > This portion of your proposed system sounds to me a lot like SD > (http://syncwith.us), against which writing your proposed bot would be fairly > straightforward. SD looks indeed really fun, however I think it fails my simplicity goal. Indeed the tool expose tons of commands and try to abstract how it is made, I'm in favor of better knowing the underlying store (a YAML file), and simply storing it with usual DVCS tools. -- Nicolas Pouillard http://nicolaspouillard.fr From nicolas.pouillard@gmail.com Mon Nov 2 03:46:34 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 02 Nov 2009 09:46:34 +0100 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257143690-sup-7839@tilus.net> References: <1257111816-sup-4397@peray> <1257143690-sup-7839@tilus.net> Message-ID: <1257150627-sup-1843@peray> Excerpts from Tero Tilus's message of Mon Nov 02 08:01:31 +0100 2009: > Requirements collected: > - Store/track > - Formal attributes: Issue type, severity, priority, category, > person assigned, progress status, incriminated version and > platform, planned milestone/released > - Informal meta: Issue details, discussion, answers, attachments > - Web-interface (at least for issue submission, searching and displaying) > - Issue submission, commenting, attachments and editing attributes by email > - Notifications by email Nice summary. > Nicolas Pouillard, 2009-11-01 23:52: > > OK lets forget Ditz[2] as an option. > > Why? (not that i have any reason why not, i've never used diz) At least temporarily, I think it also fails at staying simple. And while it is fun to hack that's fine but then it becomes burden and code to maintain. > > Note also that I would make no objection to using a traditional bug > > tracker. > > > > It seems that we do not find a tool we really like. > > Looks like this is a issue you have discussed in depth before. Any > pointers to list archives? Not really publicly, and I'm open to seeing tools I don't know. > > A simple question I asked me was: > > "Do we really need to invent this (big) tool?" > > Well... if somebody invented it for us already. :) Yes but a big tool imply development, extensions, upgrades... > > Especially for a bug tracker we need recipes, protocols more than a > > nice interface. > > Now we are talking! ...and when trying to choose a tool, we need to > think about what we need it to do for us. I would say that we need a collection of small and clear tools. > I tried to pick the requirements you used. > > > So we need a web interface for non technical users, great. > > OK, this seems reasonable requirement. > > > What about a pre-formatted email explained on a single web-page for > > reporting bugs. > ... > > A bot will receive emails on the mailing-list and process those > > which are in the right format. > > Requirement: Bug submission by email? > I'd say we need that. Yes some people tend to really dislike web UIs, and while it is not my case I prefer to keep a "by email" option anyway. > > I think that the bot will not have a lot of information to store: > > > > (correct me if you find something else) > > > > * Issue type, severity, priority, category, person assigned, > > progress status, incriminated version and platform, planned > > milestone/released. > > > > * Issue details, discussion, answers, attachments. > > This is pretty traditional. I'd still want to challenge a bit. Why > do we need severity and priority? What would they be used for? I don't say that we need all of those, that the flexibility point. The configuration will be something like: attributes: type: [defect, enhancement, task] severity: [critical, ...] priority: [high, low, ...] category: [UI, index, ...] assigned to: [someone, someoneelse, ...] progress status: [waiting, open, started, closed] ... This can be tweaked as needed, if we need one more 'type' we add it, if we do not need severity we remove it. > > I would store and manage the first category using a simple YAML > > file. The bot acknowledges its updates by simply answering to the > > discussion. > > Requirement: Email notifications to ticket "subscribers"? > That's reasonable. I would say that the mailing-list is the only subscriber, people choose to follow the discussion or not with their email-client. This only miss the "vote for this issue" feature, which we can avoid in the mean time and delegate to a polling tool afterward. > > Those of the second category can be managed using a single email > > discussion. > > Requirement: Issue comments/attachments and status changes by email? Right. > > I don't know yet how many issues I've forgotten > > I can't figure out anything really necessary you would have missed. I got some more input via other channels about the need of an UI to search, triage, sort issues. I would say that all of this can easily be done by playing with the YAML file. The only tool I see would be one to fetch the email discussion given a Message-ID, but this is a matter of another separated tool. Thanks for your input! -- Nicolas Pouillard http://nicolaspouillard.fr From isra@herraiz.org Mon Nov 2 04:14:52 2009 From: isra@herraiz.org (Israel Herraiz) Date: Mon, 02 Nov 2009 10:14:52 +0100 Subject: [sup-talk] Sup Issues Task Force (SITF) In-Reply-To: <1257146404-sup-9768@tilus.net> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net> <1257086191-sup-1136@masanjin.net> <1257146404-sup-9768@tilus.net> Message-ID: <1257153269-sup-1434@elly> Excerpts from Tero Tilus's message of Mon Nov 02 08:25:38 +0100 2009: > How about SITF responsible of the boring suff > - First line processing of inbound issues (relevance, duplication, ...) > - Issue overview > - Supervise that fixed/handled issues get closed appropriately > - Draw attention to triaged "bad" bugs > > I'm in. Who else? Me too. From tero@tilus.net Mon Nov 2 04:50:07 2009 From: tero@tilus.net (Tero Tilus) Date: Mon, 02 Nov 2009 11:50:07 +0200 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257150627-sup-1843@peray> References: <1257111816-sup-4397@peray> <1257143690-sup-7839@tilus.net> <1257150627-sup-1843@peray> Message-ID: <1257154664-sup-90@tilus.net> Nicolas Pouillard, 2009-11-02 10:46: > Excerpts from Tero Tilus's message of Mon Nov 02 08:01:31 +0100 2009: >>> "Do we really need to invent this (big) tool?" >> >> Well... if somebody invented it for us already. :) > > Yes but a big tool imply development, extensions, upgrades... Unless you take service, not the bare tool. We are already using gitorius and rubyforge (at least to some extent). I'd go for a issue tracking service that suits our needs. >> Requirement: Email notifications to ticket "subscribers"? >> That's reasonable. > > I would say that the mailing-list is the only subscriber, people > choose to follow the discussion or not with their email-client. Thats exactly why there were quotes around the word subscribers. ;) What I was thinking was that you could be a first class citized no matter the client. You could choose to comment and follow the discussion on issues using your mua or web interface. Kinda like what Alue[1] does for discussions in general. [1] http://antti-juhani.kaijanaho.fi/newblog/archives/572 -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From wmorgan-sup@masanjin.net Mon Nov 2 06:53:39 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 03:53:39 -0800 Subject: [sup-talk] Recovering a busted ferret db? In-Reply-To: References: <1256939095-sup-4201@masanjin.net> <1257087035-sup-2014@masanjin.net> Message-ID: <1257162594-sup-7077@masanjin.net> [cc'ing list] Reformatted excerpts from Steven Walter's message of 2009-11-01: > Hooray, that worked. There is an email with an exceptionally long > recipient list with the tag in question, and I received it around the > time I first noticed the bad behavior in sup. The Cc: field is 6878 > bytes long, containing 281 email addresses. Weird, because I can call split_on_commas on a string that's that size, with that many commas, in a few milliseconds. Must be something strange about that particular string that's causing the worst-case behavior. I'm going to apply the patch, but with a bigger limit. -- William From gregor@hoffleit.de Mon Nov 2 07:06:36 2009 From: gregor@hoffleit.de (Gregor Hoffleit) Date: Mon, 02 Nov 2009 13:06:36 +0100 Subject: [sup-talk] Patch for ncursesw branch (use panelw and formw) Message-ID: <1257162838-sup-737@sam.mediasupervision.de> I noticed that the ncursesw branch implements only the first part of the wide-char fixes suggested in the extconf patch in http://rubyforge.org/pipermail/sup-talk/2007-October/000297.html. Entering UTF-8 characters in the textfields ('To', 'Subject', 'Alias') still doesn't work. It worked fine, though, applied the second part of the patch as well. This is the diff against ncursesw: diff --git a/ncurses-0.9.1/extconf.rb b/ncurses-0.9.1/extconf.rb index a559385..7c4d2c2 100644 --- a/ncurses-0.9.1/extconf.rb +++ b/ncurses-0.9.1/extconf.rb @@ -118,11 +118,11 @@ have_func("attr_get") puts "checking for the panel library..." if have_header("panel.h") - have_library("panel", "panel_hidden") + have_library("panelw", "panel_hidden") end puts "checking for the form library..." if have_header("form.h") - have_library("form", "new_form") + have_library("formw", "new_form") end create_makefile('ncurses') From wmorgan-sup@masanjin.net Mon Nov 2 07:08:09 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 04:08:09 -0800 Subject: [sup-talk] updated xapian experimental branch In-Reply-To: <1257118189-sup-7392@zyrg.net> References: <1257118189-sup-7392@zyrg.net> Message-ID: <1257163403-sup-9032@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-11-01: > The major feature on this branch is the immediate label updates I've > mentioned before on the list. Awesome, really awesome. > Use of Xapian for thread relevance checks > - Instead of hardcoding the policy into InboxMode Awesome. > - New 'z' key to clear irrelevant threads > - Not strictly necessary, but removing messages in response to index > events is difficult with the current UI code Can you describe this a bit? > Fallout from async message saving > - UpdateManager messages handled in main event loop > - Avoids many races but can lag UI unless we're careful I think this is a great idea. Thanks for all of this, Rich. -- William From wmorgan-sup@masanjin.net Mon Nov 2 07:12:41 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 04:12:41 -0800 Subject: [sup-talk] i18n? In-Reply-To: <1256295847-sup-9437@viajero> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1256280223-sup-736@tilus.net> <1256295847-sup-9437@viajero> Message-ID: <1257163780-sup-1357@masanjin.net> Reformatted excerpts from Fabio Riga's message of 2009-10-23: > Well, I finally read the code and I agree with Tero. I also think that > the use of gettext will be simpler for both developer and translator. > In this way, every time a developer add a new string he need to write > it twice, or another developer has to hack it. Instead with gettext > the developer write his string, surrounded with _() or n_() and he's > done (tell me, if I'm wrong). Tero's comment wasn't about gettext, as far as I understand it. There are Ruby gettext bindings but they look like a pain in the ass to use, and it's pretty trivial to replace it a language like Ruby. > Furthermore people used to .po files (like me) will know what to do > and are already provided with tools for that purpose (i.e. Vim :-) ). That is a downside, definitely. > Can anyone explain me where and why a translated string in the UI should be > searchable with a regular expression? (Maybe this question is due to the > fact that I still don't understand sup internals...) I believe he was thinking about something like git grep. You see a weird message displayed by Sup, you want to find the code that's generating it, you can git grep the source for the message directly. -- William From wmorgan-sup@masanjin.net Mon Nov 2 07:13:01 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 04:13:01 -0800 Subject: [sup-talk] i18n? In-Reply-To: <1256280223-sup-736@tilus.net> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1256280223-sup-736@tilus.net> Message-ID: <1257163967-sup-5554@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2009-10-23: > Why not default to the english strings as translation keys and > fallback to key itself in case of missing translation? Christopher, what do you think? -- William From wmorgan-sup@masanjin.net Mon Nov 2 07:16:04 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 04:16:04 -0800 Subject: [sup-talk] (Orphaned?) bug tracker at rubyforge.org? In-Reply-To: <1256216959-sup-8012@sam.mediasupervision.de> References: <1256216959-sup-8012@sam.mediasupervision.de> Message-ID: <1257164155-sup-371@masanjin.net> Reformatted excerpts from Gregor Hoffleit's message of 2009-10-22: > If the bug tracker is not to be acticely used any longer, shouldn't it > be removed from the Sup Gitorious page? Removed, thanks! -- William From wmorgan-sup@masanjin.net Mon Nov 2 07:23:16 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 04:23:16 -0800 Subject: [sup-talk] Localized date on mbox From line in sent messages In-Reply-To: <1256276875-sup-5782@tilus.net> References: <1256276875-sup-5782@tilus.net> Message-ID: <1257164552-sup-2382@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2009-10-22: > This might be known. I accidentally used 0.8.1 instead of git next > once and it screwed up my sent box. After forwarding a mail sup > started to blow up (what felt like) after initiall poll. This was fixed in bfe40c05dc6dc2656a4dde11948ff617f2fa00d6, released in 0.9. -- William From wmorgan-sup@masanjin.net Mon Nov 2 07:35:21 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 04:35:21 -0800 Subject: [sup-talk] Recovering a busted ferret db? In-Reply-To: <1257162594-sup-7077@masanjin.net> References: <1256939095-sup-4201@masanjin.net> <1257087035-sup-2014@masanjin.net> <1257162594-sup-7077@masanjin.net> Message-ID: <1257165314-sup-679@masanjin.net> Reformatted excerpts from William Morgan's message of 2009-11-02: > I'm going to apply the patch, but with a bigger limit. Actually, strike that. The patch would mean we effectively limit the number of recipients in a to, cc, or bcc field, which seems crazy. It would be better to reimplement the regexp as a little state machine, as irritating as that might be. Steven, can you privately send me the header that's causing this? You can obscure it somewhat if you want, just leave the quotes and commas alone. -- William From tero@tilus.net Mon Nov 2 08:58:09 2009 From: tero@tilus.net (Tero Tilus) Date: Mon, 02 Nov 2009 15:58:09 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1257163780-sup-1357@masanjin.net> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1256280223-sup-736@tilus.net> <1256295847-sup-9437@viajero> <1257163780-sup-1357@masanjin.net> Message-ID: <1257169884-sup-2615@tilus.net> William Morgan, 2009-11-02 14:12: > Reformatted excerpts from Fabio Riga's message of 2009-10-23: >> Well, I finally read the code and I agree with Tero. I also think that >> the use of gettext will be simpler for both developer and translator. > > Tero's comment wasn't about gettext, as far as I understand it. You had me right. I was talking about the approach to i18n in general. > There are Ruby gettext bindings but they look like a pain in the ass > to use, and it's pretty trivial to replace it a language like Ruby. Also they are pretty trivial to wrap behind nice interface in a language like Ruby. "Been there, done that!".t :) >> Can anyone explain me where and why a translated string in the UI >> should be searchable with a regular expression? > > I believe he was thinking about something like git grep. You see a > weird message displayed by Sup, you want to find the code that's > generating it, you can git grep the source for the message directly. That was exactly what I was thinking. Having weird keys in code imo also slows down development. If I want to (write code to) display a simple message to user, with "original language as key" approac i just write "my message".t (or whatever the l10n interface is) instead of modifying some yaml file somewhere and then copy-pasting the key from there to code. I just plain code and let somebody else figure out the translation later or. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From wmorgan-sup@masanjin.net Mon Nov 2 09:50:08 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 06:50:08 -0800 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257111816-sup-4397@peray> References: <1257111816-sup-4397@peray> Message-ID: <1257169654-sup-6224@masanjin.net> Nice writeup. Just brainstorming, here are the features I personally find vital for an issue tracker that would make me happy: 1. Web submission. The burden of creating a record should be on the submitter---it's not too much to ask, and it saves developer time. This also encourages reporters to provide relevant information like version, platform, Ruby version, etc. upfront, since they can be prompted for those data explicitly. 2. Developer discussion via email. This is vital. There's no way I would want to have a technical discussion using text boxes on a website. And this discussion should be attached to the issue, of course. 3. Canonicality. I want one name for a bug, and I want one URL that I can point people to when referring to it. That URL should have the entire history, including developer discussion, of the issue. 4. Browseability. There should be some public way of getting a view of all the open issues, at a minimum. (Web seems natural.) Other stuff like sorting by priority, attachign to releases, etc. are icing on the cake, but if people are going to be chipping in on development effort, or searching to see if other people have had this bug, they have to be able to browse what's out there. > About the issues identifier I see two options, either we try to > allocate simple integers like most of the trackers or we just keep the > unique (long) identifier. I want a simple one. I can remember JIRA-style "ABC-123" names and that's really handy sometimes. Just my two cents. -- William From wmorgan-sup@masanjin.net Mon Nov 2 09:53:08 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 06:53:08 -0800 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257143690-sup-7839@tilus.net> References: <1257111816-sup-4397@peray> <1257143690-sup-7839@tilus.net> Message-ID: <1257173444-sup-295@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2009-11-01: > Requirement: Bug submission by email? > I'd say we need that. That's what we have now, basically, and what we had when we were using ditz, and I didn't like having to do the extra work of making an issue. > This is pretty traditional. I'd still want to challenge a bit. Why > do we need severity and priority? What would they be used for? At least one type of ordering would be nice. There are a large class of feature requests where my basic feeling is "sure, that would be nice, but I've got a million other things more important to do", which I would like to keep around as food for later thought, if nothing else, but would like to basically ignore in the near term. -- William From wmorgan-sup@masanjin.net Mon Nov 2 09:58:18 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 06:58:18 -0800 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257154664-sup-90@tilus.net> References: <1257111816-sup-4397@peray> <1257143690-sup-7839@tilus.net> <1257150627-sup-1843@peray> <1257154664-sup-90@tilus.net> Message-ID: <1257173616-sup-9298@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2009-11-02: > Unless you take service, not the bare tool. We are already using > gitorius and rubyforge (at least to some extent). I'd go for a issue > tracking service that suits our needs. I'm not dead-set against a hosted solution, but I am wary of making too much of the development cycle reliant on third parties. E.g. I see people who can't get any work done when Github is down. Well, that's not Github's fault, per se, but they've integrated it into their process to such an extent that they're now reliant on it. Not to say that that would happen with just an issue tracker. But still, our use of Gitorious and Rubyforge is pretty minimal right now, and I feel good about that. (And honestly I find Gitorious merge requests a little irritating, because they're invariably not rebased properly against master and I have to have the same discussion every time.) -- William From wmorgan-sup@masanjin.net Mon Nov 2 09:59:48 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 06:59:48 -0800 Subject: [sup-talk] i18n? In-Reply-To: <1257169884-sup-2615@tilus.net> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1256280223-sup-736@tilus.net> <1256295847-sup-9437@viajero> <1257163780-sup-1357@masanjin.net> <1257169884-sup-2615@tilus.net> Message-ID: <1257173950-sup-4883@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2009-11-02: > Having weird keys in code imo also slows down development. If I want > to (write code to) display a simple message to user, with "original > language as key" approac i just write "my message".t (or whatever the > l10n interface is) instead of modifying some yaml file somewhere and > then copy-pasting the key from there to code. I just plain code and > let somebody else figure out the translation later or. I tend to agree. -- William From wmorgan-sup@masanjin.net Mon Nov 2 10:07:31 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 07:07:31 -0800 Subject: [sup-talk] [PATCH] minor nits in exception apology message In-Reply-To: <1257107371-sup-3361@onnadayr.ca> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net> <1257086191-sup-1136@masanjin.net> <1257107371-sup-3361@onnadayr.ca> Message-ID: <1257174251-sup-3662@masanjin.net> Reformatted excerpts from rick.tessner's message of 2009-11-01: > Would a move to github be considered since they now have an issue > tracker. It provides tagging of issues and voting. I will move development discussion to a flat sequence of web textareas the day you pry Sup from my cold dead hands. Well, ok. I will at least take a look at it. -- William From wmorgan-sup@masanjin.net Mon Nov 2 10:08:48 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 07:08:48 -0800 Subject: [sup-talk] Sup Issues Task Force (SITF) In-Reply-To: <1257146404-sup-9768@tilus.net> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net> <1257086191-sup-1136@masanjin.net> <1257146404-sup-9768@tilus.net> Message-ID: <1257174456-sup-5631@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2009-11-01: > How about SITF responsible of the boring suff > - First line processing of inbound issues (relevance, duplication, ...) > - Issue overview > - Supervise that fixed/handled issues get closed appropriately > - Draw attention to triaged "bad" bugs > > I'm in. Who else? That sounds great. I think it needs to be combined with some kind of formal issue tracker though. -- William From wmorgan-sup@masanjin.net Mon Nov 2 10:57:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 07:57:50 -0800 Subject: [sup-talk] Using TLS instead of ssl In-Reply-To: <2b29d9f30910270434k65550eaqf5187d048b604020@mail.gmail.com> References: <2b29d9f30910270434k65550eaqf5187d048b604020@mail.gmail.com> Message-ID: <1257177347-sup-2023@masanjin.net> Reformatted excerpts from k.v.ramakrishna reddy's message of 2009-10-27: > What are the changes that i need to make so that sup uses TLS instead > of ssl when connecting to my source ? Honestly I'm not sure. I'm not that familiar with IMAP. Is that something that's negotiated during setting up a connection? > Further more how can i delete a source ? There's not a great way right now. You can remove it from ~/.sup/sources.yaml manually, and then you can remove the messages from the index with something like this: $ sh devel/console.sh >> q = Index.parse_query "source_id:4" => # ... >> Index.each_id(q) { |id| Index.delete id } => nil >> Index.save -- William From wmorgan-sup@masanjin.net Mon Nov 2 10:58:45 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 07:58:45 -0800 Subject: [sup-talk] Completion for search queries In-Reply-To: <1256199860-sup-4407@thinkpad-ubuntu> References: <1256199860-sup-4407@thinkpad-ubuntu> Message-ID: <1257177490-sup-4126@masanjin.net> Reformatted excerpts from Christopher Bertels's message of 2009-10-22: > Anyone else who would like to have this feature in sup? Sounds good to me. Probably wouldn't be too hard since we have a fairly general tab-completion mechanism in place already. -- William From wmorgan-sup@masanjin.net Mon Nov 2 11:03:41 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 08:03:41 -0800 Subject: [sup-talk] exception in mainline In-Reply-To: <1256749083-sup-3681@arrakis.es.net> References: <1256749083-sup-3681@arrakis.es.net> Message-ID: <1257177587-sup-5889@masanjin.net> Hi Jon, Reformatted excerpts from Jon Dugan's message of 2009-10-28: > i now get this when i start sup. i'm running mainline. > > --- RuntimeError from thread: load threads for thread-index-mode > wrong id called on nil > ./lib/sup.rb:17:in `id' > ./lib/sup/modes/thread-index-mode.rb:225:in `update' I posted this workaround patch earlier. I'm working on a better solution in the meanwhile. diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index 82f258b..17d5836 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -222,7 +222,7 @@ EOS def update @mutex.synchronize do ## let's see you do THIS in python - @threads = @ts.threads.select { |t| !@hidden_threads[t] }.sort_by { |t| [t.date, t.first.id] }.reverse + @threads = @ts.threads.select { |t| !@hidden_threads[t] }.select { |t| t.first }.sort_by { |t| [t.date, t.first.id] }.reverse @size_widgets = @threads.map { |t| size_widget_for_thread t } @size_widget_width = @size_widgets.max_of { |w| w.display_length } end > ./lib/sup/hook.rb:122:in `sort_by' > ./lib/sup/modes/thread-index-mode.rb:225:in `each' > ./lib/sup/modes/thread-index-mode.rb:225:in `sort_by' > ./lib/sup/modes/thread-index-mode.rb:225:in `update' > ./lib/sup/modes/thread-index-mode.rb:223:in `synchronize' > ./lib/sup/modes/thread-index-mode.rb:223:in `update' > ./lib/sup/modes/thread-index-mode.rb:628:in `__unprotected_load_n_threads' > ./lib/sup/thread.rb:334:in `load_n_threads' > ./lib/sup/xapian_index.rb:151:in `each_id_by_date' > ./lib/sup/xapian_index.rb:144:in `each_id' > ./lib/sup/xapian_index.rb:144:in `each' > ./lib/sup/xapian_index.rb:144:in `each_id' > ./lib/sup/xapian_index.rb:151:in `each_id_by_date' > ./lib/sup/thread.rb:328:in `load_n_threads' > ./lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads' > (eval):12:in `load_n_threads' > ./lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background' > ./lib/sup.rb:77:in `reporting_thread' > ./lib/sup.rb:75:in `initialize' > ./lib/sup.rb:75:in `new' > ./lib/sup.rb:75:in `reporting_thread' > ./lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' > ./lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' > (eval):12:in `load_threads' > bin/sup:199 > -- William From stevenrwalter@gmail.com Mon Nov 2 11:47:51 2009 From: stevenrwalter@gmail.com (Steven Walter) Date: Mon, 2 Nov 2009 11:47:51 -0500 Subject: [sup-talk] "Force tags to be joined" doesn't save Message-ID: If I select two threads and combine them with #, sup seems to combine them, and the current view becomes "modified." If I save ($) and reload (@), the threads show up separately again. Is this expected behavior? -- -Steven Walter From nicolas.pouillard@gmail.com Mon Nov 2 12:38:54 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 02 Nov 2009 18:38:54 +0100 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257173444-sup-295@masanjin.net> References: <1257111816-sup-4397@peray> <1257143690-sup-7839@tilus.net> <1257173444-sup-295@masanjin.net> Message-ID: <1257183478-sup-7820@peray> Excerpts from William Morgan's message of Mon Nov 02 15:53:08 +0100 2009: > Reformatted excerpts from Tero Tilus's message of 2009-11-01: > > Requirement: Bug submission by email? > > I'd say we need that. > > That's what we have now, basically, and what we had when we were using > ditz, and I didn't like having to do the extra work of making an issue. Right, but in this setup only well formatted bug reports are accepted, so no extra burden on devs. -- Nicolas Pouillard http://nicolaspouillard.fr From nicolas.pouillard@gmail.com Mon Nov 2 12:47:19 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 02 Nov 2009 18:47:19 +0100 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257169654-sup-6224@masanjin.net> References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net> Message-ID: <1257183536-sup-1174@peray> Excerpts from William Morgan's message of Mon Nov 02 15:50:08 +0100 2009: > Nice writeup. Just brainstorming, here are the features I personally > find vital for an issue tracker that would make me happy: > > 1. Web submission. The burden of creating a record should be on the > submitter---it's not too much to ask, and it saves developer time. This > also encourages reporters to provide relevant information like version, > platform, Ruby version, etc. upfront, since they can be prompted for > those data explicitly. > 2. Developer discussion via email. This is vital. There's no way I would > want to have a technical discussion using text boxes on a website. And > this discussion should be attached to the issue, of course. 1,2: Same for me. > 3. Canonicality. I want one name for a bug, and I want one URL that I > can point people to when referring to it. That URL should have the > entire history, including developer discussion, of the issue. > 4. Browseability. There should be some public way of getting a view of > all the open issues, at a minimum. (Web seems natural.) Other stuff like > sorting by priority, attachign to releases, etc. are icing on the cake, > but if people are going to be chipping in on development effort, or > searching to see if other people have had this bug, they have to be able > to browse what's out there. 3,4: Right, I think this is part of the web-page generation tool. Which given the YAML file will produce web-pages. The only unclear point to me is: "how to find the archive URL for a discussion given the message-ID?" > > About the issues identifier I see two options, either we try to > > allocate simple integers like most of the trackers or we just keep the > > unique (long) identifier. > > I want a simple one. I can remember JIRA-style "ABC-123" names and > that's really handy sometimes. Right, we want short issue numbers. I'm would still be a bit sad of completely loosing the distributed property. Maybe a solution would be to allow issues to have an optional short name. In practice it will be just temporarily, the time the issue makes its way to the central repository, or being just a local issue. -- Nicolas Pouillard http://nicolaspouillard.fr From wmorgan-sup@masanjin.net Mon Nov 2 14:20:32 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 11:20:32 -0800 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257183536-sup-1174@peray> References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net> <1257183536-sup-1174@peray> Message-ID: <1257189278-sup-7991@masanjin.net> Reformatted excerpts from Nicolas Pouillard's message of 2009-11-02: > Right, we want short issue numbers. I'm would still be a bit sad of > completely loosing the distributed property. Maybe a solution would be > to allow issues to have an optional short name. In practice it will be > just temporarily, the time the issue makes its way to the central > repository, or being just a local issue. I just think it would be really useful to say stuff like "this is a duplicate of #154" or "fixing this depends on index-48" or whatever, and have everyone be able to find that easily, e.g. by going to http://sup.com/bugs/index-48. Having to refer to the hashes in Ditz was irritating. -- William From wmorgan-sup@masanjin.net Mon Nov 2 14:22:48 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 11:22:48 -0800 Subject: [sup-talk] "Force tags to be joined" doesn't save In-Reply-To: References: Message-ID: <1257189701-sup-8211@masanjin.net> Reformatted excerpts from Steven Walter's message of 2009-11-02: > If I select two threads and combine them with #, sup seems to combine > them, and the current view becomes "modified." If I save ($) and > reload (@), the threads show up separately again. Is this expected > behavior? I pushed a fix for this to master yesterday. Do you still have this with a recent git? (I.e. one with cc2359bf87bd982501e57f703fbf4368b7f9cb5f). -- William From wmorgan-sup@masanjin.net Mon Nov 2 14:28:03 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 11:28:03 -0800 Subject: [sup-talk] [PATCH] xapian: replace DocumentMethods module with plain monkeypatching In-Reply-To: <1256019247-6046-1-git-send-email-rlane@club.cc.cmu.edu> References: <20091012223449.GB31940@tilus.net> <1256019247-6046-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1257190065-sup-2886@masanjin.net> Branch xapian-bugfix, merged into next. Thanks! -- William From wmorgan-sup@masanjin.net Mon Nov 2 14:31:38 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 11:31:38 -0800 Subject: [sup-talk] releasing 0.9.1 in the next day or so Message-ID: <1257190099-sup-9880@masanjin.net> Hi all, I'm going to release an 0.9.1 based off the current master in the next day or so. This is just a heads-up. There are a couple bugfixes that are still cooking in next, but I want to keep this as stable as possible. Changes since 0.9 will be: $ git log release-0.9..master --pretty=oneline 84d9313bfd73e86c8fea95fabc8ff8544f70b1f0 make doc/NewUserGuide.txt markdown 269cd03b183669c86df1f7336ade8fff5c566ebd fix mbox date parsing: catch ArgumentError 409ddd9c5668b5cdf67dbebea761c476a317c53a give exception log relative to BASE_DIR in exception message 2dfd378b616243d03203e49f5ee29636051d3cbf fix bug in which custom-search substitutions are not used 4a32776f523039cdcbb6165d58e24bd9753b256b increase numbers in contact-list-mode d19eda45643dff558324c6c2f34aa0148f9d65d0 don't downcase a nil content-type a8b5c6db0587fe4383758dc3400aaab85ad22d8b fix --compose option, and add a --subject option c924164c22a7bdb3fb66f9ce4ca5ac8b19dfcccf include hook filename in error messages 93b5552730c10e2a352bd33f5ee98800bcd8679e more release-script updates -- William From wmorgan-sup@masanjin.net Mon Nov 2 14:32:36 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 02 Nov 2009 11:32:36 -0800 Subject: [sup-talk] "Force tags to be joined" doesn't save In-Reply-To: <1257189701-sup-8211@masanjin.net> References: <1257189701-sup-8211@masanjin.net> Message-ID: <1257190312-sup-7892@masanjin.net> Reformatted excerpts from William Morgan's message of 2009-11-02: > I pushed a fix for this to master yesterday. Do you still have this > with a recent git? (I.e. one with > cc2359bf87bd982501e57f703fbf4368b7f9cb5f). Sorry, this is in next only for the moment. -- William From nicolas.pouillard@gmail.com Mon Nov 2 15:23:58 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 02 Nov 2009 21:23:58 +0100 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257189278-sup-7991@masanjin.net> References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net> <1257183536-sup-1174@peray> <1257189278-sup-7991@masanjin.net> Message-ID: <1257193412-sup-5939@peray> Excerpts from William Morgan's message of Mon Nov 02 20:20:32 +0100 2009: > Reformatted excerpts from Nicolas Pouillard's message of 2009-11-02: > > Right, we want short issue numbers. I'm would still be a bit sad of > > completely loosing the distributed property. Maybe a solution would be > > to allow issues to have an optional short name. In practice it will be > > just temporarily, the time the issue makes its way to the central > > repository, or being just a local issue. > > I just think it would be really useful to say stuff like "this is a > duplicate of #154" or "fixing this depends on index-48" or whatever, and > have everyone be able to find that easily, e.g. by going to > http://sup.com/bugs/index-48. Having to refer to the hashes in Ditz was > irritating. I agree, that's way I proposed it. -- Nicolas Pouillard http://nicolaspouillard.fr From joe@talkhouse.com Mon Nov 2 15:40:21 2009 From: joe@talkhouse.com (=?utf-8?q?Joe_W=C3=B6lfel?=) Date: Mon, 02 Nov 2009 15:40:21 -0500 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257169654-sup-6224@masanjin.net> References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net> Message-ID: <1257193345-sup-3174@maui.local> Excerpts from William Morgan's message of Mon Nov 02 09:50:08 -0500 2009: > 1. Web submission. The burden of creating a record should be on the > submitter---it's not too much to ask, and it saves developer time. This > also encourages reporters to provide relevant information like version, > platform, Ruby version, etc. upfront, since they can be prompted for > those data explicitly. > > 2. Developer discussion via email. This is vital. There's no way I would > want to have a technical discussion using text boxes on a website. And > this discussion should be attached to the issue, of course. Please ignore this suggestion if you feel it is stupid, but couldn't an internal sup-based bug submission perform prompting and validation tasks just as easily as a web form? Also, wouldn't it be better for automatically including or verifying operating system info, version info, libraries, etc? It seems like this might make for a more natural transition to email-based developer discussion, reduce the need for centralized infrastructure, make it easier for users to figure out how and where to submit a bug, and possibly make critical system and library information more accurate and detailed. Cheers, Joe From nicolas.pouillard@gmail.com Mon Nov 2 16:49:39 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 02 Nov 2009 22:49:39 +0100 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257193345-sup-3174@maui.local> References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net> <1257193345-sup-3174@maui.local> Message-ID: <1257198369-sup-9036@peray> Excerpts from Joe W?lfel's message of Mon Nov 02 21:40:21 +0100 2009: > Excerpts from William Morgan's message of Mon Nov 02 09:50:08 -0500 2009: > > 1. Web submission. The burden of creating a record should be on the > > submitter---it's not too much to ask, and it saves developer time. This > > also encourages reporters to provide relevant information like version, > > platform, Ruby version, etc. upfront, since they can be prompted for > > those data explicitly. > > > > 2. Developer discussion via email. This is vital. There's no way I would > > want to have a technical discussion using text boxes on a website. And > > this discussion should be attached to the issue, of course. > > Please ignore this suggestion if you feel it is stupid, but couldn't an > internal sup-based bug submission perform prompting and validation tasks just > as easily as a web form? Also, wouldn't it be better for automatically > including or verifying operating system info, version info, libraries, etc? > > It seems like this might make for a more natural transition to email-based > developer discussion, reduce the need for centralized infrastructure, make it > easier for users to figure out how and where to submit a bug, and possibly make > critical system and library information more accurate and detailed. This is indeed a nice option. Add to sup a way to send a bug report. It could simply be an email in the chosen format for bug reporting. And indeed the bonus is more precise information. However in the long run this only complementary with other way to report bugs. -- Nicolas Pouillard http://nicolaspouillard.fr From david.pflug@hostdime.com Mon Nov 2 16:53:52 2009 From: david.pflug@hostdime.com (David Pflug) Date: Mon, 02 Nov 2009 16:53:52 -0500 Subject: [sup-talk] Exception during message polling Message-ID: <1257198730-sup-5007@dpflug-desktop> I don't know what mail it's dying on, but this is sup 0.9 using Xapian. --- ArgumentError from thread: poll after loading inbox invalid byte sequence in US-ASCII /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:284:in `gsub' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:284:in `normalize_whitespace' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/message.rb:511:in `message_to_chunks' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/message.rb:435:in `block in message_to_chunks' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/message.rb:435:in `map' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/message.rb:435:in `message_to_chunks' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/message.rb:239:in `load_from_source!' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/message.rb:335:in `build_from_source' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:145:in `block in each_message_from' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/imap.rb:197:in `block in each' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/imap.rb:185:in `upto' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/imap.rb:185:in `each' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:560:in `__pass' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:547:in `method_missing' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:139:in `each_message_from' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:93:in `block (2 levels) in do_poll' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:81:in `each' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:81:in `block in do_poll' :8:in `synchronize' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:80:in `do_poll' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/modes/poll-mode.rb:15:in `poll' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:48:in `poll' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup:196:in `block (2 levels) in ' /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup.rb:77:in `block in reporting_thread' -- David Pflug System Technician Hostdime.com, Inc. From usul@aruba.it Mon Nov 2 19:01:08 2009 From: usul@aruba.it (Fabio Riga) Date: Tue, 03 Nov 2009 01:01:08 +0100 Subject: [sup-talk] i18n? In-Reply-To: <1257169884-sup-2615@tilus.net> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1256280223-sup-736@tilus.net> <1256295847-sup-9437@viajero> <1257163780-sup-1357@masanjin.net> <1257169884-sup-2615@tilus.net> Message-ID: <1257202138-sup-5711@viajero> Excerpts from Tero Tilus's message of lun nov 02 14:58:09 +0100 2009: > William Morgan, 2009-11-02 14:12: > > Tero's comment wasn't about gettext, as far as I understand it. > > You had me right. I was talking about the approach to i18n in general. Sorry, I think the problem here is my English. I understood Tero's comment wasn't about gettext, I was the one suggesting: "everybody's using gettext, why don't we?" > > There are Ruby gettext bindings but they look like a pain in the ass > > to use, and it's pretty trivial to replace it a language like Ruby. > > Also they are pretty trivial to wrap behind nice interface in a > language like Ruby. "Been there, done that!".t :) And you both answered that question... I'm just a hobbyist ruby programmer, never used gettext. I transleted a program that use it (my previous mail client :D) so I can read a .po file (I don't understand why this is a problem, though). I thought it was an easy, ready-made thing to implement, if I'm wrong, no problem, there is always a better solution. > > I believe he was thinking about something like git grep. You see a > > weird message displayed by Sup, you want to find the code that's > > generating it, you can git grep the source for the message directly. > > That was exactly what I was thinking. > > Having weird keys in code imo also slows down development. If I want > to (write code to) display a simple message to user, with "original > language as key" approac i just write "my message".t (or whatever the > l10n interface is) instead of modifying some yaml file somewhere and > then copy-pasting the key from there to code. I just plain code and > let somebody else figure out the translation later or. > Sorry, I don't understand what you mean. The idea is to (1) have a branch for every language? Translators directly write in the code? Or (2) "original language as key" means a way to substitute "on the fly" the original string with another one in the current locale? In this way you always need a yaml file, or a ruby hash, or a .po file (you can implement it in another way, but is the gettext approach...). So, I played a little with irb... do you mean something like: class String def t l10n_hash[self] || self end end Sounds good to me... "bye bye".t => "ciao ciao" From tero@tilus.net Mon Nov 2 20:22:44 2009 From: tero@tilus.net (Tero Tilus) Date: Tue, 03 Nov 2009 03:22:44 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1257202138-sup-5711@viajero> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1256280223-sup-736@tilus.net> <1256295847-sup-9437@viajero> <1257163780-sup-1357@masanjin.net> <1257169884-sup-2615@tilus.net> <1257202138-sup-5711@viajero> Message-ID: <1257210858-sup-5218@tilus.net> Fabio Riga, 2009-11-03 02:01: > Sorry, I don't understand what you mean. The idea is to (1) have a > branch for every language? Translators directly write in the code? > Or (2) "original language as key" means a way to substitute "on the > fly" the original string with another one in the current locale? The second one, yes. God save us from the first! > So, I played a little with irb... do you mean something like: > > class String > def t > l10n_hash[self] || self > end > end Exactly. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From tero@tilus.net Mon Nov 2 20:45:24 2009 From: tero@tilus.net (Tero Tilus) Date: Tue, 03 Nov 2009 03:45:24 +0200 Subject: [sup-talk] Sup Issues Task Force (SITF) In-Reply-To: <1257174456-sup-5631@masanjin.net> References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray> <1256760970-sup-8118@arrakis.es.net> <1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net> <1257086191-sup-1136@masanjin.net> <1257146404-sup-9768@tilus.net> <1257174456-sup-5631@masanjin.net> Message-ID: <1257212675-sup-1610@tilus.net> William Morgan, 2009-11-02 17:08: > I think it needs to be combined with some kind of formal issue > tracker though. Most definitely yes. Let's see where the tracker discussion goes. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From rlane@club.cc.cmu.edu Mon Nov 2 22:48:10 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Mon, 02 Nov 2009 22:48:10 -0500 Subject: [sup-talk] updated xapian experimental branch In-Reply-To: <1257163403-sup-9032@masanjin.net> References: <1257118189-sup-7392@zyrg.net> <1257163403-sup-9032@masanjin.net> Message-ID: <1257196293-sup-6882@zyrg.net> Excerpts from William Morgan's message of Mon Nov 02 07:08:09 -0500 2009: > > - New 'z' key to clear irrelevant threads > > - Not strictly necessary, but removing messages in response to index > > events is difficult with the current UI code > > Can you describe this a bit? In general, we can only determine thread relevance by querying xapian. The actual write to the db is done async, so it will happen a little after you (for example) remove a label. The index fires a message event when the new state hits the db, and the UI then checks if the thread is still relevant to the query. So, the UI would only know to hide a newly irrelevant thread after the user has potentially gone on and done other actions. Having threads randomly disappear would be unfriendly, so instead the UI displays a red X. 'z' will drop these irrelevant threads. For 'simple' queries we can determine relevance without xapian, so we could synchronously remove irrelevant threads in that case. However, this would lead to unintuitive situations where queries that appear similar have different irrelevance behaviors. The option that I will probably implement is choosing the behavior per-mode, so that inbox-mode could keep it's old behavior. That's the most important one anyway. From nicolas.pouillard@gmail.com Tue Nov 3 03:39:48 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Tue, 03 Nov 2009 09:39:48 +0100 Subject: [sup-talk] updated xapian experimental branch In-Reply-To: <1257196293-sup-6882@zyrg.net> References: <1257118189-sup-7392@zyrg.net> <1257163403-sup-9032@masanjin.net> <1257196293-sup-6882@zyrg.net> Message-ID: <1257237468-sup-5663@peray> Excerpts from Rich Lane's message of Tue Nov 03 04:48:10 +0100 2009: > Excerpts from William Morgan's message of Mon Nov 02 07:08:09 -0500 2009: > > > - New 'z' key to clear irrelevant threads > > > - Not strictly necessary, but removing messages in response to index > > > events is difficult with the current UI code > > > > Can you describe this a bit? > > In general, we can only determine thread relevance by querying xapian. > The actual write to the db is done async, so it will happen a little > after you (for example) remove a label. The index fires a message event > when the new state hits the db, and the UI then checks if the thread is > still relevant to the query. So, the UI would only know to hide a newly > irrelevant thread after the user has potentially gone on and done other > actions. Having threads randomly disappear would be unfriendly, so > instead the UI displays a red X. 'z' will drop these irrelevant threads. > > For 'simple' queries we can determine relevance without xapian, so we > could synchronously remove irrelevant threads in that case. However, > this would lead to unintuitive situations where queries that appear > similar have different irrelevance behaviors. The option that I will > probably implement is choosing the behavior per-mode, so that inbox-mode > could keep it's old behavior. That's the most important one anyway. What are non simple queries which would cause 'red X's to appear? My guess is that since we cannot change other attributes than the labels, we can statically know if the thread is still relevant without the label. No? -- Nicolas Pouillard http://nicolaspouillard.fr From wmorgan-sup@masanjin.net Tue Nov 3 08:43:25 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 03 Nov 2009 05:43:25 -0800 Subject: [sup-talk] Sup crashing upon save changes ($) In-Reply-To: <1256178926-sup-1780@Richard-Sandilandss-MacBook-Pro.local> References: <1256178926-sup-1780@Richard-Sandilandss-MacBook-Pro.local> Message-ID: <1257255713-sup-617@masanjin.net> Reformatted excerpts from Richard Sandilands's message of 2009-10-21: > I'm tracking next and when I hit $, sup crashes and logs this: > > Any clues on how to get things ironed out would be appreciated. > > Exception log: > > --- Errno::ENOENT from thread: load messages for thread-view-mode > No such file or directory - /Users/richard/.sup/drafts/18 It looks like Sup's expecting a draft message that disappeared from disk somehow. You should be able to fix this by reindexing the drafts folder: sup-sync --all -v sup://drafts But you may want to find out why that file disappeared. -- William From mailinglist@flasht.de Tue Nov 3 09:05:01 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Tue, 03 Nov 2009 15:05:01 +0100 Subject: [sup-talk] i18n? In-Reply-To: <1257163967-sup-5554@masanjin.net> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1256280223-sup-736@tilus.net> <1257163967-sup-5554@masanjin.net> Message-ID: <1257256976-sup-1266@thinkpad-ubuntu> Excerpts from William Morgan's message of Mo Nov 02 13:13:01 +0100 2009: > Reformatted excerpts from Tero Tilus's message of 2009-10-23: > > Why not default to the english strings as translation keys and > > fallback to key itself in case of missing translation? > > Christopher, what do you think? Sounds OK to me. Should we use gettext then or rely on .yaml files for any additional translations then? I haven't used gettext yet and from what I remember it lookes weird, at least the ruby binding did. Maybe it's very easy though. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From pioto@pioto.org Tue Nov 3 09:50:55 2009 From: pioto@pioto.org (Mike Kelly) Date: Tue, 03 Nov 2009 09:50:55 -0500 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257169654-sup-6224@masanjin.net> References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net> Message-ID: <02055f053011496a2dcb9085b7e7535f@localhost> On Mon, 02 Nov 2009 06:50:08 -0800, William Morgan wrote: > Nice writeup. Just brainstorming, here are the features I personally > find vital for an issue tracker that would make me happy: > > 1. Web submission. > > 2. Developer discussion via email. > > 3. Canonicality. > > 4. Browseability. > > I want a simple one. I can remember JIRA-style "ABC-123" names and > that's really handy sometimes. As much as I hate to suggest it... RT[1] should have all of these qualities. It's used by CPAN, among other things. And, a sample ticket of mine[2]. [1] http://bestpractical.com/rt [2] https://rt.cpan.org/Public/Bug/Display.html?id=45040 -- Mike Kelly From tero@tilus.net Tue Nov 3 10:08:00 2009 From: tero@tilus.net (Tero Tilus) Date: Tue, 03 Nov 2009 17:08:00 +0200 Subject: [sup-talk] i18n? In-Reply-To: <1257256976-sup-1266@thinkpad-ubuntu> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1256280223-sup-736@tilus.net> <1257163967-sup-5554@masanjin.net> <1257256976-sup-1266@thinkpad-ubuntu> Message-ID: <1257260315-sup-830@tilus.net> Christopher Bertels, 2009-11-03 16:05: > Should we use gettext then or rely on .yaml files for any additional > translations then? I haven't used gettext yet and from what I > remember it lookes weird, at least the ruby binding did. Maybe it's > very easy though. The l10n backend is an implementation detail. If we really need to we can change backend later down the road if it is decoupled enough from the i18n of sup itself. IMO you get to choose what we start with. And William gets to choose if he accepts the patches or not. ;) -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From wmorgan-sup@masanjin.net Tue Nov 3 10:13:10 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 03 Nov 2009 07:13:10 -0800 Subject: [sup-talk] i18n? In-Reply-To: <1257260315-sup-830@tilus.net> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1256280223-sup-736@tilus.net> <1257163967-sup-5554@masanjin.net> <1257256976-sup-1266@thinkpad-ubuntu> <1257260315-sup-830@tilus.net> Message-ID: <1257261122-sup-5192@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2009-11-03: > IMO you get to choose what we start with. Yeah, Christopher has a working implementation of this already using yaml, and I'm happy to merge it if he changes the keys to strings as discussed. -- William From wmorgan-sup@masanjin.net Tue Nov 3 10:16:15 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 03 Nov 2009 07:16:15 -0800 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <02055f053011496a2dcb9085b7e7535f@localhost> References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net> <02055f053011496a2dcb9085b7e7535f@localhost> Message-ID: <1257261315-sup-977@masanjin.net> Reformatted excerpts from Mike Kelly's message of 2009-11-03: > As much as I hate to suggest it... RT should have all of these > qualities. Rrrrrrrrreally. Is it a pain to set up? Why do you hate to suggest it? (I've heard people complain about it before, but I don't remember any of the details.) -- William From pioto@pioto.org Tue Nov 3 10:34:24 2009 From: pioto@pioto.org (Mike Kelly) Date: Tue, 03 Nov 2009 10:34:24 -0500 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257261315-sup-977@masanjin.net> References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net> <02055f053011496a2dcb9085b7e7535f@localhost> <1257261315-sup-977@masanjin.net> Message-ID: On Tue, 03 Nov 2009 07:16:15 -0800, William Morgan wrote: > Reformatted excerpts from Mike Kelly's message of 2009-11-03: >> As much as I hate to suggest it... RT should have all of these >> qualities. > > Rrrrrrrrreally. Is it a pain to set up? Why do you hate to suggest it? > (I've heard people complain about it before, but I don't remember any of > the details.) Yes, somewhat, IIRC. But, I haven't really ever had to set it up. It's one of those things which requires half of CPAN to work. So, it was annoying when I made an attempt to package it for a distro, but if you're just installing it following their directions, it's probably not that bad. But, someone is able to get away with charging $3250 a month for a "platinum" managed install of it. (Then again, some enterprises will pay anything for hosting...) Let me try a test install real quick, and I'll get back to you. -- Mike Kelly From reid.thompson@ateb.com Tue Nov 3 11:49:53 2009 From: reid.thompson@ateb.com (Reid Thompson) Date: Tue, 3 Nov 2009 11:49:53 -0500 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: Message-ID: <20091103164953.GA20359@ateb.com> On Tue, Nov 03, 2009 at 10:34:24AM -0500, Mike Kelly wrote: > > On Tue, 03 Nov 2009 07:16:15 -0800, William Morgan > wrote: > > Reformatted excerpts from Mike Kelly's message of 2009-11-03: > >> As much as I hate to suggest it... RT should have all of these > >> qualities. > > > > Rrrrrrrrreally. Is it a pain to set up? Why do you hate to suggest it? > > (I've heard people complain about it before, but I don't remember any of > > the details.) > > Yes, somewhat, IIRC. But, I haven't really ever had to set it up. It's one > of those things which requires half of CPAN to work. So, it was annoying > when I made an attempt to package it for a distro, but if you're just > installing it following their directions, it's probably not that bad. > > But, someone is able to get away with charging $3250 a month for a > "platinum" managed install of it. (Then again, some enterprises will pay > anything for hosting...) > > Let me try a test install real quick, and I'll get back to you. I just started looking at it, so not sure if it fits all needs but fossil has a built in bugtracker http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki From reid.thompson@ateb.com Tue Nov 3 12:03:38 2009 From: reid.thompson@ateb.com (Reid Thompson) Date: Tue, 3 Nov 2009 12:03:38 -0500 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <20091103164953.GA20359@ateb.com> References: <20091103164953.GA20359@ateb.com> Message-ID: <20091103170338.GC20359@ateb.com> On Tue, Nov 03, 2009 at 11:49:53AM -0500, Reid Thompson wrote: > On Tue, Nov 03, 2009 at 10:34:24AM -0500, Mike Kelly wrote: > > > > On Tue, 03 Nov 2009 07:16:15 -0800, William Morgan > > wrote: > > > Reformatted excerpts from Mike Kelly's message of 2009-11-03: > > >> As much as I hate to suggest it... RT should have all of these > > >> qualities. > > > > > > Rrrrrrrrreally. Is it a pain to set up? Why do you hate to suggest it? > > > (I've heard people complain about it before, but I don't remember any of > > > the details.) > > > > Yes, somewhat, IIRC. But, I haven't really ever had to set it up. It's one > > of those things which requires half of CPAN to work. So, it was annoying > > when I made an attempt to package it for a distro, but if you're just > > installing it following their directions, it's probably not that bad. > > > > But, someone is able to get away with charging $3250 a month for a > > "platinum" managed install of it. (Then again, some enterprises will pay > > anything for hosting...) > > > > Let me try a test install real quick, and I'll get back to you. > > I just started looking at it, so not sure if it fits all needs but > fossil has a built in bugtracker > > http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki > forgot to mention, it's developed by the same person as sqlite From rlane@club.cc.cmu.edu Tue Nov 3 11:12:11 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Tue, 03 Nov 2009 11:12:11 -0500 Subject: [sup-talk] updated xapian experimental branch In-Reply-To: <1257237468-sup-5663@peray> References: <1257118189-sup-7392@zyrg.net> <1257163403-sup-9032@masanjin.net> <1257196293-sup-6882@zyrg.net> <1257237468-sup-5663@peray> Message-ID: <1257263951-sup-6837@zyrg.net> Excerpts from Nicolas Pouillard's message of Tue Nov 03 03:39:48 -0500 2009: > What are non simple queries which would cause 'red X's to appear? My guess > is that since we cannot change other attributes than the labels, we can > statically know if the thread is still relevant without the label. No? is:inbox OR foo We have to use xapian to check relevance here because of the fulltext term 'foo'. From nicolas.pouillard@gmail.com Tue Nov 3 11:15:23 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Tue, 03 Nov 2009 17:15:23 +0100 Subject: [sup-talk] updated xapian experimental branch In-Reply-To: <1257263951-sup-6837@zyrg.net> References: <1257118189-sup-7392@zyrg.net> <1257163403-sup-9032@masanjin.net> <1257196293-sup-6882@zyrg.net> <1257237468-sup-5663@peray> <1257263951-sup-6837@zyrg.net> Message-ID: <1257264825-sup-7924@peray> Excerpts from Rich Lane's message of Tue Nov 03 17:12:11 +0100 2009: > Excerpts from Nicolas Pouillard's message of Tue Nov 03 03:39:48 -0500 2009: > > What are non simple queries which would cause 'red X's to appear? My guess > > is that since we cannot change other attributes than the labels, we can > > statically know if the thread is still relevant without the label. No? > > is:inbox OR foo > > We have to use xapian to check relevance here because of the fulltext > term 'foo'. Hum... Right. This is because we don't want to look into the fulltext of the threads we have... this does makes sense. -- Nicolas Pouillard http://nicolaspouillard.fr From seschwar@googlemail.com Tue Nov 3 11:20:47 2009 From: seschwar@googlemail.com (Sebastian Schwarz) Date: Tue, 3 Nov 2009 17:20:47 +0100 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257261315-sup-977@masanjin.net> References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net> <02055f053011496a2dcb9085b7e7535f@localhost> <1257261315-sup-977@masanjin.net> Message-ID: <20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de> On 2009-11-03 at 07:16 -0800, William Morgan wrote: > Is it a pain to set up? I have never installed, administered or used RT before, but curiously digging around its homepage I found this: http://bestpractical.com/rt/features.html praises it as "Easy to install". However on http://wiki.bestpractical.com/view/HomePage it says: > RT doesn't come with a formal, formatted users or administrators > guide, but it's likely most of what you need to know to use and run it > is contained somewhere within this wiki, so look around a little, be > patient... and try not to install RT on a Sunday night when you need > to run it in production on Monday: it's big, and learning how to set > it up can take some time. Can anyone with more experience with RT comment on this? Moreover I'd like to advertise/suggest [Roundup][1]. Apart form a slim web interface -- [here][2] Python's issue tracker as an example -- it also offers a fully functional [email interface][3], which allows -- from what I understand -- creating, discussing and setting properties like status and labels of issues. As a note on the ease of installation: Roundup's [documentation on installation][4] begins with: "Set aside 15-30 minutes." But again I have no personal experience to back this claim up. Can anyone comment on this or Roundup in general? [1]: http://roundup.sourceforge.net/ [2]: http://bugs.python.org/ [3]: http://roundup.sourceforge.net/docs/user_guide.html#e-mail-gateway [4]: http://www.roundup-tracker.org/docs/installation.html#installation From mailinglist@flasht.de Tue Nov 3 10:23:52 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Tue, 03 Nov 2009 16:23:52 +0100 Subject: [sup-talk] i18n? In-Reply-To: <1257261122-sup-5192@masanjin.net> References: <1254353101-sup-1021@thinkpad-ubuntu> <1254415145-sup-635@masanjin.net> <1254420802-sup-3742@thinkpad-ubuntu> <1254421405-sup-8083@masanjin.net> <1254442420-sup-3771@thinkpad-ubuntu> <1254487575-sup-5468@thinkpad-ubuntu> <1256280223-sup-736@tilus.net> <1257163967-sup-5554@masanjin.net> <1257256976-sup-1266@thinkpad-ubuntu> <1257260315-sup-830@tilus.net> <1257261122-sup-5192@masanjin.net> Message-ID: <1257261780-sup-4231@thinkpad-ubuntu> Excerpts from William Morgan's message of Di Nov 03 16:13:10 +0100 2009: > Reformatted excerpts from Tero Tilus's message of 2009-11-03: > > IMO you get to choose what we start with. > > Yeah, Christopher has a working implementation of this already using > yaml, and I'm happy to merge it if he changes the keys to strings as > discussed. Alright, I'll change that then and tell you here when I'm done. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 902 bytes Desc: not available URL: From mailinglist@flasht.de Tue Nov 3 11:31:25 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Tue, 03 Nov 2009 17:31:25 +0100 Subject: [sup-talk] Completion for search queries In-Reply-To: <1257177490-sup-4126@masanjin.net> References: <1256199860-sup-4407@thinkpad-ubuntu> <1257177490-sup-4126@masanjin.net> Message-ID: <1257265840-sup-9752@thinkpad-ubuntu> Excerpts from William Morgan's message of Mo Nov 02 16:58:45 +0100 2009: > Reformatted excerpts from Christopher Bertels's message of 2009-10-22: > > Anyone else who would like to have this feature in sup? > > Sounds good to me. Probably wouldn't be too hard since we have a fairly > general tab-completion mechanism in place already. Cool, anyone who knows how & wants to implement this? ;) -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Tue Nov 3 12:16:32 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 03 Nov 2009 09:16:32 -0800 Subject: [sup-talk] [PATCH] detect and set charset on text/* attachments In-Reply-To: <1255961127-sup-3168@tihlde.org> References: <1255961127-sup-3168@tihlde.org> Message-ID: <1257264198-sup-8152@masanjin.net> Reformatted excerpts from Helge Titlestad's message of 2009-10-19: > I got some feedback from non-suppers that my utf-8 text attachments > were messed up. When I checked they (the MIME headers) lacked any info > on charset, which I believe should be set for text/*. After reviewing the RFCs, yeah, I think you're basically right. The charset parameter is not required to be set for text/* mime types, but if it's unset, the part is assumed to be us-ascii. > Here's a patch that uses the chardet gem to (try to) detect the > appropriate charset and sets it in the Content-Type header. Although I don't relish adding yet another gem dependency, I think this is the right approach. It looks like the chardet gem is unmaintained. But someone decided to make their own special version called rchardet which is completely equivalent version but *is* maintained. (What is it with these goddamn ruby people.) I suggest we use rchardet instead of chardet. Would you like to change the patch? If not, I will get to it at some point. > Please tell me if I should use some different way of sending > patches... This git flow is a bit new to me. (= Nope, this is perfect. Thanks! -- William From wmorgan-sup@masanjin.net Tue Nov 3 12:25:29 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 03 Nov 2009 09:25:29 -0800 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de> References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net> <02055f053011496a2dcb9085b7e7535f@localhost> <1257261315-sup-977@masanjin.net> <20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de> Message-ID: <1257268977-sup-4810@masanjin.net> Reformatted excerpts from Sebastian Schwarz's message of 2009-11-03: > Moreover I'd like to advertise/suggest [Roundup][1]. Apart form a slim > web interface -- [here][2] Python's issue tracker as an example -- it > also offers a fully functional [email interface][3], which allows -- > from what I understand -- creating, discussing and setting properties > like status and labels of issues. Nicolas suggested this too. I tried installing it locally (late on a Sunday night, with a screaming infant in my ear) and couldn't get it to behave. But, bugs.python.org looks great, and it looks like they're using email to discuss and change issue state, which is awesome. I'll give it another shot. -- William From wmorgan-sup@masanjin.net Tue Nov 3 12:35:34 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 03 Nov 2009 09:35:34 -0800 Subject: [sup-talk] Completion for search queries In-Reply-To: <1257265840-sup-9752@thinkpad-ubuntu> References: <1256199860-sup-4407@thinkpad-ubuntu> <1257177490-sup-4126@masanjin.net> <1257265840-sup-9752@thinkpad-ubuntu> Message-ID: <1257269366-sup-159@masanjin.net> Reformatted excerpts from Christopher Bertels's message of 2009-11-03: > Cool, anyone who knows how & wants to implement this? ;) If anyone is interested, I would suggest this approach: have each index (Ferret and Xapian) have a method that returns a list of query terms, and then look at how BufferManager#ask_many_emails_with_completions works, and implement something similar called ask_for_search_query or the like. Then have bin/sup circa line 275 call that instead of #ask. -- William From danfalcone@gmail.com Tue Nov 3 12:37:22 2009 From: danfalcone@gmail.com (Dan Falcone) Date: Tue, 3 Nov 2009 13:37:22 -0400 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257268977-sup-4810@masanjin.net> References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net> <02055f053011496a2dcb9085b7e7535f@localhost> <1257261315-sup-977@masanjin.net> <20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de> <1257268977-sup-4810@masanjin.net> Message-ID: Hi all, Thought I'd chime in regarding RT. I've never configured it, but we use it internally where I work, so I can comment on it from a user perspective. I mainly use the email interface, which is very finicky. If you include attachments that are too large, RT will ignore your message and will not attach it to an existing ticket or open a new ticket. Our instance is well known to modify attachments (changing the md5sums), which causes all kinds of problems for us. Maybe this part is user error, but it also sends 2 copies of every message and doesn't always CC everyone on the ticket when it is supposed to. So you either get 2 copies of each email, or zero. Either way it sucks. We have lots of processes in place to work around the issues RT creates for us. Basically the only reason we use it is for archival purposes. Again, I did not install and do not administer this instance, so there could be configuration issues or possibly newer versions that address these shortcomings. However, given my past experience, I wouldn't recommend it. -Dan On Tue, Nov 3, 2009 at 1:25 PM, William Morgan wrote: > Reformatted excerpts from Sebastian Schwarz's message of 2009-11-03: > > Moreover I'd like to advertise/suggest [Roundup][1]. Apart form a slim > > web interface -- [here][2] Python's issue tracker as an example -- it > > also offers a fully functional [email interface][3], which allows -- > > from what I understand -- creating, discussing and setting properties > > like status and labels of issues. > > Nicolas suggested this too. I tried installing it locally (late on a > Sunday night, with a screaming infant in my ear) and couldn't get it to > behave. But, bugs.python.org looks great, and it looks like they're using > email to discuss and change issue state, which is awesome. I'll give it > another shot. > -- > William > _______________________________________________ > sup-talk mailing list > sup-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daemianmack@gmail.com Tue Nov 3 12:03:38 2009 From: daemianmack@gmail.com (Daemian Mack) Date: Tue, 03 Nov 2009 12:03:38 -0500 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de> References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net> <02055f053011496a2dcb9085b7e7535f@localhost> <1257261315-sup-977@masanjin.net> <20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de> Message-ID: <1257266599-sup-1535@lenin> Excerpts from Sebastian Schwarz's message of Tue Nov 03 11:20:47 -0500 2009: > > RT doesn't come with a formal, formatted users or administrators > > guide, but it's likely most of what you need to know to use and run it > > is contained somewhere within this wiki, so look around a little, be > > patient... and try not to install RT on a Sunday night when you need > > to run it in production on Monday: it's big, and learning how to set > > it up can take some time. > > Can anyone with more experience with RT comment on this? Having evaluated RT3 for fairly-intense production use at a prior job, I can't really say I'd recommend it for our use here. As an 'enterprise-ready' solution, it's a bit ungainly out of the box, and the bulk of its feature-set would probably be overkill for sup's needs. It makes heavy use of the 'departmental queue' model whereby many departments, consisting each of many employees, have some permission set for many queues. Customization was a bit opaque (though perhaps less so if you're very familiar with Perl), and though there's an O'Reilly book for RT, I found it often fell short of my needs. I'd suspect, with the glut of ticket-tracker software available, there's something a good deal better-suited for sup out there. I'll chime in again if I manage to find something that seems helpful. -- http://daemianmack.com/ From wmorgan-sup@masanjin.net Tue Nov 3 13:04:26 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 03 Nov 2009 10:04:26 -0800 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <20091103164953.GA20359@ateb.com> References: <20091103164953.GA20359@ateb.com> Message-ID: <1257271383-sup-3116@masanjin.net> Reformatted excerpts from Reid Thompson's message of 2009-11-03: > I just started looking at it, so not sure if it fits all needs but > fossil has a built in bugtracker > > http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki Is it possible to use the bug tracker without keeping all the code in Fossil itself? My impression is no. I'm very happy with git and changing development to a brand new SCM is extremely unlikely to happen at this point. -- William From pioto@pioto.org Tue Nov 3 13:06:52 2009 From: pioto@pioto.org (Mike Kelly) Date: Tue, 03 Nov 2009 13:06:52 -0500 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257266599-sup-1535@lenin> References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net> <02055f053011496a2dcb9085b7e7535f@localhost> <1257261315-sup-977@masanjin.net> <20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de> <1257266599-sup-1535@lenin> Message-ID: <3e1dd7cf334013e45e4e161e3ff512a4@localhost> On Tue, 03 Nov 2009 12:03:38 -0500, Daemian Mack wrote: > Having evaluated RT3 for fairly-intense production use at a prior > job, I can't really say I'd recommend it for our use here. > > I'd suspect, with the glut of ticket-tracker software available, > there's something a good deal better-suited for sup out there. I'll > chime in again if I manage to find something that seems helpful. Yes, feel free to ignore me. It's a pain in the butt to get going. :p On the hopefully-less-sucky front, there's Bugzilla. There is apparently a plugin for it that lets you reply to tickets by email, but I haven't set it up myself. But, I'm a perl guy, so I'm likely highly biased... :) -- Mike Kelly From wmorgan-sup@masanjin.net Tue Nov 3 13:14:37 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 03 Nov 2009 10:14:37 -0800 Subject: [sup-talk] slowly catching up In-Reply-To: <1257146774-sup-9810@tilus.net> References: <1256997213-sup-2725@masanjin.net> <1257146774-sup-9810@tilus.net> Message-ID: <1257272059-sup-9800@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2009-11-01: > Congratulations! Take your time. Your family needs it now. > > I've got two lovely kids, having the first one is a very special > thing. Thanks guys. It's been great so far. -- William From tero@tilus.net Tue Nov 3 13:33:04 2009 From: tero@tilus.net (Tero Tilus) Date: Tue, 03 Nov 2009 20:33:04 +0200 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de> References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net> <02055f053011496a2dcb9085b7e7535f@localhost> <1257261315-sup-977@masanjin.net> <20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de> Message-ID: <1257272880-sup-941@tilus.net> Sebastian Schwarz, 2009-11-03 18:20: > Moreover I'd like to advertise/suggest [Roundup][1]. Now that you mention it, I've used it in couple of projects and liked very much. > As a note on the ease of installation: Roundup's [documentation on > installation][4] begins with: "Set aside 15-30 minutes." But again > I have no personal experience to back this claim up. Can anyone > comment on this or Roundup in general? I've set it up once long time ago and I don't remember anything about it really. Installation was fluent I guess. ;) Another one I like is Redmine, but its whole a lot different kind of tool, nice and fluent tho. It also might do pretty much what we want, but I'd guess Roundup does it with less tuning and pluginnig. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From wmorgan-sup@masanjin.net Tue Nov 3 14:00:39 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 03 Nov 2009 11:00:39 -0800 Subject: [sup-talk] new list: sup-devel Message-ID: <1257272092-sup-9031@masanjin.net> Hi all, I've created a new list for Sup developer discussion. This has been requested a couple times, and I finally think the traffic level warrants it. If you're interested, please subscribe here: http://rubyforge.org/mailman/listinfo/sup-devel I'm not going to be too strict about it, and we can finish up the bug tracker conversation here, but I would like sup-talk to eventually be a place for user questions and discussions, and for future conversations about code, bugs, bug trackers, etc to talk place over there. I'm going to change the bug report email address in 0.9.1 to sup-devel as well. (And hopefully to a URL in 0.10.) -- William From helgedt@tihlde.org Tue Nov 3 14:23:28 2009 From: helgedt@tihlde.org (Helge Titlestad) Date: Tue, 03 Nov 2009 20:23:28 +0100 Subject: [sup-talk] [PATCH] detect and set charset on text/* attachments In-Reply-To: <1257264198-sup-8152@masanjin.net> References: <1255961127-sup-3168@tihlde.org> <1257264198-sup-8152@masanjin.net> Message-ID: <1257275607-sup-583@tihlde.org> Excerpts from William Morgan's message of Tue Nov 03 18:16:32 +0100 2009: > It looks like the chardet gem is unmaintained. But someone decided to > make their own special version called rchardet which is completely > equivalent version but *is* maintained. > > I suggest we use rchardet instead of chardet. Would you like to change > the patch? If not, I will get to it at some point. Here you go! One thing I noticed when trying it out: It will set charset 'ascii' for ascii text, which is allowed by the RFC but "US-ASCII" is preferred. I think I prefer to not create a special case in the code to change it to US-ASCII or remove the charset for ascii text, but other people might disagree. -- alge -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Detect-charset-for-text-file-attachments.patch Type: application/octet-stream Size: 1919 bytes Desc: not available URL: From reid.thompson@ateb.com Tue Nov 3 14:30:23 2009 From: reid.thompson@ateb.com (Reid Thompson) Date: Tue, 03 Nov 2009 14:30:23 -0500 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257271383-sup-3116@masanjin.net> References: <20091103164953.GA20359@ateb.com> <1257271383-sup-3116@masanjin.net> Message-ID: <1257276623.6780.4.camel@raker.ateb.com> On Tue, 2009-11-03 at 10:04 -0800, William Morgan wrote: > Is it possible to use the bug tracker without keeping all the code in > Fossil itself? I just created an empty repository. Contains no source code files. $ fossil new bugtracker-only $ fossil open bugtracker-only $ ls -rlt /tmp/bugtracker-only -rw-r--r-- 1 rthompso staff 50176 2009-11-03 14:23 /tmp/bugtracker-only $ fossil ui did minimal admin/config -> http://localhost:8080/setup_config then added tickets etc, looks like the data entry is free-form, so not tied to a source version existing etc. attached png. -------------- next part -------------- A non-text attachment was scrubbed... Name: TestBugTrackerOnly.png Type: image/png Size: 127986 bytes Desc: not available URL: From jim@gonzul.net Tue Nov 3 18:11:31 2009 From: jim@gonzul.net (Jim Cheetham) Date: Wed, 4 Nov 2009 12:11:31 +1300 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257111816-sup-4397@peray> References: <1257111816-sup-4397@peray> Message-ID: On Mon, Nov 2, 2009 at 10:52 AM, Nicolas Pouillard wrote: > I would like to discuss more the issue of choosing a bug tracker for sup. Having had a quick read of this thread, I think that trac (http://trac.edgewall.com) would meet your goals. It's a simple single-project combination of wiki, ticketing engine and repository browser. Tickets can be received by email, ticket updates can be emailed to a set of interested subscribers, and checkins to the repository can close tickets (via simple hooks). The wiki markup provides simple access to changes, tickets & files. -jim From pioto@pioto.org Tue Nov 3 19:07:24 2009 From: pioto@pioto.org (Mike Kelly) Date: Tue, 3 Nov 2009 19:07:24 -0500 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: References: <1257111816-sup-4397@peray> Message-ID: <20091103190724.1dd5d891@aether.home.pioto.org> On Wed, 4 Nov 2009 12:11:31 +1300 Jim Cheetham wrote: > On Mon, Nov 2, 2009 at 10:52 AM, Nicolas Pouillard > wrote: > > I would like to discuss more the issue of choosing a bug tracker > > for sup. > > Having had a quick read of this thread, I think that trac > (http://trac.edgewall.com) would meet your goals. > > It's a simple single-project combination of wiki, ticketing engine and > repository browser. Tickets can be received by email, ticket updates > can be emailed to a set of interested subscribers, and checkins to the > repository can close tickets (via simple hooks). The wiki markup > provides simple access to changes, tickets & files. Trac doesn't really allow you to reply to tickets by email. At least, not with any plugin that I've used. Also, I've used trac for years for another project, and I wouldn't recommend it. (It's been a memory hog, among other things). -- Mike Kelly From pi+sup@pihost.us Tue Nov 3 22:05:19 2009 From: pi+sup@pihost.us (Anthony Martinez) Date: Tue, 3 Nov 2009 20:05:19 -0700 Subject: [sup-talk] [PATCH] If we have a COLUMNS environment variable, wrap to that instead of 80. Message-ID: <1257303919-30524-1-git-send-email-pi+sup@pihost.us> From: Anthony Martinez I find that this provides a much smoother terminal experience, especially with dumped HTML output. At least on Linux+zsh, this environment variable is automatically updated, and if it doesn't exist, sup will continue to happily default to 80. --- 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 581b707..881ac4b 100644 --- a/lib/sup/message-chunks.rb +++ b/lib/sup/message-chunks.rb @@ -41,7 +41,7 @@ end module Redwood module Chunk - WRAP_LEN = 80 # wrap messages and text attachments at this width + WRAP_LEN = ENV["COLUMNS"] || 80 # wrap messages and text attachments at this width class Attachment HookManager.register "mime-decode", < References: <1257303919-30524-1-git-send-email-pi+sup@pihost.us> Message-ID: <1257304795-sup-5302@home.mrtheplague.net> Excerpts from Anthony Martinez's message of Tue Nov 03 20:05:19 -0700 2009: > I find that this provides a much smoother terminal experience, Or it would if I tested it. Sorry about the bad patch, seems today isn't my day. :) Either way, I'd like to see something like this. Discussion? From pi+sup@pihost.us Tue Nov 3 22:51:46 2009 From: pi+sup@pihost.us (Anthony Martinez) Date: Tue, 03 Nov 2009 20:51:46 -0700 Subject: [sup-talk] [CORRECTED PATCH] If we can get the terminal width, use that for WRAP_LEN. In-Reply-To: <1257303919-30524-1-git-send-email-pi+sup@pihost.us> References: <1257303919-30524-1-git-send-email-pi+sup@pihost.us> Message-ID: <1257306460-sup-1506@home.mrtheplague.net> I find that this provides a much smoother terminal experience, especially with elinks configured to dump to the same size in hook scripts. At least on Linux, "stty size"'s second numerical output is the number of columns, and if that fails somehow, sup will continue to happily default to 80. --- lib/sup/message-chunks.rb | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb index 581b707..56ddf1e 100644 --- a/lib/sup/message-chunks.rb +++ b/lib/sup/message-chunks.rb @@ -41,7 +41,8 @@ end module Redwood module Chunk - WRAP_LEN = 80 # wrap messages and text attachments at this width + TERM_WIDTH = `stty size 2>/dev/null`.split[1].to_i # to_i returns 0 if it fails. + WRAP_LEN = TERM_WIDTH > 0 && TERM_WIDTH || 80 # wrap messages and text attachments at this width class Attachment HookManager.register "mime-decode", < References: <1257303919-30524-1-git-send-email-pi+sup@pihost.us> <1257304795-sup-5302@home.mrtheplague.net> Message-ID: <1257313462-sup-7125@tilus.net> Anthony Martinez, 2009-11-04 05:22: > Either way, I'd like to see something like this. Discussion? Dunno why, but I myself rarely use terms wider (or narrower) than 80 chars. This could be nice for people who do. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From michael+sup@stapelberg.de Wed Nov 4 04:38:20 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Wed, 04 Nov 2009 10:38:20 +0100 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <20091103190724.1dd5d891@aether.home.pioto.org> References: <1257111816-sup-4397@peray> <20091103190724.1dd5d891@aether.home.pioto.org> Message-ID: <1257327410-sup-3421@midna.zekjur.net> Hi, Excerpts from Mike Kelly's message of Mi Nov 04 01:07:24 +0100 2009: > Also, I've used trac for years for another project, and I wouldn't > recommend it. (It's been a memory hog, among other things). I?ve also used trac for quite some time now and I don?t recommend it either. As soon as the spammers find your website, problems start. trac has no built-in possibility to delete a comment/ticket, nor do any of the anti-spam plugins work as they should (either they don?t recognize spam, they have false-positives or they are totally cumbersome for the user). Best regards, Michael From isra@herraiz.org Wed Nov 4 04:44:02 2009 From: isra@herraiz.org (Israel Herraiz) Date: Wed, 04 Nov 2009 10:44:02 +0100 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257327410-sup-3421@midna.zekjur.net> References: <1257111816-sup-4397@peray> <20091103190724.1dd5d891@aether.home.pioto.org> <1257327410-sup-3421@midna.zekjur.net> Message-ID: <1257327692-sup-7174@elly> Excerpts from Michael Stapelberg's message of Wed Nov 04 10:38:20 +0100 2009: > I?ve also used trac for quite some time now and I don?t recommend it > either. As soon as the spammers find your website, problems start. trac > has no built-in possibility to delete a comment/ticket, nor do any of > the anti-spam plugins work as they should (either they don?t recognize > spam, they have false-positives or they are totally cumbersome for the > user). I am not going to recommend Trac, because it does not fulfill the requirements listed by William, but that thing you say is simply not true. I have been using Trac since a couple of years now, and it is sensible to spam, ok, but you can always delete comments, tickets, or anything in general, and force people to register to post comments or tickets, to fight against spam. Cheers, Israel From michael+sup@stapelberg.de Wed Nov 4 05:00:43 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Wed, 04 Nov 2009 11:00:43 +0100 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257327692-sup-7174@elly> References: <1257111816-sup-4397@peray> <20091103190724.1dd5d891@aether.home.pioto.org> <1257327410-sup-3421@midna.zekjur.net> <1257327692-sup-7174@elly> Message-ID: <1257328487-sup-8593@midna.zekjur.net> Hi, Excerpts from Israel Herraiz's message of Mi Nov 04 10:44:02 +0100 2009: > I have been using Trac since a couple of years now, and it is sensible > to spam, ok, but you can always delete comments, tickets, or anything I am referring to trac 0.11.5, which does not have a possibility to delete comments or tickets without installing a third-party plugin (which is hard to use because you have to use ticket IDs). If I am wrong, please tell me where they hid the possibility, so I don?t need the plugin anymore. > in general, and force people to register to post comments or tickets, > to fight against spam. I consider forcing people to register to post comments/tickets as the end of bug reports for my project. I personally would only register at a bugtracker if the bug was *really* important and there would be *no* other possibility to contact the author of the software. However, I want to get every bugreport for my software and thus lower the requirements for users to actually help me improve my software by submitting bugreports. Best regards, Michael From isra@herraiz.org Wed Nov 4 05:05:45 2009 From: isra@herraiz.org (Israel Herraiz) Date: Wed, 04 Nov 2009 11:05:45 +0100 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257328487-sup-8593@midna.zekjur.net> References: <1257111816-sup-4397@peray> <20091103190724.1dd5d891@aether.home.pioto.org> <1257327410-sup-3421@midna.zekjur.net> <1257327692-sup-7174@elly> <1257328487-sup-8593@midna.zekjur.net> Message-ID: <1257328897-sup-4720@elly> Excerpts from Michael Stapelberg's message of Wed Nov 04 11:00:43 +0100 2009: > I am referring to trac 0.11.5, which does not have a possibility to delete > comments or tickets without installing a third-party plugin (which is > hard to use because you have to use ticket IDs). If I am wrong, please tell me > where they hid the possibility, so I don?t need the plugin anymore. Check the *_ADMIN permissions. Any user with say TICKET_ADMIN permission can remove tickets. Same applies to WIKI_ADMIN (remove wiki pages), etc. > I consider forcing people to register to post comments/tickets as the end of > bug reports for my project. I personally would only register at a bugtracker if > the bug was *really* important and there would be *no* other possibility to > contact the author of the software. However, I want to get every bugreport for > my software and thus lower the requirements for users to actually help me > improve my software by submitting bugreports. Right. It is not the best elegant solution at all. Cheers, Israel From marka@pobox.com Wed Nov 4 14:06:01 2009 From: marka@pobox.com (Mark Alexander) Date: Wed, 04 Nov 2009 14:06:01 -0500 Subject: [sup-talk] [PATCH] If we have a COLUMNS environment variable, wrap to that instead of 80. In-Reply-To: <1257303919-30524-1-git-send-email-pi+sup@pihost.us> References: <1257303919-30524-1-git-send-email-pi+sup@pihost.us> Message-ID: <1257361498-sup-7950@r50p> Excerpts from Anthony Martinez's message of Tue Nov 03 22:05:19 -0500 2009: > + WRAP_LEN = ENV["COLUMNS"] || 80 # wrap messages and text attachments at this width How about using Ncurses.cols? That's what I did in a similar patch on my copy of sup. From isra@herraiz.org Wed Nov 4 18:40:22 2009 From: isra@herraiz.org (Israel Herraiz) Date: Thu, 05 Nov 2009 00:40:22 +0100 Subject: [sup-talk] Choosing a bug tracker for Sup In-Reply-To: <1257328897-sup-4720@elly> References: <1257111816-sup-4397@peray> <20091103190724.1dd5d891@aether.home.pioto.org> <1257327410-sup-3421@midna.zekjur.net> <1257327692-sup-7174@elly> <1257328487-sup-8593@midna.zekjur.net> <1257328897-sup-4720@elly> Message-ID: <1257377988-sup-7526@elly> Excerpts from Israel Herraiz's message of Wed Nov 04 11:05:45 +0100 2009: > Check the *_ADMIN permissions. Any user with say TICKET_ADMIN > permission can remove tickets. Same applies to WIKI_ADMIN (remove wiki > pages), etc. I am afraid I am wrong with this. Tickets can only be deleted by manipulating the database. So Michael was right. Sorry for the noise. Israel From rlane@club.cc.cmu.edu Thu Nov 5 00:45:18 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 4 Nov 2009 21:45:18 -0800 Subject: [sup-talk] [PATCH 1/4] factor saving out of thread/message classes Message-ID: <1257399921-26813-1-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/index.rb | 7 +++++++ lib/sup/message.rb | 5 +---- lib/sup/modes/thread-index-mode.rb | 2 +- lib/sup/thread.rb | 2 +- 4 files changed, 10 insertions(+), 6 deletions(-) diff --git a/lib/sup/index.rb b/lib/sup/index.rb index ff03f19..5d8d714 100644 --- a/lib/sup/index.rb +++ b/lib/sup/index.rb @@ -172,6 +172,13 @@ class BaseIndex def parse_query s unimplemented end + + def save_thread t + t.each_dirty_message do |m| + update_message_state m + m.clear_dirty + end + end end index_name = ENV['SUP_INDEX'] || $config[:index] || DEFAULT_INDEX diff --git a/lib/sup/message.rb b/lib/sup/message.rb index a147c42..95ae050 100644 --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -182,11 +182,8 @@ class Message ## don't tempt me. def sanitize_message_id mid; mid.gsub(/(\s|[^\000-\177])+/, "")[0..254] end - def save_state index - return unless @dirty - index.update_message_state self + def clear_dirty @dirty = false - true end def has_label? t; @labels.member? t; end diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index 12a76f9..370903a 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -477,7 +477,7 @@ EOS BufferManager.say("Saving threads...") do |say_id| dirty_threads.each_with_index do |t, i| BufferManager.say "Saving modified thread #{i + 1} of #{dirty_threads.length}...", say_id - t.save_state Index + Index.save_thread t end end end diff --git a/lib/sup/thread.rb b/lib/sup/thread.rb index 2300305..3fdf1f6 100644 --- a/lib/sup/thread.rb +++ b/lib/sup/thread.rb @@ -112,7 +112,7 @@ class Thread def set_labels l; each { |m, *o| m && m.labels = l }; end def has_label? t; any? { |m, *o| m && m.has_label?(t) }; end - def save_state index; each { |m, *o| m && m.save_state(index) }; end + def each_dirty_message; each { |m, *o| m && m.dirty? && yield(m) }; end def direct_participants map { |m, *o| [m.from] + m.to if m }.flatten.compact.uniq -- 1.6.4.2 From rlane@club.cc.cmu.edu Thu Nov 5 00:45:19 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 4 Nov 2009 21:45:19 -0800 Subject: [sup-talk] [PATCH 2/4] async thread indexing In-Reply-To: <1257399921-26813-1-git-send-email-rlane@club.cc.cmu.edu> References: <1257399921-26813-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1257399921-26813-2-git-send-email-rlane@club.cc.cmu.edu> --- bin/sup | 2 ++ lib/sup/index.rb | 26 +++++++++++++++++++++++++- lib/sup/modes/thread-index-mode.rb | 2 +- 3 files changed, 28 insertions(+), 2 deletions(-) diff --git a/bin/sup b/bin/sup index 78c396a..910ff12 100755 --- a/bin/sup +++ b/bin/sup @@ -142,6 +142,7 @@ Index.lock_interactively or exit begin Redwood::start Index.load + Index.start_sync_worker unless $opts[:no_threads] $die = false trap("TERM") { |x| $die = true } @@ -335,6 +336,7 @@ ensure HookManager.run "shutdown" + Index.stop_sync_worker Redwood::finish stop_cursing Redwood::Logger.remove_all_sinks! diff --git a/lib/sup/index.rb b/lib/sup/index.rb index 5d8d714..1131ec7 100644 --- a/lib/sup/index.rb +++ b/lib/sup/index.rb @@ -28,6 +28,8 @@ class BaseIndex def initialize dir=BASE_DIR @dir = dir @lock = Lockfile.new lockfile, :retries => 0, :max_age => nil + @sync_worker = nil + @sync_queue = Queue.new end def lockfile; File.join @dir, "lock" end @@ -175,10 +177,32 @@ class BaseIndex def save_thread t t.each_dirty_message do |m| - update_message_state m + if @sync_worker + @sync_queue << m + else + update_message_state m + end m.clear_dirty end end + + def start_sync_worker + @sync_worker = Redwood::reporting_thread('index sync') { run_sync_worker } + end + + def stop_sync_worker + return unless worker = @sync_worker + @sync_worker = nil + @sync_queue << :die + worker.join + end + + def run_sync_worker + while m = @sync_queue.deq + return if m == :die + update_message_state m + end + end end index_name = ENV['SUP_INDEX'] || $config[:index] || DEFAULT_INDEX diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index 370903a..d2b1651 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -477,7 +477,7 @@ EOS BufferManager.say("Saving threads...") do |say_id| dirty_threads.each_with_index do |t, i| BufferManager.say "Saving modified thread #{i + 1} of #{dirty_threads.length}...", say_id - Index.save_thread t + Index.save_thread_async t end end end -- 1.6.4.2 From rlane@club.cc.cmu.edu Thu Nov 5 00:45:20 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 4 Nov 2009 21:45:20 -0800 Subject: [sup-talk] [PATCH 3/4] immediate thread indexing In-Reply-To: <1257399921-26813-2-git-send-email-rlane@club.cc.cmu.edu> References: <1257399921-26813-1-git-send-email-rlane@club.cc.cmu.edu> <1257399921-26813-2-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1257399921-26813-3-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/modes/inbox-mode.rb | 4 +++ lib/sup/modes/thread-index-mode.rb | 40 +++++++++++++---------------------- lib/sup/modes/thread-view-mode.rb | 7 ++++++ 3 files changed, 26 insertions(+), 25 deletions(-) diff --git a/lib/sup/modes/inbox-mode.rb b/lib/sup/modes/inbox-mode.rb index 6c2244a..ad3a864 100644 --- a/lib/sup/modes/inbox-mode.rb +++ b/lib/sup/modes/inbox-mode.rb @@ -42,6 +42,7 @@ class InboxMode < ThreadIndexMode cursor_thread.remove_label :inbox hide_thread cursor_thread regen_text + Index.save_thread thread end def multi_archive threads @@ -58,6 +59,7 @@ class InboxMode < ThreadIndexMode hide_thread t end regen_text + threads.each { |t| Index.save_thread t } end def read_and_archive @@ -74,6 +76,7 @@ class InboxMode < ThreadIndexMode cursor_thread.remove_label :inbox hide_thread cursor_thread regen_text + Index.save_thread thread end def multi_read_and_archive threads @@ -94,6 +97,7 @@ class InboxMode < ThreadIndexMode regen_text end + threads.each { |t| Index.save_thread t } end def handle_unarchived_update sender, m diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index d2b1651..bf3f646 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -37,7 +37,6 @@ EOS k.add :toggle_spam, "Mark/unmark thread as spam", 'S' k.add :toggle_deleted, "Delete/undelete thread", 'd' k.add :kill, "Kill thread (never to be seen in inbox again)", '&' - 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' @@ -269,12 +268,14 @@ EOS UndoManager.register "toggling thread starred status", undo update_text_for_line curpos cursor_down + Index.save_thread t end def multi_toggle_starred threads UndoManager.register "toggling #{threads.size.pluralize 'thread'} starred status", threads.map { |t| actually_toggle_starred t } regen_text + threads.each { |t| Index.save_thread t } end ## returns an undo lambda @@ -352,12 +353,14 @@ EOS undo = actually_toggle_archived t UndoManager.register "deleting/undeleting thread #{t.first.id}", undo, lambda { update_text_for_line curpos } update_text_for_line curpos + Index.save_thread t end def multi_toggle_archived threads undos = threads.map { |t| actually_toggle_archived t } UndoManager.register "deleting/undeleting #{threads.size.pluralize 'thread'}", undos, lambda { regen_text } regen_text + threads.each { |t| Index.save_thread t } end def toggle_new @@ -365,11 +368,13 @@ EOS t.toggle_label :unread update_text_for_line curpos cursor_down + Index.save_thread t end def multi_toggle_new threads threads.each { |t| t.toggle_label :unread } regen_text + threads.each { |t| Index.save_thread t } end def multi_toggle_tagged threads @@ -385,6 +390,7 @@ EOS def multi_join_threads threads @ts.join_threads threads or return + threads.each { |t| Index.save_thread t } @tags.drop_all_tags # otherwise we have tag pointers to invalid threads! update end @@ -421,6 +427,7 @@ EOS UndoManager.register "marking/unmarking #{threads.size.pluralize 'thread'} as spam", undos, lambda { regen_text } regen_text + threads.each { Index.save_thread async t } end def toggle_deleted @@ -434,6 +441,7 @@ EOS UndoManager.register "deleting/undeleting #{threads.size.pluralize 'thread'}", undos, lambda { regen_text } regen_text + threads.each { Index.save_thread async t } end def kill @@ -458,29 +466,7 @@ EOS regen_text BufferManager.flash "#{threads.size.pluralize 'thread'} killed." - end - - def save background=true - if background - Redwood::reporting_thread("saving thread") { actually_save } - else - actually_save - end - end - - def actually_save - @save_thread_mutex.synchronize do - BufferManager.say("Saving contacts...") { ContactManager.instance.save } - dirty_threads = @mutex.synchronize { (@threads + @hidden_threads.keys).select { |t| t.dirty? } } - next if dirty_threads.empty? - - BufferManager.say("Saving threads...") do |say_id| - dirty_threads.each_with_index do |t, i| - BufferManager.say "Saving modified thread #{i + 1} of #{dirty_threads.length}...", say_id - Index.save_thread_async t - end - end - end + threads.each { |t| Index.save_thread async t } end def cleanup @@ -492,7 +478,8 @@ EOS sleep 0.1 # TODO: necessary? BufferManager.erase_flash end - save false + dirty_threads = @mutex.synchronize { (@threads + @hidden_threads.keys).select { |t| t.dirty? } } + fail "dirty threads remain" unless dirty_threads.empty? super end @@ -546,6 +533,7 @@ EOS end UpdateManager.relay self, :labeled, thread.first + Index.save_thread thread end def multi_edit_labels threads @@ -582,6 +570,8 @@ EOS end regen_text end + + threads.each { |t| Index.save_thread t } end def reply type_arg=nil diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index 2da0555..e59112e 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -132,6 +132,7 @@ EOS @layout[earliest].state = :detailed if earliest.has_label?(:unread) || @thread.size == 1 @thread.remove_label :unread + Index.save_thread @thread regen_text end @@ -263,6 +264,7 @@ EOS new_labels.each { |l| LabelManager << l } update UpdateManager.relay self, :labeled, @thread.first + Index.save_thread @thread end def toggle_starred @@ -285,6 +287,7 @@ EOS ## star to the display update UpdateManager.relay self, :single_message_labeled, m + Index.save_thread @thread end ## called when someone presses enter when the cursor is highlighting @@ -503,6 +506,7 @@ EOS dispatch op do @thread.remove_label :inbox UpdateManager.relay self, :archived, @thread.first + Index.save_thread @thread end end @@ -510,6 +514,7 @@ EOS dispatch op do @thread.apply_label :spam UpdateManager.relay self, :spammed, @thread.first + Index.save_thread @thread end end @@ -517,6 +522,7 @@ EOS dispatch op do @thread.apply_label :deleted UpdateManager.relay self, :deleted, @thread.first + Index.save_thread @thread end end @@ -524,6 +530,7 @@ EOS dispatch op do @thread.apply_label :unread UpdateManager.relay self, :unread, @thread.first + Index.save_thread @thread end end -- 1.6.4.2 From rlane@club.cc.cmu.edu Thu Nov 5 00:45:21 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 4 Nov 2009 21:45:21 -0800 Subject: [sup-talk] [PATCH 4/4] force the index sync thread to give up the cpu In-Reply-To: <1257399921-26813-3-git-send-email-rlane@club.cc.cmu.edu> References: <1257399921-26813-1-git-send-email-rlane@club.cc.cmu.edu> <1257399921-26813-2-git-send-email-rlane@club.cc.cmu.edu> <1257399921-26813-3-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1257399921-26813-4-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/index.rb | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/lib/sup/index.rb b/lib/sup/index.rb index 1131ec7..4f491d6 100644 --- a/lib/sup/index.rb +++ b/lib/sup/index.rb @@ -201,6 +201,8 @@ class BaseIndex while m = @sync_queue.deq return if m == :die update_message_state m + # Necessary to keep Xapian calls from lagging the UI too much. + sleep 0.03 end end end -- 1.6.4.2 From matthias.guedemann@ovgu.de Thu Nov 5 03:27:25 2009 From: matthias.guedemann@ovgu.de (Matthias Guedemann) Date: Thu, 05 Nov 2009 09:27:25 +0100 Subject: [sup-talk] Problems with undo archive and thread focus Message-ID: <1257409101-sup-7780@pc44es141.cs.uni-magdeburg.de> Hi, while using sup for a while now I came across surprising behavior in the following situations. One is, if you hit 'a' in thread view mode, the thread is archived but undo does not work. If you go back to index view and hit 'u' the just archived thread does not appear, but the one before. The second is, if I respond to a thread and send the mail, I normally want to either archive that mail directly or label and archive it. But the thread is put to the front and the focus is on the last place of the thread. Therefore I sometimes archive the wrong thread (but undo comes in handy) The first seems to be a bug, the second may be a problem only for me. best regards, Matthias -- __________________________________________________________ ___ __ __ Dipl. Inf. Matthias Guedemann / __\/ _\ /__\ Computer Systems in Engineering / / \ \ /_\ Otto-von-Guericke Universitaet Magdeburg / /___ _\ \//__ Tel.: 0391 / 67-19359 \____/ \__/\__/ __________________________________________________________ From markr.anderson@amd.com Thu Nov 5 15:29:23 2009 From: markr.anderson@amd.com (Mark Anderson) Date: Thu, 5 Nov 2009 13:29:23 -0700 Subject: [sup-talk] Sup-sync exception Message-ID: <1257452860-sup-7983@testarossa> I have an offlineimap synced IMAP Maildir area, and for some reason I get an error when I try to run sup-sync. Any ideas? -Mark 144> sup-sync /home/manderso/src/sup-git/mainline/lib/sup/util.rb:9: warning: method redefined; discarding old gen_lock_id /home/manderso/src/sup-git/mainline/lib/sup/util.rb:20: warning: method redefined; discarding old dump_lock_id [Thu Nov 05 13:25:38 -0700 2009] WARNING: can't find character set by using locale, defaulting to utf-8 /home/manderso/src/sup-git/mainline/lib/sup/message-chunks.rb:36: warning: method redefined; discarding old make_tmpname /home/manderso/src/sup-git/mainline/lib/sup/imap.rb:119: warning: ambiguous first argument; put parentheses or even spaces [Thu Nov 05 13:25:39 -0700 2009] using index Redwood::FerretIndex /home/manderso/src/sup-git/mainline/bin/sup-sync:11: warning: method redefined; discarding old to_s [Thu Nov 05 13:25:40 -0700 2009] crypto: detected gpg binary in /usr/bin/gpg [Thu Nov 05 13:25:40 -0700 2009] locking /home/manderso/.sup/lock... [Thu Nov 05 13:25:40 -0700 2009] loading index... [Thu Nov 05 13:25:40 -0700 2009] loaded index of 3830 messages [Thu Nov 05 13:25:40 -0700 2009] scanning maildir /home/manderso/MailExchange/INBOX... [Thu Nov 05 13:25:42 -0700 2009] done scanning maildir Scanning maildir:/home/manderso/MailExchange/INBOX... [Thu Nov 05 13:25:42 -0700 2009] unlocking /home/manderso/.sup/lock... /home/manderso/src/sup-git/mainline/lib/sup/buffer.rb:15:in `cols': undefined local variable or method `stdscr' for Ncurses:Module (NameError) from /home/manderso/src/sup-git/mainline/lib/sup/message-chunks.rb:165:in `initialize' from /home/manderso/src/sup-git/mainline/lib/sup/message-chunks.rb:165:in `map' from /home/manderso/src/sup-git/mainline/lib/sup/message-chunks.rb:165:in `initialize' from /home/manderso/src/sup-git/mainline/lib/sup/message.rb:591:in `new' from /home/manderso/src/sup-git/mainline/lib/sup/message.rb:591:in `text_to_chunks' from /home/manderso/src/sup-git/mainline/lib/sup/message.rb:511:in `message_to_chunks' from /home/manderso/src/sup-git/mainline/lib/sup/message.rb:239:in `load_from_source!' from /home/manderso/src/sup-git/mainline/lib/sup/message.rb:335:in `build_from_source' from /home/manderso/src/sup-git/mainline/lib/sup/poll.rb:145:in `each_message_from' from /home/manderso/src/sup-git/mainline/lib/sup/maildir.rb:160:in `each' from /home/manderso/src/sup-git/mainline/lib/sup/maildir.rb:157:in `upto' from /home/manderso/src/sup-git/mainline/lib/sup/maildir.rb:157:in `each' from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:560:in `send' from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:560:in `__pass' from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:547:in `method_missing' from /home/manderso/src/sup-git/mainline/lib/sup/poll.rb:139:in `each_message_from' from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:520:in `send' from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:520:in `method_missing' from /home/manderso/src/sup-git/mainline/bin/sup-sync:146 from /home/manderso/src/sup-git/mainline/bin/sup-sync:141:in `each' from /home/manderso/src/sup-git/mainline/bin/sup-sync:141 From garoth@gmail.com Thu Nov 5 20:58:27 2009 From: garoth@gmail.com (Andrei Thorp) Date: Thu, 5 Nov 2009 20:58:27 -0500 Subject: [sup-talk] Arch Linux Sup Package (Ruby 1.9.1 + Sup 0.9) In-Reply-To: <1257092475-sup-4321@masanjin.net> References: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com> <1257092475-sup-4321@masanjin.net> Message-ID: <80055d7c0911051758p815b66eu722ebb15993b7f0d@mail.gmail.com> Sorry, William. I've been busy and haven't monitered the list. I'll probably set up a proper mail system tonight so I don't screw this up again. > Reformatted excerpts from Andrei Thorp's message of 2009-10-18: >> ?- I've applyed Lloyd's patch for fixing the UTF-8 check. > > Which patch was this? The only "Lloyd patch" one I'm aware of is: > http://github.com/lloyd/sup/commit/d07986419b87053b41f7ed4bd7b6d1e537704864 No, that's not it... the patch that I applied is http://aur.archlinux.org/packages/sup/sup/fix-utf8-hack.patch. At least' that's my copy of it that I uploaded to the AUR. I'm assuming that Lloyd still has this in his repos somewhere. I'm not sure this patch is strictly necessary, but at the time I was under the impression that it seemed reasonable. Admittedly, I'm not a great Ruby programmer. Ah, here it is. http://github.com/lloyd/sup/commit/e32c48c4abfb921c60d337354634cd905f7e9149 >> The error up there doesn't really make sense. Each not defined on >> buffer strings? > >It makes sense to me. There's no String#each in Ruby 1.9, so this is >probably a (trivially fixable) bug in the lockfile gem for 1.9. I'm still not sure why this bug doesn't happen for me. Oh wait! Discovery! Sean left a comment on my AUR page stating, "It was just a stale lock file. removed ~/.sup/lock and it started up nicely." So never mind that, lockfile's fine in 1.9. As for trying things like ,n, I'll give it a whirl tonight. I need to set up my mail... I've been busy/putting it off :). Cheers! -Andrei Thorp From garoth@gmail.com Thu Nov 5 21:34:31 2009 From: garoth@gmail.com (Andrei Thorp) Date: Thu, 5 Nov 2009 21:34:31 -0500 Subject: [sup-talk] [Ruby 1.9] sup-sync error Message-ID: <80055d7c0911051834u4c08786aiecc37fcdb77d75b5@mail.gmail.com> Looks like another one of those simple to fix but annoying sup errors: /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/source.rb:88:in `done?': undefined method `>=' for true:TrueClass (NoMethodError) from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:560:in `__pass' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:547:in `method_missing' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:137:in `each_message_from' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:146:in `block in ' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `each' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `' from /usr/bin/supbin/sup-sync:19:in `load' from /usr/bin/supbin/sup-sync:19:in `
' This occurs when attempting to import mail from Maildirs From garoth@gmail.com Thu Nov 5 21:38:26 2009 From: garoth@gmail.com (Andrei Thorp) Date: Thu, 5 Nov 2009 21:38:26 -0500 Subject: [sup-talk] slowly catching up In-Reply-To: <1256997213-sup-2725@masanjin.net> References: <1256997213-sup-2725@masanjin.net> Message-ID: <80055d7c0911051838m855262bi93d149549de2da8c@mail.gmail.com> On Sat, Oct 31, 2009 at 9:03 AM, William Morgan wrote: > Suggestions welcome. I propose promoting Rich Lane to commiter if he's up for it and doesn't have access yet. From what I can tell, he's done a terrific job thus far, and has a lot of experience with Sup. -AT From rlane@club.cc.cmu.edu Thu Nov 5 23:13:05 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 05 Nov 2009 23:13:05 -0500 Subject: [sup-talk] slowly catching up In-Reply-To: <80055d7c0911051838m855262bi93d149549de2da8c@mail.gmail.com> References: <1256997213-sup-2725@masanjin.net> <80055d7c0911051838m855262bi93d149549de2da8c@mail.gmail.com> Message-ID: <1257476207-sup-3459@zyrg.net> Excerpts from Andrei Thorp's message of Thu Nov 05 21:38:26 -0500 2009: > On Sat, Oct 31, 2009 at 9:03 AM, William Morgan > wrote: > > Suggestions welcome. > > I propose promoting Rich Lane to commiter if he's up for it and > doesn't have access yet. From what I can tell, he's done a terrific > job thus far, and has a lot of experience with Sup. Thanks! If William doesn't have the free time, I would be glad to help out. Rather than committing directly to mainline, I'd rather keep a public repo that I apply incoming patches to and that William can pull from. This way I could do a lot of the first-line work and he could get a more stable flow of patches to make releases from. For my own process suggestion: I can imagine that a lot of William's work caused by being the central repository is reviewing the patches that get sent in. I'd like for anyone who feels interested to read through incoming patches and comment on them. I don't want any strict processes just yet, but I'd like to see a couple of positive reviews (depending on the complexity of the patch, etc) before things get merged. Distributing the workload and ensuring code quality are only a couple of my motives here. I know I feel more comfortable sending out a patch if I'm sure someone will catch my mistakes before it's merged. Also, it's a great way for people who aren't yet familiar with the codebase to start contributing. If anyone's interested and wants to get started right away, definitely take a look at the immediate-updates patches I sent in yesterday. From wmorgan-sup@masanjin.net Fri Nov 6 08:47:51 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 06 Nov 2009 05:47:51 -0800 Subject: [sup-talk] slowly catching up In-Reply-To: <1257476207-sup-3459@zyrg.net> References: <1256997213-sup-2725@masanjin.net> <80055d7c0911051838m855262bi93d149549de2da8c@mail.gmail.com> <1257476207-sup-3459@zyrg.net> Message-ID: <1257509523-sup-3428@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-11-05: > Rather than committing directly to mainline, I'd rather keep a public > repo that I apply incoming patches to and that William can pull from. > This way I could do a lot of the first-line work and he could get a > more stable flow of patches to make releases from. That sounds good to me. I'm happy to add you to the gitorious repo, of course, but this is definitely more in line with the git lifestyle. We have a couple options on how to organize this, but I think the best would be for you to maintain one or more branches that I treat as integration branches, and periodically merge into master whenever you tell me they're ready. That's a very minimal amount of work for me. I can just merge it and forget it. The only things to be careful about in such a setup are not merging next into your branch (merging master in is fine and good to keep up with other stable changes), and not rebasing. And we will have to coordinate on releases, if nothing else so that I can make reasonable changelogs and release notes. How does that sound? > I can imagine that a lot of William's work caused by being the central > repository is reviewing the patches that get sent in. I'd like for > anyone who feels interested to read through incoming patches and comment > on them. I don't want any strict processes just yet, but I'd like to see > a couple of positive reviews (depending on the complexity of the patch, > etc) before things get merged. That would be great. Or heck, even an "I applied it and it works for me" is useful. -- William From rick.tessner@gmail.com Fri Nov 6 10:13:19 2009 From: rick.tessner@gmail.com (rick.tessner) Date: Fri, 06 Nov 2009 07:13:19 -0800 Subject: [sup-talk] Sup-sync exception In-Reply-To: <1257452860-sup-7983@testarossa> References: <1257452860-sup-7983@testarossa> Message-ID: <1257520288-sup-8595@onnadayr.ca> Hi, Excerpts from Mark Anderson's message of Thu Nov 05 12:29:23 -0800 2009: > > I have an offlineimap synced IMAP Maildir area, and for some reason I get an error when I try to run > sup-sync. I had that exact same thing. If you applied a patch that used Ncurses.cols rather than WRAP_LEN to determine screen width, you'll have that problem in the non-curses based sup applications. The patch came from an email with the subject [PATCH] Use terminal width instead of hardcoded 80 as the wrap length. I initially didn't have any problems whatsoever with that patch until I ran sup-sync. I fixed it with the attached commit. This patch just does a rescue on that call. The patch is only applicable if you had applied a patch that came through previously on this list for using Ncurses.cols rather than WRAP_LEN in lib/sup/message-chunks.rb -- Rick Tessner rick.tessner at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Corrects-Use-terminal-width-instead-of-hardcoded-80-.patch Type: application/octet-stream Size: 1637 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Fri Nov 6 11:33:03 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 06 Nov 2009 08:33:03 -0800 Subject: [sup-talk] sup bug tracker Message-ID: <1257524700-sup-9112@masanjin.net> Hi all, I've put a slightly modified Roundup installation here for tracking Sup bugs: http://masanjin.net/sup-bugs/ Please use this to submit your bug reports and feature requests. If you have existing bug reports or feature requests and you don't want to rely on my faulty memory any more, feel free to resubmit them here. You should be able to create new issues without having to register. However, if you want to receive email about an issue when updates happen, you will have to register. Sorry! On the plus side, registration is super quick because I've disabled the email confirmation step. If anyone has written Roundup detectors in the past, let me know. There are a couple things I'd like to tweak. I'm going to point the 0.9.1 crash message there too. -- William From markr.anderson@amd.com Fri Nov 6 15:06:17 2009 From: markr.anderson@amd.com (Mark Anderson) Date: Fri, 6 Nov 2009 13:06:17 -0700 Subject: [sup-talk] Sup-sync exception In-Reply-To: <1257520288-sup-8595@onnadayr.ca> References: <1257452860-sup-7983@testarossa> <1257520288-sup-8595@onnadayr.ca> Message-ID: <1257537789-sup-1961@testarossa> Excerpts from rick.tessner's message of Fri Nov 06 08:13:19 -0700 2009: > I had that exact same thing. If you applied a patch that used > Ncurses.cols rather than WRAP_LEN to determine screen width, you'll have > that problem in the non-curses based sup applications. > > The patch came from an email with the subject > > [PATCH] Use terminal width instead of hardcoded 80 as the wrap length. I had applied that previous patch, as you guessed. There was another patch that is complementary in getting the console to recognize the width of the terminal, I forget the tname, but here's what I have in my message-chunks.rb: TERM_WIDTH = `stty size 2>/dev/null`.split[1].to_i # to_i returns 0 if it fails WRAP_LEN = TERM_WIDTH > 0 && TERM_WIDTH || 80 # wrap messages and text attachments at this width I don't know why that patch preferred `stty` to ENV["COLUMNS"], since that one had worked for me. > I initially didn't have any problems whatsoever with that patch until I ran > sup-sync. I fixed it with the attached commit. > > This patch just does a rescue on that call. The patch is only > applicable if you had applied a patch that came through previously on > this list for using Ncurses.cols rather than WRAP_LEN in > lib/sup/message-chunks.rb Thanks, it is much happier now. -Mark From pi+sup@pihost.us Fri Nov 6 21:16:42 2009 From: pi+sup@pihost.us (Anthony Martinez) Date: Fri, 06 Nov 2009 19:16:42 -0700 Subject: [sup-talk] Sup-sync exception In-Reply-To: <1257537789-sup-1961@testarossa> References: <1257452860-sup-7983@testarossa> <1257520288-sup-8595@onnadayr.ca> <1257537789-sup-1961@testarossa> Message-ID: <1257556260-sup-1272@home.mrtheplague.net> Excerpts from Mark Anderson's message of Fri Nov 06 13:06:17 -0700 2009: > There was another patch that is complementary in getting the console to > recognize the width of the terminal, I forget the tname, but here's what I > have in my message-chunks.rb: > > TERM_WIDTH = `stty size 2>/dev/null`.split[1].to_i # to_i returns 0 if it fails > WRAP_LEN = TERM_WIDTH > 0 && TERM_WIDTH || 80 # wrap messages and text attachments at this width > > I don't know why that patch preferred `stty` to ENV["COLUMNS"], since that one > had worked for me. That'd be my patch. I used stty because ENV["COLUMNS"] doesn't consistently work for me: $ echo $COLUMNS 132 $ perl -wE 'say $ENV{COLUMNS}' Use of uninitialized value in say at -e line 1. $ ruby -e 'puts ENV["COLUMNS"]' nil $ irb irb(main):001:0> ENV["COLUMNS"] => "132" In Sup's console mode, ENV["COLUMNS"] is set, but when I tried WRAP_LEN = ENV["COLUMNS"] in message-chunks.rb, it gets nil. It appears to have something to do with readline: $ irb --noreadline irb(main):001:0> ENV["COLUMNS"] => nil I also tried Ncurses.cols, as suggested on sup-devel, and got a similar exception to yours. `stty`, albeit cheesy, works well enough for right now (even though I'm not quite happy with it, since, in addition to its reliance on the output of an external command, it also won't react to window size changes) Perhaps this should be a configuration option -- give it a number to wrap to that width, :auto to wrap to the terminal size (in some fashion that will allow it to resize when the terminal does), and in the absence of any configuration, 80. -- Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work. From garoth@gmail.com Fri Nov 6 22:22:28 2009 From: garoth@gmail.com (Andrei Thorp) Date: Fri, 6 Nov 2009 22:22:28 -0500 Subject: [sup-talk] Ruby 1.9: encodings Message-ID: <80055d7c0911061922w64ef7cb0qf0c7bed008cc728c@mail.gmail.com> Eh, bad news. So I've been testing Sup in an 1.9 environment further, and I have found that there are a great deal of problems with regards to encodings. "invalid byte sequence in US-ASCII" is something you'll see frequently. This seems to be when parsing messages that have non-ascii chararacters. Ouch :( Has this already been taken care of in the git somewhere? -AT From marka@pobox.com Fri Nov 6 23:10:33 2009 From: marka@pobox.com (Mark Alexander) Date: Fri, 06 Nov 2009 23:10:33 -0500 Subject: [sup-talk] Sup-sync exception In-Reply-To: <1257556260-sup-1272@home.mrtheplague.net> References: <1257452860-sup-7983@testarossa> <1257520288-sup-8595@onnadayr.ca> <1257537789-sup-1961@testarossa> <1257556260-sup-1272@home.mrtheplague.net> Message-ID: <1257566953-sup-306@r50p> Excerpts from Anthony Martinez's message of Fri Nov 06 21:16:42 -0500 2009: > That'd be my patch. I used stty because ENV["COLUMNS"] doesn't consistently work > for me: > > $ echo $COLUMNS > 132 > $ perl -wE 'say $ENV{COLUMNS}' > Use of uninitialized value in say at -e line 1. It sounds like you didn't do this: export COLUMNS From rlane@club.cc.cmu.edu Sat Nov 7 02:09:36 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 07 Nov 2009 02:09:36 -0500 Subject: [sup-talk] slowly catching up In-Reply-To: <1257509523-sup-3428@masanjin.net> References: <1256997213-sup-2725@masanjin.net> <80055d7c0911051838m855262bi93d149549de2da8c@mail.gmail.com> <1257476207-sup-3459@zyrg.net> <1257509523-sup-3428@masanjin.net> Message-ID: <1257562722-sup-9854@zyrg.net> Excerpts from William Morgan's message of Fri Nov 06 08:47:51 -0500 2009: > Reformatted excerpts from Rich Lane's message of 2009-11-05: > > Rather than committing directly to mainline, I'd rather keep a public > > repo that I apply incoming patches to and that William can pull from. > > This way I could do a lot of the first-line work and he could get a > > more stable flow of patches to make releases from. > > That sounds good to me. I'm happy to add you to the gitorious repo, of > course, but this is definitely more in line with the git lifestyle. > > We have a couple options on how to organize this, but I think the best > would be for you to maintain one or more branches that I treat as > integration branches, and periodically merge into master whenever you > tell me they're ready. That's a very minimal amount of work for me. I > can just merge it and forget it. > > The only things to be careful about in such a setup are not merging next > into your branch (merging master in is fine and good to keep up with > other stable changes), and not rebasing. And we will have to coordinate > on releases, if nothing else so that I can make reasonable changelogs > and release notes. > > How does that sound? Sounds good. I'll keep using my clone at http://github.com/rlane/sup/tree/master unless people would prefer I move it to gitorious. When I see a new patchset I'll create a branch for it, like William has been doing. One difference is that I'll hold off on merging to my master (where new patches cook before being sent upstream) until I see some positive feedback on the list. Initially this might just come from me, but like I said before I'm hoping others will join in too. My intention in creating the branch quickly after the patch is mailed is to make it trivial for people tracking my repo to try out the newest patches. As for getting changes to William, I'll occasionally (weekly?) apply the patches I deem stable on top of his master branch and send mail to the list. This way it should be a fast-forward when he pulls and we won't have to worry about resolving merges differently. As a side note, I just created a Wishlist wiki page for feature requests: http://sup.rubyforge.org/wiki/wiki.pl?Wishlist From tero@tilus.net Sat Nov 7 04:34:38 2009 From: tero@tilus.net (Tero Tilus) Date: Sat, 07 Nov 2009 11:34:38 +0200 Subject: [sup-talk] slowly catching up In-Reply-To: <1257562722-sup-9854@zyrg.net> References: <1256997213-sup-2725@masanjin.net> <80055d7c0911051838m855262bi93d149549de2da8c@mail.gmail.com> <1257476207-sup-3459@zyrg.net> <1257509523-sup-3428@masanjin.net> <1257562722-sup-9854@zyrg.net> Message-ID: <1257585999-sup-5436@tilus.net> Rich Lane, 2009-11-07 09:09: > Sounds good. I'll keep using my clone at > http://github.com/rlane/sup/tree/master unless people would prefer I > move it to gitorious. Does it really make that big difference? I don't think. > As a side note, I just created a Wishlist wiki page for feature > requests: http://sup.rubyforge.org/wiki/wiki.pl?Wishlist Why not use tracker for feature requests too? If I don't hear any reasons why, I'll go put the wishlist items there too. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From tero@tilus.net Sat Nov 7 06:15:56 2009 From: tero@tilus.net (Tero Tilus) Date: Sat, 07 Nov 2009 13:15:56 +0200 Subject: [sup-talk] sup bug tracker In-Reply-To: <1257524700-sup-9112@masanjin.net> References: <1257524700-sup-9112@masanjin.net> Message-ID: <1257591624-sup-8158@tilus.net> William Morgan, 2009-11-06 18:33: > If you have existing bug reports or feature requests and you don't > want to rely on my faulty memory any more, feel free to resubmit > them here. What should be the policy with issues are reported/discussed on irc or mailinglist but are not reported to tracker? Should The Sup Issues Task Force(TM) ;) report them to tracker or try to push the original reporter to do it? Should we (The SITF) skim mailinglist archives and transfer reported unfixed bugs (with links to archives) to tracker? > I'm going to point the 0.9.1 crash message there too. Sup home http://sup.rubyforge.org/ is not yet pointing there. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From wmorgan-sup@masanjin.net Sat Nov 7 11:32:08 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 07 Nov 2009 08:32:08 -0800 Subject: [sup-talk] sup bug tracker In-Reply-To: <1257591624-sup-8158@tilus.net> References: <1257524700-sup-9112@masanjin.net> <1257591624-sup-8158@tilus.net> Message-ID: <1257610340-sup-9345@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2009-11-07: > What should be the policy with issues are reported/discussed on irc or > mailinglist but are not reported to tracker? Should The Sup Issues > Task Force(TM) ;) report them to tracker or try to push the original > reporter to do it? I would like all new issues to go on the tracker, and I think it's completely reasonable to tell people who report things to the mailing list or IRC to instead use the issue tracker instead. > Should we (The SITF) skim mailinglist archives and transfer reported > unfixed bugs (with links to archives) to tracker? If the SITF wants to creating issues for existing bug reports, that would be very helpful. But please don't do it to the point that you get sick of it. > Sup home http://sup.rubyforge.org/ is not yet pointing there. Fixed, thanks! -- William From wmorgan-sup@masanjin.net Sat Nov 7 11:56:10 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 07 Nov 2009 08:56:10 -0800 Subject: [sup-talk] slowly catching up In-Reply-To: <1257562722-sup-9854@zyrg.net> References: <1256997213-sup-2725@masanjin.net> <80055d7c0911051838m855262bi93d149549de2da8c@mail.gmail.com> <1257476207-sup-3459@zyrg.net> <1257509523-sup-3428@masanjin.net> <1257562722-sup-9854@zyrg.net> Message-ID: <1257612219-sup-7066@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-11-06: > As for getting changes to William, I'll occasionally (weekly?) apply > the patches I deem stable on top of his master branch and send mail to > the list. This way it should be a fast-forward when he pulls and we > won't have to worry about resolving merges differently. Sounds good to me. I'm not even that concerned about fastforward vs merge. > As a side note, I just created a Wishlist wiki page for feature requests: > http://sup.rubyforge.org/wiki/wiki.pl?Wishlist I agree that these would be great to have on the issue tracker. -- William From macwright@gmail.com Sat Nov 7 12:01:31 2009 From: macwright@gmail.com (tom) Date: Sat, 7 Nov 2009 09:01:31 -0800 (PST) Subject: [sup-talk] Apple Address Book integration for Sup? Message-ID: Hey, Could anyone point me towards where I should start hacking or looking to get my address book contacts as options in Sup? I'm up for the task if the contact list is pluggable, but obviously documentation is somewhat minimal here. Thanks! Tom From rlane@club.cc.cmu.edu Sat Nov 7 12:18:51 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 07 Nov 2009 12:18:51 -0500 Subject: [sup-talk] Apple Address Book integration for Sup? In-Reply-To: References: Message-ID: <1257613929-sup-2902@zyrg.net> Excerpts from tom's message of Sat Nov 07 12:01:31 -0500 2009: > Hey, > > Could anyone point me towards where I should start hacking or looking > to get my address book contacts as options in Sup? I'm up for the task > if the contact list is pluggable, but obviously documentation is > somewhat minimal here. > > Thanks! > > Tom Hi Tom, If you're just looking to get tab-completion for these contacts you can create a extra-contact-addresses hook script that imports them. - Rich From eugeneiiim@gmail.com Mon Nov 9 01:02:07 2009 From: eugeneiiim@gmail.com (Eugene Marinelli) Date: Sun, 8 Nov 2009 22:02:07 -0800 Subject: [sup-talk] [PATCH 2/4] async thread indexing In-Reply-To: <1257399921-26813-2-git-send-email-rlane@club.cc.cmu.edu> References: <1257399921-26813-1-git-send-email-rlane@club.cc.cmu.edu> <1257399921-26813-2-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <69d60e3a0911082202t31561f18mf5e24dda7a108b58@mail.gmail.com> > - Index.save_thread t > + Index.save_thread_async t Where is the "save_thread_async" function? In patch 3/4, this looks like a syntax error: > - end > + threads.each { |t| Index.save_thread async t } > end - Eugene Marinelli On Wed, Nov 4, 2009 at 9:45 PM, Rich Lane wrote: > --- > ?bin/sup ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 ++ > ?lib/sup/index.rb ? ? ? ? ? ? ? ? ? | ? 26 +++++++++++++++++++++++++- > ?lib/sup/modes/thread-index-mode.rb | ? ?2 +- > ?3 files changed, 28 insertions(+), 2 deletions(-) > > diff --git a/bin/sup b/bin/sup > index 78c396a..910ff12 100755 > --- a/bin/sup > +++ b/bin/sup > @@ -142,6 +142,7 @@ Index.lock_interactively or exit > ?begin > ? Redwood::start > ? Index.load > + ?Index.start_sync_worker unless $opts[:no_threads] > > ? $die = false > ? trap("TERM") { |x| $die = true } > @@ -335,6 +336,7 @@ ensure > > ? HookManager.run "shutdown" > > + ?Index.stop_sync_worker > ? Redwood::finish > ? stop_cursing > ? Redwood::Logger.remove_all_sinks! > diff --git a/lib/sup/index.rb b/lib/sup/index.rb > index 5d8d714..1131ec7 100644 > --- a/lib/sup/index.rb > +++ b/lib/sup/index.rb > @@ -28,6 +28,8 @@ class BaseIndex > ? def initialize dir=BASE_DIR > ? ? @dir = dir > ? ? @lock = Lockfile.new lockfile, :retries => 0, :max_age => nil > + ? ?@sync_worker = nil > + ? ?@sync_queue = Queue.new > ? end > > ? def lockfile; File.join @dir, "lock" end > @@ -175,10 +177,32 @@ class BaseIndex > > ? def save_thread t > ? ? t.each_dirty_message do |m| > - ? ? ?update_message_state m > + ? ? ?if @sync_worker > + ? ? ? ?@sync_queue << m > + ? ? ?else > + ? ? ? ?update_message_state m > + ? ? ?end > ? ? ? m.clear_dirty > ? ? end > ? end > + > + ?def start_sync_worker > + ? ?@sync_worker = Redwood::reporting_thread('index sync') { run_sync_worker } > + ?end > + > + ?def stop_sync_worker > + ? ?return unless worker = @sync_worker > + ? ?@sync_worker = nil > + ? ?@sync_queue << :die > + ? ?worker.join > + ?end > + > + ?def run_sync_worker > + ? ?while m = @sync_queue.deq > + ? ? ?return if m == :die > + ? ? ?update_message_state m > + ? ?end > + ?end > ?end > > ?index_name = ENV['SUP_INDEX'] || $config[:index] || DEFAULT_INDEX > diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb > index 370903a..d2b1651 100644 > --- a/lib/sup/modes/thread-index-mode.rb > +++ b/lib/sup/modes/thread-index-mode.rb > @@ -477,7 +477,7 @@ EOS > ? ? ? BufferManager.say("Saving threads...") do |say_id| > ? ? ? ? dirty_threads.each_with_index do |t, i| > ? ? ? ? ? BufferManager.say "Saving modified thread #{i + 1} of #{dirty_threads.length}...", say_id > - ? ? ? ? ?Index.save_thread t > + ? ? ? ? ?Index.save_thread_async t > ? ? ? ? end > ? ? ? end > ? ? end > -- > 1.6.4.2 > > _______________________________________________ > sup-talk mailing list > sup-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk > From rlane@club.cc.cmu.edu Mon Nov 9 01:22:03 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Mon, 09 Nov 2009 01:22:03 -0500 Subject: [sup-talk] [PATCH 2/4] async thread indexing In-Reply-To: <69d60e3a0911082202t31561f18mf5e24dda7a108b58@mail.gmail.com> References: <1257399921-26813-1-git-send-email-rlane@club.cc.cmu.edu> <1257399921-26813-2-git-send-email-rlane@club.cc.cmu.edu> <69d60e3a0911082202t31561f18mf5e24dda7a108b58@mail.gmail.com> Message-ID: <1257747131-sup-7562@zyrg.net> Excerpts from Eugene Marinelli's message of Mon Nov 09 01:02:07 -0500 2009: > > - Index.save_thread t > > + Index.save_thread_async t > Where is the "save_thread_async" function? > > In patch 3/4, this looks like a syntax error: > > - end > > + threads.each { |t| Index.save_thread async t } > > end Nice catch. I'd originally named the method save_thread_async and it looks like my search-and-replace wasn't complete. I've fixed this on the immediate-updates branch. Thanks for the review! From kvrkreddy@gmail.com Tue Nov 10 04:23:22 2009 From: kvrkreddy@gmail.com (k.v.ramakrishna reddy) Date: Tue, 10 Nov 2009 14:53:22 +0530 Subject: [sup-talk] Error upon starting sup Message-ID: <2b29d9f30911100123j4b14f3dr721329306b93b5cb@mail.gmail.com> --- RuntimeError from thread: load threads for thread-index-mode invalid source 3 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:260:in `build_message' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:256:in `build_message' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:163:in `each_id_by_date' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/thread.rb:332:in `call' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/thread.rb:332:in `load_n_threads' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:163:in `each_id_by_date' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:162:in `each' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:162:in `each_id_by_date' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/thread.rb:328:in `load_n_threads' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup.rb:77:in `reporting_thread' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup.rb:75:in `initialize' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup.rb:75:in `new' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup.rb:75:in `reporting_thread' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' /home/karri/.gem/ruby/1.8/gems/sup-0.9/bin/sup:196 /home/karri/.gem/ruby/1.8/bin/sup:19:in `load' /home/karri/.gem/ruby/1.8/bin/sup:19 thanks karri -------------- next part -------------- An HTML attachment was scrubbed... URL: From rlane@club.cc.cmu.edu Tue Nov 10 12:10:42 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Tue, 10 Nov 2009 12:10:42 -0500 Subject: [sup-talk] Error upon starting sup In-Reply-To: <2b29d9f30911100123j4b14f3dr721329306b93b5cb@mail.gmail.com> References: <2b29d9f30911100123j4b14f3dr721329306b93b5cb@mail.gmail.com> Message-ID: <1257872765-sup-828@zyrg.net> Excerpts from k.v.ramakrishna reddy's message of Tue Nov 10 04:23:22 -0500 2009: > --- RuntimeError from thread: load threads for thread-index-mode > invalid source 3 It looks like you removed a source. If you remember what it was, you can just re-add it (and tweak the id in sources.yaml). Otherwise, a sup-dump, deleting the ferret db, and sup-sync -a --restore will solve the problem. From micah@riseup.net Tue Nov 10 18:47:18 2009 From: micah@riseup.net (Micah Anderson) Date: Tue, 10 Nov 2009 18:47:18 -0500 Subject: [sup-talk] Getting gpg to work References: <87k5462s8q.fsf@pond.riseup.net> <1243441483-sup-2270@entry> <8763fkwng3.fsf@pond.riseup.net> <1243730754-sup-8672@entry> Message-ID: <87fx8mkkmx.fsf@pond.riseup.net> William Morgan writes: > Reformatted excerpts from Micah Anderson's message of 2009-05-28: >> [Fri May 29 00:17:42 -0400 2009] crypto: detected gpg binary in /usr/bin/gpg > > Any other obvious messages in the log about multipart/encrypted? I failed to respond to this message, partly because I think I decided to give up on sup at the time. But I am back now, because sup is so alluring, and I'm trying harder to switch this time :) This time, gpg works fine... although it is using the wrong gpg keyid when I try to send. I did manage to find and set the gpgkey configurable in the .sup/config.yaml: :accounts: :default: :signature: /home/micah/.signature :email: micah at riseup.net :sendmail: /usr/sbin/sendmail -oem -ti :name: micah anderson :gpgkey: 0xDEADBEEF but still, that key does not get used, and instead the first key in my keyring for my email at address gets used instead. I do not want that, because that key is set to expire in about a week. micah From micah@riseup.net Tue Nov 10 23:08:22 2009 From: micah@riseup.net (Micah Anderson) Date: Tue, 10 Nov 2009 23:08:22 -0500 Subject: [sup-talk] mark-as-spam.rb and writing hooks Message-ID: <87bpj9ln49.fsf@pond.riseup.net> Howdy folks, Normally, spam is automatically put into my imap Spam folder, but something gets through, then I move it to the Mistakes folder, and send it back to the imap server. Anything put in the Mistakes folder gets processed for Spam/Ham scenarios (conversely, if I move something from the Spam folder that is actually not spam and put it in the Mistakes folder, then spamassassin trains bayes to learn that is actually Ham, not Spam). This is a pretty common Bayes training setup. Sadly, this is something that Sup doesn't do, so I am stuck getting all of this spam in my inbox. so I think what I need to do is use the mark-as-spam hook to copy the message to another location. I'm using offlineimap, so I can just do a file copy of the actual file to the right spot and let sup do the rest. This seems like the most logical place to look, use this hook to make a copy of the mail to my Mistakes maildir folder when I press 'S', and then the offlineimap process will go and put it back on the IMAP server for processing. It seems like a hook could do this fairly easily, but because I dont know ruby its a lot harder for me, also I couldn't find much information about how to use hooks. I read the hooks.txt file in the debian package, but it wans't so useful. Spent some time today trying to figure out how hooks work. Couldn't find much information out there, but eventually figured out that there are a handful of hooks available, which you can list via 'sup -l', for example: mark-as-spam ------------ File: /home/micah/.sup/hooks/mark-as-spam.rb This hook is run when a thread is marked as spam Variables: thread: The message thread being marked as spam. basically what this means is that if you put a file in .sup/hooks/mark-as-spam.rb with ruby code it will be executed when you hit the S key, and the "thread" variable is available to this hook. The above took me quite some time to determine, not being a ruby person and all, now that I got that, I want to use it! So what is that thread variable? I only really found it in thread.rb, so I looked at that for a while, I find that a thread is a bunch of messages, so I figure I need to enumerate the array. Then I taught myself some ruby looping and variable interpolation, and came up with this: log "Marking thread #{thread.to_s} of size #{thread.size} as spam..." thread.each { |message| system 'cp', message, '/home/me/Maildir/Personal/INBOX.Mistakes/cur' } and hey, it almost works, just incorrectly, my sup log gets: hook[mark-as-spam]: Marking thread > of size 1 as spam... But... I dont know how to get the thread array to tell me where the actual file is. I spent some more quality time with the source, and I am pretty sure that a @thread is an array of Containers which contain the different Messages, which are accessed via Store... but i dont know if I can access any of that, there is a Thread class, Container class, Message class and finally a Source class, and I think the problem is that thread.each isn't an actual file its more of a thread object of some sort, and if I knew how to get at the actual file, I could just use a simple system call to copy it where I need to. There has to be some way to have sup actually move a message, isn't there? thanks for any help! micah From rlane@club.cc.cmu.edu Wed Nov 11 23:30:56 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 11 Nov 2009 23:30:56 -0500 Subject: [sup-talk] [PATCH] moved deriving the cmd for bouncing to Account and fixed a bug in it In-Reply-To: <1255159160-sup-8754@tilus.net> References: <1255159160-sup-8754@tilus.net> Message-ID: <1258000130-sup-4084@zyrg.net> Excerpts from Tero Tilus's message of Sat Oct 10 03:21:33 -0400 2009: > The default sendmail command used for bouncing mail was derived from > Account#sendmail in ThreadViewMode#bounce. Moved it to > Account#bounce_sendmail. Part of work towards more DRY mail bouncing > within mark-as-spam hook. The code also had a bug, "$1" (instead of $1 > or "#{$1}"). Fixed it. > > Signed-off-by: Tero Tilus > --- > lib/sup/account.rb | 11 +++++++++++ > lib/sup/modes/thread-view-mode.rb | 7 +------ > 2 files changed, 12 insertions(+), 6 deletions(-) Looks good to me. Pushed to branch fix-bounce-cmd in my repo* and merged to master. * git://github.com/rlane/sup From rlane@club.cc.cmu.edu Thu Nov 12 01:40:14 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 12 Nov 2009 01:40:14 -0500 Subject: [sup-talk] mark-as-spam.rb and writing hooks In-Reply-To: <87bpj9ln49.fsf@pond.riseup.net> References: <87bpj9ln49.fsf@pond.riseup.net> Message-ID: <1258006050-sup-2926@zyrg.net> Hi Micah, Something like the following could work: spam = thread.labels.member? :spam what = spam ? 'spam' : 'ham' source_uri = "maildir:///tmp/mistakes" source = SourceManager.source_for(source_uri) or fail "source not found" thread.each do |m,a,b| next if !m or m == :fake_root info "marking message #{m.id} as #{what}" source.store_message m.date, m.from.email do |f| m.each_raw_message_line { |l| f.puts l } end end This code assumes a maildir (/tmp/mistakes) and that you've added it as a sup "source" with "sup-add -u maildir:///tmp/mistakes". When you mark a thread as spam/ham, it will store the messages into that maildir. One problem with the above code is that it does store the entire thread, so if only one message was miscategorized you'll end up confusing your spam filter. Depending on your exact mail setup you can probably do something smarter here. Excerpts from Micah Anderson's message of Tue Nov 10 23:08:22 -0500 2009: > There has to be some way to have sup actually move a message, isn't > there? Sup really doesn't like it when messages are deleted from a source. Best to just keep it a copy. For other sup developers: it shouldn't take this much hook code to do this. I suggest renaming Source#store_message to Source#store_raw. A new Source#store_message should take a Message as the first argument and let the mbox From header address and date be optional with reasonable defaults. We should also have a Thread#each_message which ignores any result of Thread#each that isn't a Message. These two changes would make the hook above a lot less magical. What other API changes could we do to make writing hooks easier? From andrew@pimlott.net Thu Nov 12 12:30:01 2009 From: andrew@pimlott.net (Andrew Pimlott) Date: Thu, 12 Nov 2009 09:30:01 -0800 Subject: [sup-talk] Problems with undo archive and thread focus In-Reply-To: <1257409101-sup-7780@pc44es141.cs.uni-magdeburg.de> References: <1257409101-sup-7780@pc44es141.cs.uni-magdeburg.de> Message-ID: <1258045702-sup-9760@pimlott.net> Excerpts from Matthias Guedemann's message of Thu Nov 05 00:27:25 -0800 2009: > One is, if you hit 'a' in thread view mode, the thread is archived but undo does > not work. If you go back to index view and hit 'u' the just archived thread does > not appear, but the one before. I was annoyed by this too and found that undo is minimally implemented. I added undo to thread view, at least for the cases that I care about or were easy. I have to say I was discouraged that this was necessary: the code to archive a thread should all be in one place, and the undo record should be created there. There's a lot of code duplication, and I can't tell if it's because the model and view are too coupled, or because nobody has bothered to factor it out. The patch is appended. (This is the first time I've done this with git.) > The second is, if I respond to a thread and send the mail, I normally want to > either archive that mail directly or label and archive it. But the thread is put > to the front and the focus is on the last place of the thread. Therefore I > sometimes archive the wrong thread (but undo comes in handy) That's the next most annying thing for me. Hope to get a chance to work on it. Andrew Subject: [PATCH] create undo records in thread view --- lib/sup/modes/thread-view-mode.rb | 19 ++++++++++++++++++- 1 files changed, 18 insertions(+), 1 deletions(-) diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index 81197c2..2f2d564 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -254,7 +254,8 @@ EOS end def edit_labels - reserved_labels = @thread.labels.select { |l| LabelManager::RESERVED_LABELS.include? l } + old_labels = @thread.labels + reserved_labels = old_labels.select { |l| LabelManager::RESERVED_LABELS.include? l } new_labels = BufferManager.ask_for_labels :label, "Labels for thread: ", @thread.labels return unless new_labels @@ -262,6 +263,10 @@ EOS new_labels.each { |l| LabelManager << l } update UpdateManager.relay self, :labeled, @thread.first + UndoManager.register "labeling thread" do + @thread.labels = old_labels + UpdateManager.relay self, :labeled, @thread.first + end end def toggle_starred @@ -476,6 +481,10 @@ EOS dispatch op do @thread.remove_label :inbox UpdateManager.relay self, :archived, @thread.first + UndoManager.register "archiving 1 thread" do + @thread.apply_label :inbox + UpdateManager.relay self, :unarchived, @thread.first + end end end @@ -483,6 +492,10 @@ EOS dispatch op do @thread.apply_label :spam UpdateManager.relay self, :spammed, @thread.first + UndoManager.register "marking 1 thread as spam" do + @thread.remove_label :spam + UpdateManager.relay self, :unspammed, @thread.first + end end end @@ -490,6 +503,10 @@ EOS dispatch op do @thread.apply_label :deleted UpdateManager.relay self, :deleted, @thread.first + UndoManager.register "deleting 1 thread" do + @thread.remove_label :deleted + UpdateManager.relay self, :undeleted, @thread.first + end end end -- 1.5.6.5 -- I've decided to go back to school. Kindergarden. From rlane@club.cc.cmu.edu Thu Nov 12 13:50:54 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 12 Nov 2009 13:50:54 -0500 Subject: [sup-talk] mark-as-spam.rb and writing hooks In-Reply-To: <1258040153-sup-741@pond.riseup.net> References: <87bpj9ln49.fsf@pond.riseup.net> <1258006050-sup-2926@zyrg.net> <1258040153-sup-741@pond.riseup.net> Message-ID: <1258046671-sup-7062@zyrg.net> Excerpts from micah anderson's message of Thu Nov 12 10:35:59 -0500 2009: > > spam = thread.labels.member? :spam > > what = spam ? 'spam' : 'ham' > > I'm curious about this 'what' piece. It seems like it is a way to > specify the message as 'spam' or 'ham', which is the second half of the > puzzle: go into my Spam source and review the messages there, if there > is a incorrectly categorized as spam message, I would typically stuff > that into Mistakes as well. It seems like you *have* built this into > this hook, but I don't understand how it is able to determine one from > the other? There is the 'S' mark-as-spam key, but there is no 'H' > mark-as-ham :) There's only 'S' and the mark-as-spam hook, but you can tell whether the user has marked the thread as spam or ham by checking the labels. If the thread is labelled 'spam', it's spam. > Yeah, I had realized this thread problem when I saw that the thread > variable was available for this hook. I think that this is mostly ok, I > think getting threaded spam is somewhat unusual... but I will pay > attention to see how frequently this happens. In the case that it > happens, i'll probably fire up mutt, categorize it as Spam, and then > re-index my sup index, which is what I was doing before. If you can configure your spam filter so it reads from two folders, 'spam' and 'ham', then you can safely store extra messages in them (assuming you don't have true-spam threaded with true-ham). My own setup is slightly different - I write the raw message to a tempfile and run sa-learn on it with --spam or --ham. > > We should also have a Thread#each_message which ignores any > > result of Thread#each that isn't a Message. These two changes would make > > the hook above a lot less magical. What other API changes could we do > > to make writing hooks easier? > > Would that make it so the above thread problem would go away? Nope, it would just mean easier iteration over the messages in a thread. From carlosgc@gnome.org Fri Nov 13 04:11:38 2009 From: carlosgc@gnome.org (Carlos Garcia Campos) Date: Fri, 13 Nov 2009 10:11:38 +0100 Subject: [sup-talk] Sup not working anymore after abrupt reboot Message-ID: <21063fcb0911130111h234098b5oabe77bfdd14a0dab@mail.gmail.com> Hi all, my laptop ran out of battery while sup was polling new mail and now sup always fails to start. I don't know whether my ferret index is corrupt, this is the exception I get: ---------------------------------------------------------------- --- IOError from thread: main IO Error occured at :93 in xraise Error occured in index.c:901 - sis_find_segments_file Error reading the segment infos. Store listing was /usr/lib/ruby/1.8/ferret/index.rb:736:in `initialize' /usr/lib/ruby/1.8/ferret/index.rb:736:in `new' /usr/lib/ruby/1.8/ferret/index.rb:736:in `ensure_reader_open' /usr/lib/ruby/1.8/ferret/index.rb:591:in `size' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib/ruby/1.8/ferret/index.rb:590:in `size' ./lib/sup/ferret_index.rb:31:in `load_index' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' ./lib/sup/ferret_index.rb:29:in `load_index' ./lib/sup/index.rb:67:in `load' ./lib/sup/util.rb:520:in `send' ./lib/sup/util.rb:520:in `method_missing' bin/sup:144 is there any way to recover it? (if possible without losing mi index . . . ) Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tero@tilus.net Fri Nov 13 06:10:17 2009 From: tero@tilus.net (Tero Tilus) Date: Fri, 13 Nov 2009 13:10:17 +0200 Subject: [sup-talk] Sup not working anymore after abrupt reboot In-Reply-To: <21063fcb0911130111h234098b5oabe77bfdd14a0dab@mail.gmail.com> References: <21063fcb0911130111h234098b5oabe77bfdd14a0dab@mail.gmail.com> Message-ID: <1258109288-sup-5579@tilus.net> Carlos Garcia Campos, 2009-11-13 11:11: > I don't know whether my ferret index is corrupt, this is the exception I > get: > > ---------------------------------------------------------------- > Error occured in index.c:901 - sis_find_segments_file > Error reading the segment infos. I'm not familiar with the internals of ferret, but the error looks pretty bad. It might have lost part of index data files. Do you happen to have index or dump backups or find deleted files under ferret/ with using undelete tools? Lessons learned... Always have regular (automatic, if possible) backups of your index dump, ALWAYS! I have sup-dump in my backup2l before-hook. Hum. I think for people who don't do cron backups it wouldn't be a bad idea to create (optional) rotating sup-dumps on every start. (and stop?) -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From eg@gaute.vetsj.com Fri Nov 13 06:57:05 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Fri, 13 Nov 2009 12:57:05 +0100 Subject: [sup-talk] Sup not working anymore after abrupt reboot In-Reply-To: <21063fcb0911130111h234098b5oabe77bfdd14a0dab@mail.gmail.com> References: <21063fcb0911130111h234098b5oabe77bfdd14a0dab@mail.gmail.com> Message-ID: <1258113332-sup-7090@dolk> Excerpts from Carlos Garcia Campos's message of fr. nov. 13 10:11:38 +0100 2009: > Hi all, > > my laptop ran out of battery while sup was polling new mail and now sup > always fails to start. > I don't know whether my ferret index is corrupt, this is the exception I > get: > > ---------------------------------------------------------------- > --- IOError from thread: main > IO Error occured at :93 in xraise > Error occured in index.c:901 - sis_find_segments_file > Error reading the segment infos. Store listing was > > > /usr/lib/ruby/1.8/ferret/index.rb:736:in `initialize' > /usr/lib/ruby/1.8/ferret/index.rb:736:in `new' > /usr/lib/ruby/1.8/ferret/index.rb:736:in `ensure_reader_open' > /usr/lib/ruby/1.8/ferret/index.rb:591:in `size' > /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' > /usr/lib/ruby/1.8/ferret/index.rb:590:in `size' > ./lib/sup/ferret_index.rb:31:in `load_index' > /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' > ./lib/sup/ferret_index.rb:29:in `load_index' > ./lib/sup/index.rb:67:in `load' > ./lib/sup/util.rb:520:in `send' > ./lib/sup/util.rb:520:in `method_missing' > bin/sup:144 Also, the xapian backend works better (doesn't help you now thou, im afraid). - gaute From micah@riseup.net Fri Nov 13 10:53:15 2009 From: micah@riseup.net (Micah Anderson) Date: Fri, 13 Nov 2009 10:53:15 -0500 Subject: [sup-talk] offlineimap before-poll.rb undefined method 'usual_sources' Message-ID: <877htul8us.fsf@pond.riseup.net> The before-poll.rb wiki example[0] seems to be what I am interested in, however it doesn't work and provides a traceback. It reads as follows: def offlineimap(*folders) cmd = "offlineimap -q -u Noninteractive.Basic" cmd << " -f #{folders * ','}" unless folders.compact.empty? `#{cmd}` end def folder_names(sources) sources.map { |s| s.uri.split('/').last } end def inbox_sources(sources = Index.usual_sources) sources.find_all { |s| !s.archived? }.sort_by {|s| s.id } end if (@last_fetch || Time.at(0)) < Time.now - 120 say "Running offlineimap..." # only check non-auto-archived sources on the first run log offlineimap(@last_fetch ? nil : folder_names(inbox_sources)) say "Finished offlineimap run." end @last_fetch = Time.now When I use this hook, i get this traceback in my sup log: [Fri Nov 13 10:51:28 -0500 2009] hook: error running hook: undefined method `usual_sources' for # [Fri Nov 13 10:51:28 -0500 2009] hook: /usr/lib/ruby/1.8/sup/util.rb:520:in `send' /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing' /home/micah/.sup/hooks/before-poll.rb:11:in `inbox_sources' /home/micah/.sup/hooks/before-poll.rb:18:in `__run' /usr/lib/ruby/1.8/sup/hook.rb:42:in `__run' /usr/lib/ruby/1.8/sup/hook.rb:82:in `run' /usr/lib/ruby/1.8/sup/util.rb:520:in `send' /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing' /usr/lib/ruby/1.8/sup/poll.rb:45:in `poll' /usr/lib/ruby/1.8/sup/util.rb:520:in `send' /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing' /usr/bin/sup-mail:195 /usr/lib/ruby/1.8/sup.rb:76:in `reporting_thread' /usr/lib/ruby/1.8/sup.rb:74:in `initialize' /usr/lib/ruby/1.8/sup.rb:74:in `new' /usr/lib/ruby/1.8/sup.rb:74:in `reporting_thread' /usr/bin/sup-mail:195 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:669:in `call' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:669:in `__unprotected_load_threads' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:610:in `call' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:610:in `load_n_threads_background' /usr/lib/ruby/1.8/sup.rb:76:in `reporting_thread' /usr/lib/ruby/1.8/sup.rb:74:in `initialize' /usr/lib/ruby/1.8/sup.rb:74:in `new' /usr/lib/ruby/1.8/sup.rb:74:in `reporting_thread' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' /usr/bin/sup-mail:195 Thanks, micah 0. http://sup.rubyforge.org/wiki/wiki.pl?Hooks From eg@gaute.vetsj.com Fri Nov 13 19:12:04 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Sat, 14 Nov 2009 01:12:04 +0100 Subject: [sup-talk] offlineimap before-poll.rb undefined method 'usual_sources' In-Reply-To: <877htul8us.fsf@pond.riseup.net> References: <877htul8us.fsf@pond.riseup.net> Message-ID: <1258157447-sup-5782@dolk> Excerpts from Micah Anderson's message of fr. nov. 13 16:53:15 +0100 2009: > > The before-poll.rb wiki example[0] seems to be what I am interested in, > however it doesn't work and provides a traceback. It reads as follows: > > def offlineimap(*folders) > cmd = "offlineimap -q -u Noninteractive.Basic" > cmd << " -f #{folders * ','}" unless folders.compact.empty? > `#{cmd}` > end > > def folder_names(sources) > sources.map { |s| s.uri.split('/').last } > end > > def inbox_sources(sources = Index.usual_sources) > sources.find_all { |s| !s.archived? }.sort_by {|s| s.id } > end > > if (@last_fetch || Time.at(0)) < Time.now - 120 > say "Running offlineimap..." > # only check non-auto-archived sources on the first run > log offlineimap(@last_fetch ? nil : folder_names(inbox_sources)) > say "Finished offlineimap run." > end > @last_fetch = Time.now Im using this modified version; and I filter the folders in offlineimaprc. def offlineimap(*folders) cmd = "offlineimap -u Noninteractive.Basic 2>&1" #cmd << " -f #{folders * ','}" unless folders.compact.empty? `#{cmd}` end def folder_names(sources) sources.map { |s| s.uri.split('/').last } end def inbox_sources(sources = SourceManager.sources) sources.find_all { |s| !s.archived? }.sort_by {|s| s.id } end if (@last_fetch || Time.at(0)) < Time.now - 20 say "Running offlineimap..." # only check non-auto-archived sources on the first run log offlineimap(@last_fetch ? nil : folder_names(inbox_sources)) say "Finished offlineimap." end @last_fetch = Time.now - gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From carlosgc@gnome.org Sat Nov 14 08:22:50 2009 From: carlosgc@gnome.org (Carlos Garcia Campos) Date: Sat, 14 Nov 2009 14:22:50 +0100 Subject: [sup-talk] Sup not working anymore after abrupt reboot In-Reply-To: <1258109288-sup-5579@tilus.net> References: <21063fcb0911130111h234098b5oabe77bfdd14a0dab@mail.gmail.com> <1258109288-sup-5579@tilus.net> Message-ID: <1258204741-sup-4254@charmaleon> Excerpts from Tero Tilus's message of vie nov 13 12:10:17 +0100 2009: > Carlos Garcia Campos, 2009-11-13 11:11: > > I don't know whether my ferret index is corrupt, this is the exception I > > get: > > > > ---------------------------------------------------------------- > > Error occured in index.c:901 - sis_find_segments_file > > Error reading the segment infos. > > I'm not familiar with the internals of ferret, but the error looks > pretty bad. It might have lost part of index data files. indeed, I have had to build a new index scratch. > Do you > happen to have index or dump backups or find deleted files under > ferret/ with using undelete tools? No :-/ > Lessons learned... > > Always have regular (automatic, if possible) backups of your index > dump, ALWAYS! I have sup-dump in my backup2l before-hook. Yes, I have a daily cron script for it now. > Hum. I think for people who don't do cron backups it wouldn't be a > bad idea to create (optional) rotating sup-dumps on every start. (and > stop?) > Thank you very much. -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From matthias.guedemann@ovgu.de Mon Nov 16 04:42:18 2009 From: matthias.guedemann@ovgu.de (Matthias Guedemann) Date: Mon, 16 Nov 2009 10:42:18 +0100 Subject: [sup-talk] Problems with undo archive and thread focus In-Reply-To: <1258045702-sup-9760@pimlott.net> References: <1257409101-sup-7780@pc44es141.cs.uni-magdeburg.de> <1258045702-sup-9760@pimlott.net> Message-ID: <1258363822-sup-5470@pc44es141.cs.uni-magdeburg.de> Hi Andrew, > The patch is appended. (This is the first time I've done this with git.) thanks, works perfectly. > That's the next most annying thing for me. Hope to get a chance to work > on it. I had a look at the code and it should not be too hard, basically when a reply buffer is spawned (e.g. thread-view-mode line 168), a hook to call set_sursor_pos 0 (as ThreadViewMode is a subclass of LineCursorMode) after successful sending of the reply should do the job. But unfortunately I don't know too much about the inner workings of sup (can the HookManager be used for this? or should the hook be supplied as attribute to the reply-buffer?), or even Ruby, to do it at the moment. best regards Matthias -- __________________________________________________________ ___ __ __ Dipl. Inf. Matthias Guedemann / __\/ _\ /__\ Computer Systems in Engineering / / \ \ /_\ Otto-von-Guericke Universitaet Magdeburg / /___ _\ \//__ Tel.: 0391 / 67-19359 \____/ \__/\__/ __________________________________________________________ From dhaval.giani@gmail.com Tue Nov 17 14:04:27 2009 From: dhaval.giani@gmail.com (Dhaval Giani) Date: Wed, 18 Nov 2009 00:34:27 +0530 Subject: [sup-talk] Bug report, importing emails into sup Message-ID: <8aa016e10911171104t7fd3e913y96e85e039c53ce98@mail.gmail.com> Hi, Attached an exception log. Failure occured when trying to import mails from mbox after setting up using sup-config whicch failed and i tried to run sup after that [dhaval at gondor sup]$ sup --version sup v0.9 [dhaval at gondor sup]$ Thanks, Dhaval -- Joan Crawford - "I, Joan Crawford, I believe in the dollar. Everything I earn, I spend." - http://www.brainyquote.com/quotes/authors/j/joan_crawford.html -------------- next part -------------- --- NoMethodError from thread: poll after loading inbox undefined method `downcase' for nil:NilClass /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:502:in `message_to_chunks' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:239:in `load_from_source!' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:335:in `build_from_source' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:145:in `each_message_from' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/source.rb:104:in `each' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:560:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:560:in `__pass' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:547:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:139:in `each_message_from' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:93:in `do_poll' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:81:in `each' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:81:in `do_poll' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:80:in `synchronize' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:80:in `do_poll' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/poll-mode.rb:15:in `poll' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:48:in `poll' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.9/bin/sup:196 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:77:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `initialize' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `new' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.9/bin/sup:196 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:669:in `call' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:669:in `__unprotected_load_threads' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:610:in `call' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:610:in `load_n_threads_background' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:77:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `initialize' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `new' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' /usr/lib/ruby/gems/1.8/gems/sup-0.9/bin/sup:196 /usr/bin/sup:19:in `load' /usr/bin/sup:19 From tero@tilus.net Wed Nov 18 07:38:25 2009 From: tero@tilus.net (Tero Tilus) Date: Wed, 18 Nov 2009 14:38:25 +0200 Subject: [sup-talk] Bug report, importing emails into sup In-Reply-To: <8aa016e10911171104t7fd3e913y96e85e039c53ce98@mail.gmail.com> References: <8aa016e10911171104t7fd3e913y96e85e039c53ce98@mail.gmail.com> Message-ID: <1258547658-sup-5136@tilus.net> Dhaval Giani, 2009-11-17 21:04: > Failure occured when trying to import mails from mbox after setting up > using sup-config whicch failed and i tried to run sup after that The trace is from sup, but you say it happened "when trying to import mails", which is usually done with sup-sync. What was your procedure? How did sup-config fail? btw, we now have a brand new tracker -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From rlane@club.cc.cmu.edu Thu Nov 19 23:51:22 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 19 Nov 2009 23:51:22 -0500 Subject: [sup-talk] Problems with undo archive and thread focus In-Reply-To: <1258045702-sup-9760@pimlott.net> References: <1257409101-sup-7780@pc44es141.cs.uni-magdeburg.de> <1258045702-sup-9760@pimlott.net> Message-ID: <1258692213-sup-2324@zyrg.net> Excerpts from Andrew Pimlott's message of Thu Nov 12 12:30:01 -0500 2009: > Excerpts from Matthias Guedemann's message of Thu Nov 05 00:27:25 -0800 2009: > > One is, if you hit 'a' in thread view mode, the thread is archived but undo does > > not work. If you go back to index view and hit 'u' the just archived thread does > > not appear, but the one before. > > I was annoyed by this too and found that undo is minimally implemented. > I added undo to thread view, at least for the cases that I care about or > were easy. I have to say I was discouraged that this was necessary: the > code to archive a thread should all be in one place, and the undo > record should be created there. There's a lot of code duplication, and > I can't tell if it's because the model and view are too coupled, or > because nobody has bothered to factor it out. > > The patch is appended. (This is the first time I've done this with git.) Branch thread-view-mode-undo, merged to master at git://github.com/rlane/sup From edwardludd@gmail.com Fri Nov 20 10:50:47 2009 From: edwardludd@gmail.com (Ned Ludd) Date: Fri, 20 Nov 2009 10:50:47 -0500 Subject: [sup-talk] Sup-sync exception Message-ID: <65a36ed50911200750q53cda26h5c5d374c6228a5a@mail.gmail.com> There was a message about this a week or so ago. Did anyone ever find a fix? When I run "sup-sync", regardless or the source (I tried IMAP and Maildir), I get this error: $ sup-sync Scanning maildir:/home/nedludd/.mail/INBOX... /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/source.rb:88:in `done?': undefined method `>=' for true:TrueClass (NoMethodError) from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:560:in `__pass' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:547:in `method_missing' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:137:in `each_message_from' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:146:in `block in ' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `each' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `' from /usr/bin/supbin/sup-sync:19:in `load' from /usr/bin/supbin/sup-sync:19:in `
' [I'm on Arch with sup 0.9 and Ruby 1.9.1] ----- Ned Ludd From garoth@gmail.com Sat Nov 21 00:18:28 2009 From: garoth@gmail.com (Andrei Thorp) Date: Sat, 21 Nov 2009 00:18:28 -0500 Subject: [sup-talk] Sup-sync exception In-Reply-To: <65a36ed50911200750q53cda26h5c5d374c6228a5a@mail.gmail.com> References: <65a36ed50911200750q53cda26h5c5d374c6228a5a@mail.gmail.com> Message-ID: <80055d7c0911202118v4360f880n373676a90a92d3a3@mail.gmail.com> You can solve this particular problem (I have), but then it uncovers quite a few other probems with sup and Ruby 1.9. As the maintainer of the sup package in the AUR, I pretty much recommend using ruby 1.8 until the dev team can beat sup into working. Sorry, -AT On Fri, Nov 20, 2009 at 10:50 AM, Ned Ludd wrote: > There was a message about this a week or so ago. ?Did anyone ever find a fix? > > When I run "sup-sync", regardless or the source (I tried IMAP and > Maildir), I get this error: > > $ sup-sync > Scanning maildir:/home/nedludd/.mail/INBOX... > /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/source.rb:88:in `done?': > undefined method `>=' for true:TrueClass (NoMethodError) > ? ? ? ?from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:560:in `__pass' > ? ? ? ?from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:547:in > `method_missing' > ? ? ? ?from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:137:in > `each_message_from' > ? ? ? ?from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:520:in > `method_missing' > ? ? ? ?from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:146:in `block > in ' > ? ? ? ?from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `each' > ? ? ? ?from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in ` (required)>' > ? ? ? ?from /usr/bin/supbin/sup-sync:19:in `load' > ? ? ? ?from /usr/bin/supbin/sup-sync:19:in `
' > > > [I'm on Arch with sup 0.9 and Ruby 1.9.1] > > ----- > Ned Ludd > _______________________________________________ > sup-talk mailing list > sup-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk > From rlane@club.cc.cmu.edu Mon Nov 23 18:33:06 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Mon, 23 Nov 2009 18:33:06 -0500 Subject: [sup-talk] Sup-sync exception In-Reply-To: <65a36ed50911200750q53cda26h5c5d374c6228a5a@mail.gmail.com> References: <65a36ed50911200750q53cda26h5c5d374c6228a5a@mail.gmail.com> Message-ID: <1259018950-sup-9876@zyrg.net> Excerpts from Ned Ludd's message of Fri Nov 20 10:50:47 -0500 2009: > There was a message about this a week or so ago. Did anyone ever find a fix? > > When I run "sup-sync", regardless or the source (I tried IMAP and > Maildir), I get this error: > > $ sup-sync > Scanning maildir:/home/nedludd/.mail/INBOX... > /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/source.rb:88:in `done?': > undefined method `>=' for true:TrueClass (NoMethodError) > from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:560:in `__pass' > from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:547:in > `method_missing' > from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:137:in > `each_message_from' > from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:520:in > `method_missing' > from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:146:in `block > in ' > from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `each' > from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in ` (required)>' > from /usr/bin/supbin/sup-sync:19:in `load' > from /usr/bin/supbin/sup-sync:19:in `
' > > > [I'm on Arch with sup 0.9 and Ruby 1.9.1] Is there a cur_offset key for every source in sources.yaml? If not (or if it is nil/blank) see if setting cur_offset to 0 fixes it. From eg@gaute.vetsj.com Wed Nov 25 12:27:53 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Wed, 25 Nov 2009 18:27:53 +0100 Subject: [sup-talk] browser filter / attachment ideas Message-ID: <1259170070-sup-7628@dolk> Greetings, Is there already a way to put a filter on the file browser? i.e: exclude anything that start with a '.' ? is there a hook for this? I know there is a way of saving all attachments to a folder, but is there a way to save a single attachment to a folder, now when I want to save it I have to remove the file name to get tab-completion, and then type the file name again when I want to save it. And sup doesn't understand attachment names with inline encoding: i.e.: =?ISO-8859-1?Q?framside_sm=E5_stader_STORE_VYER.jpg?= which should be displayed as: framside_sm?_stader_STORE_VYER.jpg (see issue 24) - gaute From tero@tilus.net Thu Nov 26 07:13:18 2009 From: tero@tilus.net (Tero Tilus) Date: Thu, 26 Nov 2009 14:13:18 +0200 Subject: [sup-talk] browser filter / attachment ideas In-Reply-To: <1259170070-sup-7628@dolk> References: <1259170070-sup-7628@dolk> Message-ID: <1259237544-sup-7216@tilus.net> Gaute Hope, 2009-11-25 19:27: > And sup doesn't understand attachment names with inline encoding: > i.e.: =?ISO-8859-1?Q?framside_sm=E5_stader_STORE_VYER.jpg?= > which should be displayed as: framside_sm?_stader_STORE_VYER.jpg I think I have this fixed, but haven committed/pushed it. Shame on me. Should try to find time to do that... -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From guillaume.quintard@gmail.com Sun Nov 29 08:39:56 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Sun, 29 Nov 2009 14:39:56 +0100 Subject: [sup-talk] sup-add won't work. Message-ID: <1e5fdab70911290539j75355e9ds23468c866abae66b@mail.gmail.com> Here, I have a somewhat clean install of sup (gems + next branch), and here's what I get at the end of sup-config : Ok, trying to run "bin/sup-add mbox:/home/shivan/.gmail.mbox"... /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require': no such file to load -- sup (LoadError) from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' from bin/sup-add:7 Something changed? -- Guillaume