From: cworth@cworth.org (Carl Worth)
Subject: [sup-talk] In next: thread-view-mode labelling No method join for Set
Date: Wed, 19 Aug 2009 17:31:12 -0700 [thread overview]
Message-ID: <1250727630-sup-3112@yoom.home.cworth.org> (raw)
In-Reply-To: <1250714501-sup-3033@chigamba>
Excerpts from Wirt Wolff's message of Wed Aug 19 13:41:54 -0700 2009:
> Lots of great improvements in next. Love the utf8.
Agreed. These are very nice.
> When I try to 'l'abel in thread view mode, however, sup crashes with
>
> --- NoMethodError from thread: main
> undefined method `join' for #<Set: {:list, :xm}>
> ./lib/sup/buffer.rb:506:in `ask_for_labels'
I'm getting that too. It bisected down to the following which is not
so surprising:
commit 7aea418a8a62b7070eee764475fcfc0bdd8d58dd
Author: William Morgan <wmorgan-sup at masanjin.net>
Date: Tue Aug 11 16:00:52 2009 -0400
maintain labels as Sets rather than arrays
I've attached a patch that at least makes the crashes I was able ro
reproduce go away. But I have no idea if I got them all of course[*].
And please let me know if I'm doing anything wrong. I'm new to ruby as
well as sup here, so go easy on me, please! :-)
-Carl
[*] Totally off-topic: This is one of the things about "dynamically
typed" languages that I've never been able to wrap my brain around. I
really like that with static typing I can trust the compiler to help
me be very thorough if I make a type change like this, (and catch all
the cases before shipping any code). Instead, here, there's a hard
task of exercising every possible code path (at run time) before we
know if there are any type errors still lingering. I've seen some
proponents of dynamically-typed languages argue that unit testing
should provide the same coverage that a statically-typed compiler
would, but I haven't seen that in practice.
You all definitely have a lot more experience with ruby than I do, so
I'm honestly interested in learning form your experience. What do you
do to deal with cases like this?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Convert-a-couple-of-arrays-to-sets-for-labels.patch
Type: application/octet-stream
Size: 1685 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/c4120e6d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/c4120e6d/attachment.bin>
next prev parent reply other threads:[~2009-08-20 0:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-19 20:41 Wirt Wolff
2009-08-20 0:31 ` Carl Worth [this message]
2009-08-20 2:57 ` Ben Walton
2009-08-20 4:03 ` Carl Worth
2009-08-21 0:16 ` Ben Walton
2009-08-24 18:13 ` William Morgan
2009-08-25 7:44 ` Nicolas Pouillard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1250727630-sup-3112@yoom.home.cworth.org \
--to=cworth@cworth.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox