similar to: A note about #search vs #search_each

Hi, I seem to be having trouble getting more than 10 hits from Index#search_each since upgrading to 0.10.2 (ie, this was working in 0.9.4). Maybe a bug, as the #search_each doesn''t seem to use the options parameter any more ? Thanks, Neville =========================================== require ''rubygems'' require ''ferret'' p Ferret::VERSION idx =

The included test script turned up the following anomolies (run against Ferret 0.10.3, but had same problems with 0.10.2): 1. When the content word is not in the index the inclusion of a wildcard file term causes search_each to throw a segmentation fault. $ ./test.rb zzz file:*.txt query: +content:zzz +file:*.txt ./test.rb:28: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24)

Recently I''ve been revisiting some of my search code. With a greater understanding of how Java Lucene implements its search methods, I realized that one level of abstraction is not present in the Ferret classes/methods. Here are the relevant method signatures: Ferret''s search methods: in Ferret::Index::Index: search(query, options = {}) -> returns a TopDocs

Hi, I''m building a web server application using Ferret [thanks so much Dave], Mongrel and Camping which works fine servicing one request at a time, but serialises searches if more than one request arrives, so I''d like some advice please about the best way to use multiple readers and one writer. Some background ... query requests which in my case are always read only, arrive via

I was having some odd results when working with acts_as_ferret (current trunk), so I decided to test with the current version of ferret to see if I encountered the same problem. I did. Here are the details: installed ferret 0.10.10 on debian sarge with ''sudo gem install ferret'' (btw, same results on OSX) opened up an irb session: irb(main):001:0> require

Hi, I have a largish index [700MB] which is updated from time to time, requiring me to close and recreate the Ferret::Search::Searcher to use the latest index. My problem is that the first few searches on the new index are slow [by comparison to before the close/recreate], I''m guessing because the new index is being loaded into RAM by my OS and into Ferret as needed. I''m

Here''s the deal: static TopDocs *isea_search_w(Searcher *self, Weight *weight, int first_doc, // OFFSET int num_docs, // LIMIT Filter *filter, Sort *sort, filter_ft filter_func,

Steps to reproduce: - Enable CLucene FTS in Dovecot; - Open mailbox with MUA; - Search for message with any text; - IMAP session crash. OS: Gentoo Base System release 2.6 Version: FTS: dev-cpp/clucene-2.3.3.4-r6 IMAP: net-mail/dovecot-2.3.2.1 LIBC: sys-libs/musl-1.1.21 Dovecot FTS config: plugin { fts = lucene fts_lucene = whitespace_chars=@. normalize no_snowball fts_autoindex=yes

Hi, I am unable to use the Searcher''s explain method. Anytime I call it, I get Segmentation Faults and it kills the process I have running my Rails site. Has anyone else had this problem? Here is some code I am trying to use it in... search = Search.create(:query => query) @quotations = [] searcher = Ferret::Search::Searcher.new("index") # FerretConfig::INDEX bq =

Hi, I''m confused about managing field boosting ... I have set the :boost for the :name field in my docs to 10, via :boost => 10 Then I performed a search for ''keith'' over all fields via with *:(keith*), expecting a doc with Keith in the :name field to come out on top. But another doc with Keith mentioned in other fields (:comments, :address) scored higher. I

My linux Ruby application is using Ferret 0.11.4. I created my own class IndexSearcher to contain the Searcher of multiple directories. If I do not have the searcher.close called, the end of runner/console or runner/server will pop out with system error: *** glibc detected *** irb: double free or corruption (fasttop): 0x0a51d6c0 *** ======= Backtrace: ========= /lib/libc.so.6[0x638ac1]

I''m using ferret 0.10.14 in Linux Fedora 3. When I do highlight with Index::Index#highlight, it works well. But, doing the same test with Searcher#highlight, [BUG] Segmentation fault occurred. Here''s my test code. require ''rubygems'' require ''ferret'' include Ferret::Search #searcher = Ferret::Index::Index.new(:path =>

I just started using Ferret and I successfully indexed some documents. I can search this index using the following code: index = Index::Index.new(:path => path) index.search_each("something") do |doc, score| print "##{doc} #{index[doc][''url'']} - #{score}" print "\n" end However, when I try to use Search::Searcher and QueryParser

Hi, i''m working on a project using Ferret for indexing it''s datas. I''m very happy with it but i need to code an extension to implement a .to_json method to TopDocs class, because ruby''s json implementation is really really slow... It''s my second (the first was the tutorial :/ ) ruby C extension, so i''m not really at ease with ruby C

Hi, I''m having some trouble with ferret search_each. I''m posting rails'' script/console output, so I guess you can decrypt it: >> res = [] => [] >> index.search_each(''name: a*'') do |doc, score| ?> res << doc >> end => 50 >> res.size => 10 >> I''m guessing the ''=>50''

Hi Dave, The options hash is not used in search_each() method. -- Posted via http://www.ruby-forum.com/.

Hi. I want to learn more about ferret. So I downloaded ferret-0.10.14 and write a simple test script Only query = TermQuery.new(:content, ''program'') gives result. If I change ''program'' with ''Good'' or ''Extra'' -> no result and searching on (:title, ''Ruby'') -> no result Strange, Strange Here is the

Hi, I''m trying to get parallelized ferret indexing working for my AAF indices, based on the example in the O''Reilly Ferret shortcut. However, the resulting indices after merging seem to have no actual documents. I went and made minimal changes to the example in the Ferret shortcut pdf, and indeed can''t get that to work either. I''d appreciate any help

Hi, Using the 0.10.4 gem under ruby 1.8.5 (2006-08-25) [i686-linux], I get different results with a TermQuery and a search string. Namely, using a search string seems to always work whereas using a TermQuery often doesn''t return any entries. For example: > x=@i[450][:message_id] => "9e7db9110509070759732b21c4 at mail.gmail.com" >

If searching multiple indexes with a single searcher is there anyway to identify which index a resulting doc is stored in? i1 = Ferret::I.new i2 = Ferret::I.new i1 << {:id=>1,:text=>"random stuff"} i1.commit reader = Ferret::Index::IndexReader.new([i1.options[:dir],i2.options[:dir]]) searcher = Ferret::Index::IndexSearcher.new(reader) query =