As I said during #parrotsketch [1], I have recently (and belatedly)
learned that exception handling is planned for a major shakeup. (FWIW,
I now see that is because exceptions are being recast as events; I had
assumed that PDD24 was just about asynchronous events. Since PDD23
hasn't changed mu
[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
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 various test files.
Something to consider after the 1.0 r
On Fri, Jul 28, 2006 at 08:46:50AM -0600, Kevin Tew wrote:
> I'm seeking information regarding TGE's design goals, aspirations,
> future plans, etc.
>
> I see that Perl6 implements its own version of PAST and POST nodes.
> Is it possible to share basic PAST and POST nodes and extend them for
> p
Kevin Tew wrote:
I'm seeking information regarding TGE's design goals, aspirations,
future plans, etc.
I see that Perl6 implements its own version of PAST and POST nodes.
Is it possible to share basic PAST and POST nodes and extend them for
particular HLL needs?
I know that different HLLs sh
I'm seeking information regarding TGE's design goals, aspirations,
future plans, etc.
I see that Perl6 implements its own version of PAST and POST nodes.
Is it possible to share basic PAST and POST nodes and extend them for
particular HLL needs?
I know that different HLLs share a lot of the
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
ne to be able to suggest and improve the development process.
>
> I've been thinking that getting the approach roughed out takes
> precedence over picking teams. You wouldn't know what you were being
> picked for, for a start. There's definitely an art in deciding who
&
> 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
use I want
everyone to be able to suggest and improve the development process.
I've been thinking that getting the approach roughed out takes
precedence over picking teams. You wouldn't know what you were being
picked for, for a start. There's definitely an art in deciding who
should wo
Nathan Torkington wrote:
> We're lucky to have the experience of Chip to draw upon (he's already
> blazed some of the trails we'll be turning into fully-paved four-lane
> highways with Waffle Houses and Conocos), as well as a lot of people
> who've worked with perl5. They know what works and wha
> "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
This will ultimately go in a more detailed version of the Roadmap,
but here's my current thinking on what comes next. Be warned, it's
written as a braindump.
Larry releases his draft language design, an overview of what will be
in the language and what it will look like. There'll be some
clarif
40 matches
Mail list logo
