Re: overhaul apropos(1) interface

[Kristaps Dzonsons <kristaps@bsd.lv>]

> I cannot; i need to get this working in the OpenBSD tree ASAP,
> i.e. tomorrow.  The logical and and or are not critical for me
> right now, i can do without those for some time, but i need a
> working mandocdb-apropos toolchain in-tree to build upon.

Ingo,

Oi oi, a hackathon!  In this case, I'm fine with your patch -- I wasn't 
aware of the conditions.  If exprexec() simply does the type-check and 
the strcmp/regexec, then it works for the single-case expression: Ar == 
foo, Ar =~ foo, etc.  This can then be further built up, later. 
Further, if everything's kept within exprcomp() and exprexec(), it's 
nice and neat to upgrade later.

Better yet, as we've agreed upon the tests (==, =~, etc.), the upgrade 
to allow logical statements (and, or, etc.) is backwards-compatible.

So please go ahead with these changes; I'll merge and check my 
improvements (they'll more or less re-write exprcomp() and exprexec(), 
and add structs etc.) afteward.

Is that alright with you?

Thanks,

Kristaps

> Ports hackathons are short, and i want to get on as fast as
> possible with the following critical path:
>
>   1) get mandocdb working on single directories
>      to produce databases in the macro-format,
>      i.e. with types like TYPE_An, TYPE_Cd
>   2) get apropos to work with that, such that the
>      databases can be used
>   3) get rid of the most glaring bugs
>      and complete backward compatibility
>   4) integrate the man.conf parser into mandocdb
>      such that mandocdb can walk the MANPATH
>      just like makewhatis(8) does
>   5) integrate the man.conf parser into apropos such that
>      mandoc-apropos gets useable as a real apropos replacement
>   6) rudimentary formatted page parsing in mandocdb
>   7) integrate mandocdb into pkg_add such that it gets
>      useable as a real makewhatis replacement


>
> I realized in Ljubljana that this is more work than i thought
> before, and i can't hold off, especially not this week, or i will
> surely miss the 5.1 release.
>
> Maybe you can hold off and bring in the and/or stuff
> afterwards, i.e. after the patches i have posted so far?
> You need not wait long, i would *gladly* push all my stuff
> tomorrow in the morning, and then you have clean earth to
> till and to adjust your work to it.
>
>> It's by no means finished; as mentioned in the source checkin,
>> I'll post to tech@ when the implementation is feature complete.
>
> Sure, no doubt, but blocking system integration at a critical
> time to implement optional, fancy features is a bad idea!
>
>> Consider, to gauge the complexity:
>>
>>   apropos Ar == foo -a Ar =~ baz
>>
>> (I don't care at all about the connecting syntax, ==, etc., so long
>> as it's regular.  Your notation is not extensible to
>> case-insensitive matching: can one extend to include these?)
>
> It is.
>
> ischwarze@isnote $ cd /usr/share/man
> ischwarze@isnote $ apropos.m Nm~^b.e$
> BCE(4) - Broadcom BCM4401 10/100 Ethernet device
> BGE(4) - Broadcom BCM57xx/BCM590x 10/100/Gigabit Ethernet device
> ischwarze@isnote $ apropos.m Nm~^B.e$
> ischwarze@isnote $ apropos.m Nm,i~^B.e$
> BCE(4) - Broadcom BCM4401 10/100 Ethernet device
> BGE(4) - Broadcom BCM57xx/BCM590x 10/100/Gigabit Ethernet device
>
> That's not a mockup, that's what i'm running right now.
>
> However, i propose that substring match always be case-insensitive.
> Substring match is a simplification for daily wear and tear
> and doesn't need such complexity.  If case-insensitive substring
> match drowns you in noise, just use regex matching - done.
>
>> Anyway, the "AND" is tricky: each file's evaluation state must be
>> retained for all keyword entries (which have no guarantee on
>> ordering) then post-operated.  Thus, I'm maintaining evaluation
>> trees during the parse.  The goal is to make the trivial case -- "Ar
>> foo", say -- as fast as in the simple implementation before.  (I
>> guarantee the trivial case by the partial evaluation.)
>>
>> Anyway, I anticipate a few days til I get the final checkins.  The
>> code is not tricky in implementation (not much, anyway) and
>> guarantees arbitrary expressions with well-defined compute time.
>>
>> I'm also not at all married to the filenames, but let's hold off for
>> a bit more as I get these chunks into place.  apropos_db.c is fine
>> by me, for the record.
>
> Sounds good, except that a hackathon is a bad time to make me wait.
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv