On 9/9/14, Werner LEMBERG w...@gnu.org wrote:
Out of that discussion came Doug's excellent suggestion for a new
primitive, '.decor' or similarly named, that's extensible so various
kinds of decoration can be applied to text, not just underlining
(which, IMO, groff seriously needs). [...]
Hi Ralph,
Ralph Corderoy wrote on Wed, Sep 10, 2014 at 09:57:31AM +0100:
Ingo wrote:
That can be combined with writing unit tests if one feels so
inclined, which is another desideratum.
Ingo, have you any opinion on a test framework?
I'd recommend POSIX make(1) together with POSIX sh(1),
Bertrand --
On Fri, Sep 12, 2014, Bertrand Garrigues wrote:
I would not be afraid to dive into the source code. Although my main
language is C, not C++, groff's C++ code seems quite understandable for
a C programmer, as it was already said in the list. The problem is that
I didn't feel I had
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
Hallo Ingo, Ulrich, list,
Ingo Schwarze schwa...@usta.de 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
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. The same
Ulrich Lauther ulrich.laut...@t-online.de 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
Werner LEMBERG w...@gnu.org 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,
On Wed, 10 Sep 2014 11:49:37 +0200
Ulrich Lauther ulrich.laut...@t-online.de wrote:
other modifications would really
improve readability and maintainability:
- capitalization of class names
- a naming convention for class member variables
- reducing the number of
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 ulrich.laut...@t-online.de wrote:
other modifications would really
improve readability and maintainability:
- capitalization of class names
- a naming
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 ulrich.laut...@t-online.de wrote:
other modifications would really
improve readability and maintainability:
-
On Thu, 11 Sep 2014 19:57:43 +0200
Ulrich Lauther ulrich.laut...@t-online.de 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
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
belongs in a
Hi Peter,
On Tue, Sep 09 2014 at 11:31:38 PM, Peter Schaffter pe...@schaffter.ca 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,
Hi,
Ingo wrote:
But look at the actual C++ we are talking about here. There are
neither templates nor rocket science in there.
Yes, it's nowhere near as bad as modern C++.
That can be combined with writing unit tests if one feels so inclined,
which is another desideratum.
Ingo, have you
On Wed, Sep 10, 2014 at 09:57:31AM +0100, Ralph Corderoy wrote:
Hi,
...
That's my favourite. Its conventions might be different, given its age,
but I think it's pretty consistent. Enthusiasm for anything other than
trivial changes in style would soon wear thin if bugs were being
you may be right about setter()/getter() usage;
He is definitely right! :-)
other modifications would really improve readability and
maintainability:
- capitalization of class names
- a naming convention for class member variables
Mhmm, this is much work, and I don't see
On Wed, Sep 10, 2014 at 12:16:06PM +0200, Werner LEMBERG wrote:
you may be right about setter()/getter() usage;
He is definitely right! :-)
other modifications would really improve readability and
maintainability:
- capitalization of class names
- a naming
Additionally, `git blame' would become much more inconvenient to
use.
I am not familiar with git and git blame, used cvs in my active
time. Could you explain, what the problem with upper case class
names and git blame would be?
Please say `git help blame' on the command line and read
Hi,
Werner wrote:
Please say `git help blame' on the command line and read this
command's manpage :-)
Also http://git-scm.com/docs/git-blame
git grep color_flag
http://git-scm.com/docs/git-grep
And the -w option is handy, just as with grep(1), to avoid matching
tricolor_flag and
Werner LEMBERG w...@gnu.org wrote:
|Please say `git help blame' on the command line and read this
|command's manpage :-)
Or $ man git-XY, e.g., man git-blame (but Ralph yet said so).
| - reducing the number of global variables
|
| Why? Again, please provide an example that could
Because it consumes space in BSS, or DATA -- and then even causing
linker work upon loading time, even if never used.
A program with a DATA section is shit ;)
Well, I don't care :-) groff uses static constructors to initialize
some of the global variables, this is a very nice and elegant
Hi Ulrich,
Ulrich Lauther wrote on Wed, Sep 10, 2014 at 01:01:37PM +0200:
On Wed, Sep 10, 2014 at 12:16:06PM +0200, Werner LEMBERG wrote:
Additionally, `git blame' would become much more inconvenient to use.
I am not familiar with git and git blame, used cvs in my active time.
Could you
Werner LEMBERG w...@gnu.org wrote:
| Because it consumes space in BSS, or DATA -- and then even causing
| linker work upon loading time, even if never used.
| A program with a DATA section is shit ;)
|
|Well, I don't care :-) groff uses static constructors to initialize
|some of the global
On Wed, Sep 10, 2014 at 03:55:12PM +0200, Werner LEMBERG wrote:
Because it consumes space in BSS, or DATA -- and then even causing
linker work upon loading time, even if never used.
A program with a DATA section is shit ;)
Well, I don't care :-) groff uses static constructors to
On Wed, Sep 10, 2014 at 05:29:13PM +0200, Ingo Schwarze wrote:
Hi Ulrich,
Ulrich Lauther wrote on Wed, Sep 10, 2014 at 01:01:37PM +0200:
On Wed, Sep 10, 2014 at 12:16:06PM +0200, Werner LEMBERG wrote:
Additionally, `git blame' would become much more inconvenient to use.
I am not
On Wed, Sep 10, 2014 at 01:23:41PM +0200, Werner LEMBERG wrote:
Additionally, `git blame' would become much more inconvenient to
use.
I am not familiar with git and git blame, used cvs in my active
time. Could you explain, what the problem with upper case class
names and git blame
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. The same is true with global variables. Sorry to say, but we
are now going into hearsay
well, I know how to find and read man-pages. But I was confused
about the connection you made between moving to upper case class
names and git blame. I guess, what you really wanted to say is that
ANY nonfunctional change would lead to false reports of git blame.
Exactly. You have to do
On Wed, Sep 10, 2014 at 08:02:30PM +0200, 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.
Yes, e.g., for
Hi Ulrich,
The problem with global variables is their long range effect,
comparable with the infamous goto statement: considered harmful.
I see little difference between looking at all the locations where the
global is changed and doing the same but for calls to a `set' routine,
other than the
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. The same is true with global variables.
Ingo --
On Wed, Sep 10, 2014, 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.
...
Your table is great. I'm going to print off a copy. It was a lot
of typing, so
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 groff's C++ is essentially C code
Ingo --
On Wed, Sep 10, 2014, Ingo Schwarze wrote:
One of the issues he raised with me off-list is an apparent lack
of organization. It's true.
I disagree. Lack of reviewable patches is not lack of organization.
If you have reviewable patches and people go for each other's throat
On Wed, Sep 10, 2014 at 10:16:47PM +0200, 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
Greetings.
Traffic and activity on the list got pretty hot over the summer.
Good discussions about underlining, Betrand's automake migration
nearly completed, and Bernd's Herculean labours tackling manpage
updates, licensing, copyrights, and a whole whack of other annoying
but essential details.
Hello Peter!
Out of that discussion came Doug's excellent suggestion for a new
primitive, '.decor' or similarly named, that's extensible so various
kinds of decoration can be applied to text, not just underlining
(which, IMO, groff seriously needs). [...]
Such suggestions or feature
Hi Peter,
Peter Schaffter wrote on Tue, Sep 09, 2014 at 05:31:38PM -0400:
The addition of useful new requests is part of our mission
statement, and Doug's '.decor' fits the bill. Problem is, the
thread died, and nothing came of it.
Well, even if a morsel fits the bill, there is no guarantee
Wow! Don't we hate project management! :) Looks like the word ETA caused
much heartburn.
Let me explain what I meant when was talking offline with Peter.
I hate processes as much as the next engineer but we do need some structure
if we are to let more people in.
I think, currently there is a lot
With respect to Vaibhaw's candidacy as maintainer, I propose leaving
the looking for a new maintainer notice on the webpage until the
matter is definitively settled. (If everyone's agreeable, I'll take
ownership of the webpage.)
Yes, we should keep looking; to find Gotham the hero that it needs.
41 matches
Mail list logo
