[EMAIL PROTECTED] wrote:
A possible scheme might be a directory hierarchy matching the OS/CPU
combination, e.g. Linux/x_86, Linux/i_64, Solaris/Sparc, containing dummy
files whose names match the processes NOT to be run for that environment.
(The precise structure would depend on which combinati
> I think the data will support the idea that a directory structure based
on OS/CPU is probably not the way to start.
>
Quite possibly. The proposed file could suffer from the same combinatorial
explosion, if not properly structured. Does anyone have a good idea of the
most economical structure for
On Thu, 10 Jan 2008, [EMAIL PROTECTED] wrote:
> Some hand-waving on the problem of configuration and test selection, (as
> the two appear to share the issues, an ideal solution would address both).
>
> For any usable environment, a large set of common processes have to be
> executed, with a small
Some hand-waving on the problem of configuration and test selection, (as
the two appear to share the issues, an ideal solution would address both).
For any usable environment, a large set of common processes have to be
executed, with a smaller, OS &&/|| CPU specific set omitted. One way to do
this
Gabor Szabo wrote:
[darwin]
t/pmc/foo.t 3 5-7 9 # platform doesn't support libfoo
t/pmc/bar.t 1 42
...
This seems to be too obvious to be a real question but what if someone
adds a new test
in the middle of bar.t ?
Will she have to remember to update the numbers in the central config file?
T
On Jan 10, 2008 12:23 PM, Allison Randal <[EMAIL PROTECTED]> wrote:
> Aye, I would want to improve on the Python solution. But maintaining a
> config file something like:
>
> [darwin]
> t/pmc/foo.t 3 5-7 9 # platform doesn't support libfoo
> t/pmc/bar.t 1 42
> ...
>
> [MSWin32]
> t/pmc/foo.t 32
>
Rafael Garcia-Suarez wrote:
That assumes that tests are skipped per file, which is not always the
case (sometimes you want to skip only one test, sometimes even to work
around an OS bug that appears only in one specific version). But
reorganizing platform-dependent tests might be a good idea.
# from Rafael Garcia-Suarez
# on Wednesday 09 January 2008 05:36:
>Allison Randal wrote in perl.perl6.internals :
>> In the Python test suite, there's a single global location to
>> declare a list of test files that are expected to be skipped on a
>> particular platform. This has a much cleaner fe
Allison Randal wrote in perl.perl6.internals :
> In the Python test suite, there's a single global location to declare a
> list of test files that are expected to be skipped on a particular
> platform. This has a much cleaner feel than our own motley collection of
> skip and todo markers in vari
On Thu, 14 Sep 2000, Steve Fink wrote:
> Alan Burlison wrote:
> > Having done so I have been very happy to see the wide consensus
> > that seems to be appearing.
>
> Huh? I'd say quite the opposite. I expected more. There are many, many
> people who use perl. Anybody who uses anything will come u
Alan Burlison wrote:
>
> Adam Turoff wrote:
>
> > It would have been nicer to institute this policy from the start,
> > but no one expected to get 200 RFCs in just over one month, either.
>
> Indeed - I think everyone was astonished by the rate at which they
> appeared. I just hope the code is
J. David Blackstone writes:
> Wait. Does a good idea have to go away simply because the person
> who originally proposed it no longer has interest? What if several
> people are interested, but the original author has totally skipped out
> on Perl6 development, and the other interested people d
On Mon, Sep 11, 2000 at 11:49:52PM -0500, J. David Blackstone wrote:
> > Presumably the discarding will be heralded with an announcement on the
> > mailing list, as well as a note to the maintainer. The interested
> > parties should see this and yell.
>
> Just wanted to get that stated explici
> I believe in having small control teams (2-3 people) assigned to
> each issue; these teams act as moderators for whatever they are
> implementing. These teams consist entirely of proven people. Give
> the control teams whatever they need to function: read-only + public
> mailing lists, etc.
On Mon, Sep 11, 2000 at 11:49:52PM -0500, J. David Blackstone wrote:
> > On Mon, Sep 11, 2000 at 11:34:55PM -0500, J. David Blackstone wrote:
> >
> > Presumably the discarding will be heralded with an announcement on the
> > mailing list, as well as a note to the maintainer. The interested
> > pa
Nat "Is pm for Project Management or Perl Module" Torkington wrote:
> You're right that it's very unclear how RFCs will be accepted or
> rejected. It's become obvious from the variety of RFCs proposed that
> Perl cannot be designed by committee. That's why there's one person
> designated as the
> On Mon, Sep 11, 2000 at 11:34:55PM -0500, J. David Blackstone wrote:
>> Wait. Does a good idea have to go away simply because the person
>> who originally proposed it no longer has interest? What if several
>> people are interested, but the original author has totally skipped out
>> on Perl6
On Mon, Sep 11, 2000 at 11:34:55PM -0500, J. David Blackstone wrote:
> Wait. Does a good idea have to go away simply because the person
> who originally proposed it no longer has interest? What if several
> people are interested, but the original author has totally skipped out
> on Perl6 devel
Adam Turoff wrote:
> All of the RFCs have mailing lists associated with them, and all of
> the mailing lists have chairpeople leading discussion.
>
> Why not ask these chairpeople to start a Last Call process, whereby
> any unmaintained RFCs can be marked as "unmaintained and withdrawn"
> by the r
On Mon, 11 Sep 2000, Alan Burlison wrote:
> I hope many more people take
> note of your gutsy lead and follow it.
> I'm sure that your mail will have put you high up on the list of
> 'promising fresh blood' :-) Please don't take my original commnents as
> being directed at you personally - your
Well, THAT was certainly specific, insightful, politely phrased, and
filled with pertinent advice on how to remedy the problem!
Alan, you're right about certain things...it's important that talented,
experienced people have the final say over the final product. However,
most of the problems in e
Alan Burlison wrote:
>
> I'm sorry but I really can't stomach watching this slow motion train
> wreck any longer, so good luck and goodbye.
Plonk.
--
John Porter
Adam Turoff wrote:
> From this, I can extract these action items:
>
> 1) Set up p6 development like other open source projects, where there
>is a "core team" responsible for the progress of Perl6 or a component
>of Perl6. These people have write access to the source repository
>(wha
Nathan Wiger wrote:
> Well, as I suggested once before (but it was probably premature at the
> time), I think people should start retracting RFC's that they don't
> think are wins, or that the general consensus is against. I'm going to
> retract 3 of my own today.
Good for you. That is a very c
On Sun, Sep 10, 2000 at 09:58:14PM +0100, Alan Burlison wrote:
> I don't believe in magic. I'm an engineer by profession, not an
> astrologer. However, I will predict endless arguments when some of the
> less than coherent proposals are rejected.
The RFC process was intended to bring out both
> > What we're doing about that:
> > * pushing the output through Larry
> > [Yes, this addresses only part of the problem. Any suggestions for
> > other ways to solve this?]
>
> The RFC mountain is way, way too high to be climbed by just one person,
> let alone the output of the various mailing
Nathan Torkington wrote:
> Thanks for that grim view, Alan. I've been looking around for someone
> to act as the Devil's Advocate and say what might go wrong, so I was
> happy to see this.
Glad to be of service ;-)
> I agree that the current brainstorming is chaotic. I feel like that's
> the
Andy Dougherty wrote:
> I think the chaotic brainstorming on -language has been very necessary. We
> need a forum that encourages new radical ideas. Sure, most of them
> probably won't pan out or prove worthwhile, but I'm hopeful that there
> will ultimately be a few new things in perl6 that gr
On Sun, 10 Sep 2000, Alan Burlison wrote:
> Unfortunately the greatest volume on the various p6 sublists tends to be
> coming from the least experienced people. The comments based on common
> sense and long experience tend to be lost in the hubbub of uninformed
> noise.
I think the chaotic bra
Thanks for that grim view, Alan. I've been looking around for someone
to act as the Devil's Advocate and say what might go wrong, so I was
happy to see this.
Your message seems to have two points: that the current brainstorming
phase is so chaotic that it's hard to see how anything good can come
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Chaim Frenkel writes:
>> Would it be worthwhile to 'waste' some time on writing caller and callee
>> stubs? This would flesh out the final api and give the module writers
>> something of an environment to work with?
NT> Yes, I'm app
Chaim Frenkel writes:
> Would it be worthwhile to 'waste' some time on writing caller and callee
> stubs? This would flesh out the final api and give the module writers
> something of an environment to work with?
Yes, I'm appalled I forgot this. It's part of what I've been thinking
about.
By ha
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Once we have an API, we write test cases to exercise the API.
NT> Then we code.
Would it be worthwhile to 'waste' some time on writing caller and callee
stubs? This would flesh out the final api and give the module writers
something
33 matches
Mail list logo
