community/pipermail-archives/sup-devel/2011-04.txt (46019B) - raw
1 From wmorgan-sup@masanjin.net Sat Apr 2 14:15:48 2011
2 From: wmorgan-sup@masanjin.net (William Morgan)
3 Date: Sat, 02 Apr 2011 18:15:48 +0000
4 Subject: [sup-devel] turnsole alpha preview
5 Message-ID: <1301767622-sup-4907@masanjin.net>
6
7 Ok, if you've managed to get Heliotrope running, you can now try a super-alpha
8 preview of Turnsole, the curses client.
9
10 Get it by cloning
11 https://wmorgan at github.com/wmorgan/turnsole.git
12 and then following the instructions in HACKING. You will have to update your
13 Heliotrope repo to the latest master as well.
14
15 Things that work: searching, getting results from the server, viewing threads,
16 changing labels in thread-view-mode. (The very, very basics.)
17
18 Things that don't work: almost everything else. Any by "don't work" I mean will
19 crash with a backtrace. Lots of code still needs to be updated. I've also
20 ripped out various hooks and config options when they've gotten in my way.
21
22 But generally this should be a faster, leaner experience. It's at roughly 1/3
23 the sup codebase and I'm hoping it won't grow too much more.
24
25 For fun, run two turnsoles at the same time and marvel at your power.
26 --
27 William <wmorgan-sup at masanjin.net>
28
29 From michael+sup@stapelberg.de Sat Apr 2 15:00:55 2011
30 From: michael+sup@stapelberg.de (Michael Stapelberg)
31 Date: Sat, 02 Apr 2011 21:00:55 +0200
32 Subject: [sup-devel] turnsole alpha preview
33 In-Reply-To: <1301767622-sup-4907@masanjin.net>
34 References: <1301767622-sup-4907@masanjin.net>
35 Message-ID: <1301770677-sup-9153@midna.zekjur.net>
36
37 Hi William,
38
39 I just tried turnsole/heliotrope and was able to import one of my maildirs.
40 After fixing a complaint in lib/turnsole/accounts.rb:39 about calling gpgkey on
41 nil, I could run it.
42
43 It looks very promising! It?s fast and I very much like the parallel loading of
44 threads for example. So, keep it up, I?m looking forward to actually using it :).
45
46 Best regards,
47 Michael
48
49 BTW: I still get some UTF-8 stacktraces in heliotrope (with latest master). Is
50 that something you are interested in fixing right now or should I report these
51 later (should they still exist then)?
52
53 From wmorgan-sup@masanjin.net Sat Apr 2 16:40:39 2011
54 From: wmorgan-sup@masanjin.net (William Morgan)
55 Date: Sat, 02 Apr 2011 20:40:39 +0000
56 Subject: [sup-devel] turnsole alpha preview
57 In-Reply-To: <1301770677-sup-9153@midna.zekjur.net>
58 References: <1301767622-sup-4907@masanjin.net>
59 <1301770677-sup-9153@midna.zekjur.net>
60 Message-ID: <1301776782-sup-4638@masanjin.net>
61
62 Reformatted excerpts from Michael Stapelberg's message of 2011-04-02:
63 > It looks very promising! It?s fast and I very much like the parallel loading of
64 > threads for example. So, keep it up, I?m looking forward to actually using it :).
65
66 Great!
67
68 > BTW: I still get some UTF-8 stacktraces in heliotrope (with latest master). Is
69 > that something you are interested in fixing right now or should I report these
70 > later (should they still exist then)?
71
72 I've love a stacktrace for both that and the gpg key thing in turnsole. Thanks!
73 --
74 William <wmorgan-sup at masanjin.net>
75
76 From matthieu.rakotojaona@gmail.com Sat Apr 2 18:39:41 2011
77 From: matthieu.rakotojaona@gmail.com (Matthieu Rakotojaona)
78 Date: Sun, 3 Apr 2011 00:39:41 +0200
79 Subject: [sup-devel] [sup-talk] turnsole alpha preview
80 In-Reply-To: <1301767622-sup-4907@masanjin.net>
81 References: <1301767622-sup-4907@masanjin.net>
82 Message-ID: <AANLkTimv9yUTMQ+Xc8bshBFU-eogs-K-6QVWLY+_J3aY@mail.gmail.com>
83
84 Hello there,
85
86 I'd like to give you some backtraces of the problems that occur when I
87 use heliotrope/turnsole. I have absolutely no knowledge in ruby, so I
88 hope this will help everyone who is developing
89
90 I'd like to point out a few problems about turnsole :
91 - you need to install the 'locale' gem
92 - I happen to have a 256colors terminal (rxvt-unicode-256color), and
93 the "color!" method in ncurses-patch.rb seems to fail :
94
95 >rakoo at Otokar % ruby -Ilib -I ../heliotrope/lib bin/turnsole
96 >/home/rakoo/src/turnsole/lib/turnsole/ncurses-patches.rb:19:in `block in <module:Curses>': undefined method `color!' for Curses:Module (NoMethodError)
97 > from /home/rakoo/src/turnsole/lib/turnsole/ncurses-patches.rb:19:in `times'
98 > from /home/rakoo/src/turnsole/lib/turnsole/ncurses-patches.rb:19:in `<module:Curses>'
99 > from /home/rakoo/src/turnsole/lib/turnsole/ncurses-patches.rb:1:in `<top (required)>'
100 > from <internal:lib/rubygems/custom_require>:29:in `require'
101 > from <internal:lib/rubygems/custom_require>:29:in `require'
102 > from /home/rakoo/src/turnsole/lib/turnsole.rb:16:in `<top (required)>'
103 > from <internal:lib/rubygems/custom_require>:29:in `require'
104 > from <internal:lib/rubygems/custom_require>:29:in `require'
105 > from bin/turnsole:5:in `<main>'
106
107 - When I switch back to xterm with 8 colors, the previous error
108 doesn't occur (the if test fais), but I have a problem with "gpgkey" :
109
110 rakoo at Otokar % ruby -I lib -I ../heliotrope/lib bin/turnsole
111 >/home/rakoo/src/turnsole/lib/turnsole/accounts.rb:39:in `block in add_account': undefined method `gpgkey' for nil:NilClass (NoMethodError)
112 > from /home/rakoo/src/turnsole/lib/turnsole/accounts.rb:39:in `each'
113 > from /home/rakoo/src/turnsole/lib/turnsole/accounts.rb:39:in `add_account'
114 > from /home/rakoo/src/turnsole/lib/turnsole/accounts.rb:25:in `initialize'
115 > from /home/rakoo/src/turnsole/lib/turnsole.rb:96:in `new'
116 > from /home/rakoo/src/turnsole/lib/turnsole.rb:96:in `setup!'
117 > from bin/turnsole:75:in `<main>'
118
119 These happened with ruby v1.8 and 1.9.2, and gems v1.3.7.
120
121 Now with heliotrope, I have the problems with the encoding :
122 - When I search for words with "?", I have an error :
123
124 >HeliotropeServer::RequestError - can't parse query: parse error: line 1: syntax error, unexpected $end, expecting WORD:
125 > bin/heliotrope-server:137:in `rescue in block in <class:HeliotropeServer>'
126 > bin/heliotrope-server:114:in `block in <class:HeliotropeServer>'
127 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:1126:in `call'
128 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:1126:in `block in compile!'
129 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:709:in `instance_eval'
130 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:709:in `route_eval'
131 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:693:in `block (2 levels) in route!'
132 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:741:in `block in process_route'
133 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:738:in `catch'
134 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:738:in `process_route'
135 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:692:in `block in route!'
136 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:691:in `each'
137 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:691:in `route!'
138 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:826:in `dispatch!'
139 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:619:in `block in call!'
140 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:791:in `instance_eval'
141 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:791:in `block in invoke'
142 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:791:in `catch'
143 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:791:in `invoke'
144 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:619:in `call!'
145 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:604:in `call'
146 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/showexceptions.rb:21:in `call'
147 > /usr/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/lint.rb:48:in `_call'
148 > /usr/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/lint.rb:36:in `call'
149 > /usr/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/showexceptions.rb:24:in `call'
150 > /usr/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/commonlogger.rb:18:in `call'
151 > /usr/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/content_length.rb:13:in `call'
152 > /usr/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/handler/webrick.rb:52:in `service'
153 > /usr/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service'
154 > /usr/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run'
155 > /usr/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'
156 >127.0.0.1 - - [03/Apr/2011 00:24:50] "GET /search?q=%22%C3%A9%22 HTTP/1.1" 500 82586 0.0504
157 >Otokar - - [03/Apr/2011:00:24:50 CEST] "GET /search?q=%22%C3%A9%22 HTTP/1.1" 500 82586
158 >http://localhost:8042/search?q=%22zegzaegsg%22 -> /search?q=%22%C3%A9%22
159
160 - an error also happens when I want to see some messages, that doesn't
161 happen when I use ruby v1.8 instead :
162
163 >ArgumentError - invalid byte sequence in UTF-8:
164 > /usr/lib/ruby/gems/1.9.1/gems/rmail-1.0.0/lib/rmail/parser.rb:217:in `split'
165 > /usr/lib/ruby/gems/1.9.1/gems/rmail-1.0.0/lib/rmail/parser.rb:217:in `parse_header'
166 > /usr/lib/ruby/gems/1.9.1/gems/rmail-1.0.0/lib/rmail/parser.rb:194:in `parse_low'
167 > /usr/lib/ruby/gems/1.9.1/gems/rmail-1.0.0/lib/rmail/parser.rb:183:in `parse'
168 > /usr/lib/ruby/gems/1.9.1/gems/rmail-1.0.0/lib/rmail/parser.rb:331:in `parse'
169 > /usr/lib/ruby/gems/1.9.1/gems/rmail-1.0.0/lib/rmail/parser.rb:345:in `read'
170 > /home/rakoo/src/heliotrope/lib/heliotrope/message.rb:17:in `parse!'
171 > bin/heliotrope-server:292:in `load_actual_message'
172 > bin/heliotrope-server:297:in `message_to_html'
173 > bin/heliotrope-server:209:in `block in <class:HeliotropeServer>'
174 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:1125:in `call'
175 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:1125:in `block in compile!'
176 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:709:in `instance_eval'
177 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:709:in `route_eval'
178 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:693:in `block (2 levels) in route!'
179 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:741:in `block in process_route'
180 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:738:in `catch'
181 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:738:in `process_route'
182 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:692:in `block in route!'
183 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:691:in `each'
184 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:691:in `route!'
185 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:826:in `dispatch!'
186 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:619:in `block in call!'
187 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:791:in `instance_eval'
188 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:791:in `block in invoke'
189 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:791:in `catch'
190 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:791:in `invoke'
191 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:619:in `call!'
192 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/base.rb:604:in `call'
193 > /usr/lib/ruby/gems/1.9.1/gems/sinatra-1.2.1/lib/sinatra/showexceptions.rb:21:in `call'
194 > /usr/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/lint.rb:48:in `_call'
195 > /usr/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/lint.rb:36:in `call'
196 > /usr/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/showexceptions.rb:24:in `call'
197 > /usr/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/commonlogger.rb:18:in `call'
198 > /usr/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/content_length.rb:13:in `call'
199 > /usr/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/handler/webrick.rb:52:in `service'
200 > /usr/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service'
201 > /usr/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run'
202 > /usr/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'
203
204 These problems seem to happen because of my mails being encoded in
205 UTF-8. When the charset is "ISO-8859-1" or "US-ASCII", they appear
206 fine. But I do think everyone should use UTF-8.
207
208 In a totallly unrelated note, do you plan on syncing back heliotrope
209 work with the maildir directory ? Just to know.
210
211 Thank you for your sweet coding,
212
213 --
214 Matthieu RAKOTOJAONA
215
216 From wmorgan-sup@masanjin.net Sun Apr 3 16:44:17 2011
217 From: wmorgan-sup@masanjin.net (William Morgan)
218 Date: Sun, 03 Apr 2011 20:44:17 +0000
219 Subject: [sup-devel] turnsole alpha preview
220 In-Reply-To: <1301776782-sup-4638@masanjin.net>
221 References: <1301767622-sup-4907@masanjin.net>
222 <1301770677-sup-9153@midna.zekjur.net>
223 <1301776782-sup-4638@masanjin.net>
224 Message-ID: <1301863418-sup-788@masanjin.net>
225
226 Reformatted excerpts from William Morgan's message of 2011-04-02:
227 > I've love a stacktrace for both that and the gpg key thing in turnsole.
228 > Thanks!
229
230 I think I've fixed both of these. Can you try with the latest heliotrope
231 and the latest turnsole master?
232 --
233 William <wmorgan-sup at masanjin.net>
234
235 From wmorgan-sup@masanjin.net Sun Apr 3 16:52:08 2011
236 From: wmorgan-sup@masanjin.net (William Morgan)
237 Date: Sun, 03 Apr 2011 20:52:08 +0000
238 Subject: [sup-devel] [sup-talk] turnsole alpha preview
239 In-Reply-To: <AANLkTimv9yUTMQ+Xc8bshBFU-eogs-K-6QVWLY+_J3aY@mail.gmail.com>
240 References: <1301767622-sup-4907@masanjin.net>
241 <AANLkTimv9yUTMQ+Xc8bshBFU-eogs-K-6QVWLY+_J3aY@mail.gmail.com>
242 Message-ID: <1301863573-sup-881@masanjin.net>
243
244 Hi Matthieu,
245
246 Thanks for the detailed bug reports.
247
248 Reformatted excerpts from Matthieu Rakotojaona's message of 2011-04-02:
249 > >/home/rakoo/src/turnsole/lib/turnsole/ncurses-patches.rb:19:in `block in <module:Curses>': undefined method `color!' for Curses:Module (NoMethodError)
250
251 I think this is fixed in the latest turnsole master. Can you please try it?
252
253 > >/home/rakoo/src/turnsole/lib/turnsole/accounts.rb:39:in `block in add_account': undefined method `gpgkey' for nil:NilClass (NoMethodError)
254
255 Also should be fixed in the latest turnsole master.
256
257 > Now with heliotrope, I have the problems with the encoding :
258 > - When I search for words with "?", I have an error :
259 >
260 > >HeliotropeServer::RequestError - can't parse query: parse error: line 1: syntax error, unexpected $end, expecting WORD:
261
262 Good bug! I didn't test this at all. This one I am going to have to spend a
263 little bit of time on.
264
265 > >ArgumentError - invalid byte sequence in UTF-8:
266 > > /usr/lib/ruby/gems/1.9.1/gems/rmail-1.0.0/lib/rmail/parser.rb:217:in `split'
267
268 Can you try the latest heliotrope master? I think I've fixed this.
269
270 > But I do think everyone should use UTF-8.
271
272 I kind of agree. Heliotrope is utf-8 specific. But in Turnsole I am trying to
273 be nice and support the system encoding.
274
275 > In a totallly unrelated note, do you plan on syncing back heliotrope work
276 > with the maildir directory ? Just to know.
277
278 No. Since Heliotrope is a server, I plan on avoiding that class of problem
279 entirely by a) making it easy to extract your email from Heliotrope, if you
280 decide to not use it any more, and b) eventually adding an IMAP emulation
281 layer, if you want to use other clients.
282
283 So you would entrust Heliotrope to both store, as well as index, your email, in
284 whatever way it wants to.
285 --
286 William <wmorgan-sup at masanjin.net>
287
288 From dmishd@gmail.com Mon Apr 4 19:01:18 2011
289 From: dmishd@gmail.com (Hamish)
290 Date: Tue, 05 Apr 2011 00:01:18 +0100
291 Subject: [sup-devel] editing messages outside of sup
292 In-Reply-To: <1298833983-sup-4830@pruts.nl>
293 References: <1298239068-sup-6985@whisper> <1298747943-sup-9749@whisper>
294 <1298768518-sup-4041@alvh.no-ip.org>
295 <1298774629-sup-4062@medusa> <1298819507-sup-8138@pruts.nl>
296 <1298826314-sup-276@whisper> <1298833983-sup-4830@pruts.nl>
297 Message-ID: <1301957971-sup-1165@whisper>
298
299 Excerpts from Ico Doornekamp's message of Sun Feb 27 19:44:15 +0000 2011:
300 > > Excerpts from Ico Doornekamp's message of Sun Feb 27 15:31:14 +0000 2011:
301 > > > > Hamish, definitely thank you for doing something about this. I
302 > > > > actually had a general question about this problem a while back - if
303 > > > > it is possible to edit the message independently via the approach you
304 > > > > took in this patch, why can't the editor be fired up in a
305 > > > > "nonblocking" kind of mode in the first place? Something like a
306 > > > > fork()/exec() to start the editor, and then handling SIGCHLD rather
307 > > > > than calling a variant of wait() immediately. The SIGCHLD handling
308 > > > > could check the return code from the editor, and then update the
309 > > > > message sending buffer appropriately.
310 >
311 > When the infrastructure for background-editor hooks is there, I'm ready
312 > to try to make the hook!
313
314 OK, I've pushed a change to allow hooks for this functionality. For now
315 it is just on the async_message_edit branch (in the main gitorious
316 repo).
317
318 To quote from the hook text:
319
320 Runs when 'H' is pressed in async edit mode. You can run whatever code
321 you want here - though the default case would be launching a text
322 editor. Your hook is assumed to not block, so you should use exec() or
323 fork() to launch the editor.
324
325 Once the hook has returned then sup will be responsive as usual. You will
326 still need to press 'E' to exit this buffer and send the message.
327
328 Variables:
329 file_path: The full path to the file containing the message to be edited.
330
331 Return value: None
332
333
334 If the hook did block then sup would be unresponsive, which would kind
335 of ruin the point of the exercise.
336
337 So this should work fine to launch a GUI text editor - your hook could
338 just be:
339
340 fork { system "/usr/bin/gedit #{file_path} > /dev/null 2>&1" }
341
342 (Note that if you don't redirect all output to /dev/null then you can end
343 up with the screen being written all over, which gets a bit messy ...)
344
345 The next step would be to have the async mode exit as soon as the forked
346 hook code has finished. The best way I've thought of to do this is to
347 trap SIGUSR1. As long as there was only one async mode active this would
348 work fine, but if there were two there would be trouble. I guess I could
349 add a return value to the hook about whether to pay attention to
350 SIGUSR1. Then the BufferManager could know which buffer was waiting for
351 SIGUSR1. If a second buffer called the same hook while the first was
352 still waiting for the signal, then it should refuse to honour it. It
353 does feel a bit messy ... I might have a go at it at some point, but if
354 anyone has other ideas, then please shout out.
355
356 Hamish
357
358 From sup@zevv.nl Tue Apr 5 00:38:06 2011
359 From: sup@zevv.nl (Ico Doornekamp)
360 Date: Tue, 05 Apr 2011 06:38:06 +0200
361 Subject: [sup-devel] editing messages outside of sup
362 In-Reply-To: <1301957971-sup-1165@whisper>
363 References: <1298239068-sup-6985@whisper> <1298747943-sup-9749@whisper>
364 <1298768518-sup-4041@alvh.no-ip.org>
365 <1298774629-sup-4062@medusa> <1298819507-sup-8138@pruts.nl>
366 <1298826314-sup-276@whisper> <1298833983-sup-4830@pruts.nl>
367 <1301957971-sup-1165@whisper>
368 Message-ID: <1301977961-sup-9660@pruts.nl>
369
370 * On Tue Apr 05 01:01:18 +0200 2011, Hamish wrote:
371
372 > > When the infrastructure for background-editor hooks is there, I'm ready
373 > > to try to make the hook!
374 >
375 > OK, I've pushed a change to allow hooks for this functionality. For now
376 > it is just on the async_message_edit branch (in the main gitorious
377 > repo).
378 >
379 > To quote from the hook text:
380 >
381 > Runs when 'H' is pressed in async edit mode. You can run whatever code
382 > you want here - though the default case would be launching a text
383 > editor. Your hook is assumed to not block, so you should use exec() or
384 > fork() to launch the editor.
385 >
386 > Once the hook has returned then sup will be responsive as usual. You will
387 > still need to press 'E' to exit this buffer and send the message.
388
389 Sounds very useful to me!
390
391 > The next step would be to have the async mode exit as soon as the forked
392 > hook code has finished. The best way I've thought of to do this is to
393 > trap SIGUSR1. As long as there was only one async mode active this would
394 > work fine, but if there were two there would be trouble. I guess I could
395 > add a return value to the hook about whether to pay attention to
396 > SIGUSR1. Then the BufferManager could know which buffer was waiting for
397 > SIGUSR1. If a second buffer called the same hook while the first was
398 > still waiting for the signal, then it should refuse to honour it. It
399 > does feel a bit messy ... I might have a go at it at some point, but if
400 > anyone has other ideas, then please shout out.
401
402 I might have understood the details of your implementation wrong, but
403 why would it not just be possible to act on a SIGCHLD and use wait() to
404 retreive the pid and exitstatus of the finished process ? The pid would
405 distinguish the different async handlers, resolving the ambiguity ?
406
407 Thanks!
408
409 --
410 :wq
411 ^X^Cy^K^X^C^C^C^C
412
413 From alvherre@alvh.no-ip.org Wed Apr 13 16:18:24 2011
414 From: alvherre@alvh.no-ip.org (Alvaro Herrera)
415 Date: Wed, 13 Apr 2011 17:18:24 -0300
416 Subject: [sup-devel] sup v2 progress report
417 In-Reply-To: <1301257195-sup-9486@masanjin.net>
418 References: <1301257195-sup-9486@masanjin.net>
419 Message-ID: <1302724410-sup-5965@alvh.no-ip.org>
420
421 Excerpts from William Morgan's message of dom mar 27 17:41:59 -0300 2011:
422
423 > Heliotrope, the server component, is close to ready for a version 1 release.
424 > You can find it at https://github.com/wmorgan/heliotrope/.
425
426 Hi,
427
428 I find this to be great. Thanks for writing it.
429
430 I just tried to follow the instructions on a Debian machine and noticed
431 that you need to install the package ruby1.9.1-dev in order for the
432 whistlepig and oklahoma_mixer gems. Probably most Ruby-addicted people
433 already have it so they don't see that problem, but since I'm not one of
434 those, it did bit me. I suggest this should be in the README file.
435
436 I ran into a problem importing email that has Latin1 headers. The crash
437 I got was:
438
439 /home/alvherre/Code/heliotrope/lib/heliotrope/maildir-walker.rb:44:in `block in get_date_in_file': invalid byte sequence in UTF-8 (ArgumentError)
440 from /home/alvherre/Code/heliotrope/lib/heliotrope/maildir-walker.rb:42:in `open'
441 from /home/alvherre/Code/heliotrope/lib/heliotrope/maildir-walker.rb:42:in `get_date_in_file'
442 from /home/alvherre/Code/heliotrope/lib/heliotrope/maildir-walker.rb:35:in `block in get_files'
443 from /home/alvherre/Code/heliotrope/lib/heliotrope/maildir-walker.rb:35:in `map'
444 from /home/alvherre/Code/heliotrope/lib/heliotrope/maildir-walker.rb:35:in `get_files'
445 from /home/alvherre/Code/heliotrope/lib/heliotrope/maildir-walker.rb:21:in `done?'
446 from bin/heliotrope-add:98:in `<main>'
447
448 I added a debugging rescue to that block and found that the message has
449 this header:
450 List-Id: Consultas T<E9>cnicas sobre Linux y Software Libre <l-linux.velug.org.ve>
451
452 Note that the <E9> is actually a Latin-1 "?". (The message has a valid Date:
453 header).
454
455 This is obviously a bogus message; you're not supposed to use non-ASCII
456 chars in the header. But these guys did it anyway. I'm not sure what
457 would be a good fix for this problem. I guess it involves discarding
458 the failing line so that it can index the message using the proper date
459 instead of "0".
460
461 I haven't tried Turnsole yet. I checked the WEBrick thingy and it seems
462 pretty neat.
463
464 Thanks!
465
466 --
467 ?lvaro Herrera <alvherre at alvh.no-ip.org>
468
469 From sup@zevv.nl Thu Apr 14 03:39:44 2011
470 From: sup@zevv.nl (Ico Doornekamp)
471 Date: Thu, 14 Apr 2011 09:39:44 +0200
472 Subject: [sup-devel] sup v2 progress report
473 In-Reply-To: <1301257195-sup-9486@masanjin.net>
474 References: <1301257195-sup-9486@masanjin.net>
475 Message-ID: <1302766464-sup-8275@pruts.nl>
476
477 * On Sun Mar 27 22:41:59 +0200 2011, William Morgan wrote:
478
479 > Heliotrope, the server component, is close to ready for a version 1 release.
480 > You can find it at https://github.com/wmorgan/heliotrope/.
481
482 Heliotrope (Actually Time.parse()) crashes on some illegaly formatted dates:
483
484 /usr/lib/ruby/1.9.1/time.rb:137:in `apply_offset': undefined method `<' for nil:NilClass (NoMethodError)
485 from /usr/lib/ruby/1.9.1/time.rb:197:in `make_time'
486 from /usr/lib/ruby/1.9.1/time.rb:261:in `parse'
487 from /home/ico/external/heliotrope/lib/heliotrope/message.rb:27:in `parse!'
488 from bin/heliotrope-add:108:in `<main>'
489
490 The date of the message was "Wed, 7 2005 22:55: 1 -0180".
491
492 Fixed by adding a NoMethodError catch:
493
494 diff --git a/lib/heliotrope/message.rb b/lib/heliotrope/message.rb
495 index 1682062..d63e411 100644
496 --- a/lib/heliotrope/message.rb
497 +++ b/lib/heliotrope/message.rb
498 @@ -23,7 +23,7 @@ class Message
499 @from = Person.from_string decode_header(validate_field(:from, @m.header["from"]))
500 @date = begin
501 Time.parse(validate_field(:date, @m.header["date"])).to_i
502 - rescue ArgumentError
503 + rescue ArgumentError, NoMethodError
504 #puts "warning: invalid date field #{@m.header['date']}"
505 Time.at 0
506 end
507
508
509 --
510 :wq
511 ^X^Cy^K^X^C^C^C^C
512
513 From sup@zevv.nl Thu Apr 14 03:51:50 2011
514 From: sup@zevv.nl (Ico Doornekamp)
515 Date: Thu, 14 Apr 2011 09:51:50 +0200
516 Subject: [sup-devel] sup v2 progress report
517 In-Reply-To: <1301257195-sup-9486@masanjin.net>
518 References: <1301257195-sup-9486@masanjin.net>
519 Message-ID: <1302767233-sup-1329@pruts.nl>
520
521 * On Sun Mar 27 22:41:59 +0200 2011, William Morgan wrote:
522
523 > Heliotrope, the server component, is close to ready for a version 1 release.
524 > You can find it at https://github.com/wmorgan/heliotrope/.
525
526 Here's another crash, but I've not been able yet to find out what exactly is
527 happening. The problem seems to be caused by a mismatch of multipart mime
528 boundary strings.
529
530 /home/ico/external/heliotrope/lib/heliotrope/message.rb:151:in `decode_mime_parts': undefined method `multipart?' for nil:NilClass (NoMethodError)
531 from /home/ico/external/heliotrope/lib/heliotrope/message.rb:154:in `decode_mime_parts'
532 from /home/ico/external/heliotrope/lib/heliotrope/message.rb:130:in `mime_parts'
533 from /home/ico/external/heliotrope/lib/heliotrope/message.rb:116:in `has_attachment?'
534 from /home/ico/external/heliotrope/lib/heliotrope/index.rb:77:in `add_message'
535 from bin/heliotrope-add:113:in `<main>'
536 You have new mail in /home/ico/Maildir
537
538
539 I've stripped the offending mail down to the following minimal mbox which causes the crash:
540
541
542 >From foo at bar.com Tue May 9 11:22:38 2006
543 Date: Tue, 09 May 2006 02:22:18 -0800
544 From: foo@bar.com
545 Mime-Version: 1.0
546 Content-Type: multipart/alternative; boundary="one"
547 Message-Id: <1>
548
549 --two
550
551 Part
552
553 --three
554
555
556
557 --
558 :wq
559 ^X^Cy^K^X^C^C^C^C
560
561 From gregor@hoffleit.de Fri Apr 15 06:46:40 2011
562 From: gregor@hoffleit.de (Gregor Hoffleit)
563 Date: Fri, 15 Apr 2011 12:46:40 +0200
564 Subject: [sup-devel] sup-server revisited
565 In-Reply-To: <1299179837-sup-4675@masanjin.net>
566 References: <1298320404-sup-5972@masanjin.net> <1298744738-sup-631@whisper>
567 <1298757625-sup-9756@masanjin.net>
568 <1298762120-sup-1118@masanjin.net> <1299008245-sup-5110@whisper>
569 <1299062215-sup-8517@sam.mediasupervision.de>
570 <1299091467-sup-7084@masanjin.net>
571 <1299172989-sup-8183@sam.mediasupervision.de>
572 <1299179837-sup-4675@masanjin.net>
573 Message-ID: <1302789095-sup-9782@sam.mediasupervision.de>
574
575 * William Morgan <wmorgan-sup at masanjin.net> [Do M?r 03 20:17:36 +0100 2011]
576 > Reformatted excerpts from Gregor Hoffleit's message of 2011-03-03:
577 > > William, I was able to isolate my problem: For me, heliotrope-add hangs
578 > > for messages with more than 32768 content lines.
579 >
580 > Crazy! I will take a look. Thanks for the good debugging.
581
582 William, I noticed that heliotrope still has a problem with mails with
583 my mail with more than 32768 lines of content.
584
585 The source of this problem is in whistlepig's tokenizer. I'm hurt by an
586 overflow in posarray->next and posarray->size, which are defined as
587 uint16_t. I was able to fix my problem by defining these to uint32_t:
588
589
590 commit 42dbc087260074513af22078b77e65b91d3318d9
591 Author: Gregor Hoffleit <gregor at hoffleit.de>
592 Date: Fri Apr 15 12:19:10 2011 +0200
593
594 Bugfix: uint16_t is too small for posarray->size and posarray->next
595
596 Change the type of posarray->size and posarray->next from uint16_t
597 to uint32_t. 16 bits are not enough to hold really large messages.
598
599 diff --git a/entry.h b/entry.h
600 index 9799e15..56673a0 100644
601 --- a/entry.h
602 +++ b/entry.h
603 @@ -15,8 +15,8 @@
604 #include "khash.h"
605
606 typedef struct posarray {
607 - uint16_t size;
608 - uint16_t next;
609 + uint32_t size;
610 + uint32_t next;
611 pos_t* data;
612 } posarray;
613
614
615
616 Regards,
617 Gregor Hoffleit
618
619 From wmorgan-sup@masanjin.net Fri Apr 15 13:16:43 2011
620 From: wmorgan-sup@masanjin.net (William Morgan)
621 Date: Fri, 15 Apr 2011 17:16:43 +0000
622 Subject: [sup-devel] sup-server revisited
623 In-Reply-To: <1302789095-sup-9782@sam.mediasupervision.de>
624 References: <1298320404-sup-5972@masanjin.net> <1298744738-sup-631@whisper>
625 <1298757625-sup-9756@masanjin.net>
626 <1298762120-sup-1118@masanjin.net> <1299008245-sup-5110@whisper>
627 <1299062215-sup-8517@sam.mediasupervision.de>
628 <1299091467-sup-7084@masanjin.net>
629 <1299172989-sup-8183@sam.mediasupervision.de>
630 <1299179837-sup-4675@masanjin.net>
631 <1302789095-sup-9782@sam.mediasupervision.de>
632 Message-ID: <1302887129-sup-7325@masanjin.net>
633
634 Reformatted excerpts from Gregor Hoffleit's message of 2011-04-15:
635 > The source of this problem is in whistlepig's tokenizer. I'm hurt by an
636 > overflow in posarray->next and posarray->size, which are defined as
637 > uint16_t. I was able to fix my problem by defining these to uint32_t:
638
639 Thanks! This is totally good. I will admit I got distracted by some
640 other tasks and forgot to come back to this. Maybe that's a sign I
641 should start using Github's vaunted issue tracker.
642
643 What I don't understand is that the posarray stuff is all for token
644 offsets, isn't it? So why would the number of lines actually matter?
645 Large messages can overflow this but it should be in terms of tokens,
646 not lines.
647 --
648 William <wmorgan-sup at masanjin.net>
649
650 From gregor@hoffleit.de Fri Apr 15 16:53:21 2011
651 From: gregor@hoffleit.de (Gregor Hoffleit)
652 Date: Fri, 15 Apr 2011 22:53:21 +0200
653 Subject: [sup-devel] sup-server revisited
654 In-Reply-To: <1302887129-sup-7325@masanjin.net>
655 References: <1298320404-sup-5972@masanjin.net> <1298744738-sup-631@whisper>
656 <1298757625-sup-9756@masanjin.net>
657 <1298762120-sup-1118@masanjin.net> <1299008245-sup-5110@whisper>
658 <1299062215-sup-8517@sam.mediasupervision.de>
659 <1299091467-sup-7084@masanjin.net>
660 <1299172989-sup-8183@sam.mediasupervision.de>
661 <1299179837-sup-4675@masanjin.net>
662 <1302789095-sup-9782@sam.mediasupervision.de>
663 <1302887129-sup-7325@masanjin.net>
664 Message-ID: <1302900208-sup-1898@sam.mediasupervision.de>
665
666 * William Morgan <wmorgan-sup at masanjin.net> [Fr Apr 15 19:16:43 +0200 2011]
667 > Reformatted excerpts from Gregor Hoffleit's message of 2011-04-15:
668 > > The source of this problem is in whistlepig's tokenizer. I'm hurt by an
669 > > overflow in posarray->next and posarray->size, which are defined as
670 > > uint16_t. I was able to fix my problem by defining these to uint32_t:
671 >
672 > Thanks! This is totally good. I will admit I got distracted by some
673 > other tasks and forgot to come back to this. Maybe that's a sign I
674 > should start using Github's vaunted issue tracker.
675 >
676 > What I don't understand is that the posarray stuff is all for token
677 > offsets, isn't it? So why would the number of lines actually matter?
678 > Large messages can overflow this but it should be in terms of tokens,
679 > not lines.
680
681 Yep. In fact the number of lines is a pure coincidence.
682
683 The mail that got stuck was a logcheck report, which had 35.000 lines
684 all starting with the current date. I guess whistlepig tried to append
685 some 35.000 instances of "Feb" to the posarray, which lead to an
686 infinite loop.
687
688 Regards,
689 Gregor
690
691 From wmorgan-sup@masanjin.net Sun Apr 17 12:58:06 2011
692 From: wmorgan-sup@masanjin.net (William Morgan)
693 Date: Sun, 17 Apr 2011 16:58:06 +0000
694 Subject: [sup-devel] sup-server revisited
695 In-Reply-To: <1302789095-sup-9782@sam.mediasupervision.de>
696 References: <1298320404-sup-5972@masanjin.net> <1298744738-sup-631@whisper>
697 <1298757625-sup-9756@masanjin.net>
698 <1298762120-sup-1118@masanjin.net> <1299008245-sup-5110@whisper>
699 <1299062215-sup-8517@sam.mediasupervision.de>
700 <1299091467-sup-7084@masanjin.net>
701 <1299172989-sup-8183@sam.mediasupervision.de>
702 <1299179837-sup-4675@masanjin.net>
703 <1302789095-sup-9782@sam.mediasupervision.de>
704 Message-ID: <1303022861-sup-8661@masanjin.net>
705
706 Reformatted excerpts from Gregor Hoffleit's message of 2011-04-15:
707 > Bugfix: uint16_t is too small for posarray->size and posarray->next
708
709 Applied. Thanks!
710 --
711 William <wmorgan-sup at masanjin.net>
712
713 From wmorgan-sup@masanjin.net Sun Apr 17 13:55:06 2011
714 From: wmorgan-sup@masanjin.net (William Morgan)
715 Date: Sun, 17 Apr 2011 17:55:06 +0000
716 Subject: [sup-devel] sup-server revisited
717 In-Reply-To: <1303022861-sup-8661@masanjin.net>
718 References: <1298320404-sup-5972@masanjin.net> <1298744738-sup-631@whisper>
719 <1298757625-sup-9756@masanjin.net>
720 <1298762120-sup-1118@masanjin.net> <1299008245-sup-5110@whisper>
721 <1299062215-sup-8517@sam.mediasupervision.de>
722 <1299091467-sup-7084@masanjin.net>
723 <1299172989-sup-8183@sam.mediasupervision.de>
724 <1299179837-sup-4675@masanjin.net>
725 <1302789095-sup-9782@sam.mediasupervision.de>
726 <1303022861-sup-8661@masanjin.net>
727 Message-ID: <1303062778-sup-7536@masanjin.net>
728
729 Reformatted excerpts from William Morgan's message of 2011-04-17:
730 > Reformatted excerpts from Gregor Hoffleit's message of 2011-04-15:
731 > > Bugfix: uint16_t is too small for posarray->size and posarray->next
732 >
733 > Applied. Thanks!
734
735 I have released this as 0.5. Also, I have pushed a forced update to
736 whistlepig master in order to correct some erroneous email addresses in
737 the commit logs, so you'll have to reset your local master branch next
738 time you fetch.
739 --
740 William <wmorgan-sup at masanjin.net>
741
742 From gregor@hoffleit.de Thu Apr 21 06:18:52 2011
743 From: gregor@hoffleit.de (Gregor Hoffleit)
744 Date: Thu, 21 Apr 2011 12:18:52 +0200
745 Subject: [sup-devel] heliotrope: Crash with empty message.recipients
746 Message-ID: <1303381090-sup-9904@sam.mediasupervision.de>
747
748 I noticed that heliotrope-add bangs out on message
749 <E1JZvDB-0000vf-17 at faramir.fjphome.nl> from the debian-vote list:
750 http://lists.debian.org/debian-vote/2008/03/msg00130.html
751
752 # ruby1.9.1 -Ilib ./bin/heliotrope-add -m debian-vote-2008 -d test
753 /home/test/GIT/heliotrope/lib/heliotrope/index.rb:482:in `block in index!': undefined method `indexable_text' for nil:NilClass (NoMethodError)
754 from /home/test/GIT/heliotrope/lib/heliotrope/index.rb:482:in `map'
755 from /home/test/GIT/heliotrope/lib/heliotrope/index.rb:482:in `index!'
756 from /home/test/GIT/heliotrope/lib/heliotrope/index.rb:80:in `add_message'
757 from ./bin/heliotrope-add:113:in `<main>'
758
759 As you can see even in the HTML representation of the message linked
760 above:
761
762 To: , debian-vote at lists.debian.org
763
764 This code in line 482 of lib/heliotrope/index.rb will fail work if any
765 recipient is empty:
766
767 message.recipients.map { |x| x.indexable_text }.join(" ").downcase
768
769 Sadly, I'm lacking the Ruby skills to make heliotrope cope with such
770 pathological messages. In Python, I would fix it like this:
771
772 [x.indexable_text for x in message.recipients if x]
773
774 Regards,
775 Gregor
776
777 From vnhnsn@gmail.com Sat Apr 23 20:46:59 2011
778 From: vnhnsn@gmail.com (Evan Hanson)
779 Date: Sat, 23 Apr 2011 19:46:59 -0500
780 Subject: [sup-devel] [PATCH] toggle killed status
781 Message-ID: <1303605889-sup-5283@Apollo.local>
782
783 Attached allows toggling 'killed' status of a thread. If there was a way to do
784 this previously, please ignore.
785
786 UpdateManager didn't seem responsive to 'killed'/'unkilled' so uses 'labeled'.
787
788 Evan
789 -------------- next part --------------
790 A non-text attachment was scrubbed...
791 Name: toggle-killed-status.patch
792 Type: application/octet-stream
793 Size: 1464 bytes
794 Desc: not available
795 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20110423/fb5001da/attachment.obj>
796 -------------- next part --------------
797 A non-text attachment was scrubbed...
798 Name: signature.asc
799 Type: application/pgp-signature
800 Size: 487 bytes
801 Desc: not available
802 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20110423/fb5001da/attachment.bin>
803
804 From hsanson@gmail.com Sun Apr 24 21:23:19 2011
805 From: hsanson@gmail.com (Horacio Sanson)
806 Date: Mon, 25 Apr 2011 10:23:19 +0900
807 Subject: [sup-devel] Cannot query Japanese characters
808 Message-ID: <201104251023.19659.hsanson@gmail.com>
809
810 I like sup's idea and have a lot of hope in heliotrope but unfortunately both
811 have problems when dealing with my language: Japanese.
812
813 When I put a search string like this "subject: ??" I get the following crash:
814
815 27.0.0.1 - - [25/Apr/2011 10:17:17] "GET /search?q=%E6%89%8B%E7%B4%99
816 HTTP/1.1" 200 12306 0.0169
817 localhost.localdomain - - [25/Apr/2011:10:17:17 JST] "GET
818 /search?q=%E6%89%8B%E7%B4%99 HTTP/1.1" 200 12306
819 http://localhost:8042/search?q=%E6%89%8B%E7%B4%99 ->
820 /search?q=%E6%89%8B%E7%B4%99
821 127.0.0.1 - - [25/Apr/2011 10:17:17] "GET /favicon.ico HTTP/1.1" 404 441
822 0.0007
823 localhost.localdomain - - [25/Apr/2011:10:17:17 JST] "GET /favicon.ico
824 HTTP/1.1" 404 441
825 - -> /favicon.ico
826 HeliotropeServer::RequestError - can't parse query: parse error: line 1:
827 syntax error, unexpected $end, expecting WORD or '"' or '(':
828 bin/heliotrope-server:161:in `rescue in block in <class:HeliotropeServer>'
829 bin/heliotrope-server:138:in `block in <class:HeliotropeServer>'
830 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:1165:in `call'
831 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:1165:in `block in
832 compile!'
833 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:738:in
834 `instance_eval'
835 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:738:in
836 `route_eval'
837 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:722:in `block (2
838 levels) in route!'
839 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:772:in `block in
840 process_route'
841 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:769:in `catch'
842 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:769:in
843 `process_route'
844 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:721:in `block in
845 route!'
846 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:720:in `each'
847 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:720:in `route!'
848 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:857:in `dispatch!'
849 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:648:in `block in
850 call!'
851 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:822:in
852 `instance_eval'
853 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:822:in `block in
854 invoke'
855 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:822:in `catch'
856 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:822:in `invoke'
857 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:648:in `call!'
858 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/base.rb:633:in `call'
859 /var/lib/gems/1.9.1/gems/sinatra-1.2.3/lib/sinatra/showexceptions.rb:21:in
860 `call'
861 /var/lib/gems/1.9.1/gems/rack-1.2.2/lib/rack/lint.rb:48:in `_call'
862 /var/lib/gems/1.9.1/gems/rack-1.2.2/lib/rack/lint.rb:36:in `call'
863 /var/lib/gems/1.9.1/gems/rack-1.2.2/lib/rack/showexceptions.rb:24:in `call'
864 /var/lib/gems/1.9.1/gems/rack-1.2.2/lib/rack/commonlogger.rb:18:in `call'
865 /var/lib/gems/1.9.1/gems/rack-1.2.2/lib/rack/content_length.rb:13:in `call'
866 /var/lib/gems/1.9.1/gems/rack-1.2.2/lib/rack/handler/webrick.rb:52:in
867 `service'
868 /usr/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service'
869 /usr/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run'
870 /usr/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'
871 127.0.0.1 - - [25/Apr/2011 10:17:28] "GET
872 /search?q=subject%3A+%E6%89%8B%E7%B4%99 HTTP/1.1" 500 92955 0.0266
873 localhost.localdomain - - [25/Apr/2011:10:17:28 JST] "GET
874 /search?q=subject%3A+%E6%89%8B%E7%B4%99 HTTP/1.1" 500 92955
875 http://localhost:8042/search?q=%E6%89%8B%E7%B4%99 ->
876 /search?q=subject%3A+%E6%89%8B%E7%B4%99
877 127.0.0.1 - - [25/Apr/2011 10:17:28] "GET /__sinatra__/500.png HTTP/1.1" 304 -
878 0.0006
879 localhost.localdomain - - [25/Apr/2011:10:17:28 JST] "GET /__sinatra__/500.png
880 HTTP/1.1" 304 0
881 http://localhost:8042/search?q=subject%3A+%E6%89%8B%E7%B4%99 ->
882 /__sinatra__/500.png
883 127.0.0.1 - - [25/Apr/2011 10:17:28] "GET /favicon.ico HTTP/1.1" 404 441
884 0.0008
885 localhost.localdomain - - [25/Apr/2011:10:17:28 JST] "GET /favicon.ico
886 HTTP/1.1" 404 441
887
888
889
890 I am running the latest heliotrope from git with ruby 1.9.2 from the default
891 Kubuntu 10.10 distribution.
892
893
894 --
895 regards,
896 Horacio Sanson
897
898 From hsanson@gmail.com Sun Apr 24 22:25:04 2011
899 From: hsanson@gmail.com (Horacio Sanson)
900 Date: Mon, 25 Apr 2011 11:25:04 +0900
901 Subject: [sup-devel] turnsole cannot handle Japanese labels.
902 Message-ID: <201104251125.04792.hsanson@gmail.com>
903
904 Any attempt to add a label with Japanese characters crashes the application.
905 Seems this is a common problem to all Ruby 1.9 applications. I can see Rails
906 had or has a lot of problems with this:
907
908 http://yehudakatz.com/2010/05/05/ruby-1-9-encodings-a-primer-and-the-solution-
909 for-rails/
910
911 https://rails.lighthouseapp.com/projects/8994/tickets/4683-ascii-8bit-and-
912 utf-8-in-hell
913
914
915 The backtrace I get follows:
916
917 /var/lib/gems/1.9.1/gems/console-0.3/lib/console/string.rb:27:in
918 `display_width': "\xE3" from ASCII-8BIT to UTF-8
919 (Encoding::UndefinedConversionError)
920 from /var/lib/gems/1.9.1/gems/console-0.3/lib/console/string.rb:27:in
921 `display_width'
922 from /home/ryujin/Apps/turnsole/lib/turnsole/textfield.rb:129:in
923 `handle_input'
924 from /home/ryujin/Apps/turnsole/lib/turnsole/input.rb:108:in `ask'
925 from /home/ryujin/Apps/turnsole/lib/turnsole/input.rb:141:in
926 `ask_many_with_completions'
927 from /home/ryujin/Apps/turnsole/lib/turnsole/input.rb:198:in
928 `ask_for_labels'
929 from /home/ryujin/Apps/turnsole/lib/turnsole/modes/thread-index-
930 mode.rb:585:in `block in edit_labels'
931 from /home/ryujin/Apps/turnsole/lib/turnsole/input.rb:42:in `asking'
932 from /home/ryujin/Apps/turnsole/lib/turnsole/modes/thread-index-
933 mode.rb:584:in `edit_labels'
934 from /home/ryujin/Apps/turnsole/lib/turnsole/input.rb:92:in `handle'
935 from /home/ryujin/Apps/turnsole/lib/turnsole/ui.rb:73:in `step'
936 from bin/turnsole:134:in `<main>'
937
938 --
939 regards,
940 Horacio Sanson
941
942 From wmorgan-sup@masanjin.net Tue Apr 26 00:47:53 2011
943 From: wmorgan-sup@masanjin.net (William Morgan)
944 Date: Tue, 26 Apr 2011 04:47:53 +0000
945 Subject: [sup-devel] turnsole cannot handle Japanese labels.
946 In-Reply-To: <201104251125.04792.hsanson@gmail.com>
947 References: <201104251125.04792.hsanson@gmail.com>
948 Message-ID: <1303793197-sup-8060@masanjin.net>
949
950 Reformatted excerpts from Horacio Sanson's message of 2011-04-25:
951 > Any attempt to add a label with Japanese characters crashes the
952 > application.
953
954 Thanks for the bug report. This is a bit tricky. The problem is actually
955 that ncurses is giving me the characters one byte at a time. I'll see
956 what I can do to fix this.
957 --
958 William <wmorgan-sup at masanjin.net>
959
960 From wmorgan-sup@masanjin.net Tue Apr 26 00:49:04 2011
961 From: wmorgan-sup@masanjin.net (William Morgan)
962 Date: Tue, 26 Apr 2011 04:49:04 +0000
963 Subject: [sup-devel] Cannot query Japanese characters
964 In-Reply-To: <201104251023.19659.hsanson@gmail.com>
965 References: <201104251023.19659.hsanson@gmail.com>
966 Message-ID: <1303793294-sup-688@masanjin.net>
967
968 Reformatted excerpts from Horacio Sanson's message of 2011-04-25:
969 > I like sup's idea and have a lot of hope in heliotrope but unfortunately both
970 > have problems when dealing with my language: Japanese.
971 >
972 > When I put a search string like this "subject: ??" I get the following
973 > crash:
974
975 Thanks for the bug report on this one too. It's great to have someone testing
976 this stuff with non-ASCII code. This is a known bug in Whistlepig and I should
977 be releasing a fix soon.
978 --
979 William <wmorgan-sup at masanjin.net>
980
981 From john.wyzer@gmx.de Tue Apr 26 05:52:06 2011
982 From: john.wyzer@gmx.de (John Wyzer)
983 Date: Tue, 26 Apr 2011 11:52:06 +0200
984 Subject: [sup-devel] odd - mime-decode not working on some text/html mails
985 Message-ID: <1303810927-sup-9051@localhost>
986
987 I tried that with and without having the mime-decode.rb
988
989 ## turn text/html attachments into plain text, unless they are part
990 ## of a multipart/alternative pair
991 unless sibling_types.member? "text/plain"
992 case content_type
993 when "text/html"
994 `/usr/bin/w3m -dump -T #{content_type} '#{filename}'`
995 end
996 end
997
998 in .sup/hooks
999
1000 Some html emails that I receive work fine - I can read them as text.
1001
1002 But some are just displayed as an attachment every time. I can open them with
1003 mime-view - but I would prefer to have the text displayed without further
1004 interaction...
1005
1006 Attached is one of those messages - perhaps someone more enlightened than me
1007 could have a short look and knows instantly why sup does not do the correct
1008 thing? ;-)
1009
1010 Many thanks!
1011 -------------- next part --------------
1012 An embedded and charset-unspecified text was scrubbed...
1013 Name: anonymised-html-message.txt
1014 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20110426/12721d76/attachment.txt>
1015
1016 From wmorgan-sup@masanjin.net Fri Apr 29 00:52:47 2011
1017 From: wmorgan-sup@masanjin.net (William Morgan)
1018 Date: Fri, 29 Apr 2011 04:52:47 +0000
1019 Subject: [sup-devel] Cannot query Japanese characters
1020 In-Reply-To: <1303793294-sup-688@masanjin.net>
1021 References: <201104251023.19659.hsanson@gmail.com>
1022 <1303793294-sup-688@masanjin.net>
1023 Message-ID: <1304052708-sup-4240@masanjin.net>
1024
1025 Reformatted excerpts from William Morgan's message of 2011-04-26:
1026 > Thanks for the bug report on this one too. It's great to have someone
1027 > testing this stuff with non-ASCII code. This is a known bug in
1028 > Whistlepig and I should be releasing a fix soon.
1029
1030 This is fixed in Whistlepig 0.6. Heliotrope should now be fine with
1031 utf-8 input. I'm still working on this issue in turnsole.
1032
1033 Let me know if you have any more issues!
1034 --
1035 William <wmorgan-sup at masanjin.net>
1036