Stories
Slash Boxes
Comments
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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • OS Surveys [networkcomputing.com] out on the net and in print for an idea of what platforms people are using most often. It really depends how many people on the more esoteric platforms are hoping/planning to upgrade to P6 once it is released. You could also pick a year, say 1995, and declare that anything older than that won't be 'officially' supported as there will be people who won't take no for an answer and port it themselves :)

  • If you can't find anyone with the ability (or the means by which to sponsor someone) to build it on an esoteric platform, cut it. Or you could be more pleasant than I am today (voting day), and welcome potential pumpkings to fix things up anywhere else.

    Either way, if it's not important enough for someone to devote time, money, or curiosity, it should be a low priority to the (probably overburdened) developers.

  • or, if emacs can run on it, we should.
    • I don't think that's a great idea - Perl 5 supports some pretty crufty old platforms, and trying hard to support those platforms will probably waste developer effort when it's not clear that it's worth it to anybody anymore.

      I know (or I think) Dan is looking for specifics rather than philosophy statements, but here's one principle I'd put forth: breadth is more important than depth in this case. It's reasonable to ask people to have relatively recent versions of compilers, etc. when building Perl6, becau
  • To get the project going, you should probably stick to the most common platforms and versions to start of. Online surveys of used platforms, can lead the way (with x86, sun, hp being the most used).

    So if you start of getting x86 for the most used kernel-versions of linux and for win32 (probably Mac OS X too), you'll have a big bunch of interested developers and testers, of whom one or another might work on a different platform too...
    --
    Hmmm... someone stole my signature...
  • The issue isn't as much what platforms do we support as it is at what point is breakage not a show-stopper?

    For example, suppose we roll support for complex numbers into the core, and use the ANSI C99 standard so parrot can't build unless you have GCC 3.0.2 or higher. That's setting things too far forward, and it's a show-stopper.

    On the other hand, parrot's going to use threads, and require POSIX compliance for platforms with POSIX threads. That means that HP/UX 10.x is out of luck, but that's not a show
    • -I would say that you should focus on standards
      and let the chips fall where they may. Pick
      standards that are reasonably well supported
      and not bleeding edge.

      - If you want specifics, I'd say any OS older than
      5 years or that has been EOL'd by the vendor
      can't generate a show-stopper. As far as software
      like gcc goes I think the same 5yr limit should
      apply or perhaps "one major revision". This would
      pretty much put all the things on your list in
      the "no show stopper" bucket ( except I don't know
      about VMS
  • I found quite appalling the idea that we should drop any platforms that Perl 5 supports-- but of course within reason: if we can' find a champion that can do the porting and maintenance on that platform, we are obviously out of luck, as is that platform.

    But if we start throwing around arbitrary time limits, I'm afraid that's the wrong way to go about it. Instead we should think about features: make Perl 6 modular enough that if your platform doesn't do, say, POSIX threads, you get all but threads. What