4

Ruby 1.8.7で少し作業を行っていますが、これには無向グラフのトラバースとパーティション分割が必要ですが、本番環境では奇妙なことに失敗しています。失敗したコードを最も重要なコンポーネントまで抽出すると、次の奇妙な失敗のテストが発生します。

it 'should be able to clear a ruby set of arrays' do
  a = ["2", "b", "d"]
  b = ["1", "a", "c", "e", "f"]
  set = Set.new([a, b])
  a.concat(b)

  p "before clear: #{set.inspect}"
  set.clear
  p "after clear: #{set.inspect}"
  set.size.should == 0
end

テストは次の出力で失敗します：

"before clear: #<Set: {[\"1\", \"a\", \"c\", \"e\", \"f\"], [\"2\", \"b\", \"d\", \"1\", \"a\", \"c\", \"e\", \"f\"]}>"
"after clear: #<Set: {[\"2\", \"b\", \"d\", \"1\", \"a\", \"c\", \"e\", \"f\"]}>"

expected: 0
     got: 1 (using ==)

セットから削除しようとすると、奇妙な動作もします。配列内のキーのハッシュ値がconcat（）で変更されていることに、Rubyがハングアップしていると思いますが、それでもSetをクリアできるはずです。右？

4

2 に答える 2

1

.dupアプローチは確かに私の最初の回避策であり、宣伝どおりに実行されました。

Setに次のモンキーパッチを追加することになりました。

class Set
  def rehash
    @hash.rehash
  end
end

これにより、ハッシュ値を変更する操作の後にセットのキーを再ハッシュできます。

これはすべてRuby1.9で修正されているようです。

于 2012-06-13T00:47:49.880 に答える
1

これには回避策があります。キーを変更した後にセットを複製すると、新しいセットには更新されたキーが含まれ、適切にクリアされます。したがって、設定set = set.dupするとその問題が修正されます。

于 2012-06-12T18:37:58.853 に答える