On Sat, Feb 03, 2007 at 11:05:21AM +0900, Pe, Botp wrote:
> fwiw, mine here is:
> 
> C:\family\ruby>fastri-server -b
[...]
> Indexed:
> * 10240 methods
> * 2046 classes/modules
> Needed 3.984 seconds
> 
> ok, i think that's success alright. 
> Now,
> 
> C:\family\ruby>fastri-server -B
> Indexing RI docs for ZenTest version 3.4.3.
> <snip>....
> Indexing RI docs for win32-sound version 0.4.0.
> Indexing RI docs for win32console-1.0.8-i386 version mswin32.
> Indexing RI docs for windows-pr version 0.6.2.
> c:/ruby/lib/ruby/gems/1.8/gems/fastri-0.3.0.1/bin/fastri-server:70:
> C:\family\ruby>
> 
> is that a success or what?

Don't really know. Do you get a new .fastri-fulltext directory with
full_text.dat and suffixes.dat in HOME?

> i think the full rebuild is buggy, how can we debug it using just ruby?

It'd seem Ruby is crashing so hard it doesn't even give you a backtrace, but I
can't really tell. Maybe adding a  rescue Exception; puts $!.backtrace  to the 
make_full_text_index method would tell us something, or it could make the
heisenbug go away.

Just realized that there could be a simple explanation to this: sometimes ruby
cannot detect stack overflows correctly and you get a segfault. However, ruby
doesn't use a recursive qsort (the most obvious possible culprit)...
If this is the reason, the problem should consistently fail to manifest itself
when you enlarge the stack (I don't know how to do that on win32, though).

-- 
Mauricio Fernandez  -   http://eigenclass.org   -  singular Ruby