For years I missed the man pages of the C++ standard library and now found out that some Linux distros provide them as extra package. The man pages are not generated by a default during a GCC bootstrap install but need an explicit make doc-install-man in the corresponding doc directory of libstdc++.

Is there any such mechanism to generate man pages for D/Phobos?

Stefan

On Sat, Jan 05, 2019 at 09:59:27PM +0000, kdevel via Digitalmars-d-learn wrote:
> For years I missed the man pages of the C++ standard library and now found out that some Linux distros provide them as extra package. The man pages are not generated by a default during a GCC bootstrap install but need an explicit make doc-install-man in the corresponding doc directory of libstdc++.
> 
> Is there any such mechanism to generate man pages for D/Phobos?
> 
> Stefan

The current ddoc-based scheme may not be flexible enough to generate man pages (though I could be wrong).  But something like Adam Ruppe's adrdox could possibly be the basis for translating individual module symbols into manpages perhaps?

Though I have to warn, working with troff/groff syntax is probably not going to be pretty, esp. given the laxness / HTML-specificity of your typical Phobos doc comment.  But perhaps it could be made to work... Question is, who's gonna do the grunt work?


T

-- 
Computers shouldn't beep through the keyhole.

On Sunday, 6 January 2019 at 02:23:20 UTC, H. S. Teoh wrote:
> But something like Adam Ruppe's adrdox could possibly be the basis for translating individual module symbols into manpages perhaps?

The approach I'd take is actually converting my generated html to text and just piping it through less. Or if we specifically want man, convert the html into man syntax (there's enough semantic information there to do the conversion).

http://arsdnet.net/arsd/dman.png

But that's the result of about 5 mins of work... though I really like my hyperlinks and actually kinda prefer the browser for that reason (tho making a custom little terminal browser to handle the links is p tempting)

On Sun, Jan 06, 2019 at 03:11:48AM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote: [...]
> http://arsdnet.net/arsd/dman.png
> 
> But that's the result of about 5 mins of work... though I really like my hyperlinks and actually kinda prefer the browser for that reason (tho making a custom little terminal browser to handle the links is p tempting)

Lately I've come to hate the modern graphical browser more and more. It's a single over-complex point of failure that simply tries to do too much and be too much. Instead of doing one thing well and delegating other tasks to other programs that do them better, it does everthing mediocrely and wants to take over everything else, and inevitably ends up being a minefield of security holes, excessive unexplained resource consumption, needless hidden complexity, and generally stinks of bad (or rather lack of) design.

(My latest gripe is those pervasive evil svg/css spinners that consume ridiculous amounts of CPU for something completely irrelevant... once I dared to look at the related W3C specs, and found to my horror a completely ridiculously over-engineered mess that shows all the bad symptoms of design by committee with none of the benefits, along with the associated bloatware that cannot be anything *but* bloated and inefficient 'cos there's no other way to be spec-conformant. And all this just for some eye-candy. It's utterly insane, yet these days people swear by it.)

A text-based links browser with a focused use case sounds like a far better idea. Though programs like elinks or pinfo may have already have you beat on this front. :-D


T

-- 
If I were two-faced, would I be wearing this one? -- Abraham Lincoln

On Monday, 7 January 2019 at 14:25:26 UTC, H. S. Teoh wrote:
> A text-based links browser with a focused use case sounds like a far better idea. Though programs like elinks or pinfo may have already have you beat on this front. :-D

elinks does an ok job on dpldocs (of course, I partially designed it for such, but mostly it is just because my html is only partially crap), but a custom program can do better, and is really very little effort to write anyway...

On Saturday, 5 January 2019 at 21:59:27 UTC, kdevel wrote:
> For years I missed the man pages of the C++ standard library and now found out that some Linux distros provide them as extra package. The man pages are not generated by a default during a GCC bootstrap install but need an explicit make doc-install-man in the corresponding doc directory of libstdc++.
>
> Is there any such mechanism to generate man pages for D/Phobos?
>
> Stefan

Hello,
I have the same question. Where to find something similar to man pages from C?
I would like to use core.sys.posix.dirent and don't know where to find manuals about it.
Reading dirent.h or man opendir is a lot easier than reading dirent.d from
/usr/lib64/gcc/x86_64-slackware-linux/9.2.0/include/d/core/sys/posix
If I read dirent.d, then I see something like:
else version (CRuntime_Bionic)
{
}
else version (CRuntime_Musl)
{
}
else version (CRuntime_UClibc)
{
    void   seekdir(DIR*, c_long);
    c_long telldir(DIR*);
}
else
{
    static assert(false, "Unsupported platform");
}
does it mean that I can't use seekdir() on systems with Musl? (Alpine linux)?

On Monday, 23 September 2019 at 06:06:05 UTC, Jarek wrote:
> I have the same question. Where to find something similar to man pages from C?

They are the same functions, so the idea is you can just use the C man pages directly. There's just the pattern of the D module name to know.

but...

> does it mean that I can't use seekdir() on systems with Musl? (Alpine linux)?

it is possibly just not copied in there, I'd say to just try it and see if it triggers the static assert down there.

the man page says

CONFORMING TO
       4.3BSD, POSIX.1-2001.

so it probably should work with the core.sys.posix header there, maybe it just isn't verified as to the type of the argument (the notes section warns it has changed, so the D devs are surely being extra cautious about which one it actually has in there, waiting for someone to verify it before putting in the file)

On Monday, 23 September 2019 at 12:31:16 UTC, Adam D. Ruppe wrote:
> On Monday, 23 September 2019 at 06:06:05 UTC, Jarek wrote:
>> I have the same question. Where to find something similar to man pages from C?
>
> They are the same functions, so the idea is you can just use the C man pages directly. There's just the pattern of the D module name to know.
>
> but...
>
>> does it mean that I can't use seekdir() on systems with Musl? (Alpine linux)?
>
> it is possibly just not copied in there, I'd say to just try it and see if it triggers the static assert down there.
>
> the man page says
>
> CONFORMING TO
>        4.3BSD, POSIX.1-2001.
>
> so it probably should work with the core.sys.posix header there, maybe it just isn't verified as to the type of the argument (the notes section warns it has changed, so the D devs are surely being extra cautious about which one it actually has in there, waiting for someone to verify it before putting in the file)

Hello,
thanks for reply.
This is my first dlang work:
import std.stdio;
import std.conv;
import core.sys.posix.dirent;

int main(string[] args)
{
        DIR* proc;
        dirent *ent;
        proc = opendir("/proc");
        if(proc == null)        {
                stderr.writeln("Open /proc error");
                return 1;
        }
        stdout.writeln("proc opened");
        while((ent = readdir(proc)) != null)    {
                if(ent.d_type != DT_DIR)        {
                        continue;
                }
                stdout.writeln("Subdir: ", to!string(ent.d_name));
        }
        if(closedir(proc) == -1)        {
                stderr.writeln("Close dir error");
                return 1;
        }
        return 0;
}

How to handle ent.d_name? When I writeln it with to!string() conversion then it doesn't print well.
As a result I got something like this:
(...)
Subdir: 8�
10�11�12�13�14�15�17�18�19�
10�11�12�13�14�15�17�18�19�22�
Subdir: 10�11�12�13�14�15�17�18�19�22�23�
ubdir: 11�12�13�14�15�17�18�19�22�23�24�K
Subdir: 12�13�14�15�17�18�19�22�23�24�K25�L
Subdir: 13�14�15�17�18�19�22�23�24�K25�L73�M
Subdir: 14�15�17�18�19�22�23�24�K25�L73�M74�N
Subdir: 15�17�18�19�22�23�24�K25�L73�M74�N75�O
Subdir: 17�18�19�22�23�24�K25�L73�M74�N75�O76�Q
Subdir: 18�19�22�23�24�K25�L73�M74�N75�O76�Q77�R
Subdir: 19�22�23�24�K25�L73�M74�N75�O76�Q77�R79�S
Subdir: 22�23�24�K25�L73�M74�N75�O76�Q77�R79�S80�T
Subdir: 23�24�K25�L73�M74�N75�O76�Q77�R79�S80�T81�U
(...)
to!string() doesn't work?
thanks for help

On Thursday, 10 October 2019 at 18:52:32 UTC, Jarek wrote:
> On Monday, 23 September 2019 at 12:31:16 UTC, Adam D. Ruppe wrote:
>> [...]
>
> Hello,
> thanks for reply.
> This is my first dlang work:
> import std.stdio;
> import std.conv;
> import core.sys.posix.dirent;
>
> [...]

You should use fromStringZ: https://dlang.org/phobos/std_string.html#.fromStringz

On Thursday, 10 October 2019 at 19:19:42 UTC, Daniel Kozak wrote:
> On Thursday, 10 October 2019 at 18:52:32 UTC, Jarek wrote:
>> On Monday, 23 September 2019 at 12:31:16 UTC, Adam D. Ruppe wrote:
>>> [...]
>>
>> Hello,
>> thanks for reply.
>> This is my first dlang work:
>> import std.stdio;
>> import std.conv;
>> import core.sys.posix.dirent;
>>
>> [...]
>
> You should use fromStringZ: https://dlang.org/phobos/std_string.html#.fromStringz

stdout.writeln("Subdir: ", ent.d_name.fromStringz);