Rakudo leaving the Parrot nest

As many of you will have gathered from discussions on other mailing
lists and IRC, it's time for Rakudo Perl to "leave the Parrot nest" 
and move to its own repository.  I think we should also take this
opportunity to re-evaluate the entire Rakudo Perl infrastructure
and decide what will be most productive for the community for
the upcoming year.  Indeed, as part of any move we need to
communicate the details of the changes to others, which brings
to the surface some of the shortcomings of what we have now.

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-compiler@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

0
pmichaud
1/15/2009 3:01:08 AM
perl.perl6.compiler 1237 articles. 0 followers. Follow

30 Replies
492 Views

Similar Articles

[PageSpeed] 8

As a Rakudo contributor I feel I should comment on this, although most
of my comments aren't all that exciting.

Patrick R. Michaud wrote:
> Source code repository
> ----------------------
[...]
> 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, 

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.

> 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.

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

> * 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.

I don't like that wiki engine either.

> * 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).

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).

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

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" .../>)

> 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.

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

> 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.

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, ...)

> Mailing list
> ------------
> Currently Rakudo's primary mailing list is <perl6-compiler@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.

Same here.
0
moritz
1/15/2009 7:53:33 AM
----- Original Message ----=0A=0A> From: Patrick R. Michaud <pmichaud@pobox=
..com>=0A=0A> Source code repository=0A> ----------------------=0A> This is =
the immediate issue at hand, because we need to move Rakudo=0A> out of the =
Parrot repository so that it can cleanly move to its new=0A> home at parrot=
..org.  Currently Rakudo Perl lives at=0A> http://svn.perl.org/parrot/trunk/=
languages/perl6/ , while the =0A> spectest suite (on which development/test=
ing depends) lives at=0A> http://svn.pugscode.org/pugs/t/spec/ .=0A=0AWhat'=
s the rationale for the spectest suite to remain in the pugs repository?  A=
FAICT, pugs is no longer being actively developed and I wouldn't be surpris=
ed if many of its spectests currently break and don't have a TODO.  Plus, t=
he way fudge works, you have to be able to fudge things against both pugs a=
nd rakudo, making things rather confusing (and it's not documented very wel=
l that I can see, so I was royally confused at first).  In fact, I think th=
at might even eliminate the need for fudge if done right.=0A=0AWhy 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 swi=
tch 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.=0A=0AMerging the test suite and eliminating fudge se=
ems like a great simplification to me.=0A=0A =0ACheers,=0AOvid=0A--=0ABuy t=
he book         - http://www.oreilly.com/catalog/perlhks/=0ATech blog      =
      - http://use.perl.org/~Ovid/journal/=0ATwitter              - http://=
twitter.com/OvidPerl=0AOfficial Perl 6 Wiki - http://www.perlfoundation.org=
/perl6=0A
0
publiustemp
1/15/2009 7:57:02 AM
Ovid wrote:
> ----- Original Message ----
> 
>> From: Patrick R. Michaud <pmichaud@pobox.com>
> 
>> 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/ .
> 
> What's the rationale for the spectest suite to remain in the pugs repository? 

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.

> 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.

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

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

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
0
moritz
1/15/2009 8:13:04 AM
----- Original Message ----=0A=0A> From: Patrick R. Michaud <pmichaud@pobox=
..com>=0A=0A> Many people have strongly suggested that we switch to=0A> usin=
g "git" as our version control system.  At the moment I'm=0A> neither stron=
gly in favor of nor strongly opposed to switching=0A> version control syste=
ms, but we have to recognize that at least=0A> two of Rakudo's "dependencie=
s" (Parrot and the spectest suite) =0A> are using Subversion and are likely=
 to remain that way for =0A> a while.  We don't want to require non-develop=
ers to install a =0A> lot of different source code control systems simply t=
o run and =0A> test the latest incarnation of Rakudo Perl.=0A=0AI'm not goi=
ng 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 c=
ontrol 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 l=
onger great.  I find that it's not too hard to use simply because I use it,=
 not because I like it.=0A=0AWith 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 sys=
tem (and does it still have Windows issues?).  If that's the primary object=
ion to git, I could accept that argument.  If the primary objection is mere=
ly to accept the fact that we have a bunch of architecture based on bad tec=
hnology, then we're making the decision for the wrong reason.=0A=0A(I just =
need to install svk and have at least *some* of my subversion pain go away)=
=0A=0ACheers,=0AOvid=0A--=0ABuy the book         - http://www.oreilly.com/c=
atalog/perlhks/=0ATech blog            - http://use.perl.org/~Ovid/journal/=
=0ATwitter              - http://twitter.com/OvidPerl=0AOfficial Perl 6 Wik=
i - http://www.perlfoundation.org/perl6=0A
0
publiustemp
1/15/2009 10:38:14 AM
Ovid (>), Patrick (>>):
>> 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'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
0
cmasak
1/15/2009 1:12:55 PM
As outlined, the requirements seem to be pretty much those of any major
Open Source development project. Keeping this in mind might yield a
generic template usable by other projects in future.

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

0
ajr
1/15/2009 4:20:28 PM
As a comment to my use.perl journal post, Infinoid wrote:
> Earlier today on the IRC channel, Will Coleda made an 
> interesting comment regarding partcl.
> 
> 07:28 <@Coke> I'd rather have folks go to /partcl/ to get parrot.
> 
> That makes a lot of sense. So, have you given much thought to how 
> you want to enforce and/or manage the version of Parrot you will be 
> running Rakudo under? I think this may be an important issue. 
> Given how much breakage we see in languages still in the parrot 
> repository, I worry that decoupling of parrot from rakudo will only 
> make the "moving target" problem worse.
> 
> Presumably, Rakudo itself is in the best position to define which 
> version(s) of Parrot it expects to run under. So do you think 
> there should be some kind of startup sanity check? Or going even 
> farther, a "make parrot" target which (if the appropriate version 
> of parrot isn't found on the system) goes and fetches it, unpacks 
> and builds it?

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
0
pmichaud
1/15/2009 5:20:34 PM
On Thu, Jan 15, 2009 at 04:20:28PM -0000, ajr@ippimail.com wrote:
> As outlined, the requirements seem to be pretty much those of any major
> Open Source development project. Keeping this in mind might yield a
> generic template usable by other projects in future.
> 
> 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.

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
0
moritz
1/15/2009 7:48:30 PM
On Thu, Jan 15, 2009 at 08:53:33AM +0100, Moritz Lenz wrote:
> 
> 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. 

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.

> 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.

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.

> > Web site / blog / wiki
> > ----------------------
> > Currently Rakudo really does not have a dedicated website
> > providing basic information about it.  [...] 
> > Here's what we ''do'' have at the moment (as best as I can recall):
> 
> 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" .../>)

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).

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

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
> > --------------
> 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, ...)

Good point, thanks.

Pm
0
pmichaud
1/15/2009 11:02:17 PM
On Wed, Jan 14, 2009 at 11:57:02PM -0800, Ovid wrote:
> > From: Patrick R. Michaud <pmichaud@pobox.com>
> 
> 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.  

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).

> 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).  

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).

> 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.  

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
0
pmichaud
1/15/2009 11:07:33 PM
----- Original Message ----=0A=0A> From: Patrick R. Michaud <pmichaud@pobox=
..com>=0A=0A> Moritz already replied with why spectest is currently in pugs,=
 I=0A> tend to agree.  For now I'd like spectests to continue to have=0A> a=
 very liberal commitbit policy, and that may or may not be=0A> compatible w=
ith Rakudo's commitbit policy (depending on how=0A> things end up).=0A=0AI =
buy the arguments put forward.  Some had been explained before and now that=
 I'm reminded, yeah, they make sense.=0A=0A=0ACheers,=0AOvid=0A--=0ABuy the=
 book         - http://www.oreilly.com/catalog/perlhks/=0ATech blog        =
    - http://use.perl.org/~Ovid/journal/=0ATwitter              - http://tw=
itter.com/OvidPerl=0AOfficial Perl 6 Wiki - http://www.perlfoundation.org/p=
erl6=0A
0
publiustemp
1/15/2009 11:49:55 PM
Patrick R. Michaud wrote (on p6c):
> On Thu, Jan 15, 2009 at 08:53:33AM +0100, Moritz Lenz wrote:
>> 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. 
> 
> 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.

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
0
darren
1/16/2009 12:03:10 AM
On Thu, 2009-01-15 at 16:03 -0800, Darren Duncan wrote:
> Patrick R. Michaud wrote (on p6c):
> > On Thu, Jan 15, 2009 at 08:53:33AM +0100, Moritz Lenz wrote:
> >> 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. 
> > 
> > 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.
> 
> 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.

The problem with this method is that there are usually *several* ways to
implement each feature in terms of some number of other features.  The
creators of the shared prelude are then stuck with the problem of
deciding which of these to use.  If their choices do not match the way a
particular implementation is designed, it will then be necessary for the
implementation to replace large swaths of the Prelude to get decent
performance.

For example, implementations in pure C, Common Lisp, and PIR will
probably have VASTLY different concepts of available and optimized
primitive operations.  A prelude written with any one of them in mind
may well be pessimal for one of the others.

That's not to say it's not a useful idea for helping to jumpstart new
implementations -- I just somewhat doubt that a mature implementation
will be able to use more than a fraction of a "common" prelude.


-'f

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.


0
geoff
1/16/2009 12:38:29 AM
Geoffrey Broadwell wrote:
> The problem with this method is that there are usually *several* ways to
> implement each feature in terms of some number of other features.  The
> creators of the shared prelude are then stuck with the problem of
> deciding which of these to use.  If their choices do not match the way a
> particular implementation is designed, it will then be necessary for the
> implementation to replace large swaths of the Prelude to get decent
> performance.
> 
> For example, implementations in pure C, Common Lisp, and PIR will
> probably have VASTLY different concepts of available and optimized
> primitive operations.  A prelude written with any one of them in mind
> may well be pessimal for one of the others.
> 
> That's not to say it's not a useful idea for helping to jumpstart new
> implementations -- I just somewhat doubt that a mature implementation
> will be able to use more than a fraction of a "common" prelude.

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
0
darren
1/16/2009 2:01:22 AM
Forgive my ignorance, but what is a Prelude?

-- 
Jonathan "Dataweaver" Lang
0
dataweaver
1/16/2009 2:31:38 AM
Jon Lang wrote:
> Forgive my ignorance, but what is a Prelude?

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
0
darren
1/16/2009 2:44:16 AM
--0015174c13aa081cd204609092ef
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On Thu, Jan 15, 2009 at 8:31 PM, Jon Lang <dataweaver@gmail.com> wrote:

> Forgive my ignorance, but what is a Prelude?
>
> --
> 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
perlpilot@gmail.com

--0015174c13aa081cd204609092ef--
0
perlpilot
1/16/2009 2:45:48 AM
On Thu, Jan 15, 2009 at 6:45 PM, Jonathan Scott Duff
<perlpilot@gmail.com> wrote:
> On Thu, Jan 15, 2009 at 8:31 PM, Jon Lang <dataweaver@gmail.com> wrote:
>>
>> Forgive my ignorance, but what is a Prelude?
>>
>> --
>> 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.

OK, then.  If I'm understanding this correctly, the problem being
raised has to do with deciding which language features to treat as
primitives and which ones to bootstrap from those primitives.  The
difficulty is that different compilers provide different sets of
primitives; and you're looking for a way to avoid having to write a
whole new Prelude for each compiler.  Correct?

Note my use of the term "language features" in the above.  Presumably,
you're going to have to decide on some primitive functions as well as
some primitive datatypes, etc.  For instance: before you can use
meta-operators in the Prelude, you're going to have to define them in
terms of some choice of primitive functions - and that choice is
likely to be compiler-specific.  So how is that any easier to address
than the matter of defining datatypes?  Or is it?

-- 
Jonathan "Dataweaver" Lang
0
dataweaver
1/16/2009 2:59:57 AM
------=_Part_265761_10553286.1232078264772
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Thu, Jan 15, 2009 at 8:59 PM, Jon Lang <dataweaver@gmail.com> wrote:

> OK, then.  If I'm understanding this correctly, the problem being
> raised has to do with deciding which language features to treat as
> primitives and which ones to bootstrap from those primitives.  The
> difficulty is that different compilers provide different sets of
> primitives; and you're looking for a way to avoid having to write a
> whole new Prelude for each compiler.  Correct?
>
> Note my use of the term "language features" in the above.  Presumably,
> you're going to have to decide on some primitive functions as well as
> some primitive datatypes, etc.  For instance: before you can use
> meta-operators in the Prelude, you're going to have to define them in
> terms of some choice of primitive functions - and that choice is
> likely to be compiler-specific.  So how is that any easier to address
> than the matter of defining datatypes?  Or is it?


Did I miss something here? I've never heard Prelude. I'm not really
convinced that each implementation should have a large set of shared code;
that seems contrary of the idea of having independent implementations.
Having to support a common set of implemented classes like this may end up
being more of a burden than a benefit. You may find each implementation
replacing parts of the Prelude to serve their needs.

It also seems like that Prelude.pm is dated and also very pugs specific,
which is ironic. What are all the references to Pugs::Internals and
pugs_internals_m:perl5? Is rx:Perl5 and rd:P5 valid perl6?

I'm skeptical of the this idea unless someone can convince me otherwise.

-Jason "s1n" Switzer

------=_Part_265761_10553286.1232078264772--
0
jswitzer
1/16/2009 3:57:44 AM
Following some responses I've seen, I'll try to clarify my proposal.  Basically 
its like this.

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
0
darren
1/16/2009 6:08:19 AM
The Prelude could be helpful for training. I've been trying to work out a
logical path into Perl 6 for quite some time, not least because it's been
a moving target. If there's a set of definitions that a computer can
follow, humans should be able to move along that path too.


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

0
ajr
1/16/2009 5:19:29 PM
On Jan 14, 9:01 pm, pmich...@pobox.com (Patrick R. Michaud) wrote:

Sorry for the 'tldr' reply...

> 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.

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

> 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/.

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.

> 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.

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.

> 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.

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.

> 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.

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
>   with the wider Perl community and provides a good blog-like
>   interface, but again isn't useful at basic Rakudo information
>   and orientation.

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

> * 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.

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

> * 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).

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.

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

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"
> 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
> athttp://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.

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 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.

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)

> 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.

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

> 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

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)
diakopter@gmail.com

0
diakopter
1/16/2009 10:26:43 PM
> From: Patrick R. Michaud [mailto:pmichaud@pobox.com]
> [...]
> 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.
> [...]
> * 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.

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.=20

(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 =97 http://www.perlfoundation.org/perl6=A0


0
conrad
1/17/2009 7:39:30 PM
Sorry for the 'tldr' reply...

On Jan 14, 9:01 pm, pmichaud@pobox.com (Patrick R. Michaud) wrote:
> 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.

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

> 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/.

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.

> 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.

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.

> 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.

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.

> 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.

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
>   with the wider Perl community and provides a good blog-like
>   interface, but again isn't useful at basic Rakudo information
>   and orientation.

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

> * 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.

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

> * 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).

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.

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

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"
> 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
> athttp://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.

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 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.

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)

> 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.

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

> 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

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)
diakopter@gmail.com
0
diakopter
1/18/2009 1:38:13 AM
Darren Duncan wrote:
> 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.

I do agree that a prelude.pm should be written atas higher level as 
possible, but I would not that Perl6 is not a "declarative" language. 
Using the most powerful operators available (I'd like to see more of 
them) is about the best you can do: as soon at you start using 
codeblocks to define things, you get beyond the realm where compile-time 
analysis is possible in a dynamic language.

Lets imagine I want to define a "sqrt($x)" function in a declarative 
style in perl6 (and lets image we've defined a Real type with 
Real::Epsilon being the precision of the representation). The 
declarative version of sqrt must say to find a value within the set of 
Real numbers that, when squared, is closest to $x:

sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
   (0..$x/2 :by(Real::Epsilon)).min: { abs $x - $^candidate ** 2 }
}

(This assumes that Array::min will one day accept a code-block, just 
like grep, to define the property of the input list to be minimized).

The code would give a correct answer (the positive sqrt), and is written 
as a fairly direct implementation of the declarative formulation. What 
I'm not so sure of is that it would be a good way to write prelude.pm: 
running the test suite would probably take quite a while.

So do you really mean "as declarative a manner as possible"? Or would 
you consider this example to go beyond "possible"?
0
dpuu
1/19/2009 6:54:19 PM
Dave Whipp wrote:
> I do agree that a prelude.pm should be written atas higher level as 
> possible, but I would not that Perl6 is not a "declarative" language. 
> Using the most powerful operators available (I'd like to see more of 
> them) is about the best you can do: as soon at you start using 
> codeblocks to define things, you get beyond the realm where compile-time 
> analysis is possible in a dynamic language.
> 
> Lets imagine I want to define a "sqrt($x)" function in a declarative 
> style in perl6 (and lets image we've defined a Real type with 
> Real::Epsilon being the precision of the representation). The 
> declarative version of sqrt must say to find a value within the set of 
> Real numbers that, when squared, is closest to $x:
> 
> sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
>   (0..$x/2 :by(Real::Epsilon)).min: { abs $x - $^candidate ** 2 }
> }
> 
> So do you really mean "as declarative a manner as possible"? Or would 
> you consider this example to go beyond "possible"?

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
0
darren
1/21/2009 2:20:37 AM
Darren Duncan wrote:
> Dave Whipp wrote:

>> sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
>>   (0..$x/2 :by(Real::Epsilon)).min: { abs $x - $^candidate ** 2 }
>> }
>>
>> So do you really mean "as declarative a manner as possible"? Or would 
>> you consider this example to go beyond "possible"?
> 
> I would declare sqrt this way instead (the body is the important change):
> 
>   sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
>     $x ** (1/2)
>   }

In other words, you prefer explicit definition to implicit declaration 
(in this case, you're basically saying that "sqrt" is a curried 
exponentiation). Do you have any examples of what you'd propose as 
declarative forms for prelude.pm?
0
dpuu
1/21/2009 7:40:41 PM
Dave Whipp wrote:
> Darren Duncan wrote:
>> Dave Whipp wrote:
> 
>>> sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
>>>   (0..$x/2 :by(Real::Epsilon)).min: { abs $x - $^candidate ** 2 }
>>> }
>>>
>>> So do you really mean "as declarative a manner as possible"? Or would 
>>> you consider this example to go beyond "possible"?
>>
>> I would declare sqrt this way instead (the body is the important change):
>>
>>   sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
>>     $x ** (1/2)
>>   }
> 
> In other words, you prefer explicit definition to implicit declaration 
> (in this case, you're basically saying that "sqrt" is a curried 
> exponentiation). Do you have any examples of what you'd propose as 
> declarative forms for prelude.pm?

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
0
darren
1/22/2009 10:24:40 PM
Darren Duncan wrote:

> 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)
0
dpuu
1/22/2009 10:46:33 PM
Dave Whipp wrote:
> 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
0
darren
1/23/2009 8:26:53 PM
Reply:

Similar Artilces:

[svn:parrot-pdd] r32941
Author: coke Date: Thu Nov 20 08:20:24 2008 New Revision: 32941 Modified: trunk/docs/pdds/pdd19_pir.pod Changes in other areas also in this revision: Modified: trunk/DEPRECATED.pod trunk/compilers/imcc/imcc.l trunk/compilers/imcc/imcc.y trunk/compilers/imcc/imclexer.c trunk/compilers/imcc/imcparser.c trunk/compilers/imcc/pbc.c trunk/compilers/imcc/unit.h trunk/compilers/pct/src/POST/Compiler.pir trunk/compilers/pct/src/POST/Node.pir trunk/editor/pir-mode.el trunk/editor/pir_vim.in trunk/include/parrot/sub.h trunk/languages/perl6/...

[svn:parrot-pdd] r34905
Author: jkeenan Date: Sat Jan 3 16:22:40 2009 New Revision: 34905 Modified: trunk/docs/pdds/draft/pdd06_pasm.pod Changes in other areas also in this revision: Added: trunk/compilers/pirc/src/ - copied from r34904, /trunk/compilers/pirc/new/ Removed: trunk/compilers/pirc/new/ Modified: trunk/MANIFEST trunk/compilers/pirc/README.pod trunk/compilers/pirc/src/hdocprep.c trunk/compilers/pirc/src/pirlexer.c trunk/compilers/pirc/src/pirlexer.h trunk/compilers/pirc/src/pirsymbol.c trunk/config/gen/makefiles/pirc.in trunk/lib/Parrot/Distrib...

RE: GCC for PARROT (GCC Compiling itself to PARROT, then compilin g all supported languages to PARROT from PARROT)?!?!
OK, I think I'm starting to get a better picture of what needs to happen. Does this sound more reasonable? Java, C#, Fortran(???), (Managed???)C++, (Other languages with appropriate non-direct memory access) ==> GCC Parser ==> Parse Tree ==> Enhanced RTL (where enhanced means semantics preserving RTL rather than the current machine oriented RTL) ==> ERTL (Enhanced RTL) -> PARROT ByteCode ==> PARROT Optimizer ==> PARROT Runtime (w/ JIT) The important point is that the starting language must have semantics which treat variables, objec...

[svn:parrot-pdd] r22465
Author: tewk Date: Wed Oct 24 17:11:20 2007 New Revision: 22465 Modified: trunk/docs/pdds/pdd23_exceptions.pod Changes in other areas also in this revision: Added: trunk/t/op/exceptions.t Modified: trunk/DEPRECATED.pod trunk/compilers/json/JSON/pge2pir.tg trunk/compilers/json/postalcodes.pir trunk/compilers/past-pm/POST/Grammar.tg trunk/compilers/pct/src/HLLCompiler.pir trunk/compilers/pct/src/POST/Grammar.tg trunk/compilers/pge/PGE/Exp.pir trunk/compilers/pirc/src/pirutil.c trunk/compilers/tge/TGE/Compiler.pir trunk/docs/compiler_faq.p...

[svn:parrot-pdd] r13503
Author: ambs Date: Mon Jul 24 08:26:45 2006 New Revision: 13503 Modified: trunk/docs/pdds/clip/pdd22_io.pod (contents, props changed) trunk/docs/pdds/clip/pdd24_events.pod (contents, props changed) trunk/docs/pdds/clip/pdd25_threads.pod (contents, props changed) trunk/docs/pdds/pdd23_exceptions.pod (props changed) Changes in other areas also in this revision: Modified: trunk/cage/todo.pod (props changed) trunk/compilers/bcg/src/pmc/bcg.pmc (props changed) trunk/compilers/imcc/imcc.y (props changed) trunk/compilers/imcc/parser.h (props ch...

Pugs to become a Perl6 -> Parrot AST/IMC compiler.
--ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline After a IRC meeting with Leo, I've outlined my roadmap of how to make the three compiler backends in Pugs to work in concert to provide a much faster evaluator: http://use.perl.org/~autrijus/journal/23890 Note that existing code in the Eval monad need not be rewritten; also Pugs will still run Perl 6 code without a parrot installation, by compiling IMC to Haskell on the fly and executing it. More details and code will follow shortly; suggestions and feedbacks to this plan are ver...

Loading Rakudo's perl6.pbc from the Parrot embedding API
Howdy, I am trying to load an installed perl6.pbc from the Parrot embedding API like this: #include "parrot/embed.h" #include "parrot/extend.h" Parrot_Interp interp; int main(int argc, char *argv[]) { Parrot_PMC func_pmc; Parrot_String err, filename; Parrot_set_config_hash(); interp = Parrot_new(NULL); filename = Parrot_str_new(interp, "/Users/leto/svn/parrot/installed_parrot/lib/2.4.0-devel/languages/perl6/perl6.pbc"); Parrot_load_bytecode(interp,filename); } Compiled with: gcc embed2.c -o embed2 `pkg-config ...

Announce: Rakudo Perl6 compiler, Development Release #69 ("Roederbergweg")
--047d7b6dc6eee0e86104e8ffef52 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On behalf of the Rakudo development team, I'm happy to announce the October 2013 release of Rakudo Perl #69 "Roederbergweg". Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine and the Java Virtual Machine. The tarball for this release is available from <http://rakudo.org/downloads/rakudo/>. Please note: This announcement is not for the Rakudo Star distribution[^1] --- it's announcing a new release of the compiler only. F...

[svn:parrot-pdd] r22180
Author: allison Date: Wed Oct 17 12:33:17 2007 New Revision: 22180 Modified: trunk/docs/pdds/pdd15_objects.pod trunk/docs/pdds/pdd17_pmc.pod Changes in other areas also in this revision: Added: trunk/include/parrot/oo.h - copied unchanged from r22176, /branches/pdd15oo/include/parrot/oo.h trunk/include/parrot/oo_private.h - copied unchanged from r22176, /branches/pdd15oo/include/parrot/oo_private.h trunk/src/oo.c - copied unchanged from r22176, /branches/pdd15oo/src/oo.c trunk/t/oo/isa.t - copied unchanged from r22176, /branches/pdd1...

[svn:parrot-pdd] r32652
Author: coke Date: Fri Nov 14 16:33:41 2008 New Revision: 32652 Modified: trunk/docs/pdds/pdd19_pir.pod Changes in other areas also in this revision: Modified: trunk/DEPRECATED.pod trunk/compilers/imcc/imcc.y trunk/compilers/imcc/imcparser.c trunk/languages/dotnet/build/builtins.pl trunk/languages/dotnet/build/translator.pl trunk/languages/dotnet/src/exception.pir trunk/languages/dotnet/src/field.pir trunk/languages/dotnet/src/method.pir trunk/languages/dotnet/src/net2pbc.pir trunk/languages/dotnet/src/signature.pir trunk/languages/dotne...

[svn:parrot-pdd] r26309
Author: allison Date: Tue Mar 11 02:50:21 2008 New Revision: 26309 Modified: trunk/docs/pdds/draft/pdd04_datatypes.pod trunk/docs/pdds/pdd17_pmc.pod Changes in other areas also in this revision: Added: trunk/lib/Parrot/Pmc2c/Attribute.pm - copied unchanged from r26307, /branches/pdd17pmc/lib/Parrot/Pmc2c/Attribute.pm trunk/tools/dev/vtablize.pl - copied unchanged from r26307, /branches/pdd17pmc/tools/dev/vtablize.pl Modified: trunk/MANIFEST trunk/compilers/bcg/src/pmc/bcg.pmc trunk/compilers/imcc/pbc.c trunk/config/auto/pmc.pm trunk/c...

[svn:parrot-pdd] r25116
Author: pmichaud Date: Mon Jan 21 18:32:45 2008 New Revision: 25116 Modified: trunk/docs/pdds/pdd26_ast.pod Changes in other areas also in this revision: Modified: trunk/compilers/pct/src/PCT/Node.pir trunk/runtime/parrot/library/Parrot/Capture_PIR.pir Log: [pct]: * Add shift and pop operations to PAST::Nodes. * Patch courtesy Stuart Jansen <sjansen at gurulabs.com> Modified: trunk/docs/pdds/pdd26_ast.pod ============================================================================== --- trunk/docs/pdds/pdd26_ast.pod (original) +++ trunk/docs/pdds/pdd26_...

[svn:parrot-pdd] r29952
Author: allison Date: Sat Aug 2 15:45:13 2008 New Revision: 29952 Modified: trunk/docs/pdds/draft/pdd08_keys.pod trunk/docs/pdds/pdd17_pmc.pod trunk/docs/pdds/pdd23_exceptions.pod Changes in other areas also in this revision: Added: trunk/src/pmc/exceptionhandler.pmc - copied unchanged from r29949, /branches/pdd25cx/src/pmc/exceptionhandler.pmc Removed: trunk/src/pmc/exception_handler.pmc Modified: trunk/MANIFEST trunk/compilers/bcg/src/pmc/bcg.pmc trunk/compilers/imcc/imcc.l trunk/compilers/imcc/imcc.y trunk/compilers/imcc/imclexer.c ...

[svn:parrot-pdd] r31668
Author: allison Date: Sun Oct 5 04:30:01 2008 New Revision: 31668 Modified: trunk/docs/pdds/pdd27_multiple_dispatch.pod Changes in other areas also in this revision: Added: trunk/docs/multidispatch.pod - copied unchanged from r31667, /branches/pdd27mmd/docs/multidispatch.pod trunk/include/parrot/multidispatch.h - copied unchanged from r31667, /branches/pdd27mmd/include/parrot/multidispatch.h trunk/lib/Parrot/Pmc2c/MULTI.pm - copied unchanged from r31667, /branches/pdd27mmd/lib/Parrot/Pmc2c/MULTI.pm trunk/src/multidispatch.c - copied unc...

Web resources about - Rakudo leaving the Parrot nest - perl.perl6.compiler

School leaving qualification - Wikipedia, the free encyclopedia
A school leaving qualification is an academic qualification awarded for the completion of high school . Depending on the country or region, it ...

Jas Athwal Promoted To Chief Accounting Officer At Facebook; David Spillane Leaving Company
Facebook Revenue Controller Jas Athwal has been promoted to chief accounting officer, succeeding David Spillane , who is leaving the company. ...

Checking in at the World Cup and Leaving with Friends
Hundreds of thousands of people from around the world traveled to the 2014 World Cup and we wanted to take a closer look at those who used Facebook ...

New mobile ‘action links’ allow users to take specific actions in other apps without leaving Facebook ...
Facebook appears to be testing its “ action links ” feature on mobile, making it easy for users to engage with third-party apps without leaving ...

Scripting News: I vote for leaving off the at-sign if you're saying trash about a celeb.
... Even Kevin Durant, who is a great leader and player probably can't overcome the audacity and tenacity of the Miami Heat. So I vote for leaving ...

Pinterest : Why is Jon Jenkins leaving Pinterest?
Answer: I'm glad you asked! The decision to leave Pinterest really is bittersweet. Since I joined the company, the engineering team has more ...

'We will make a Brexit work': David Cameron on leaving the EU
It would not be the &quot;right answer&quot; for Britons to vote to leave the European Union, but the government would have to make it work if ...

Woman charged after leaving young child locked in car
A woman has been charged after allegedly leaving her two-year-old son in a parked car at Bankstown on Monday.

Bridgetown woman, 20, charged with leaving baby girl in car on 38-degree day
A 20-year-old woman has been charged after police rescued a heat-stricken baby girl from inside a car in Bridgetown last weekend.

Coming Out: How Is It Like Leaving Biglaw?
On its face, the comparison seems absurd but the deeper you look, the more the analogy makes sense.

Resources last updated: 1/17/2016 4:07:00 PM