First pass at Perl 6 -> Raku

[coke]

Providing a target for for the Raku discussion going on at

Raku/problem-solving#81

Should not be merged until that issue has a clear resolution.

Only targeted the places in text where Perl 6 could safely be changed; if it's a historical quote, or required some context, made minimal edits.

Needs to also address instances of the executable name.

Didn't change the nbsp test because "Perl 6" still appears in some places (just not many).

Please feel free to keep this branch up to date with rebases, and with more commits.

[AlexDaniel]

Moreover, here's an unfiltered list of things to check. Anything that talks about “Perl” in general should now use “Raku” instead. Any references to perl5 should be moved to 5to6 docs (this was discussed long time ago).

ack 'Perl [^6]'

Language/101-basics.pod6
368:Perl code can appear within curly braces, C<Array>s and C<Hash>es may be

Language/5to6-nutshell.pod6
125:those restrictions are unlikely to concern much real-life Perl code (e.g.,
127:there are a few that will unfortunately conflict with some Perl hackers'
319:In Perl 5, the C<*> sigil referred to the GLOB structure that Perl uses to
1285:Perl pragma to use integer arithmetic instead of floating point.  There is
1491:=head2 Perl module library path
1494:Perl modules is C<PERL5LIB>.
1516:(Perl 6 does not recognize either the C<PERL5LIB> or the older Perl environment
1826:This project is dedicated to automated modernization of Perl code. It does
1837:This project is a suite of Perl cross-compilers, including Perl 5-to-6

Language/5to6-perlfunc.pod6
32:=head1 Alphabetical listing of Perl functions
518:of I<replacing> your Perl program's process with the new program;

Language/5to6-perlop.pod6
309:backticks do not do shell quoting as in Perl 5, and Perl variables are

Language/5to6-perlsyn.pod6
7:perlsyn - Perl syntax

Language/5to6-perlvar.pod6
140:like C<v6.c>; the full stringified version of the Perl interpreter is obtained

Language/classtut.pod6
834:C<$o.perl> returns a string that can be executed as Perl code, and

Language/community.pod6
10:of Perl and of the community." - Larry Wall
23:Perl 6 is also a common topic at L<Perl conferences|https://www.perl.org/events.html> and L<Perl Monger meetings|https://www.pm.org/> and L<other meetups|https://perl.meetup.com/>.
33:If you want a single resource to know what is going on in the Perl community now, this is your best resource

Language/concurrency.pod6
29:Additionally, certain Perl features may implicitly operate in an asynchronous

Language/faq.pod6
951:=item Perl 6's mottos remain the same as they have been for Perl all along:
952:“Perl is different. In a nutshell, Perl is designed to make the easy jobs easy,

Language/glossary.pod6
150:initial barrage of RFCs that came out of the Perl community. Now only kept
587:"There's More Than One Way To Do It", the Perl motto.
835:The Perl programming language in its many forms.
841:by many in the L<Perl Community|/language/community>.
1234:A virtual machine is the Perl compiler entity that executes the

Language/grammar_tutorial.pod6
709:check out the more advanced L<Perl Grammar Guide|/language/grammars>.

Language/io-guide.pod6
151:Here's an example that finds lines in a text file that mention Perl and prints

Language/io.pod6
217:on failure. Thus the standard Perl idiom works as expected:

Language/modules.pod6
49:have the same structure as any distribution in the Perl family of languages:

Language/nativecall.pod6
37:Sometimes you want the name of your Perl subroutine to be different from the
43:routine in your library that may be different from your Perl subroutine name.

Language/rb-nutshell.pod6
66:restrictions are unlikely to concern much real-life Perl code (e.g. whitespace
1052:=head2 Perl module library path

Language/regexes.pod6
1331:(e.g., replacing 'Perl Jam' with 'Pearl Jam'), to reformatting an ISO8601

Language/testing.pod6
32:As with any Perl project, the tests live under the C<t> directory in the

Language/variables.pod6
432:    $~MAIN       the current main language (e.g. Perl statements)
1479:Contains the name of the Perl executable that is currently running. (e.g.

Type/IO/CatHandle.pod6
567:(my $f1 = 'foo'.IO).spurt: 'Perl loves to';
571:    say .readchars: 11;   # OUTPUT: «Perl loves ␤»

Type/CallFrame.pod6
26:Perl constructs a frames for blocks and such as well, so if you need a callframe

Type/Code.pod6
91:    say comber 'Perl is awesome! Python is great! And PHP is OK too';
92:    # OUTPUT: «(Perl Python PHP)␤»

Type/Mu.pod6
179:ways to write a Perl expression that produces a particular value.

Type/Pair.pod6
186:    my $p = (Perl => 6);
197:    my $p = (Perl => 6);
239:    my $p = (Perl => 6);
251:    my $p = (Perl => 6);
253:    say $p.pairs[0];    # OUTPUT: «Perl => 6␤»
266:    say $p.first;                                     # OUTPUT: «Perl => 6␤»
287:    :foo<Perl is great>.invert.perl.say;

Type/Perl.pod6
5:=SUBTITLE Perl related information
7:    class Perl does Systemic { }
17:L<Compiler|/type/Compiler>, associated with the Perl object.

Type/independent-routines.pod6
386:$fh.say: 'I ♥ writing Perl code';

[AlexDaniel]

Oh, yeah, and “5to6” wouldn't mean much (or enough) if the Raku proposal is accepted, so should these be called something else too? Like “perl-to-raku”?

[Grinnz]

Embracing the power of names without numbers: perl2raku ;)

[AlexDaniel]

Embracing the power of names without numbers: perl2raku ;)

I like that. Just need to make sure there's a redirect so that we're not braking any links outside of our infrastructure.

[JJ]

Well... links will be broken no matter what. Just for the record, we shouldn't rely on server redirections to take care of that. We'll probably be using a static-only pages for Perl 6 doc for some time to come, maybe for ever. Also, I don't know how to take care of this, but renaming stuff is probably not the best way to handle that. I would opt for creating a new site with the new names, leave this old one as a branch, and insert a notice in the header of every one redirecting people to the new place, which will be the one that will eventually remain. After all, people are bound to keep using their current perl6 infrastructure and be oblivious of the name change for quite some time. Eventually we'll create a DNS-level redirect for documentation (and I guess the rest), but for some time I would leave the two sites coexist. Thus said, I wouldn't merge this before branching the "old" documentation, and creating an issue that addresses needed changes. PRs should address issues, after all. So I would really prefer this PR to be closed, and open an issue instead to discuss all issues involved. After all, from here to the eventual merge there's bound to be many, maybe conflicting, changes.

[JJ]

And there are conflicts already

[AlexDaniel]

I would opt for creating a new site with
the new names, leave this old one as a branch, and insert a notice in the
header of every one redirecting people to the new place

Isn't it, like, a lot of work? Doesn't look very actionable to me, giving the time constraints most people have.

[JJ]

We just have to change one file, the header.html. People will keep on looking for Perl 6 for quite some time after changing. We don't want to lose them. El mié., 14 ago. 2019 11:39, Aleks-Daniel Jakimenko-Aleksejev < notifications@github.com> escribió:

…

I would opt for creating a new site with the new names, leave this old one as a branch, and insert a notice in the header of every one redirecting people to the new place Isn't it, like, *a lot* of work? Doesn't look very actionable to me, giving the time constraints most people have. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2951>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAAD5HKWVTKLW44O5AJECDQEPHEHANCNFSM4ILPGRGA> .

[coke]

For things that match Perl with no 6, it's not entirely clear that it's a simple substitution to Raku. Probably needs a human to verify the context.

My first pass here was most of the Perl 6 instances that didn't have some sort of historic context; it was my intent that any literal "Perl 6" that was left was intentional, so please also double check those before updating.

[coke]

my 2¢: Maintaining 2 copies of the site, one with redirects, is harder than adding more redirects to the .htaccess file, especially since, as you say, we're probably going to be static for some time.

I would expect that, when we change the DNS, we have one top level redirect to get people to the new hostname, and then any redirects for page names changed as a result of the rename can be tracked in .htaccess, so that old links still work.

We can add the redirects in this branch as we rename the pod6 files.

[JJ]

Hi, El mié., 14 ago. 2019 a las 17:06, Will Coleda (<notifications@github.com>) escribió:

my 2¢: Maintaining 2 copies of the site, one with redirects, is harder than adding more redirects to the .htaccess file, especially since, as you say, we're probably going to be static for some time.

I'm not talking about redirects, but links either to the general site or to the equivalent page. That's a straightforward transformation except in the cases the URL involves perl6. Again, people are going to keep searching "strings in perl 6" for quite some time. The equivalent raku page is not going to be returned by that search query. We can have them both for an agreed period of time (6 months, for instance) or until the domains expire (which might be never).

I would expect that, when we change the DNS, we have one top level redirect to get people to the new hostname, and then any redirects for page names changed as a result of the rename can be tracked in .htaccess, so that old links still work.

Static pages needn't include .htaccess, and I wouldn't want to have that kind of URL-generating hacks in the new site. It's caused enough headaches up to now. So, two points here: 1. A PR is not the place to discuss this, but the problem-solving repo. 2. We will need for the sake of search engines to keep both set of pages, with links from perl6 to raku, for a period of time. And then we'll need some SEO hacks so that new pages will keep being returned when people search for Perl 6 (which they will). Part of that SEO hack will be to point from the old pages to the new ones, but we'll need a bit more, I guess.

[coke]

Please feel free to create an issue.

I understand the problem you're trying to fix about people searching for the literal string "strings in perl6". But keeping two sites live doesn't really help this, as it will confuse the users and the search engines, and whenever we shut it down, the bandaid that was in place is not replaced. And if the old site is somehow manually redirecting to the new site, that's more work to maintain. If it's automatically doing it (but at the page level), then we have a whole site that can be replaced with a single host level redirect (see below).

I don't understand the problem you're seeing with .htaccess (which we are already using on the existing live site). The issue I'm discussing is not about URL generation, it's about preserving the old URL paths. You don't need to keep both sets of pages if you have the redirects in place so that hitting the old page brings you to the new page. With a redirect at the top level so that anything at the old hostname goes to the new hostname, and then something to redirect any use of the old path to the new path, you cover any old URLS hitting the newly renamed pages on the new hostname.

So, on the old site, have a redirect that matches anything with the old hostname to the same path at the new hostname (this can be done inside an .htaccess controlled in the site, or via one that is part of the deployment to the original site.); say "https://doc.perl6.org/old-5-to-6-url" - this would then get redirected to "https://doc.raku.org/old-5-to-6-url", which would then get redirected to .../new-5-raku-url" - we'd change any internal references to the correct relative URL, but any old URLS would continue to work.

[JJ]

El mié., 14 ago. 2019 a las 18:57, Will Coleda (<notifications@github.com>) escribió:

Please feel free to create an issue. I understand the problem you're trying to fix about people searching for the literal string "strings in perl6". But keeping two sites live doesn't really help this, as it will confuse the users and the search engines, and whenever we shut it down, the bandaid that was in place is not replaced. And if the old site is somehow manually redirecting to the new site, that's more work to maintain. If it's *automatically* doing it (but at the page level), then we have a whole site that can be replaced with a single host level redirect (see below).

I don't intend to do that forever, just for some time. I don't have a big problem with having to work a bit more.

I don't understand the problem you're seeing with .htaccess (which we are already using on the existing live site). The issue I'm discussing is not about URL generation, it's about preserving the old URL paths.

No, we're no longer using it, since we moved it to the interim infrastructure. And I'm not sure it really worked before that.

You don't need to keep both sets of pages if you have the redirects in place so that hitting the old page brings you to the new page. With a redirect at the top level so that anything at the old hostname goes to the new hostname, and then something to redirect any use of the old path to the new path, you cover any old URLS hitting the newly renamed pages on the new hostname.

Then what happens is that the Google crawler gets a page that was indexed under "perl6" with something that has eliminated any mention to perl 6: boom, it gets demoted to last in the query, not only for the old query terms, but the new query terms. That's not good for the documentation, and it's the situation I'm trying to prevent here. On the other hand, if we create clear path with both pages coexisting at the same time, there will be some time for the new pages to pick up SEO juice, and we can eventually just bring down the old site (or use redirections, it does not really matter at that point in time) with no penalization by search engines.

[AlexDaniel]

No, we're no longer using it, since we moved it to the interim
infrastructure. And I'm not sure it really worked before that.

It did work, it needs to be fixed. Breaking links is not cool.

[robertlemmen]

regarding seo juice: if we have almost-the-same pages under two different URLs, I believe we need to say in the header (of both) which one is the "canonical" and that the two are equivalent, or get punished for link farming. I guess you know better than I how to do that, if not then I can find out...

[lizmat]

It feels to me we're getting ahead of ourselves here. There hasn't been an official decision yet about a rename. And in the end, Larry could still put a stop to it. Which would have consequences, but still.

Could we halt work on this until after the SPW (this weekend)?

[JJ]

El mié., 14 ago. 2019 a las 19:28, Aleks-Daniel Jakimenko-Aleksejev (< notifications@github.com>) escribió:

No, we're no longer using it, since we moved it to the interim infrastructure. And I'm not sure it really worked before that. It did work, it needs to be fixed. Breaking links is not cool.

It really didn't work very well. Some directives just didn't fire for some reason, and I suspect it's been not working for a really long time. The server that it's actually been serving page for some time has been a Mojo server, which does not really understand .htaccess. It needs nginx in front, which if I remember correctly was the way it was done in the previous one, but I'm not sure it really worked, since .htaccess probably includes many Apache-specific directives. Also, since it's been moved to the interim infrastructure there have been zero reports of broken links. Internal broken links have been fixed. The big picture is: we need to generate URLs in a single place, and make them not depend on the infrastructure. If we need to change URLs at another level, something is not really working, so we need to fix that, not patch it at another level. That's, however, another issue. If we opt for redirection we'll obviously need to include a .htaccess file eventually.

[JJ]

El mié., 14 ago. 2019 a las 19:40, JJ Merelo (<jjmerelo@gmail.com>) escribió:

El mié., 14 ago. 2019 a las 19:28, Aleks-Daniel Jakimenko-Aleksejev (< ***@***.***>) escribió: > No, we're no longer using it, since we moved it to the interim > infrastructure. And I'm not sure it really worked before that. > > It did work, it needs to be fixed. Breaking links is not cool. > It really didn't work very well. Some directives just didn't fire for some reason, and I suspect it's been not working for a really long time. The server that it's actually been serving page for some time has been a Mojo server, which does not really understand .htaccess. It needs nginx in front, which if I remember correctly was the way it was done in the previous one, but I'm not sure it really worked, since .htaccess probably includes many Apache-specific directives.

On this note, I changed several directives and they didn't really work. So that's why I say it didn't really work.

[JJ]

@lizmat 👍

[nxadm]

It feels to me we're getting ahead of ourselves here. There hasn't been an official decision yet about a rename. And in the end, Larry could still put a stop to it. Which would have consequences, but still.

See how much enthusiasm you generated? :)

[JJ]

I'm closing this now, since it's conflicting, but also we prefer things to be done step by step and as indicated in the issue #3046