features
>in that area, write patches, and submit them. Starting with
>something easy and with small patches, of course, then slowly
>increasing his range.
That is good advice Ingo. Thanks! It is my current focus.
On Wed, Sep 10, 2014 at 10:39 AM, Vaibhaw Pandey
wrote:
> Wow!
t;
> The only thing you should usually refrain from is refactoring code
> that requires no functional changes (there are exceptions, for
> example when a security audit is urgently required). And most
> definitely, the worst thing one can do is advertise seemingly easy
> refactoring
# generated automatically by aclocal 1.13.1 -*- Autoconf -*-
Probably, we need to written a scarier Auto-generated file notice? All CAPS
maybe, with a Do not hand edit notice? :)
On Fri, Sep 5, 2014 at 10:35 AM, Werner LEMBERG wrote:
>
> > I tried to let groff create a data directory for the
OS X report:
Dale Snell wrote:
>You appear to be missing the netpbm package. This was discussed
>on the list a while back. Netpbm is needed for the initial build
>of Groff. It's not needed for the distributed tarballs. You are
>also missing gs (GhostScript) and psselect (which allows one to
>
Was attempting a OS X (13.3.0 Darwin) install. Didn't complete.
0. bootstrap: successful
1. configure warned me of a bunch of programs missing: `pnmcut', `pnmcrop',
`pnmtopng', `psselect', `pnmtops' and `gs'.
Of these I installed gs as make would fail without it. configure succeeded
otherwise.
2.
Steffen,
I took a shot at reviewing this last week. Turned out I don't have enough
context of the groff code base to be able to do a useful review. I am
currently familiarizing myself with the parts of code to which this review
is pertinent. However, given my current abilities and the size of the
This is extremely helpful! Thanks Bertrand!
Is there any work pending before we can merge this into master? Do you need
any additional help in testing this?
Werner,
Do you see any specific tests/requirements that this change needs to meet?
- Vaibhaw
On Mon, Aug 11, 2014 at 2:23 AM, Heinz-Jürg
Werner,
You had suggested to me to start around process_input_stack earlier so I
have some handle on what goes around there. I will take this up.
Steffen,
I will help to understand this, will contact you soon.
Thanks,
Vaibhaw
On Tue, Jul 29, 2014 at 3:14 PM, Werner LEMBERG wrote:
>
> > Is t
Is this something I should be looking at?
- Vaibhaw
On Tue, Jul 29, 2014 at 11:01 AM, Werner LEMBERG wrote:
>
> > So for some more annoyance i'll also post the review tweaks. Brings
> > some consistency and avoids a uselessly large buffer. Everything in
> > the Public Domain, of course. Cia
Werner,
> I was handling the rest, fixing `global' glitches here and there. Since
> I'm no longer actively maintaining groff, the glitches become more
> visible. We need someone who is going to handle this... Basically
> for license issues, Ingo won't do that, which is a pity, but we have
> to
This is probably a good time for me to pop this question which I have had
for a while: Don't we have a formal unit-test/review cycle around the
commits we make into the code base? Also do we have any test suites around
major packages that can quickly sanitize our checkins? Or an automated
build and
Should we be worried about having too few characters left though? Do we
need to work on a solution?
- Vaibhaw
On Tue, Jun 17, 2014 at 7:44 AM, Werner LEMBERG wrote:
> >> A `groff' option for running the `gideal' preprocessor is needed.
> >
> > Only once the preprocessor has a significant enoug
Greetings,
I have been given an opportunity to be the new maintainer of GNU troff.
Werner suggested that I introduce myself to this mailing list. So here goes.
Technical background:
http://www.linkedin.com/in/vaibhawkpandey
Indian CSE engineering grad with around 6 years of experience. Spent 5
ye
13 matches
Mail list logo
