NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

use Perl

All the Perl that's Practical to Extract and Report

Leaving the Parrot nest More | Login | Reply

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Without JavaScript enabled, you might want to use the classic discussion system instead. If you login, you can remember this preference.

Parrot management (Score:1)

by infinoid (7118)

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 "mo
- Re: (Score:1)
  
  by pmichaud (6013)
  
  I've just posted a reply to this comment on the perl6-compilers mailing list -- when perl6.org's mailing list manager catches up it should appear here [google.com].
  (It seemed more useful to put it on the mailing list than to try to keep separate threads on use.perl, rakudo.org, and the mailing list.)
  Pm
Re: Leaving the Parrot nest (Score:1)

by kid51 (5328)

Patrick:
Thank you for this thorough and temperate summation of the issues. I don't follow Rakudo or Perl 6 that closely; I barely have tuits to follow Parrot. So I don't have much to say one way or the other about how Rakudo's infrastructure should evolve.
I just wish we had had a blog post like this concerning Parrot's infrastructure before all these changes started happening.
Thank you very much.
What are our constraints? (Score:1)

by geoffrey (5895)

To frame the discussion, it might help to know what our current constraints are. For example, if we decide to replace rt.perl.org, are we limited in our choice by available hosting hardware, or admin expertise (of other tracking products), or admin tuits? Are any of those constraints so tight that we will need to seek donations or grants to allow us to make the best choice for Rakudo and Perl 6?
- Re: (Score:1)
  
  by pmichaud (6013)
  
  I agree that knowing about constraints is important; that said, I haven't been able to come up with any limitations or constraints along the lines you've mentioned that I think are insurmountable.
  Pm
mod_perl6 dependencies (Score:1)

by jhorwitz (4227)

Something just occurred to me. Since I'm also in the process of moving mod_perl6 out of the mod_parrot repository, building mod_perl6 will soon require 4 separate SVN checkouts (parrot, rakudo, mod_parrot, mod_perl6). Of course, in the future stable releases of each project will ease this pain, but still...ouch!
- Re: (Score:1)
  
  by pmichaud (6013)
  
  I'm thinking we might be able to eliminate the Parrot checkout for many/most projects. Maybe not mod_parrot itself, but who knows?
  Pm
- Re: (Score:1)
  
  by duff (16)
  
  This sounds like one place where svn:externals can be put to good use. You could make an "umbrella repository" that gets all of the proper revisions of all the required pieces and to the outside universe, it'll be just a single "svn checkout".
No need to switch to Drupal (Score:1)

by stu42j (6348)

MT4 can easily be used to create standard "web pages" in addition to a blog.