tech@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Baptiste Daroussin <bapt@FreeBSD.org>
To: tech@mdocml.bsd.lv
Subject: Re: Allow gzipped .so and search .so in manpath
Date: Wed, 26 Nov 2014 21:24:13 +0100	[thread overview]
Message-ID: <20141126202413.GF82931@ivaldir.etoilebsd.net> (raw)
In-Reply-To: <20141126201033.GG26411@iris.usta.de>

[-- Attachment #1: Type: text/plain, Size: 3109 bytes --]

On Wed, Nov 26, 2014 at 09:10:33PM +0100, Ingo Schwarze wrote:
> Hi Baptiste,
> 
> Baptiste Daroussin wrote on Mon, Nov 24, 2014 at 03:36:29PM +0100:
> 
> > Here is a new patch that allows to open gzipped .so files
> > as well as looking inside mpath for the files requested.
> 
> This is a terrible layering violation for three (!) reasons:
> 
>  1. The mandoc toolbox consists of code in two major categories:
>      a) code that is handling files irrespective of context
>      b) code that is aware of file context / file systems
>     While b) code is allowed to use a) code, the reverse
>     is not true.
>     The file read.c is part of the file handling code a), while
>     manpath.h is part of the b) interface; so read.c cannot
>     include manpath.h.
>     It is true that the implementation of .so in roff.c (which
>     is also part of a) slightly strains the "irrespective of
>     context" paradigm by accessing another file.  But at least
>     it retrieves the file in exactly one well-defined place
>     near the original file, and this strain is unavoidable
>     if we want to support .so at all.
>     Widening the gap by making read.c search for files along
>     the path is neither acceptable nor needed.
> 
>  2. As proposed, the patch is horribly inefficient.
>     For some purposes, the function mparse_readfd() is called
>     in inner loops, so it is not acceptable to do such expensive
>     operations in there.
>     Explained differently, we must not recalculate the manpath
>     for each and every file we parse.  Think about makewhatis(8),
>     for example.
>     Calculating the manpath belongs on the level of the main
>     program, not into some inner loop in a library.
> 
>  3. The patch utterly breaks the library hierarchy.
>     The function mparse_readfd() is a libmandoc interface
>     as documented in mandoc(3), while manpath.h is not.
>     While manpath.c can (and does) use libmandoc, the reverse
>     cannot happen.
>     You see part of the havoc wrought in that you suddenly
>     need manpath.o to link demandoc(1) even though that
>     program does not use the manpath.h interface.
> 
> I have to think about a better way to solve this.
> Maybe i should make mparse_readfd() use mparse_open()
> and extend mparse_open a bit to use file.gz if file
> is not found.  Or something like that.
> It shouldn't take too long to figure out.

I was expecting the above :)
What about using zlib directly, that could simplify a bunch of things.
> 
> > This allows zshall manpage which contains: .so man1/zshmodules.1
> > to work with mandoc, tested on freebsd this .so find as expected
> > /usr/local/man/man1/zshmodules.1.gz
> 
> The .so links are a bad idea in the first place, so it would be
> good to get rid of them completely.  But admittedly, that's a
> separate matter.

Right now in the ports tree I'm ripping them at package creation using soelim
from groff and I wrote minimalistic version in base to be able to continue using
that when groff will be removed.

regards,
Bapt

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2014-11-26 20:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-24 14:36 Baptiste Daroussin
2014-11-26 20:10 ` Ingo Schwarze
2014-11-26 20:24   ` Baptiste Daroussin [this message]
2014-11-27  0:12     ` Ingo Schwarze
2014-11-27  2:03       ` Ingo Schwarze
2014-11-29 17:54       ` Baptiste Daroussin
2014-11-29 18:14         ` Ingo Schwarze

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141126202413.GF82931@ivaldir.etoilebsd.net \
    --to=bapt@freebsd.org \
    --cc=tech@mdocml.bsd.lv \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).