Hi guys!
I saw the refdoc on the Pike site is somewhat broken. The plan is to port the new refdoc layout in 8.1 to 8.0, and I'm working on that as we speak. But in order to make that work I need to add the standalone Tools.Standalone.pike_to_html tool since that is used to highlight example code in the refdoc. Is that ok?
Regards ----------------------------- Pontus Östlund Developer • Roxen AB +46 70-662 81 69
www.roxen.com http://www.roxen.com/ | twitter.com/roxen https://twitter.com/roxen
On Sat, Nov 12, 2016 at 3:31 AM, Pontus Östlund pontus@roxen.com wrote:
I saw the refdoc on the Pike site is somewhat broken. The plan is to port the new refdoc layout in 8.1 to 8.0, and I'm working on that as we speak. But in order to make that work I need to add the standalone Tools.Standalone.pike_to_html tool since that is used to highlight example code in the refdoc. Is that ok?
Do it. For the record I don't currently consider Tools.Standalone part of the stable API, but maybe it should be.
Regards,
13 nov. 2016 kl. 00:09 skrev Peter Bortas bortas@gmail.com:
On Sat, Nov 12, 2016 at 3:31 AM, Pontus Östlund pontus@roxen.com wrote:
I saw the refdoc on the Pike site is somewhat broken. The plan is to port the new refdoc layout in 8.1 to 8.0, and I'm working on that as we speak. But in order to make that work I need to add the standalone Tools.Standalone.pike_to_html tool since that is used to highlight example code in the refdoc. Is that ok?
Do it. For the record I don't currently consider Tools.Standalone part of the stable API, but maybe it should be.
I committed the new refdoc in 8.0 yesterday, so who ever is in charge of building the doc on the website can test that now and see if it works as expected.
Regards ----------------------------- Pontus Östlund Developer • Roxen AB +46 70-662 81 69
www.roxen.com http://www.roxen.com/ | twitter.com/roxen https://twitter.com/roxen
Pontus ??stlund wrote:
I saw the refdoc on the Pike site is somewhat broken. The plan is to port the new refdoc layout in 8.1 to 8.0, and I'm working on that as we speak. But in order to make that work I need to add the standalone
It appears that @[...] does not generate a clickable href anymore in your new code.
27 nov. 2016 kl. 11:51 skrev Stephen R. van den Berg srb@cuci.nl:
Pontus ??stlund wrote:
I saw the refdoc on the Pike site is somewhat broken. The plan is to port the new refdoc layout in 8.1 to 8.0, and I'm working on that as we speak. But in order to make that work I need to add the standalone
It appears that @[...] does not generate a clickable href anymore in your new code.
You are absolutely right, but I'm not 100% sure that has anything to do with the new layout, but I'm unsure.
It seems that when resolve_reference is called in atutodoc_to_html (which actually calls my_resolve_reference in autodoc_to_split_html) the second argument (xml_node->get_attributes()) is always an empty mapping. When I looked in the XML file the doc is built from I see:
<doc> <text> <p>Test if <ref>set_options()</ref> will be linked to from <ref>a</ref> ?</p> </text> <group> <param name="a"/> <text> <p>Just a parameter</p> </text> </group> </doc>
The <ref/>-nodes doesn't contain any info about their targets. I don't know if this is supposed to be like this and that the targets are resolved later or not, but it doesn't look like it from what I can see? So the problem seems to be related to when the modref.xml is generated rahter than when the refdoc pages are built. Or am I totally wrong here?
Regards ----------------------------- Pontus Östlund Developer • Roxen AB +46 70-662 81 69
www.roxen.com http://www.roxen.com/ | twitter.com/roxen https://twitter.com/roxen
Another thing I noticed is that when you run pike -x module module_modref in a local CMOD module the cmod doesn't get extracted. The .so file (and .pmod) gets copied to plib/module but not the .cmod file. Then in extract_autodoc.pike is this line:
foreach(filter(get_dir(srcdir), has_suffix, ".cmod"), string fn)
But there will never be any .cmod file in there.
But this might be due to a misconfiguration from my side in module?
Regards ----------------------------- Pontus Östlund Developer • Roxen AB +46 70-662 81 69
www.roxen.com http://www.roxen.com/ | twitter.com/roxen https://twitter.com/roxen
29 nov. 2016 kl. 13:56 skrev Pontus Östlund pontus@roxen.com:
Another thing I noticed is that when you run pike -x module module_modref in a local CMOD module the cmod doesn't get extracted. The .so file (and .pmod) gets copied to plib/module but not the .cmod file. Then in extract_autodoc.pike is this line:
foreach(filter(get_dir(srcdir), has_suffix, ".cmod"), string fn)
But there will never be any .cmod file in there.
But this might be due to a misconfiguration from my side in module?
Ok, after som searching I found you need the AUTODOC_SRC_IN directive in Makefile.in. But "cmods" isn't allowed there apparently:
if( !(< "c", "cc", "cpp", "m", /* "cmod", */ "pike", "pmod", >)[suffix] ) error("Unknown filetype %O.\n", suffix);
Regards ----------------------------- Pontus Östlund Developer • Roxen AB +46 70-662 81 69
www.roxen.com http://www.roxen.com/ | twitter.com/roxen https://twitter.com/roxen
I think the intent is that the final source file will be used to generate the autodoc, so in this case, module.c. That's in case there are transformations occurring during precompilation.
Bill
On Nov 29, 2016, at 8:24 AM, Pontus Östlund pontus@roxen.com wrote:
29 nov. 2016 kl. 13:56 skrev Pontus Östlund pontus@roxen.com:
Another thing I noticed is that when you run pike -x module module_modref in a local CMOD module the cmod doesn't get extracted. The .so file (and .pmod) gets copied to plib/module but not the .cmod file. Then in extract_autodoc.pike is this line:
foreach(filter(get_dir(srcdir), has_suffix, ".cmod"), string fn)
But there will never be any .cmod file in there.
But this might be due to a misconfiguration from my side in module?
Ok, after som searching I found you need the AUTODOC_SRC_IN directive in Makefile.in. But "cmods" isn't allowed there apparently:
if( !(< "c", "cc", "cpp", "m", /* "cmod", */ "pike", "pmod", >)[suffix] ) error("Unknown filetype %O.\n", suffix);
Regards
Pontus Östlund Developer • Roxen AB +46 70-662 81 69
www.roxen.com | twitter.com/roxen
29 nov. 2016 kl. 14:45 skrev H William Welliver III william@welliver.org:
I think the intent is that the final source file will be used to generate the autodoc, so in this case, module.c. That's in case there are transformations occurring during precompilation.
It was just a bit confusing that in one method ".cmod"s were scanned for and in another prohibited :D
Regards ----------------------------- Pontus Östlund Developer • Roxen AB +46 70-662 81 69
www.roxen.com http://www.roxen.com/ | twitter.com/roxen https://twitter.com/roxen
I think the intent is that the final source file will be used to generate the autodoc, so in this case, module.c. That's in case there are transformations occurring during precompilation.
It wasn't about transformations so much as avoiding to figure out what c files belong to what cmod files. You need to skip one or the other, so skipping the cmod files are easier.
27 nov. 2016 kl. 11:51 skrev Stephen R. van den Berg srb@cuci.nl:
Pontus ??stlund wrote:
I saw the refdoc on the Pike site is somewhat broken. The plan is to port the new refdoc layout in 8.1 to 8.0, and I'm working on that as we speak. But in order to make that work I need to add the standalone
It appears that @[...] does not generate a clickable href anymore in your new code.
From what I can tell it's this commit (http://pike-librarian.lysator.liu.se/piff.xml?module=pike.git&file=lib/m... http://pike-librarian.lysator.liu.se/piff.xml?module=pike.git&file=lib/modules/Tools.pmod/Standalone.pmod/join_autodoc.pike&from=3e6a5403fadfa653c5e66ef8413541f385c3c6ba&to=ee1c5d49b2d57c665c3f01ec8d83e8df81d89504) that broke it.
I guess some arguments don't behave the same way as before.
Regards ----------------------------- Pontus Östlund Developer • Roxen AB +46 70-662 81 69
www.roxen.com http://www.roxen.com/ | twitter.com/roxen https://twitter.com/roxen
pike-devel@lists.lysator.liu.se