👍. I was asking about it earlier in #perl6. Here is the file that does perl5 pod processing in github:

https://github.com/github/markup/blob/master/lib/github/markups.rb#L41

As @Skarsnik mentioned on irc, why not use the .pod6 extension? Or couldn't you just require a v6 pragma? Lastly, there's always gitattributes!

👍 on using .pod6

So?

OK, now what?

Now do a PR against https://github.com/github/markup/blob/master/lib/github/markups.rb#L41 to differentiate and render pod6

github/markup#907

Unassigning @coke because it seems like he agreed to work on file renaming but not the github markup thing. Assign yourself again if that's not the case.

GitHub replied about setting up Perl 6 Pod renderer: github/markup#907 (comment)

Per the github/markup ticket, they could use someone from our team to make a PR:

You're certainly more than welcome to perform a PR with tests, and update the .travis.yml file so that our CI test suite verifies that Perl6 documentation is being generated.

Yeah, but they'd need to install Perl 6 for any of that to be of use. They talk about Ruby glue, but how do we get the stuff to glue with? And as far as my understanding goes: it'd be (a) a fully functional Perl 6 compiler that would compile arbitrary code from strangers; and (b) they don't pre-build the pages, right? So how would they cope with (a) and having potentially thousands of pages rendered with slow and resource hungry compiler?

Do we have any option of limiting the pod parser to just pod and not arbitrary code?

Anyway. I think both problems can be circumvented

I don't see how that advice help at all with the topic of this Issue. Who'd be pregenerating anything? GitHub?

@zoffixznet off the top of my head I guess that a restricted setting could be made that only does enough to parse and render the pod, but it would still be somewhat vulnerable to anything in BEGIN, INIT or CHECK blocks.

And I would say this one is actually solved, right?

Not at all. For example, here's a random page that is still not rendered:
https://github.com/perl6/doc/blob/master/doc/Language/about.pod6

As an example, here is a page that is rendered: https://github.com/perl6/nqp/blob/master/README.pod (but it's POD5)

I do have an issue with the external label. If it's something that has been reported elsewhere, it might be better to reference it here. If it's simply not related to this repo, we should simply close it. If we can fix it by working around the documentation quirks and rewrite the POD6 code, we should simply create a list of the pages affected and work through it, removing the external label.

@Skarsnik apparently not, but that's external to this repo. except if you want to change content to avoid that.

So does .pod6 get finally rendered correctly?

No.

As for closing tickets for issues that are still relevant, let's please not. The problem is still there, let's have a ticket for every problem. Otherwise people may open new dup tickets because, well, who would search through the closed ones?

@AlexDaniel this issue depends on another issue in the github/markdown (mentioned above) which does not seem like it's going to be closed or solved any time soon. In fact, googling perl6 pod rendering github returns that issue, not this one. There's slim chance someone else will open another ticket here on that particular matter. I think we can safely close this one. If some duplicate arrives, I'll close it immediately too.

And I'm closing this one, since nobody objected to this comment two days ago.

Uh… well, just because nobody objected doesn't really mean that it's right :)

There's also my comment above, where I think I've said it all already. We have external tag, and marking an issue as such is enough. Closing it does no good, having it open does not hurt and helps a lot when you need to find something.

Has anyone experimented with rendering pod6 from perl 5?

Pragmatically it may be easier to get github to install a Perl 5 module than Perl 6 itself.

This would at least be progress (although clearly using Perl 6 would be better).

I do have an issue with external tags in general.

Okay.

They tend to stay there like for ever.

Just like other issues that are hard to fix.

Even after the original issue has been solved.

This is not specific to external issues. Many of our old rakudo tickets were like this.

I don't think it's going to ever be solved

Your pessimism is irrelevant to the fact that we have this problem that needs to be resolved.

I would like to have this kind of issues not only reopened, but also self-assigned

We are volunteers. Feel free to self-assign.

wastes my time

I'm very sorry. FWIW you can include -label:external in your search to ignore these tickets. There are only 3 of them at the moment though.

Keeping it in the tally of unsolved issues is not good image either.

Closing issues that are not resolved creates an image that is even worse.

if google is used, it's going to search into solved and unsolved issues

Are you saying that I should search for tickets using google? That's not how I've been doing things, but that's an interesting idea…

"Hey! I'm not helpful and don't solve anything, but at least I'm green, meaning I care"

That sounds pretty good to me? EDIT: to clarify, caring about something is the first step to getting something helpful, and eventually solving the issue

My point is that issues in a particular repository should result in actionable changes in that particular repository.

In an ideal world, yes. But sometimes we depend on other things and need to track progress and stuff. FWIW here's an example of an issue that needs no commits in the repo but heavily depends on other stuff. According to your logic that issue should not exist, even though it was (and still is!) super helpful.

This means that the rest of the repo improvements can safely proceed without this particular one open.

The rest of the repo improvements can safely proceed with this particular one open.

Sorry I don't think I want to discuss this matter more.

EDIT: FWIW all references in irc log to this issue: poink

Pinging again to see if there's anything missing from the PR. It looks like I've done all changes requested, but...

Just as an update, there was an attempt to implement that in GitHub, but it failed since, for the time being, there is no way to parse the documents and avoid running code. There was a test repo here, but it has been since abandoned. So I'm closing this, since it seems impossible with the current (and foreseeable) state of things.

… Yeah, but the issue is still not resolved, right?

It's never going to be solved. I see no point in keeping it open. But, whatever.

It's never going to be solved.

I haven't followed this issue, but can we stop this bullshit, please? Surely you can write a dumb parser that doesn't execute any code. How many of the actual .pod6 files need code to be executed in order to render them properly? Yes, of course a parser like that will fail to render some files, so what?

In fact, you have to execute code in order to do correct syntax highlighting. Guess what, it doesn't stop all of the editors to highlight perl 6 code.

Well, maybe you should have. Since the Pod6 parser is part of the perl6 parser, it's basically impossible to guarantee that pod parsing is not running any code. Check this answer in StackOverflow, for instance. What I'm telling above is the actual sequence of events, which I have been following (and that's the reason why I'm closing this). Please check this comment by Kivikakk, who was in charge of implementing this for GitHub, and their subsequent quitting.
Baseline is: GitHub is not going to look at this any more. We can keep the issue open, close it or whatever. That's not going to change unless we come up with a Pod-only parser, which might or might not happen, but that will mean we will have to start the process all over again.

That's not going to change unless we come up with a Pod-only parser

OK, sounds great, let's keep this open then.

that will mean we will have to start the process all over again

Makes sense. We can also create a new ticket for our next iteration.

It would be much better if we closed this issue and summarized the problems for whatever comes next in a new one. Lots of people (including me) have wasted a lot of energy to solve it, for no good. It can be said that it has contributed to the greater good of Pod::To::HTML rendering, which it has, but still there's some specific work done to solve the issue which has gone to waste, and for precisely the reasons that were advised in several comments in this issue some time ago.

In fact, I am going to call a vote on closing this issue, for these reasons.

1. It's not actually a documentation issue, so it does not belong in this repo to start with. Rendering pod6 in GitHub might be a marketing, or an ecosystem issue, but definitely not part of the documentation.
2. The issue has actually been solved as posted. The pull requests created by several of us have actually been merged. They have finally been rejected in the actual production phase, but the work requested has actually been done.
3. The underlying problem (pod6 is parsed by perl6) is still there, and it's not going to be solved in terms of changes to this repository, so it does not belong to this repository. It might need a Pod6::Simple module in the ecosystem which has a Pod6-only grammar, or a Pod6::Clean module which cleans all code from the Pod before rendering it. None of them are, or will be, part of this repository.

So please vote by thumbs up (closing the issue), thumbs down (keep it open). And, of course, comment to explain your vote if you so like.

Ticket moved: Raku/user-experience#35

Please don't close still-unresolved issues without creating a new ticket first.