Where Should We Set the Way-Back Machine?

pudge on 2001-11-06T21:10:10

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?"


You might try looking at

hfb on 2001-11-06T23:16:27

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

Re:You might try looking at

Elian on 2001-11-06T23:55:08

Ah, I'd forgotten about the rags and their surveys. I'll go poke about and see what I can find. Thanks.

Be Pragmatic

chromatic on 2001-11-07T00:03:50

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.

support whatever platforms Perl 5 supports

metaperl on 2001-11-07T03:52:15

or, if emacs can run on it, we should.

Re:support whatever platforms Perl 5 supports

kwilliams on 2001-11-07T09:31:49

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, because we have the luxury of having no users who are depending on Perl6 yet.

It's vital that Perl6 be first-class on lots of different kinds of machines though, because that's one of the things that really makes Perl Perl.

Of course, things that are reasonably standard across platforms (breadth) are also more likely to be well-established in the history of a single platform (depth), so you might get some free depth by focusing on breadth.

Maybe a plea up on Slashdot for smoke testers?

To start of: Keep it simple and small

Random Logic on 2001-11-07T08:28:23

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

I guess I wasn't clear

Elian on 2001-11-07T13:46:57

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

Do we not worry about Solaris 2.4? SunOS 4.x? VMS 5.5-1h2? GCC 1.x?

At some point we need to say "This is the base level of required functionality, and if you don't provide it too bad. (But we're keen if you fake it)". I'm just trying to get a feel for that point.

Re:I guess I wasn't clear

booker on 2001-11-07T21:03:21

-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 5.5 ). A perl 6 that didn't run on them
wouldn't bother me too much.

- Booker C. Bense

a bit scared

jhi on 2001-11-07T22:44:15

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. Whatever you have, we'll work with it.

<PerlDevelopmentOldFart Hat="On"> It is our job to bend over backwards to support Perl on as many platforms as possible. If we were saying that only linux and win32 on x86 and gcc/vc are supported why would we waste our time on Perl at all? </PerlDevelopmentOldFart>

For me one of the greatest magicks of Perl is its portability: that it gives us on any platform an illusion of a wonderful combination of a flexible language and a portable operating system. Just like NetBSD has the motto "Of course it runs NetBSD", At least so far, one of Perl's unspoken mottos has been "Of course Perl runs on it". I wish that'll be the case in the future, too.

Re:a bit scared

ask on 2001-11-09T01:26:20

Subscribe!