Levin Alexander wrote:
Ah, yes. I'd probably do it with SyncEnumerator rather than zip as
well, then[1]. I just used zip since its what you started with and you
didn't specify performance as an issue.
Performance would probably be the wrong motivation to switch to
SyncEnumerator. On my machine it is about 100 times slower then
Enumerable#zip.
sync-enum: 1.676
zip-enum: 0.018
sizedqueue: 0.226
-Levin
Thanks for bringing this up.
The variant with each_zip in Enumerable needs only one thread:
user system total real
sync-enum: 1.594000 0.500000 2.094000 ( 2.110000)
zip-enum: 0.016000 0.000000 0.016000 ( 0.015000)
sizedqueue: 0.250000 0.000000 0.250000 ( 0.250000)
each_zip: 0.125000 0.000000 0.125000 ( 0.125000)
but no match against zip-enum in terms of speed.
Still interesting that threads are 10 times faster in this case than continuations.
cheers
Simon
compare.bm.rb (1.23 KB)
···
On 9/2/05, Jacob Fugal <lukfugl@gmail.com> wrote:
[...]
Ah, sorry, I missed the fact that you were iterating over characters
instead of lines. 10 == ?\n. Gotcha.
But isn't that different than the original functionality? He
originally wanted a warning (specifically assert_equal as part of
Test::Unit) for each line that differed. Your code will only match the
first such case then break out of the loop.
Jacob Fugal
hmm, true .. on the other hand assert_equal throws an AssertionFailedError, so this is kind of breaking out of the loop also. (But right, its not the same thing)
cheers
Simon
Yeah, I should have looked into that before my first post. Again, my
apologies 
Jacob Fugal
···
On 9/2/05, Simon Kröger <SimonKroeger@gmx.de> wrote:
It is a _sized_ queue wich i initailized to be of size 1, so there is
only 1 item max in the queue at any given time. This comes from a lib
called 'thread' so i would assume that it is in fact "built with threads
in mind". It blocks if there is an item in it and you want to write and
it block if there is no such item and you want to read.
Indeed, I forgot about that as well. Most my programming has been in
PHP lately (*shudder*) and the testing framework I use continues past
failed assertions, so you can have many failed assertions in one test.
So if you replaced the puts "..." or break if ... with an assertEqual,
you'd pretty much have it right on. And since you fail at the first
mismatched character, your prior newlines are sure to have matched up.
Cool beans.
Jacob Fugal
···
On 9/2/05, Simon Kröger <SimonKroeger@gmx.de> wrote:
hmm, true .. on the other hand assert_equal throws an
AssertionFailedError, so this is kind of breaking out of the loop also.
(But right, its not the same thing)