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

use Perl Log In

Log In

[ Create a new account ]

Where Should We Set the Way-Back Machine?

posted by pudge on 2001.11.06 16:10   Printer-friendly
Dan writes "As anyone who's tried building Parrot lately has probably noticed, the current source is rather... version and platform sensitive. Needless to say, this just won't cut it for very long. (Like past about 10 minutes ago) The question, though, is how far back do we go? What's a reasonable spot in an OS or compiler's life to declare "past here we don't support"?

Now, obviously we're not going to go out of our way to build on a System 7 machine, but neither can we put the spot at today's latest'n'greatest. So--where should it be put?"

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.
  • OS Surveys [] 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