Activity for Erik Auerswald
-
Erik Auerswald posted a comment on ticket #748
I have further explored the man page generation rabbit hole, and attached two fresh patches against current HEAD in the GitLab git repository. The XML source seems not to be used by the normal build scripts. Thus modifying doc/_clisp.1 seems closest to the practical source of the man page. The attached patch clisp-gitlab-manpage-formatting-fix-via-_clisp.1.patch against current GitLab HEAD does this for both current instances of the problem. But since the doc/_clisp.1 file seems to be generated from...
-
I have also opened a bug report regarding this issue at Ubuntu, because I originally encountered the issue with CLISP packaged in Ubuntu 20.04: https://bugs.launchpad.net/bugs/2022970
-
Hi Florian, I am not involved with the CLISP project, but it seems to me as if the project has switched to GitLab. It seems as if they imported issues from this tracker there at some point in time in the past (see https://gitlab.com/gnu-clisp/clisp/-/issues). The clisp.org (redirected to https://clisp.sourceforge.io/) and https://www.gnu.org/software/clisp/ sites still direct bug reporters here, to the SourceForge bug tracker. I do not see much activity here in the SourceForge project, but the GitLab...
-
Well, I have looked at the wrong repository, i.e., the one at SourceForge instead of the one at GitLab. The problem is still there, but the affected line in doc/_clisp.1 is 438, not 434. Thus the fix would be sed -i '438s/:\.PP/:\n.PP/' doc/_clisp.1 for the generated man page, and possibly sed -i '316s/:/:\n /' doc/clisp.xml.in for the XML source for (among other formats) the man page (same line as in SourceForge Mercurial repository). Since the generated doc/_clisp.1 man page is checked into the...
-
Going deeper down this rabbit hole…: doc/man.xsl seems to be the style sheet entry point this reference http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl that file invokes further XSL stuff, somewhere within must be defined how to write man macros, including .PP One might assume that the docbook transformation to man page format should ensure that formatting directives that need to be preceded by a newline are actually preceded by a newline. Thus one might assume that there...
-
OK, I think I found the problematic file: doc/clisp.xml.in. Comparing the domain encoding and on error sections it seems to me as if a newline should be inserted in front of <variablelist>: sed -i '316s/:/:\n /' doc/clisp.xml.in The attached patch shows the results of above command. Please note that I did not test this and thus do not know if it really fixes the issue. I have not yet attempted to build the clisp sources….
-
I have created the attached patch via sed -i '434s/:\.PP/:\n.PP/' doc/_clisp.1 followed by hg diff.
-
Well, it seems as if the file doc/_clisp.1 might be generated via XSLT transformations, but I have not yet found the source, nor have I found the relevant style sheet. The root cause for the issue might be found in either of them, or at least a workaround would likely pertain to the man page source or the style sheet. If I were told (e.g., via ticket comment) where to find those and how to generate just the doc/_clisp.1 file, I would be happy to look into finding a solution.
-
While the above sed command works in the current case, the . in the pattern should have been escaped: sed -i '434s/:\.PP/:\n.PP/' doc/_clisp.1
-
docs: formatting error in man page: missing newline before macro (with fix)
-
Fails to build with GCC 10
-
According to the lex & yacc and flex & bison books, using extern FILE *yyin is correct. Obviously, omitting extern worked since introducing the functionality in the year 2000. It still works with GCC versions less than 10. I have tested the patch on Ubuntu 18.04.3 LTS with gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0. The NAS server builds and parses the configuration with and without extern. Note that using extern FILE *yyin can only be used with a non-reentrant scanner. The scanner used for parsing...
-
No License file
-
Closing this bug since the license is included in the README since "forever."
-
Fix building with GCC 10
-
Hello Petr, On Thu, Jan 23, 2020 at 12:52:54PM -0000, Petr Písař wrote: [bugs:#7] Fails to build with GCC 10 Status: open Group: v1.0 (example) Created: Thu Jan 23, 2020 12:52 PM UTC by Petr Písař Last Updated: Thu Jan 23, 2020 12:52 PM UTC Owner: nobody Attachments: nas-1.9.4-Fix-building-with-GCC-10.patch (1.5 kB; application/octet-stream) nas-1.9.4 fails to build with GCC 10 due to a double global variable definition. An attached patch fixes it. Thanks for the patch. At first glance it seems sensible,...
1