Hi,
This is getting off-topic. Groff uses a limited form of C++, thus it's
still approachable by C programmers. If it starts becoming more C++ and
less C then it will lose that possible pool. I think it's widely
accepted that C++ is a large complex sprawling language that few
understand complet
Hallo Ingo, Ulrich, list,
Ingo Schwarze wrote:
[.]
|Some things work more or less similarly in git:
|
| * cvs co module -> git clone module
| Except that it also mirrors the whole repo including history.
Not necessarily. I usually find the advice to "clone" a repo
a bad one: now that
lxnf9...@gmail.com wrote:
|On Wed, 10 Sep 2014, Werner LEMBERG wrote:
|>> The problem with global variables is their long range effect,
|>> comparable with the infamous goto statement: considered harmful.
|>
|> I like `goto' a lot, and it is an invaluable instruction if used with
|> care. Th
Ulrich Lauther wrote:
|That templates are not used is a GOOD THING.
I disagree with you, templates are a fantastic thing for
typesafety. The problem i have with STL is the massive code blow.
I instead used all-inline template wrappers of void* based generic
collection types; to be able to manag
Werner LEMBERG wrote:
|> I may have to look into this C++ stuff. I have only written C and I
|> have not figured out how to write multi-threaded applications
|> without global variables. And I make good use of goto and
|> longjmp. Apps would be a lot junkier without them.
|
|Well, right now
Hello,
after making distclean or realclean there are still generated files. With
which make target can I get rid of them?
$ git status
# On branch master
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# src/libs/gnulib/Makefile
# src/libs/gnulib/co
Hi Carsten,
Carsten Kunze wrote on Thu, Sep 11, 2014 at 03:40:58PM +0200:
> after making distclean or realclean there are still generated files.
Known issue, see my bug report https://savannah.gnu.org/bugs/?42970
Werner's comment is bogus. It has nothing to do with automake.
Actually, in the
Hello,
despite the fact that grohtml produces faulty output for it
anyway, i really think that -mdoc would need a few more commands
so that it would be possible to create "better" documents with it,
where "better" refers to usability and user experience.
E.g., even mandoc(1) -Tx?html doesn't crea
Robert --
On Wed, Sep 10, 2014, Robert Bocchino wrote:
> As I mentioned to Werner, I'm a professional software engineer,
> regular groff user, and Unix tool enthusiast, and I'd like to
> contribute back to groff development.
Welcome!
--
Peter Schaffter
http://www.schaffter.ca
Hi Steffen,
Steffen Nurpmeso wrote on Thu, Sep 11, 2014 at 04:22:22PM +0200:
> despite the fact that grohtml produces faulty output for it
> anyway, i really think that -mdoc would need a few more commands
> so that it would be possible to create "better" documents with it,
> where "better" refer
On Wed, 10 Sep 2014 11:49:37 +0200
Ulrich Lauther wrote:
> other modifications would really
> improve readability and maintainability:
> - capitalization of class names
> - a naming convention for class member variables
> - reducing the number of global variables
You want
On Thu, Sep 11, 2014 at 01:11:40PM -0400, James K. Lowden wrote:
> On Wed, 10 Sep 2014 11:49:37 +0200
> Ulrich Lauther wrote:
>
> > other modifications would really
> > improve readability and maintainability:
> > - capitalization of class names
> > - a naming convention for class
On 09/11/2014 11:57 AM, Ulrich Lauther wrote:
On Thu, Sep 11, 2014 at 01:11:40PM -0400, James K. Lowden wrote:
On Wed, 10 Sep 2014 11:49:37 +0200
Ulrich Lauther wrote:
other modifications would really
improve readability and maintainability:
- capitalization of class names
-
On Thu, 11 Sep 2014 19:57:43 +0200
Ulrich Lauther wrote:
> As I understand it, the man-pages are directed at the user of a
> program who wants to know WHAT a program is supposed to do and how
> she can control it via options.
On Thu, 11 Sep 2014 14:48:51 -0600
Clarke Echols wrote:
> Ulrich is
On Thu, Sep 11, 2014 at 05:46:22PM -0400, James K. Lowden wrote:
[ ... ]
> If by "all about" Urich meant a sentence or two, sure, a comment block
> is fine. If by "all about" he meant a description of the semantics of
> the public interface (which is what I thought he meant) then ISTM that
> belon
Hi,
Ulrich wrote:
> As I understand it, the man-pages are directed at the user of a
> program who wants to know WHAT a program is supposed to do and how she
> can control it via options.
>
> Comments in the source are directed at the programmer, who wants to
> understand HOW the functionality of
Feel free to use inside the groff project in any way you like,
including republishing and including in official lists,
but please don't change the content without speaking to me.
Bertrand Garrigues:
Specific short/medium term pr
Hi Peter,
On Tue, Sep 09 2014 at 11:31:38 PM, Peter Schaffter wrote:
> The thread on underlining raised a couple of issues. One is whether
> a long-established request (.ul) should be updated. The rationale
> is that it's unlikely anyone in 2014+ needs (or, if young enough,
> even understands)
> I think what's missing is a higher-level view of how the source fits
> together, and that's probably why Werner's enthusiastic about a
> comment-block per class.
Exactly.
> Perhaps those on the list that can grok C could have a go at doing
> Werner's class comments, [...] But would it require
19 matches
Mail list logo
