Re: Is Pod::Simple::POD worth pursuing?
On Mon, Jan 13, 2014 at 3:10 PM, Karl Williamson pub...@khwilliamson.com wrote: On 06/27/2013 11:41 PM, John SJ Anderson wrote: I'm happy to work towards #1, FWIW. I would think getting it into the CPAN Pod::Simple would be a necessary first step there. I finally got around to starting on this tonight: https://github.com/genehack/pod-simple/tree/add-pod-simple-pod Feedback is appreciated, especially on the tests (which are not yet all passing). I think I've got the first 80% done, and now I'm dealing with the second 80% of various irregularities. Thanks for starting this. What are your current plans regarding it? I ran out of tuits and it's stalled. If somebody else wants to pick it up, I have no objections to that. Failing that, I'm putting it back on my active project list -- but it's at the bottom, the list is long, and the free time is short... 8^) j.
Re: Is Pod::Simple::POD worth pursuing?
I'm happy to work towards #1, FWIW. I would think getting it into the CPAN Pod::Simple would be a necessary first step there. I finally got around to starting on this tonight: https://github.com/genehack/pod-simple/tree/add-pod-simple-pod Feedback is appreciated, especially on the tests (which are not yet all passing). I think I've got the first 80% done, and now I'm dealing with the second 80% of various irregularities. j.
Re: Is Pod::Simple::POD worth pursuing?
On Tue, May 21, 2013 at 04:33:14PM -0700, John SJ Anderson wrote: * Is this a worthwhile idea? (The recent How do I get Pod::Simple to extract pod thread suggests the answer is yes.) * Should I be working on this as a branch of Pod::Simple with the idea it could be included there eventually? * Does anybody else have any other feedback? I think that it is a good idea. In addition to extracting Pod, it could be used to build on give back a pod from a input that have the same 'internal representation' as Pod::Simple. For example, one could imagine an XML parser that starts from the XML produced by Pod::Simple::DumpAsXML and emits the same function calls as Pod::Simple such that using your modules turns it back to Pod easily. -- Pat
Re: Is Pod::Simple::POD worth pursuing?
On 05/21/2013 08:16 PM, Ricardo Signes wrote: * John SJ Anderson geneh...@genehack.org [2013-05-21T19:33:14] * Is this a worthwhile idea? (The recent How do I get Pod::Simple to extract pod thread suggests the answer is yes.) It's hard to judge this without the context in which you're considering it. The GH issue to which you linked is largely context-free. That said, wanting the ability to say gimme just the Pod from this Pod document seems pretty reasonable. Your code looks nice and simple. I'd rename it from POD to Pod so it's easier to remember. We cannot remove Pod::Parser from the core until podcheck.t stops using it. The version of podcheck.t that works with Marc Green's Pod::Checker uses Pod::Parser for only one remaining purpose: to extract the pod from a file. In order to remove this dependency, one of these things will have to happen: 1) We put John's new code in core, and podcheck.t uses it. 2) I steal John's code and put it in podcheck.t 3) I reimplement what John's code does, for podcheck.t I have been trying to avoid #3.
Re: Is Pod::Simple::POD worth pursuing?
On Wed, May 22, 2013 at 9:07 AM, Karl Williamson pub...@khwilliamson.com wrote: In order to remove this dependency, one of these things will have to happen: 1) We put John's new code in core, and podcheck.t uses it. 2) I steal John's code and put it in podcheck.t 3) I reimplement what John's code does, for podcheck.t I have been trying to avoid #3. I'm happy to work towards #1, FWIW. I would think getting it into the CPAN Pod::Simple would be a necessary first step there. chrs, john.
Re: Is Pod::Simple::POD worth pursuing?
* John SJ Anderson geneh...@genehack.org [2013-05-21T19:33:14] * Is this a worthwhile idea? (The recent How do I get Pod::Simple to extract pod thread suggests the answer is yes.) It's hard to judge this without the context in which you're considering it. The GH issue to which you linked is largely context-free. That said, wanting the ability to say gimme just the Pod from this Pod document seems pretty reasonable. Your code looks nice and simple. I'd rename it from POD to Pod so it's easier to remember. -- rjbs signature.asc Description: Digital signature
Re: Is Pod::Simple::POD worth pursuing?
On Tue, May 21, 2013 at 7:16 PM, Ricardo Signes perl@rjbs.manxome.org wrote: It's hard to judge this without the context in which you're considering it. The GH issue to which you linked is largely context-free. The context is that MetaCPAN's '/pod' endpoint is currently using Pod::POM for this purpose (i.e., returning the POD associated with a given module). Pod::POM does not return the =encoding line from the POD. Pod::POM also seems to be effectively abandoned, based on its rt.cpan.org queue and lack of recent releases. Finally, cpan-api already depends on Pod::Simple::XHTML, so making it possible for Pod::Simple to do this would eliminate one dependency there as well as fix bugs caused by the =encoding line being dropped. Further deep background: I found this bug when I ran 'cpandoc utf8::all' when utf8::all was not installed. I noticed a POD encoding error in the output (the utf8::all SYNOPSIS includes some Unicode glyphs and there was apparently no =encoding line present). I reported a bug there, discovered that utf8::all _was_ setting an =encoding properly, chased it back through Pod::Cpandoc, to MetaCPAN/cpan-api, and finally to Pod::POM -- where I found two open tickets about the same issue. Subsequent discussion on #metacpan lead to the suggestion of implementing something in Pod::Simple. So, here I am, with this lovely pile of yak hair and the first 80% of Pod::Simple::Pod. (I agree about the name suggestion, thanks.) Anyway, hopefully that helps people better understand what I'm trying to do here, or at least makes somebody smile ruefully. chrs, john.
