Rakudo leaving the Parrot nest

By "infrastructure" I'm primarily referring to the following items:
* source code repositories (note: plural)
* web sites
* blog / news
* wiki
* issue tracking
* mailing lists

Currently these things are spread in many different locations with
different tools, and while I don't believe it's necessary for them
completely unified, we should at least aim to reduce the overall
complexity of what we do have so that we can better serve those
who are interested (or are yet to become interested) in Rakudo Perl.
In fact, it may be that in many cases we'll keep what we have now,
but at least it'll be a confirmed decision instead of simply going
along with what we've had in the past.

Also, I'm sure it will be easy and tempting to address
larger issues about Perl 6 as a whole (as opposed to just
"Rakudo"). I'm not at all opposed to seeing that larger discussion
take place, but for my purposes I'll be tending to focus on Rakudo's
immediate needs.

Here's my off-the-cuff inventory of where things are in Rakudo today
and where things might head. It's entirely possible that my
description below misunderstands or misrepresents reality in
some areas -- but I'm dedicating this week to resolving that.
Indeed, that's the primary purpose of this message, to help us
all clear up confusion surrounding Rakudo (and Perl 6).

Source code repository
----------------------
This is the immediate issue at hand, because we need to move Rakudo
out of the Parrot repository so that it can cleanly move to its new
home at parrot.org. Currently Rakudo Perl lives at
http://svn.perl.org/parrot/trunk/languages/perl6/ , while the
spectest suite (on which development/testing depends) lives at
http://svn.pugscode.org/pugs/t/spec/ .

Many people have strongly suggested that we switch to
using "git" as our version control system. At the moment I'm
neither strongly in favor of nor strongly opposed to switching
version control systems, but we have to recognize that at least
two of Rakudo's "dependencies" (Parrot and the spectest suite)
are using Subversion and are likely to remain that way for
a while. We don't want to require non-developers to install a
lot of different source code control systems simply to run and
test the latest incarnation of Rakudo Perl.

I have a lot more comments on source code management for
Rakudo Perl, but to keep to the "overview" nature of this post
I'll save the rest for a longer post. Feel free to start
submitting your opinions, however!

Web site / blog / wiki
----------------------
Currently Rakudo really does not have a dedicated website
providing basic information about it. There is the
http://rakudo.org/ site, but it's currently more of a
blog than a true web site. For example, someone visiting
rakudo.org would not be able to easily find out how to
download and run Rakudo Perl.

Here's what we ''do'' have at the moment (as best as I can recall):

* Rakudo.org is run by Andy Lester and currently provides a
"blog" for Rakudo Perl. Andy has mused about switching
rakudo.org to Drupal instead of Movable Type, which could
enable us to more easily have "introductory content"
information instead of just blog-type entries.

* Of course, many of us regularly post to journals at
http://use.perl.org/ . This is good for keeping in touch
with the wider Perl community and provides a good blog-like
interface, but again isn't useful at basic Rakudo information
and orientation.

* The Perl Foundation hosts a "Perl 6 wiki" at
http://www.perlfoundation.org/perl6/index.cgi?perl_6 ,
and Rakudo has a few pages there. Currently I find the
wiki to be not very well organized, and it's difficult to
find Rakudo out of the many other items that appear there.
Beyond that, I'm not impressed with the wiki engine the
site uses, but if a sizable group of people think that's
where Rakudo information should be centered then I can
live with it.

* TPF also hosts the "Perl 6" website at
http://dev.perl.org/perl6/ , but "Rakudo Perl" isn't even
mentioned there, and I don't even really know the correct
procedure for getting updates or modifications to those pages.
My impression is that this site isn't really conducive to
frequent updates or lots of contributors (but perhaps I'm
incorrect about that).

* Planet Perl 6 (http://planetsix.perlfoundation.org) is an
excellent aggregator of Perl 6 related posts, including those
involving Rakudo Perl.

Also, for the record, I currently own the "rakudoperl.org"
and "rakudoperl.com" domains, so if we want to do something
somehow separate from any of the existing domains cited above,
we can use those domains, and I may have (or be able to acquire)
additional server resources to support it.

Issue tracking
--------------
Currently issue tracking for Rakudo is being done using RT
at http://rt.perl.org/ (the same RT instance that does Perl 5
bug tracking). In the past I've stated that Rakudo bugs will
continue to use this tracker, and I'm still planning for that
to be the case, but in recent weeks I've encountered a
number of times were rt.perl.org was too slow/unreachable
to be an effective tool. I'm not (yet?) advocating that we
switch to a different issue tracker, but since we're looking
at the whole of infrastructure items I did want to leave the
possibility open for discussion.

Mailing list
------------
Currently Rakudo's primary mailing list is <perl6-c...@perl.org>.
I see no major reason to change anything here, as it works
well and is a good companion to the other "official"
Perl 6 mailing lists.

-----

Throughout all of this, I'm looking at things from a very
practical perspective -- i.e., what can we achieve with the
resources currently at our disposal. It's also important
to consider the needs of the various audiences -- not only
the Rakudo developers, but also people who want to experiment
with Rakudo and those who want to start building applications
for it. So, we need to keep in mind the many perspectives on
the issue as we go through the discussion.

Also, I'm expecting that some of the decisions I eventually
make may disappoint some; apologies in advance, but such is
the nature of decisions.

With that background in place, I'll now (with great trepidation)
open the discussion for others to comment and/or make suggestions
of what they'd like to see changed about the way we currently
manage Rakudo Perl.

Thanks in advance,

Pm

Patrick R. Michaud wrote:
> Source code repository
> ----------------------
[...]

Same here. As long as somebody tells me how to do the things with git
that I used to do with svn, I'm fine with git. Svn also worked for me so
far.

Another thing to keep in mind is that once we start to have a Perl 6
prelude, we might decide to be nice neighbors and share it with other
implementations, as far as that's practical. And we might also want to
import STD.pm from the pugs repo in the future. That might or might not
have some influence our decision, I just want to mention it.

I'd be willing to spend some time on that.

I don't like that wiki engine either.

You're correct. I sent some patches in the future, and once we've
settled on an official website (including introductory information) I'll
send another patch that adds some links to the Rakudo site(s).

Let me add

* http://rakudo.de/ (domain owned by me, and content hosted by me)
has a chart of of Rakudo's progress in the test suite.
I don't care if we keep it like this, or make it a bit more
"official" or whatever, but I think in some form this should
be kept. (Simplest way: leave as is. Second simplest:
<img src="http://rakudo.de/progress.png" .../>)

We can also use feather.perl6.nl to host sites we want.

Even though it's slow I currently like it better than parrot's trac
instance (emails with too large headers, no email interface, need to
learn some markup to submit readable tickets, ...)

Same here.

What's the rationale for the spectest suite to remain in the pugs repository? AFAICT, pugs is no longer being actively developed and I wouldn't be surprised if many of its spectests currently break and don't have a TODO. Plus, the way fudge works, you have to be able to fudge things against both pugs and rakudo, making things rather confusing (and it's not documented very well that I can see, so I was royally confused at first). In fact, I think that might even eliminate the need for fudge if done right.

Why not bite the bullet and include those tests in Rakudo? If they're not listed in t/spectest.data, they don't get run. Plus, it will make it much easier for a developer to write tests and to review them because they don't need to switch to a different repository or terminal window. Thus, a developer won't need to have (or even know about) a separate repository *just for tests*. That just seems weird.

Merging the test suite and eliminating fudge seems like a great simplification to me.

Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog - http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

1) Many people have commit access to the test suite, and it's a good
entry point for the new Perl 6 programmer. I'd like to keep access as
liberal as possible.
2) There are other projects (namely elf atm) that use the test suite and
live in pugs repo.
3) If we'd move it out of the pugs repo, I would rather have it as a
completely separate project; keeping it in the repo of another
implementation seem unfair, because none is more official than another
4) The synopsis live in the pugs repo; it feels good to have the test
suite close to them.

We're in Perl culture. Tests are known to be important here. Don't even
dare of speaking of "just [for] the tests" ;-)

We need fudge for keeping the tests implementation agnostic (remember,
we're not writing the Rakudo Regression Test Suite, but the Official
Perl 6 Test suite). We can do with #?rakudo whatever we like to make the
tests run, and don't compromise on the tests themselves. That's
incredibly valuable.

Cheers,
Moritz

I'm not going to jump up and down about this issue. At the very least, Subversion isn't CVS. However, it *is* Subversion which means we have a painful source control system which attempts to wrap a soft cloth around the hammer to the head that is CVS. For it's time, Subversion was great. Subversion is no longer great. I find that it's not too hard to use simply because I use it, not because I like it.

With my admittedly limited exposure to git, it is superior in terms of both usability and design to Subversion. I admit, though, that many people are not willing to learn a new source control system (and does it still have Windows issues?). If that's the primary objection to git, I could accept that argument. If the primary objection is merely to accept the fact that we have a bunch of architecture based on bad technology, then we're making the decision for the wrong reason.

(I just need to install svk and have at least *some* of my subversion pain go away)

This sounds like a good summary of my thoughts on the issue. I'm not
going to fight for Rakudo switching over to git, because I don't have
a big enough grudge with svn, and I'm not a very frequent committer to
Rakudo. But git _is_ nicer in many ways, especially when dealing with
merging and branches.

As far as I understand, people on Windows can run git in various ways
nowadays. The question is more, as Patrick wrote, whether we create a
VCS nightmare for developers, by requiring them to acquire and learn
git on top of svn.

// Carl

Solving generic problems rather than specific ones does involve a little
more thought, (it's possible to get into an infinite regression of
abstractions), but the effort could be repaid by lower maintenance
burdens.

--

Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ippimail.com

Throughout the Parrot 1.0 planning process, I had been (somewhat
forcefully) advocating that Parrot have its "make install" target
working _prior_ to moving Rakudo out of the repository, and all
of the Parrot milestone planning reflected that. Then Rakudo
could simply say "install revision ##### of Parrot" and use that
installed version to build and test Rakudo.

Unfortunately it now looks as though repository moves are going
to occur before Parrot's "make install" is working -- i.e.,
the reverse of what I had been advocating. That complicates
things for us a bit.

Parrot's plan is that language developers will target only
"stable" releases (e.g., 1.0, 1.5, 2.0), but that's not likely
to work for Rakudo. Indeed, given the way in which Rakudo
currently drives Parrot feature development I suspect that
even monthly Parrot releases aren't sufficiently frequent
for Rakudo.

(There are many times when implementing a Rakudo feature or
fixing a bug necessitates adding or correcting something
in Parrot, PGE, PCT, a core PMC, etc. Requiring Rakudo users
to wait up to a month prior to seeing the benefit of that fix
is not likely to work well in practice.)

And, like you, I also have the concern about Parrot trunk changes
breaking Rakudo, since it will be more difficult/less likely
that Parrot developers will test their changes against Rakudo.
So we probably don't want to track Parrot HEAD, but want to
lag slightly behind -- recent enough to keep the most
recent Parrot changes that we want/need, but not so recent that
every Parrot commit has the potential to break Rakudo.

My best guess at this point is to do something like you advocate--
i.e., have Rakudo build Parrot (whatever version Rakudo wants)
instead of Parrot building Rakudo. We would then update the
"required version" of Parrot as dictated by Rakudo timelines.

In fact, for normal Rakudo users (i.e., people not also
involved in Parrot development), we could just maintain a
read-only copy of the "correct Parrot version" as part of
the Rakudo repository. That would reduce the number of
source code repositories that non-Parrot-committers would
have to deal with for working with Rakudo. We wouldn't
need Parrot's full revision history for this, or even
all of Parrot.

Thoughts?

Pm

I don't know about other Perl 6 developers, but I don't feel motivated to
tackle the general problem now. We have enough trouble building a generic
virtual machine, a generic compiler building toolkit, and a very demanding
programming language.

Cheers,
Moritz

Moritz already replied with why spectest is currently in pugs, I
tend to agree. For now I'd like spectests to continue to have
a very liberal commitbit policy, and that may or may not be
compatible with Rakudo's commitbit policy (depending on how
things end up).

Being able to fudge against multiple implementations is the
whole purpose of fudge. Agreed that it's not documented very
well -- that's one of the things I'd like to fix via the
Rakudo web site (that is also being discussed as part of
this infrastructure topic).

Currently I don't have to switch to a different repository or
terminal window now -- I just edit the tests directly in t/spec/
and do commits as I normally would. It just so happens that
those commits end up in the pugs repository instead of the Parrot one.

Perhaps that approach doesn't work on other platforms, but thus far
it's been working great for me.

Pm

My guess is that there will be a shared prelude that is maintained
in a central repository like the spectests, but that individual
implementations are likely to want or need customized versions of
the prelude for performance or implementation reasons. In this
sense the shared prelude acts as a "reference standard" that
implementations can use directly or optimize as appropriate.

Similar to Rakudo's need to follow Parrot's HEAD closely but
not directly, I suspect this is a place where individual implementations
will want to track STD.pm versions closely but rarely use the
latest version directly. Otherwise changes to STD.pm in the shared
repository have the potential to inadvertently break an implementation.

> > providing basic information about it. [...]

Yes, thank you for this important addition. I did remember it at
one point yesterday, but forgot it at the time I was crafting my
message.

My intent is that the daily spectest updates will automatically
update graphs and statistics on the main Rakudo site (just like
rakudo.de does) -- until now we simply haven't had a main Rakudo
site that could handle that (other than rakudo.de).

This may indeed be what we do--it does have the advantage of
having multiple admins readily available. Do we need any permission
from Juerd or someone to use feather for this purpose?

> > Issue tracking
> > --------------

Good point, thanks.

Pm

I buy the arguments put forward. Some had been explained before and now that I'm reminded, yeah, they make sense.

Now about the Perl 6 Prelude, rather than have customized versions, ...

A couple things I've learned from designing a language for implementation over
multiple architectures are:

1. It is usually possible to define almost all of the built-in types and
operators of a language in terms of each other using the mechanisms the language
provides for user-defined types and operators; left to itself this means the
language is recursively defined.

2. Each implementation architecture has its own concepts of what are the most
fundamental and efficient types and operators to use as a foundation. For
example, Haskell and Parrot would have many differences on what the fundamentals
are.

What I recommend, and forgive me if things already work this way, is to expand
the Prelude so that it defines every Perl 6 core type and operator using pure
Perl 6, complete enough such that there are as few as possible actual primitives
not defined in terms of other things. This Prelude would then be shared
unchanged between all the Perl 6 implementations.

Then, each implementation would also define its own PreludeOverride file (name
can be different) in which it lists a subset of the type and operator
definitions in the Prelude that the particular implementation has its own
implementation-specific version of, and the latter then takes precedence over
the former in terms of being compiled and executed by the implementation.

And so, as Perl 6 evolves or new implementations come along, the amount of work
necessary specific to the implementation to just get Perl 6 running at all is
minimal, and so more implementation specific work then is mainly for just making
it run more efficiently.

Take for example, non-integer numeric types and operators. These could be fully
defined in the Prelude or other plain Perl 6 file in terms of the (big) Int type
and its operators, so implementations only need native (big) Int support to get
all the other numeric types working for free. Then, if some implementations
want to get faster float or complex or small-int etc performance, they can
override with versions that use C-defined or machine native etc types and
operators in those cases. (As a more extreme example, you could also define
character strings etc in terms of dense arrays of Perl Int, and all the
complexity for Unicode etc would have a default implementation in Perl 6; in
that case, Str, and Perl identifiers, wouldn't be opaque but rather would be
class defs with array-of-Int attributes.)

So abstractly speaking the Prelude is still customized, but all differences from
the self-hosted shared one are in separate files.

So have I made any sense here, and what do you think?

-- Darren Duncan

I have a few answers to this:

0. I agree that, no matter what, the implementation will still want to
substitute in its own versions. But so what? Having a reasonably more complete
high-level reference implementation of the Prelude in Perl 6 won't lose us
anything over what we have now and should on average gain something.

1. What we *should* be doing with the Prelude, like with STD.pm, is write under
the assumption that the implementation is also written in Perl 6.

We should write the Prelude in as declarative a manner as possible, saying
*what* we want to happen rather than how, such as you do when writing in a
functional language.

We should make use of Perl's higher-level tools like hyper-operators and
reduce-operators etc and write in a fashion that is developer focused, same as
writing normal Perl 6.

We do not, except where it makes sense, want to be defining things in terms of
the lowest level things possible, as that would be premature optimization, which
may help some implementations and harm others.

We should instead be defining all the low level operators in terms of the high
level operators, where possible. It is easier for an average implementation to
translate a high level source operation to low level native operations on
average, than try to amalgamate a whole bunch of low level source operations to
fewer high level implementation operations.

(Note for example I suggested using big/unlimited-size Int as a basis of
definition rather than a machine-int.)

Don't be afraid to be recursive, if it is even possible. For example, one could
define Hash in terms of Array *and* define Array in terms of Hash. Or Int in
terms of Rat *and* Rat in terms of Int.

2. We should be able to live with the benefit of at least short term hindsight,
seeing what likely implementations we will have, and aim for the middle. For
example, write as if high-level concepts are supported in the implementation.

3. Perl 6 does have multi-methods. Maybe make use of them to define
alternative sample implementations where it makes sense, though don't go too far
citing combinational exponents.

Or if multi-methods don't work quite that way, we could add a kind of trait to
them or something that says use one or the other but not both, and
implementations can mark in their override file to pick a particular version.

Even if not all implementations are the same, some are similar to each other and
can share that work.

Call them "possible representations" or "possible implementation versions" or
something.

To some extent I think Perl 6 does have what we need in a different fashion,
such as where you can declare a class or attribute and indicate an
implementation type like Opaque vs Hash or what-have-you.

> P.S. I did this sort of thing once -- a Forth prelude that attempted to
> minimize the primitive set, and it *was* very nice from an abstract
> perspective. Unfortunately, it also made some operations take millions
> of cycles that would take no more than one assembly instruction on just
> about every CPU known to man. It's a REALLY easy trap to fall into.

That may be because you wrote in terms of a few low level operations rather than
a few high level ones; what if you did the reverse?

As for me, I am in the process of doing this now with my Muldis D language,
which is fairly high level and should run on everything Perl 6 does, though with
a stronger implied support for functional-paradigm-supporting languages, and
also run over SQL; though at the same time each implementation can choose to
leave out some features as it sees fit, some are more important to include than
others. In my implementation of Muldis D over Perl (Muldis Rosetta's default
engine), most built-in types and operators are defined as users would, in terms
of other ones, save for its only 4 truly-primitive types, [Int (opaque
unlim-size scalar), String (dense-array-of-Int), QTuple (heterogenous
collection), QRelation (homogenous collection)], but the Perl class/object
representing a user/as-user-defined type is sub-classed for various other
built-in types like [Bool, Blob, Text, Rat, Set, Maybe, Array, Bag, etc] which
override implementation details to use the Perl primitives directly. My point
is here that most of the Muldis D implementation that I have to do is written in
Muldis D, so that part can generally be shared between Perl 5, Perl 6, PIR,
Haskell, etc; by design all the Muldis D code is translated to equivalent
Perl/PIR/Haskell etc code first anyway, letting their compilers do the real
work, and so overriding with a non-translated Perl/Haskell etc routine is easy
to do. Bringing this back on topic, the large amount of Muldis D built-ins
written in that language are analogous to the Perl 6 Prelude. As long as the
Perl 6 Prelude is written in sufficiently high-level a fashion, it should be
effectively reusable.

-- Darren Duncan

The Prelude is a file written in Perl 6 that defines some Perl 6 built-ins.

See http://perlcabal.org/svn/pugs/view/src/perl6/Prelude.pm for what AFAIK is
the newest version.

-- Darren Duncan

A significant subset of Perl 6 native features, eg types and operators, native
meaning they are declared and described in the Perl 6 Synopsis documents, have
been implemented under Pugs by being written in plain Perl 6 in terms of other
Perl 6 features, rather than being written in Haskell or C or Perl 5.

See for example the modules Math::Basic and Set, which live in the ext/
directory of Pugs and are defined like any user-defined module.

Then recall that different languages have varying concepts of what constitutes a
core language feature and what is an optional or third-party extension feature.
For example, some languages have native types and operators for temporal
artifacts like dates and times and durations, and others don't. Some languages
have "big" numbers as a fundamental and others only have machine-size numbers.

Now I anticipate that for any given native / Synopsis-described types and
operators of Perl 6, some Perl 6 implementations will define those as plain Perl
6 code in terms of other Perl 6 features, and other implementations will instead
have them directly wrap features of the host language.

My main point here is that the demarcation line between what is written in Perl
6 and what is written in the host language can vary wildly and can pay little to
no attention to the conceptual boundaries in the Perl 6 Synopsis between what is
more fundamental and what is more of an extension.

Therefore, it does not hurt to increase as much as possible the fraction of the
Perl 6 language that has a reference implementation defined just in terms of Perl 6.

Especially if this reference Perl 6 code is written in a more declarative
fashion, it increases the likelihood that more starter code is available to help
bootstrap any given Perl 6 implementation, where writing some parts of the
language are more optional for them to do themselves than otherwise.

Note that I just referred to this body as the Prelude because I was replying to
a particular p6c comment naming that, and also Pugs had something by that name
with a similar purpose which is what was referred to in the original post.

So I'm not so much talking about the existing Prelude file as the concept it
represents, which is making it easier to share code between Perl 6
implementations, where each implementation wants to use it. Or just to take
advantage of the fact that Perl 6 itself should be easier to write some kinds of
code in than other languages, including itself. We can go further than the
minimal bit we have now.

-- Darren Duncan

> --
> Jonathan "Dataweaver" Lang
>

The stuff you load (and execute) to bootstrap the language into utility on
each invocation. Usually it's written in terms of the language you're
trying to bootstrap as much as possible with just a few primitives to get
things started.

-Scott
--
Jonathan Scott Duff
perl...@gmail.com

The Perl 6 Wiki can be reorganized however you (and others)
suggest. I'd be happy to do the wiki editing work.

The November (Rakudo-based) wiki project should eventually
provide a much better wiki engine than the current one.

(BTW, what are your main issues with the current
wiki engine, and preferred alternatives?)

Best regards,
Conrad Schneiker

www.AthenaLab.com

Official Perl 6 Wiki — http://www.perlfoundation.org/perl6 

I assume you're saying the parrot project will be moving from
svn.perl.org to its own repo somewhere on the parrot domain.

> http://svn.perl.org/parrot/trunk/languages/perl6/, while the

I propose a restructuring/divestiture of the pugscode and
rakudo code repositories, as follows:

1. Centralize/reorganize the implementation-independent/agnostic
resources, documentation, and tools under a new repository, which
could be hosted at one of the perl6-related domain names I have,
such as git:// (and http(s)://www.perlsix.org/git/perl6 for
git-http-*), with automatic one-way (or two-way! with user
impersonation) replication/mirroring to svn and/or bzr on
launchpad.net/perl6. This repo would include both the human-
readable (!) language specifications, and the machine-
readable/testable language specifications (the spec tests),
the standard grammar and its related tools, any global prelude,
and all the other implementation-nonspecific items. The current
pugscode user accounts can be migrated to whatever backs the
authentication.

2. Leave the current svn.pugscode repo as is (except for the
items listed above), so that all the other implementations and
Perl6-related miscellany stored there can be migrated over to new
repos as necessary.

3. Host the rakudo repository in git or whatever [else] is
selected following the same convention,
git/http(s)://www.perlsix.org/git/rakudo and
http(s)://www.perlsix.org/svn/rakudo Use the same authentication
store as http(s)://www.rakudo[perl].org (see below)... perhaps
integrated with single-sign-on and unified-sign-on systems at
launchpad.net, OpenID, BitCard, etc.

No, but for this use case, snapshots of the requisite Parrot
release and then the client for whatever scm system Rakudo uses
should be sufficient, since the spectest suite can be hosted in
the same format, even if merely a one-way mirror.

> ----------------------

> http://rakudo.org/site, but it's currently more of a

As the site of a major implementation of a multi-implementation
programming language, the www.rakudo(perl).* site(s) need to be
similar in content to the sites, for the following use cases:
www.ruby-lang.org
www.python.org
www.php.net

1. Obtain/Develop-ish category
a. Download binaries/installer links
b. Linux/BSD distribution/packages links (deb, rpm, launchpad)
c. Build-from-source walkthrough (including dependencies)
d. Contributor/developer initiation/training
(1) git/svn training/walkthrough
(2) bug-tracking system (launchpad.net?) links/tutorial
(3) mailing list descriptions
e. Spec-test progress/history/graphics
f. Release announcements, developers' blog
g. IRC links, logs
h. gitweb and/or SVN::Web intefaces
i. PCT tutorials/documentation
4. Discover-ish category
a. Rakudo documentation, tutorials
b. [Links to] Perl 6 documentation, specifications, tutorials
c. User/community support forums & mailing lists
(exposed through http, smtp, and nntp)
d. Links to and/or aggregates of other/related blogs
e. Links to Perl Foundation & development/benefactor news
f. Link to www.perl.org or replicate much of its content
g. Interactive web terminal to try out rakudo, "live"
h. Links to sites/projects using rakudo

I recommend hosting this site on the WebGUI CMS on a VPS I'll
provide; I'll also provide a $30/year GoDaddy SSL certificate in
perpetuity for privacy/security, though since it's an open-source
project, the first year of the SSL cert may be free from GoDaddy.
I have a VPS where the site (including all SCM repos) could be
hosted; others' VPSes could provide backup destinations.

One option is to set the http://www.rakudo.org page to redirect
to http://www.perlsix.org/rakudo, where all the above content
can be hosted in an integrated site on WebGUI. The biggest
benefit of this would be the SSL certificate cost savings.

I would use the built-in CMS features to delegate/administer the
maintenance of the site's content; the WebGUI web application
platform supports "staged"/"RC" revision sets of all content, and
is written in Perl (mod_perl/apache2/mysql5). There are lots of
other features of WebGUI that would be useful to such a site (read
up on it!). But by far the most attractive feature for this
application is its easy Perl
extensibility/pluggability/customizability. The content can be
styled centrally, with the built-in rich text editor (TinyMCE)
pulling styles from stylesheets for point-and-click styling of
pages, though raw HTML is also accepted. All changes are
versioned, backed by the database, and can be rolled back if
necessary.

Migrate its entries to the Rakudo news blog; borrow the style. ;)

> http://use.perl.org/. This is good for keeping in touch

Aggregate [comment-nodes for] these on www.rakudo*.*

This can continue in its current form, as a not-quite-
authoritative source of information on various Perl 6
implementations.

> http://dev.perl.org/perl6/, but "Rakudo Perl" isn't even

This can be replaced with redirects to a new site that allows
easier updates on the WebGUI CMS: www.perlsix.org, which would
be an implementation-independent home for the Perl 6 language,
with much of the same (or shared, if the sites are integrated)
content/structure as listed above for the Rakudo site, but of
course implementation-nonspecific.

This can be proxied/mirrored on the rakudo*.* site(s), or
merely left as-is.

> athttp://rt.perl.org/ (the same RT instance that does Perl 5

The forum system in WebGUI is fairly good (if it's styled nicely),
especially its SMTP integration. New (emailed) threads can be
configured to create new "issues", to which file attachments or
replies can be added using either SMTP or HTTP uploads, just like
similar email-integrated forums. I think it also supports issue
merging and referencing. An NNTP interface could be added with a
bit of work. I recommend also considering using Ubuntu's central
launchpad.net for the Rakudo bug-tracking system. It wouldn't be
as integrated (authentication, identity) as using the same site,
but the bug-tracking and other project management features are
quite nice. On launchpad my account is the owner of the rakudo &
perl6 projects, so we can appropriate those resources, which
would also of course ease the eventual ubuntu/debian packaging &
distribution.

> Mailing list
> ------------
> Currently Rakudo's primary mailing list is <perl6-compi...@perl.org>.

I disagree; I think Rakudo needs its own mailing list(s) in
addition to the implementation-nonspecific perl6-compiler list,
as it's currently named (the name should be made plural?):
1. A (new-)user-support/help mailing list/forum
2. A mailing list/forum for Rakudo developers
3. A Rakudo announcement mailing list/forum/blog (which in WebGUI
are [based on] the same Wobject)

I'm not married to [m]any ;) of these suggestions/ideas, so I
don't expect to be disappointed, hurt, or defensive about their
debunking or non-adoption. :D

Sorry for expanding the thread to include the Perl 6 web properties
ideas in addition to the Rakudo proposals. I registered those
domain names originally exactly for this purpose (for the Perl 6
language and its implementations to have homes), so I'm excited
that they could be used for that purpose. I hope you all catch
my implication that all the other Perl 6 implementations could &
would have similar hosting opportunities available and provided.

-Matthew Wilson (diakopter)
diak...@gmail.com

> Source code repository

I assume you're saying the parrot project will be moving from

> Currently Rakudo Perl lives at
> http://svn.perl.org/parrot/trunk/languages/perl6/, while the

> lives at http://svn.pugscode.org/pugs/t/spec/.

> Many people have strongly suggested that we switch to

No, but for this use case, snapshots of the requisite Parrot

> Web site / blog / wiki

> http://rakudo.org/site, but it's currently more of a

As the site of a major implementation of a multi-implementation

> Here's what we ''do'' have at the moment (as best as I can recall):

Migrate its entries to the Rakudo news blog; borrow the style. ;)

> * Of course, many of us regularly post to journals at
> http://use.perl.org/. This is good for keeping in touch

Aggregate [comment-nodes for] these on www.rakudo*.*

> * The Perl Foundation hosts a "Perl 6 wiki" at

This can continue in its current form, as a not-quite-

> * TPF also hosts the "Perl 6" website at
> http://dev.perl.org/perl6/, but "Rakudo Perl" isn't even

This can be replaced with redirects to a new site that allows

> * Planet Perl 6 (http://planetsix.perlfoundation.org) is an

This can be proxied/mirrored on the rakudo*.* site(s), or
merely left as-is.

> Also, for the record, I currently own the "rakudoperl.org"

> athttp://rt.perl.org/ (the same RT instance that does Perl 5

The forum system in WebGUI is fairly good (if it's styled nicely),

> Mailing list
> ------------
> Currently Rakudo's primary mailing list is <perl6-compi...@perl.org>.

I disagree; I think Rakudo needs its own mailing list(s) in

> Throughout all of this, I'm looking at things from a very

I'm not married to [m]any ;) of these suggestions/ideas, so I

> With that background in place, I'll now (with great trepidation)

Sorry for expanding the thread to include the Perl 6 web properties

I would declare sqrt this way instead (the body is the important change):

sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
$x ** (1/2)
}

My point with this example is that any time there exists 2 operators for which
one is a more specialized case of the other, or the other is a more generalized
case of the first, then the specialized one is defined in terms of the
generalized one.

So defining sqrt as just a special case of exponentiation makes for a simple
declarative solution.

I think when I said "define in terms of higher level", I also meant to say
"define in terms of the most generalized operators applicable".

Note also that, as I've defined it, sqrt is still defined in exact terms rather
than approximate / precision-varying terms, and so each underlying
implementation can easily interpret this as an exact math operation if it is
itself capable of exact math, and otherwise it still has enough information to
know how to do it in approximate math.

-- Darren Duncan

I don't quite follow you. Are you saying your version of sqrt is an implicit
declaration; maybe I don't understand how that differs from an explicit
definition in this case? In any event, right at this moment I can't think of an
answer to your question. Go ahead with what you think works and I'll just speak
up later if I have something constructive to offer. -- Darren Duncan

I actually agree that your explicit definition (a simple/efficient
implementation in terms of other operators) is better for prelude than
my "declarative" form (which isn't really declarative, because Perl6
isn't a declarative language). My only disagreement was with your
earlier statement in this thread, where you said that prelude.pm should
use a declarative style.

I think we agree that what you really meant was that it should be
written in an explicit self-referential style; and that it should avoid
"programming" implementations as much as possible (e.g. prefer hyper-ops
over explicit loops)

Yes, I agree; what you stated in the second paragraph here is what I considered
important for a prelude.pm. -- Darren Duncan