On Mon, Nov 06, 2017, Bjarni Ingi Gislason wrote:
> This year 5 centuries are since Martin Luther challenged procedures of the
> Catholic Church.
It might be _ein feste Burg_ in the field of document processing
sofware, but don't think groff is quite on a par with the
Reformation. :)
--
Peter
On Sun, Nov 05, 2017 at 09:49:06AM -0500, G. Branden Robinson wrote:
> At 2017-11-05T15:09:41+0100, Bertrand Garrigues wrote:
> >if (len == 0)
> > -return NULL;
> > +goto end;
>
> We're kind of giving a hostage to fortune here, aren't we?
>
> https://en.wikipedia.org/wiki/Unreachable_
On Sun, Nov 05, 2017, Ingo Schwarze wrote:
> Are -me and -mom documents notorious for using large macros inside
> deep loops? In particular as opposed to -ms and -mm, which are
> installed unstripped?
I'm not sure how large large is, or deep deep is, but I suspect the
mom macros qualify on both c
On Sun, Nov 05 2017 at 04:13:22 PM, Ralph Corderoy
wrote:
> Hi Branden,
>
>> >if (len == 0)
>> >goto end;
>>
>> We're kind of giving a hostage to fortune here, aren't we?
>> https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug
>
> The whole code base skips braces so is goto wo
Hi Werner,
Werner LEMBERG wrote on Sun, Nov 05, 2017 at 06:38:14PM +0100:
> Ingo Schwarze wrote:
>> In that sense, macro file size does seem to be the main effect, and
>> the savings in execution time seem to usually fall into the range of
>> 5-20% in cases that occur in practice.
> OK, but grof
> Actually, the tests on a large, real-world corpus of manual pages
> containing a large fraction of mdoc(7) that i did two and a half
> years ago seemed to indicate that the execution time benefit is
> roughly consistent with what one would expect if it were mainly due
> to the simple reduction o
I prefer minimal changes and those that are more future-proof.
1) Ship the unstripped files in the tar archive
2) Add a explanation to the head of the stripped versions about the reason
for it.
More extensive changes:
3) Add '-u' to the name to other macro files and strip them too.
That
Hi Ingo,
> seemed to indicate that the execution time benefit is roughly
> consistent with what one would expect if it were mainly due to the
> simple reduction of the macro file size:
The rule of thumb I've often heard is the lexer is the bottleneck. I
haven't time to dig right now, but I've on
Hi Branden,
> >if (len == 0)
> >goto end;
>
> We're kind of giving a hostage to fortune here, aren't we?
> https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug
The whole code base skips braces so is goto worth special casing? It's
just as likely to be removed in some future e
At 2017-11-05T15:09:41+0100, Bertrand Garrigues wrote:
>if (len == 0)
> -return NULL;
> +goto end;
We're kind of giving a hostage to fortune here, aren't we?
https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug
Can I beg a pair of braces there in case someone in the future de
Hi,
Werner LEMBERG wrote on Sun, Nov 05, 2017 at 08:04:46AM +0100:
> Branden wrote:
>> I move that we stop stripping the files. Stripping them is saving
>> us only a few hundred kB out of 25 megs.
> It's not about saving disk space.
Actually, the tests on a large, real-world corpus of manual p
Hi Bertrand,
> You are right; here is a patch to fix all that, does it look OK to you?
...
> + /* uchardet 0.0.1 could return an empty string instead of NULL */
> + if (charset && *charset) {
> ret = (char *)calloc(strlen(charset) + 1, 1);
> strcpy(ret, charset);
>}
Yep. The call
Hi Ralph,
On Sun, Nov 05 2017 at 10:05:07 AM, Ralph Corderoy
wrote:
>> +/* uchardet 0.0.1 could return an empty string instead of NULL */
>> +if (!charset[0]) {
>> + uchardet_delete(ud);
>> + return NULL;
>> +}
>
> That doesn't free(data), as the code continues to do after
Hi Mikkel,
> Do eny of you have an idea what the weird signs are and how to get rid
> of them?
...
> .nr 3bot 76000>?76000
> .nr 3bot 39>?39
...
> \# mymarkuppp filename.gms |groff -t -P-la4 -ms >filename.ps;
We need the output of `mymarkuppp filename.gms' to have a play for
ourselves, o
Hi guys
Do eny of you have an idea what the weird signs are and how to get rid of
them?
It's in the top and bottom left of the table in the pdf
.nr 3bot 76000>?76000
.nr 3bot 39>?39
/Mikkel
faellesindkoeb.gms
Description: Binary data
faellesindkoeb.pdf
Description: Adobe PDF documen
Hi Mike,
I'm doing some work cleaning up the groff man pages for the GNU Project,
and I noticed that you are still listed as maintainer of the gdiffmk
program. However, we've seen some retirements and other forms of
"stepping back" from GNU roff in recent years, and when I consult the
gdiffmk Cha
Hi James,
I'm doing some work cleaning up the groff man pages for the GNU Project,
and I noticed that your email address still appears in a few pages,
alongside your credit as an author of many parts of the groff system.
In other places, your email address is not listed.
I'd like to make the page
At 2017-11-05T11:42:48+0100, Ulrich Lauther wrote:
> > > Werner wrote:
> > > > Branden wrote:
> > > > > I move that we stop stripping the files. Stripping them is
> > > > > saving us only a few hundred kB out of 25 megs.
> > > > It's not about saving disk space. Remember that groff is an
> > > >
On Sun, Nov 05, 2017 at 11:32:10AM +0100, oe wrote:
> Am 05.11.2017 um 11:11 schrieb Ralph Corderoy:
> > Hi,
> >
> > Werner wrote:
> > > Branden wrote:
> > > > I move that we stop stripping the files. Stripping them is saving
> > > > us only a few hundred kB out of 25 megs.
> > > It's not about s
Am 05.11.2017 um 11:11 schrieb Ralph Corderoy:
Hi,
Werner wrote:
Branden wrote:
I move that we stop stripping the files. Stripping them is saving
us only a few hundred kB out of 25 megs.
It's not about saving disk space. Remember that groff is an
interpreted language *without* a translation
Hi,
Werner wrote:
> Branden wrote:
> > I move that we stop stripping the files. Stripping them is saving
> > us only a few hundred kB out of 25 megs.
>
> It's not about saving disk space. Remember that groff is an
> interpreted language *without* a translation to an internal
> representation.[*]
Hi Branden,
On Sat, Nov 04 2017 at 09:46:57 PM, "G. Branden Robinson"
wrote:
> At 2017-11-05T01:12:38+0100, Bertrand Garrigues wrote:
>> Which version of `uchardet' do you have on your system? On mine I have
>> version 0.0.6.
>
> Well, that's my problem right there. I'm running Debian 9 ("Stre
Hi Branden,
>if (debug_flag)
> fprintf(stderr, " charset: %s\n", charset);
>if (charset) {
> +/* uchardet 0.0.1 could return an empty string instead of NULL */
> +if (!charset[0]) {
> + uchardet_delete(ud);
> + return NULL;
> +}
> ret = (char *)calloc(strle
Am 05.11.2017 03:09 schrieb "G. Branden Robinson"
:
>
> At 2017-11-05T00:40:48+0100, Bertrand Garrigues wrote:
> > > Am Donnerstag, 2. November 2017, 08:09:48 CET schrieb Werner LEMBERG:
> > >> If my memory serves me well, the `u' stands for `uncompressed', i.e.,
> > >> without comments and in
> I move that we stop stripping the files. Stripping them is saving
> us only a few hundred kB out of 25 megs.
It's not about saving disk space. Remember that groff is an
interpreted language *without* a translation to an internal
representation.[*] This means, for example, that a comment with
25 matches
Mail list logo
