[KinoSearch] ORQuery dislikes Perl Compiler classes

webmasters at ctosonline.org webmasters at ctosonline.org
Mon Jun 1 12:52:02 PDT 2009


On Jun 1, 2009, at 11:05 AM, Marvin Humphrey wrote:
> Ordinarily not being able to load an XS shared object would be a  
> fatal error,
> which Apple would hopefully have caught.  However, in the case of
> Scalar::Util, failing to load the XS shared object triggers a  
> fallback to the
> Pure-perl implementation -- which is incomplete.  IMO, that's poor  
> API design
> -- a nasty little trap which you can guarantee some fraction of your  
> users are
> going to fall into.

The good news is that the latest version includes List::Util::XS, to  
avoid precisely this problem.
>
>> I had this same  problem, and simply reinstalled Scalar::Util and  
>> IO. Apple
>> fixed this  in 10.5.7 by changing the install location for core  
>> module
>> upgrades.
>
> Dunno what's up with my system, but right now I'm running 10.5.7 and  
> I get the
> "weaken" failures when I use the stock Perl.

OK, it seems that Apple has only prevented future security updates  
from causing the problem if it hasn’t already occurred....
>
> Whatever.  For my laptop, I think I'm going to continue to use the  
> manually
> compiled Perl.  For the Mini, though, I'm messing with the system  
> Perl.
>
>>> * Run "./Build distclean", then "perl Build.PL", "./Build test".
>>
>> What’s the difference between ./Build clean and ./Build distclean?
>
> "./Build distclean" wipes out the "Build" script and the "_build"  
> directory.
> On dev branch KS, I don't think there will be a difference.  For  
> stable branch
> KS, the code autogeneration work is done by Build.PL rather than  
> Build,
> though... and I just got in the habit of running "distclean" rather  
> than
> "clean" from back then.

Well, the test I sent you works now on both machines. The original  
script it was reduced from is still failing, but if I change it to use  
a RAMFolder as in the test, it works. So I think the index needs to be  
regenerated (it was made with 4625). This is a several hour process  
(no, KinoSearch is not the bottleneck), which I’ll run at night. I’ll  
try again tomorrow.


Father Chrysostomos




More information about the kinosearch mailing list