This fixes a typo and enables X>>+< X
| X
-| X
+| X
]
= $; }>
On 2009 Jan 21, at 7:35, Carl Mäsak wrote:
Moritz (>):
So Larry and Patrick developed the idea of creating an
adverb on the test operator instead:
$x == 1e5 :ok('the :ok makes this is a test');
I'm trying to explain to myself why I don't like this idea at all. I'm
only partially successfu
On Fri, Jan 23, 2009 at 6:39 PM, Dave Whipp wrote:
> A spec-test is (or should be) different from an ad-hoc test. I want to be
> able to say "test S09.237 passes on pugs but not on Rakudo" (perhaps with a
> nicer name). Unique identifiers allow comparisons of specific tests across
> multiple imp
jerry gay wrote:
i don't understand the drive to have unique test identifiers. we don't
have unique identifiers for every code statement, or every bit of
documentation. why are tests so important/special/different that each
warrants a unique id? that aside, this functionality sounds like it
can
On Fri, Jan 23, 2009 at 12:37, Dave Whipp wrote:
> I could also imagine writing code that reads from an Sqlite database, and
> imposes that info onto the test. Whatever mechanism is used, I think we need
> a language-defined mechanism to supply a stable unique identifier for each
> test, so that i
Larry Wall wrote:
module MyTests {
sub group1 {
ok foo :name; ## Q - would a label be better?
}
}
>> ## Elsewhere
>> MyTests.group1.test_foo is also broken;
I guess I don't see offhand what you're trying to do with that.
...
We must keep a clean
separation between code t
Dave Whipp wrote:
I actually agree that your explicit definition (a simple/efficient
implementation in terms of other operators) is better for prelude than
my "declarative" form (which isn't really declarative, because Perl6
isn't a declarative language). My only disagreement was with your
ear
On Fri, Jan 23, 2009 at 11:16:21AM -0800, Dave Whipp wrote:
> I can see that. So the alternative is to give things names and/or tags,
> so that we can attach parameters remotely.
Hmm, well, we also decided not to use any solutions that encourage
putting the metadata too far away from the place i
Larry Wall wrote:
On Fri, Jan 23, 2009 at 08:01:14AM -0800, Dave Whipp wrote:
For example, I could conceive of a trait:
ok foo, :broken
which might downgrade the error to a warning on rakudo, but not on other
implementations.
On the surface that seems like a good idea, and pugs started o
On Fri, Jan 23, 2009 at 08:01:14AM -0800, Dave Whipp wrote:
> For example, I could conceive of a trait:
>
> ok foo, :broken
>
> which might downgrade the error to a warning on rakudo, but not on other
> implementations.
On the surface that seems like a good idea, and pugs started out doing
thi
Timothy S. Nelson wrote:
method foo() does assume { ... }
method bar() does ensure { ... }
Is "ensure" equivalent to the "assert" that you describe above?
Yes. "does ensure" was meant to be an englishification of
"postcondition"; and "does assume" is "precondition".
From the perspec
fREW (>), Moritz (>>), fREW (>>>):
>> > And should I
>> > just mail patches to rakudo...@perl.org?
>>
>> In general if you find a bug: yes.
>> In this case not, because it's a known limitation.
>
> Where do I mail the patches for the tests?
The Pugs repository (containing the Perl 6 test suite) h
> > And should I
> > just mail patches to rakudo...@perl.org?
>
> In general if you find a bug: yes.
> In this case not, because it's a known limitation.
Where do I mail the patches for the tests?
--
-fREW
Darren Duncan wrote:
I don't quite follow you. Are you saying your version of sqrt is an
implicit declaration; maybe I don't understand how that differs from an
explicit definition in this case? In any event, right at this moment I
can't think of an answer to your question. Go ahead with wh
14 matches
Mail list logo
