* [sup-talk] In next: thread-view-mode labelling No method join for Set
@ 2009-08-19 20:41 Wirt Wolff
2009-08-20 0:31 ` Carl Worth
0 siblings, 1 reply; 7+ messages in thread
From: Wirt Wolff @ 2009-08-19 20:41 UTC (permalink / raw)
Lots of great improvements in next. Love the utf8.
When I try to 'l'abel in thread view mode, however, sup crashes with
--- NoMethodError from thread: main
undefined method `join' for #<Set: {:list, :xm}>
./lib/sup/buffer.rb:506:in `ask_for_labels'
./lib/sup/util.rb:520:in `send'
./lib/sup/util.rb:520:in `method_missing'
./lib/sup/modes/thread-view-mode.rb:253:in `edit_labels'
./lib/sup/mode.rb:50:in `send'
./lib/sup/mode.rb:50:in `handle_input'
./lib/sup/buffer.rb:260:in `handle_input'
----------------------------------------
Most recent commit is
Merge branch 'various-api-refactors' into next
commit 3de96fb9b308afe600c7ccfcee75913f039ef4f6
run with % ruby -Ilib bin/sup
----------------------------------------
Advice how to fix?
thanks,
--
wmw
^ permalink raw reply [flat|nested] 7+ messages in thread* [sup-talk] In next: thread-view-mode labelling No method join for Set
2009-08-19 20:41 [sup-talk] In next: thread-view-mode labelling No method join for Set Wirt Wolff
@ 2009-08-20 0:31 ` Carl Worth
2009-08-20 2:57 ` Ben Walton
2009-08-24 18:13 ` William Morgan
0 siblings, 2 replies; 7+ messages in thread
From: Carl Worth @ 2009-08-20 0:31 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 7+ messages in thread* [sup-talk] In next: thread-view-mode labelling No method join for Set
2009-08-20 0:31 ` Carl Worth
@ 2009-08-20 2:57 ` Ben Walton
2009-08-20 4:03 ` Carl Worth
2009-08-24 18:13 ` William Morgan
1 sibling, 1 reply; 7+ messages in thread
From: Ben Walton @ 2009-08-20 2:57 UTC (permalink / raw)
Excerpts from Carl Worth's message of Wed Aug 19 20:31:12 -0400 2009:
> [*] Totally off-topic: This is one of the things about "dynamically
> typed" languages that I've never been able to wrap my brain around. I
> really like that with static typing I can trust the compiler to help
> me be very thorough if I make a type change like this, (and catch all
> the cases before shipping any code). Instead, here, there's a hard
> task of exercising every possible code path (at run time) before we
> know if there are any type errors still lingering. I've seen some
> proponents of dynamically-typed languages argue that unit testing
> should provide the same coverage that a statically-typed compiler
> would, but I haven't seen that in practice.
The term you'll see bandied about in ruby circles/books/etc is 'duck
typing' which coming from strongly typed languages is definitely
something that takes some getting used to. Basically, instead of
caring about the type of the object, you case about what the object
does. If it walks like a duck and quacks like a duck, treat it like a
duck.
A very simple example is a function that expects to append data to
another object. You could pass it a string (which uses << to append)
or an array (which uses << to push elements on the end). If you
originally passed a string, but found performance (memory ->
realloc()) issues, you could swap the string object for an array
object and do array.join when everything is collected into array
elements.
Then, you'll see many examples where there is code like:
raise SomeException, "blah" unless someobject.respond_to?(:somemethod)
Your code doesn't care _what kind_ of object it gets as long as it
knows _how_ to talk to it.
Personally, I really like this. Ruby isn't perfect by any stretch,
but of all the languages I've used, it's hands down the most fun to
write.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/a644ea46/attachment.bin>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [sup-talk] In next: thread-view-mode labelling No method join for Set
2009-08-20 2:57 ` Ben Walton
@ 2009-08-20 4:03 ` Carl Worth
2009-08-21 0:16 ` Ben Walton
0 siblings, 1 reply; 7+ messages in thread
From: Carl Worth @ 2009-08-20 4:03 UTC (permalink / raw)
Excerpts from Ben Walton's message of Wed Aug 19 19:57:25 -0700 2009:
> Excerpts from Carl Worth's message of Wed Aug 19 20:31:12 -0400 2009:
>
> > [*] Totally off-topic: This is one of the things about "dynamically
> > typed" languages that I've never been able to wrap my brain around. I
> > really like that with static typing I can trust the compiler to help
> > me be very thorough if I make a type change like this, (and catch all
> > the cases before shipping any code).
...
> The term you'll see bandied about in ruby circles/books/etc is 'duck
> typing' which coming from strongly typed languages is definitely
> something that takes some getting used to. Basically, instead of
> caring about the type of the object, you case about what the object
> does. If it walks like a duck and quacks like a duck, treat it like a
> duck.
Yes, I understand that just fine. But two points:
1. That's not actually helping in the current case where we're trying
to do simple things like '+' and the distinction between Set and
Array is causing problems. (See the patch where we're having to add
.to_a and Set.new to coerce things.) So, here, at least things are
falling down. So somehow something in ruby isn't living up to the
concept here.
> Then, you'll see many examples where there is code like:
>
> raise SomeException, "blah" unless someobject.respond_to?(:somemethod)
>
> Your code doesn't care _what kind_ of object it gets as long as it
> knows _how_ to talk to it.
2. Even with the "duck typing" I'd still like to express this
constraint in a way that is decidable statically. I've definitely
failed as a programmer if a user sees a runtime exception like
that. Sytems with sophisticated runtimes are very interesting to
me. It's just discouraging to me that so many such systems fail to
actually help me avoid problems like this before the user is
running my code.
> Personally, I really like this. Ruby isn't perfect by any stretch,
> but of all the languages I've used, it's hands down the most fun to
> write.
That could still be the case for me here. I haven't tried much with it
yet, so I don't have any strong opinion there yet. :-)
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/aae17dcd/attachment.bin>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [sup-talk] In next: thread-view-mode labelling No method join for Set
2009-08-20 4:03 ` Carl Worth
@ 2009-08-21 0:16 ` Ben Walton
0 siblings, 0 replies; 7+ messages in thread
From: Ben Walton @ 2009-08-21 0:16 UTC (permalink / raw)
Excerpts from Carl Worth's message of Thu Aug 20 00:03:08 -0400 2009:
> 1. That's not actually helping in the current case where we're trying
> to do simple things like '+' and the distinction between Set and
> Array is causing problems. (See the patch where we're having to add
> .to_a and Set.new to coerce things.) So, here, at least things are
> falling down. So somehow something in ruby isn't living up to the
> concept here.
You're correct. The difference between fixing this in Ruby vs fixing
this in a strongly typed language though is that you could implement
Set#join such that the code expecting an array wouldn't know the
difference _or_ you could have that code use kind_of?(Array) to ensure
it was getting the type of argument it was expecting. Both are
technically correct.
In a strongly typed language, you'd have to modify the acceptable
arguments (function definition) and ensure everything that called the
function passed something acceptable or provide an overloaded version
(if you're working with a language that supports it).
Those are correct solutions too.
> > Your code doesn't care _what kind_ of object it gets as long as it
> > knows _how_ to talk to it.
>
> 2. Even with the "duck typing" I'd still like to express this
> constraint in a way that is decidable statically. I've definitely
> failed as a programmer if a user sees a runtime exception like
> that. Sytems with sophisticated runtimes are very interesting to
> me. It's just discouraging to me that so many such systems fail to
> actually help me avoid problems like this before the user is
> running my code.
Bugs are bugs! :) Static typing only goes so far to prevent some of
this stuff...just look what you can make a C compiler do with funky
casts. I take your point though.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/575e53e4/attachment.bin>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [sup-talk] In next: thread-view-mode labelling No method join for Set
2009-08-20 0:31 ` Carl Worth
2009-08-20 2:57 ` Ben Walton
@ 2009-08-24 18:13 ` William Morgan
2009-08-25 7:44 ` Nicolas Pouillard
1 sibling, 1 reply; 7+ messages in thread
From: William Morgan @ 2009-08-24 18:13 UTC (permalink / raw)
Reformatted excerpts from Carl Worth's message of 2009-08-19:
> I've attached a patch that at least makes the crashes I was able ro
> reproduce go away.
Applied, thanks!
> [*] Totally off-topic: This is one of the things about "dynamically
> typed" languages that I've never been able to wrap my brain around. I
> really like that with static typing I can trust the compiler to help
> me be very thorough if I make a type change like this, (and catch all
> the cases before shipping any code). Instead, here, there's a hard
> task of exercising every possible code path (at run time) before we
> know if there are any type errors still lingering. I've seen some
> proponents of dynamically-typed languages argue that unit testing
> should provide the same coverage that a statically-typed compiler
> would, but I haven't seen that in practice.
You're right, this is a classic example of the type of bug that would be
caught with static typing. Unit tests are the canonical answer. I'd
argue that unit tests provide better error checking than static typing,
since they allow you to capture the exact set of errors you're
interested in, rather than the set of type mismatches that a
type-checker can detect. (IMO the two sets rarely have more than a very
small overlap.)
Unit tests are only useful, of course, if you write them. Sup doesn't
have very many. I've made an explicit choice to spend my oh-so-limited
Sup time adding new features rather than ensuring a rock-solid platform.
The occasional bug like this is the price we all pay. But it's a matter
of tradeoffs---I do believe that if I were using a statically-typed
language, development would be significantly slower, and Sup would be
nowhere near the point it is now. I have no proof of this statement, of
course.
And if anyone wants to retrofit some unit tests, I'm more than happy to
accept them!
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [sup-talk] In next: thread-view-mode labelling No method join for Set
2009-08-24 18:13 ` William Morgan
@ 2009-08-25 7:44 ` Nicolas Pouillard
0 siblings, 0 replies; 7+ messages in thread
From: Nicolas Pouillard @ 2009-08-25 7:44 UTC (permalink / raw)
Excerpts from William Morgan's message of Mon Aug 24 20:13:43 +0200 2009:
> Reformatted excerpts from Carl Worth's message of 2009-08-19:
> > I've attached a patch that at least makes the crashes I was able ro
> > reproduce go away.
>
> Applied, thanks!
>
> > [*] Totally off-topic: This is one of the things about "dynamically
> > typed" languages that I've never been able to wrap my brain around. I
> > really like that with static typing I can trust the compiler to help
> > me be very thorough if I make a type change like this, (and catch all
> > the cases before shipping any code). Instead, here, there's a hard
> > task of exercising every possible code path (at run time) before we
> > know if there are any type errors still lingering. I've seen some
> > proponents of dynamically-typed languages argue that unit testing
> > should provide the same coverage that a statically-typed compiler
> > would, but I haven't seen that in practice.
[...]
> I do believe that if I were using a statically-typed
> language, development would be significantly slower, and Sup would be
> nowhere near the point it is now. I have no proof of this statement, of
> course.
I don't really want to start troll on this subject... However it depends
on what kind of statically-typed language to talk about, if you mean Java
or C++ then I agree with you, the development would be much sloooower.
Although if we take a language like Haskell (or OCaml, or Scala...) the
development become really competitive.
Best regards,
--
Nicolas Pouillard
http://nicolaspouillard.fr
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-08-25 7:44 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-19 20:41 [sup-talk] In next: thread-view-mode labelling No method join for Set Wirt Wolff
2009-08-20 0:31 ` Carl Worth
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox