lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [lucy-dev] 0.3.0
Date Tue, 22 Nov 2011 16:45:12 GMT
On Mon, Nov 21, 2011 at 09:06:31PM -0600, Peter Karman wrote:
> What stands in our way for a 0.3.0 release?
> 
> We've had a lot of churn in trunk over the last couple of months, particularly
> exorcising Parse::RecDescent and adding utf8proc. 

Another important change not in the 0.2.x line is the swapout of JSON::XS and a
translation layer for a core JSON parser.

> I think we should aim for a new release as soon as whatever top-priority
> TODOs are identified and addressed.

In addition to your list, I would cringe if ClusterSearcher were to go out in
its present state.  If we want to triage it, perhaps we can disable the select
loop and just go with serial collection of responses -- the remotes still work
in parallel that way.  It will still be fragile and inflexible, but hopefully
that will stop it from crashing outright.

Also, we should run lucytidy.pl after adding some new excludes:

    diff --git a/devel/bin/lucytidy.pl b/devel/bin/lucytidy.pl
    index ddb61cc..778b1e7 100755
    --- a/devel/bin/lucytidy.pl
    +++ b/devel/bin/lucytidy.pl
    @@ -26,7 +26,12 @@ use Fcntl;
     my $ignore = qr/(
           \.svn
         | \.git
    +    | clownfish.src.CFCLexHeader
    +    | devel.bin.release_commands.pl
         | modules.analysis.snowstem.source
    +    | modules.unicode.utf8proc
    +    | lemon.lemon.c
    +    | lemon.lempar.c
         | perl.sample
         )/x;


> On my list:
> 
>  * the highlighter bug (LUCY-182)

We have a patch now from Nick Wellnhofer which hopefully exterminates this
persistent little critter.

>  * any 0.2.2 cpantesters failures

These fall into three categories.

First, there's the Perl 5.15.x destruction bug.  I have a provisional patch
which seems to work.  However, I don't fully understand why it works, which
makes me nervous.

Second, there's one Strawberry Perl failure arising from this Charmonizer probe
error:

    64-bit types, but no literal syntax found

It's GCC, so we should assume that LL and ULL are OK as suffixes for 64-bit
integer literals and that the problem therefore resides in our probe logic or
probing mechanism.  Who knows why that probe seems to work absolutely
everywhere else, including my copy of Strawberry Perl, though.  Sigh.  I'd just
let that one go for now.

Last, we have a slew of failures on OpenBSD because of pthreads.  I took a
blind stab at this one, but looks like I missed:

    https://issues.apache.org/jira/browse/LUCY-157

We should be able to solve that problem if we can get access to an OpenBSD box.

Marvin Humphrey


Mime
View raw message