Re: Building Documentation

[Paul Smith]

On Sun, 2020-05-24 at 21:10 -0500, Pete Dietl wrote:
> Does anyone have advice on how to build the web documentation?
> I tried running `make gendocs` but I get errors like:
> 
> cvs -d :pserver:anonym...@cvs.sv.gnu.org:/web/www co 'www/server/standards'
> 
> cvs [checkout aborted]: connect to cvs.sv.gnu.org(209.51.188.81):2401
> failed: Connection refused

I don't know why this wouldn't work: this is anonymous CVS access so
anyone should be able to retrieve these with no special permissions
required (you do need to install CVS obviously).

Anyway, you don't necessarily need the boilerplate since you're not
going to be pushing official docs.

You can try just:

   make html

in the make root directory.  Or, probably better if you just want to
post the content to the mailing list, use:

   make info

to generate the info files which are basically text.

Building Documentation

[Pete Dietl]

Does anyone have advice on how to build the web documentation?
I tried running `make gendocs` but I get errors like:

cvs -d :pserver:anonym...@cvs.sv.gnu.org:/web/www co 'www/server/standards'

cvs [checkout aborted]: connect to cvs.sv.gnu.org(209.51.188.81):2401
failed: Connection refused

Re: math expressions (was: Re: Tail call elimination)

[Paul Smith]

On Sun, 2020-05-24 at 14:09 -0500, Pete Dietl wrote:
> > I think, as I mentioned before, that someone (I guess that's you
> > :)) should write up an actual proposal (maybe, for example, the
> > start of a new manual section) that can be examined and commented
> > on.
> 
> Challenge accepted! What is the best form to choose...
> maybe creating a branch of the source and adding a new manual page
> there that anyone can render?

As you may notice, Savannah doesn't support fork and pull request
capabilities like some other services, so we don't really have a way to
share branches like this.

You can just write the text and worry about formatting it later, or
make the changes to the texinfo file and send a diff, or make changes
to the texinfo file then format it for info output and send the
resulting formatted text.

As long as it's not a mess of unreadable HTML source it doesn't matter
to me :).

> > I do want to reiterate something I mentioned initially: any effort
> > of this size will require copyright assignment to the FSF / GNU
> > project.
> 
> Where can I find more information about this? And where do I do it?

I'll send you an email with next steps for this.

> > We can always use evaluation so you could just implement the basics
> > first and get grouping via evaluation for free, then add explicit
> > grouping as a next step if you want.
> 
> Yes incremental changes sound good. Would you recommend
> first trying to agree on a proposal and then attempt some
> implementation?
> Or to do these things together?

It's up to you.  If you want to just write something that's fine.  If
you feel like doing some prototyping would help you come up with the
proposal that's good too.  Note that we likely won't let amount of work
already completed to have much impact on requests to make changes, so
if it will cause sadness to throw out work or have to redo it, then the
less up-front work the better :).

FYI if you do start work on code be sure to read the GNU coding
standards which are slightly unique.  New code needs to follow the
existing formatting.

[bug #58435] make 4.3 is not c89 compliant

[anonymous]

Follow-up Comment #3, bug #58435 (project make):

perhaps the maintainers of gnulib ought to be notified of this also...

gnu's coding standards state that c89 should be the default targeted c
standard, and c99 functionality should be checked for if used. if gnulib is
using c99 features, and is meant to be the canonical source of portability
code, that seems like an issue to me...

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: math expressions (was: Re: Tail call elimination)

[Pete Dietl]

> I think, as I mentioned before, that someone (I guess that's you :))
> should write up an actual proposal (maybe, for example, the start of a
> new manual section) that can be examined and commented on.  Endless
> streams of mailing list responses quickly give diminishing returns.  My
> experience is that it's much easier to come to conclusions when there
> is a concrete plan to start from.

Challenge accepted! What is the best form to choose...
maybe creating a branch of the source and adding a new manual page
there that anyone can render?

> I do want to reiterate something I mentioned initially: any effort of
> this size will require copyright assignment to the FSF / GNU project.
> Please be sure you are OK with that.  Getting that in motion earlier
> will avoid delays at the end.

Where can I find more information about this? And where do I do it?

> We can always use evaluation so you could just implement the basics
> first and get grouping via evaluation for free, then add explicit
> grouping as a next step if you want.

Yes incremental changes sound good. Would you recommend
first trying to agree on a proposal and then attempt some implementation?
Or to do these things together?

[bug #57962] make attempts to execute a directory found on PATH

[Paul D. Smith]

Follow-up Comment #13, bug #57962 (project make):

Thanks for pointing that out!

This has been fixed in the findprog-in module in gnulib now as well.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: math expressions (was: Re: Tail call elimination)

[Paul Smith]

On Sat, 2020-05-23 at 15:43 -0500, Pete Dietl wrote:
> > I understand what Tim is saying but I still prefer to have a single
> > function.  I want to reduce the "namespace leakage" for these
> > capabilities.  If we decide to add more operations to this in the
> > future I don't want it colliding with something else we want to do.
> > 
> > However, sometimes it's hard to see exactly how something will look
> > until we actually see it.
> 
> Hm so does that imply that we're still on the fence?
> What can we do to resolve this? Take a poll?

I think, as I mentioned before, that someone (I guess that's you :))
should write up an actual proposal (maybe, for example, the start of a
new manual section) that can be examined and commented on.  Endless
streams of mailing list responses quickly give diminishing returns.  My
experience is that it's much easier to come to conclusions when there
is a concrete plan to start from.

I do want to reiterate something I mentioned initially: any effort of
this size will require copyright assignment to the FSF / GNU project. 
Please be sure you are OK with that.  Getting that in motion earlier
will avoid delays at the end.

> You're the benevolent dictator right Paul? :)

Perhaps, in the sense that I reserve the right of ultimate refusal :)

However, the person who makes the proposal and does the work gets to
make a lot of the decisions.

So, I say you should do that.

> > > I propose the following (a variation of example 2):
> > > 
> > > $(math + 5 (/ (* (/ (* 2 9) (+ 7 5 4)) (* 1024 1024)) 19))
> > 
> > If we want to support grouping directly we're still requiring the
> > function to be recursive.  If we use make expansion to provide
> > grouping the function doesn't need to be recursive (of course, we
> > get recursion implicitly because of make's expansion).
> 
> By recursive do you mean the implementation of
> $(math) in the make source is recursive?

Yes.

> It you need more convincing, one could argue that parsing it directly
> would likely lead to a more efficient implementation -- we would
> have the opportunity to implement this as an iterative process;
> either by loops or tail-call recursion. But I'll reiterate that my
> motivation is a more concise syntax.

We can always use evaluation so you could just implement the basics
first and get grouping via evaluation for free, then add explicit
grouping as a next step if you want.

I'm not sure that attempting to avoid recursion (which basically
involves replacing it with some sort of array- or list-based stack) is
worthwhile for the anticipated uses.  So, to me it all comes down to
the implementation: how much more complex is it.

I recommend as above: it is approached iteratively and then we can
decide at each point of it's "good enough" and how much complexity the
next step adds.

Re: Maybe a bug in make manual. https://www.gnu.org/software/make/manual/make.html#Overriding-Makefiles

[Martin Dorey]

I think the text is as intended.  The previous paragraph talks about the -t, -n 
and -q switches as being treated similarly.  The example could use any but has 
to pick one.


From: Bug-make  on behalf of 牛啊 
<285430...@qq.com>
Sent: Sunday, May 24, 2020 07:26
To: bug-make
Subject: Maybe a bug in make manual. 
https://www.gnu.org/software/make/manual/make.html#Overriding-Makefiles

* EXTERNAL EMAIL *
https://www.gnu.org/software/make/manual/make.html#Overriding-Makefiles

The last 2 paragraph of chapter [3.5 How Makefiles are Remade ]

 Original Manul 
However, on occasion you might actually wish to prevent updating of even the 
makefiles. You can do this by specifying the makefiles as goals in the command 
line as well as specifying them as makefiles. When the makefile name is 
specified explicitly as a goal, the options ‘-t’ and so on do apply to them.

Thus, ‘make -f mfile -n mfile foo’ would read the makefile mfile, print the 
recipe needed to update it without actually running it, and then print the 
recipe needed to update foo without running that. The recipe for foo will be 
the one specified by the existing contents of mfile.

<<<

I think the option you want to explain is '-n', rather than '-t'. So the 
sentance should be:

  When the makefile name is specified explicitly as a goal, the options 
  ‘-n’ and so on do apply to them. <<<


I'm not sure whether I'm right , thank you for your time, that's all.

Best regards!

Maybe a bug in make manual. https://www.gnu.org/software/make/manual/make.html#Overriding-Makefiles

[????]

https://www.gnu.org/software/make/manual/make.html#Overriding-Makefiles


The last 2 paragraph of chapter [3.5 How Makefiles are Remade ]

 Original Manul 
However, on occasion you might actually wish to prevent updating of even the 
makefiles. You can do this by specifying the makefiles as goals in the command 
line as well as specifying them as makefiles. When the makefile name is 
specified explicitly as a goal, the options ??-t?? and so on do apply to them.

Thus, ??make -f mfile -n mfile foo?? would read the makefile mfile, print 
the recipe needed to update it without actually running it, and then print the 
recipe needed to update foo without running that. The recipe 
for foo will be the one specified by the existing contents 
of mfile.

<<<

I think the option you want to explain is '-n', rather than '-t'. So the 
sentance should be:

  When the makefile name is specified explicitly as a 
goal, the options ??-n?? and so on do apply to them. <<<




I'm not sure whether I'm right , thank you for your time, that's all.

Best regards!

[bug #58435] make 4.3 is not c89 compliant

[Dmitry Goncharov]

Follow-up Comment #2, bug #58435 (project make):

This code was introduced when a local implementation of strerror was replaced
with gnulib's one.

commit 4d00ceba264a9fd04241dcd2685526ce64c1346b
Author: Paul Smith 
Date:   Sat Jul 13 08:34:45 2019 -0400

Switch to the gnulib version of strerror()

* bootstrap.conf: Add strerror module
* configure.ac: Remove strerror check
* src/misc.c: Remove local strerror() implementation
* src/config.ami.template: Remove HAVE_STRERROR
* src/config.h-vms.template: Ditto.
* src/config.h.W32.template: Ditto.


Either c90 conformance has to be dropped or code from gnulib cannot be easily
integrated.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/