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

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 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

    • I've just posted a reply to this comment on the perl6-compilers mailing list -- when's mailing list manager catches up it should appear here [].

      (It seemed more useful to put it on the mailing list than to try to keep separate threads on use.perl,, and the mailing list.)


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

  • To frame the discussion, it might help to know what our current constraints are. For example, if we decide to replace, 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?
    • 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.


  • 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!
    • I'm thinking we might be able to eliminate the Parrot checkout for many/most projects. Maybe not mod_parrot itself, but who knows?


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

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