On 8-Oct-06, at 12:24 AM, David Balmain wrote:
> On 10/7/06, Bob Hutchison <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I've listened in to this mail list for quite a while now but not
>> doing anything with Ferret until I was ready to incorporate it. I've
>> used Lucene for years, but not Ferret.
>>
>> I downloaded and installed the 'bleeding edge' version (lets call it
>> 0.10.9.1). There appears to be a significant re-working of the API
>> happening. It all looks good. But there might be a couple of gaps
>> still there.
>
> I'm all ears. What do you think needs improvement?
It may simply be a misunderstanding on my part, read on. I also can't
figure out how to redefine the field used as an id (again, read on,
the documented way isn't working for me and probably because of what
comes up below).
>
>> The first question: should I even consider using the 0.10.9.1 version
>> of Ferret? What I intend to use it for will not be a critical
>> component, at least for the time being. I'm also used to working with
>> shifting software. The advantage that I see is the new API.
>> Performance is a BIG issue with my project.
>
> I've just release 0.10.10. Version 0.10.9 is probably the most stable
> version to date. 0.10.10 has some significant changes to improve
> performance of sorting and filtering of large unoptimized indexes
> (putting Ferret orders up to orders of magnitude ahead of Lucene for
> these tasks). In a few days we should know if I broke anything. There
> are currently only 3 outstanding tickets on Trac and they are only on
> Windows and OS X so if you are on Linux you should be fine.
Of course I'm running OS X... this couldn't be easy :-) I'm also
seeing issues 127 and 136 (like everyone else on OS X will be).
Another thing for OS X, until Apple fixes their gcc4 compiler either
use the gcc3 compiler or use -O1 rather than -O2. I changed the
ext_conf file to do this, but the two OS X issue remain. If you don't
do this you will eventually get a corrupted heap (usually takes a
while). I've had to recompile ruby to this optimisation level for it
to work reliably.
>
>> The second question: are there any opinions regarding ease-of-upgrade
>> from the current stable version to what is being worked on now. I
>> don't have anything to upgrade at the moment, but if I go with the
>> stable version then I will have.
>
> Well, 0.10.9 is the most stable version since the pure ruby version so
> that would be the version I go with. Also, I can usually fix most
> problems within a day or two if I can reproduce the problem or you are
> willing to give me ssh access to your server.
Okay, I'm convinced. The most recent is the way to go.
>
>> The third question: it looks to me that in the 0.10.9.1 version the
>> content of the fields is being stored in the index. For my
>> application this is worse than a waste of time. Am I missing
>> something.
>>
>
> It depends how you set your index up. You specify which fields you
> want stored/indexed or term-vectorized (I know, it's not a word).
>
> # set to not store fields by default
> field_infos = FieldInfos.new(:store => :no)
> # must store id field however
> field_infos.add_field(:id, :store => :yes, :index => :untokenized)
So, I tried requiring ferret. It simply won't admit to knowing
anything about the FieldInfos class. How bad are those two remaining
OS X bugs?
So, I tried requiring rferret. That worked better.
I tried your example (actually I tried this before posting and this
is why I said I thought I saw a few gaps). It doesn't work for me.
The initialize method for FieldInfos is defined as:
def initialize(dir = nil, name = nil)
@fi_array = []
@fi_hash = {}
if dir and dir.exists?(name)
The options in your example are assigned to the dir and an exists?
method is undefined on a hash and so a method missing exception is
thrown.
I've happily forgotten most of my C code, but it looks as though the
C version is doing something similar (not that it matters in my case
because FieldInfos is invisible)
>
>> The fourth question: in a message from August 23 there was a hint of
>> a write-up discussing the new API. Did this ever get published?
>
> No. But I did update the documentation here:
>
> http://ferret.davebalmain.com/api/files/TUTORIAL.html
I thought that was the old way since I couldn't get it to work (see
above).
>
> You may even find the Ferret FAQ even better.
>
> http://ferret.davebalmain.com/trac/wiki/FAQ
I don't know how I missed that. Thanks.
>
> And there may be an O'Reilly "shortcut" coming out soon.
That's great!
Cheers,
Bob
>
>> I think there is some *very* nice work here. I'm looking forward to
>> using Ferret.
>
> Great. Thanks,
> Dave
> _______________________________________________
> Ferret-talk mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/ferret-talk
----
Bob Hutchison -- blogs at <http://www.recursive.ca/
hutch/>
Recursive Design Inc. -- <http://www.recursive.ca/>
Raconteur -- <http://www.raconteur.info/>
xampl for Ruby -- <http://rubyforge.org/projects/xampl/>
_______________________________________________
Ferret-talk mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ferret-talk
