Austin Hastings wrote:
I'll guess that you're pointing at
.:send_one($_);
Which supposedly uses "topic" to resolve .:send_one into $this.send_one.
If that works, then I'm happy -- I like being able to control topic and
$_ differently. But if C changes topic, then what?
OUTER::.:send_one($_);
Yu
Larry Wall wrote:
On Sun, Dec 05, 2004 at 12:05:46AM +, Matthew Walton wrote:
: I'm sorry, but from a C++ background, overriding postcircumfix:<( )>
: feels far more natural to me than setting 'is default' on some method.
That only works for disambiguation if you know which .() to call in
th
Larry Wall <[EMAIL PROTECTED]> wrote:
> Also says maybe you could attach a block to a hash or array to
> define what subscripting does. Hmm.
That's...wow.
class Patient {
my DBI::Connection $db;
my Patient @byid[Int $id] {
select_patients("SELECT * FROM patients WHERE patientid
On Tue 07 Dec 2004 05:28, Andy Lester <[EMAIL PROTECTED]> wrote:
> I think even better than
>
> ok( $expr, "name" );
>
> or
>
> ok( $expr, "comment" );
>
> is
>
> ok( $expr, "label" );
or ok ($expr, "indicator");
or ok ($expr, "tag");
for me the name/comment/label/tag/indicator/... is
Matt Fowles <[EMAIL PROTECTED]> wrote:
>internal exception clean up
> James deBoer submitted a patch that cleans up internal exception output.
> Then later he submitted a second better version of the patch. Warnock
> applies.
From: James deBoer
Date: 03.12.2004
... "I will
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> There is of course a test case. I have mentioned it at least 20 times ;)
>> t/op/gc_13.imc - currently using lexicals.
> $ parrot t/op/gc_13.imc
> 3 * 5 == 15!
> What's broken?
By using lexicals it works now.
> The current delegat
Michael G Schwern wrote:
> On Mon, Dec 06, 2004 at 10:00:32AM -, Clayton, Nik wrote:
>> Then you have one of ok() or ok2() at your disposal. ok()'s first
>> parameter is the code to test. The second parameter is the test name.
>> This is a printf()like format string, and the third and subsequ
Michael G Schwern wrote:
>> An alternative is to drop the ugly ok2() and force the test writer to
>> use:
>>
>> ok(1 == 2, "");
>>
>> I prefer that since I want to make it hard for people to avoid giving
>> a test a name, er, comment.
>
> At the very least some better name than ok2().
Na
Andrew Savige wrote:
> 1) You might be able to steal some implementation ideas from:
>
> http://cutest.sourceforge.net/
>
> This is a very simple C Unit Testing framework.
> In particular, it keeps state in a CuTest struct which is passed
> around as the first (mostly hidden) parameter to most fu
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Further to my last response. If you have things set up so that you can
> return multiple times from the same function invocation then the return
> continuation should have been replaced with a full continuation before
> the first return, so even the first
On Mon, Dec 06, 2004 at 10:28:45PM -0600, Andy Lester wrote:
> I think even better than
>
> ok( $expr, "name" );
>
> or
>
> ok( $expr, "comment" );
>
> is
>
> ok( $expr, "label" );
>
> RJBS points out that "comment" implies "not really worth doing", and I
> still don't like "name" beca
On Tue, Dec 07, 2004 at 09:11:06AM -, Clayton, Nik wrote:
> > At the very least some better name than ok2().
>
> Name suggestions gratefully received. I wanted something short, to make
> it easier than "ok(1 == 1, "");", and ok2() fits in with the historical
> naming of functions like wait(),
On Tue, Dec 07, 2004 at 09:07:36AM -, Clayton, Nik wrote:
> There's no way to tell from the first argument whether or not the second
> argument exists. If it doesn't exist you can't even safely check for its
> existence.
>
> To give a printf() example, something like this:
>
> int n = 42
On Tue, Dec 07, 2004 at 09:21:32AM -, Clayton, Nik wrote:
> Andrew Savige wrote:
> > If so, you better think about it now because it's very hard to retrofit.
>
> Any "Writing thread safe libraries for dummies" texts you could point me
> at?
Apart from the ones that say "run away screaming?"
On Tue, Dec 07, 2004 at 11:46:24AM +, Dominic Mitchell wrote:
> What does it mean to run the test in multiple threads anyway? What are
> those other threads doing? I can see someone running code in a separate
> thread, but I can't imagine running the TAP stuff in more than one
> thread.
Mayb
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Luke Palmer) wrote:
>David Green writes:
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Larry Wall) wrote:
> > >Maybe type parameters are just subscripts? [...]
> > >my Fight %fight does key{Dog;Cat};
> > I like that.
>
>Yeah, me
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Larry Wall) wrote:
>On Mon, Dec 06, 2004 at 03:11:15AM -0700, David Green wrote:
>[snip]
>: I like that.
>: I like that even better.
[etc.]
>Um. You're so very...easy to please... I guess I'm okay with that...
=) But you'll notice we didn't hi
* namespace (class) names are now prepended with a NUL char
* fix globals ops that take a namespace
* some tests in t/pmc/globals.t
.sub Foo
.end
.namespace ["Foo"]
...
can now bew used, The two names don't collide any more.
leo
Michael G Schwern writes:
> On Tue, Dec 07, 2004 at 09:11:06AM -, Clayton, Nik wrote:
> > Name suggestions gratefully received. I wanted something short, to make
> > it easier than "ok(1 == 1, "");", and ok2() fits in with the historical
> > naming of functions like wait(), wait2(), wait3(), w
On Dec 7, 2004, at 4:07 AM, Clayton, Nik wrote:
Michael G Schwern wrote:
On Mon, Dec 06, 2004 at 10:00:32AM -, Clayton, Nik wrote:
Then you have one of ok() or ok2() at your disposal. ok()'s first
parameter is the code to test. The second parameter is the test
name.
This is a printf()like for
I've added a few ops and methods:
* pow MMD function and opcodes
* hash vtable and opcode
Both aren't yet implemented in classes/*
The "new_extended" opcode and vtable got renamed to the more appropriate
"instantiate". classes/complex.pmc has an implementation of this method,
the default is a fal
I don't really agree that "comment" implies "not really worth doing". I
think
those inclined to not put a name/comment/label on their test will not
do it
whatever we end up calling it. IMO the only way to get people to do it
would
be to make it required, and I don't think that is a good idea.
I
If a name is stored into a namespace that starts with two underscores,
the method cache is invalidated now.
The follwing program runs now as expected:
.sub main @MAIN
.local pmc o, cl
newclass cl, "Foo"
subclass cl, cl, "Bar"
$I0 = typeof cl
o = new $I0
print o
$P0 = g
>[Matt wrote:]
>>I can't get TCL to `make', on the most recent CVS checkout:
>>
>>[EMAIL PROTECTED] ~/personal/devel/parrot $ cd languages/tcl
>>[EMAIL PROTECTED] ~/personal/devel/parrot/languages/tcl $ make
>>make: *** No rule to make target `lib/commands/join.imc', needed by
>>`lib/tcllib.imc'.
Leopold Toetsch wrote:
The current delegation internals are not likely a good match for
languages like Python or Ruby. I see such languages as implementing
their own semantics for classes, and Parrot limiting its knowledge to
methods like findmeth and invoke.
Another good reason to use pmc->vtabl
Leopold Toetsch wrote:
I've added a few ops and methods:
* pow MMD function and opcodes
* hash vtable and opcode
Both aren't yet implemented in classes/*
The "new_extended" opcode and vtable got renamed to the more appropriate
"instantiate". classes/complex.pmc has an implementation of this method
Leo~
Yup.
From: James deBoer <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Date: Sat, 04 Dec 2004 15:50:36 -0500
Subject: Re: [perl #32769] [PATCH] Standardizes and improves the
formatting of internal_exception() calls
Matt
On Tue, 7 Dec 2004 09:23:34 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wro
On Tue, Dec 07, 2004 at 09:33:40AM -0500, Matthew Zimmerman wrote:
Check out the readme - you need to build PGE first, as it's not
built as part of the default parrot build.
>From the top level parrot directory, (cd compilers/pge && make)
>
> [EMAIL PROTECTED] ~/personal/devel/parrot $ ./parro
On Tue, 7 Dec 2004 00:39:08 -0800, Brent 'Dax' Royal-Gordon
<[EMAIL PROTECTED]> wrote:
> Larry Wall <[EMAIL PROTECTED]> wrote:
> > Also says maybe you could attach a block to a hash or array to
> > define what subscripting does. Hmm.
>
> That's...wow.
>
> class Patient {
> my DBI::Connection
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Excellent!
Welcome.
> Question: what is the difference (conceptually) between "new" and
> "instantiate"? If they are different, these differences should be
> highlighted. If not, the opcode should be named the same in both cases.
$ perldoc -F ops/pmc.ops
Matthew Zimmerman <[EMAIL PROTECTED]> wrote:
> That compiled. I'm getting errors about PGE at runtime, followed by a
> segfault, but I guess that may be my problem:
The build of PGE isn't fully integrated.
$ cd compilers/pge ; make
should do it.
leo
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Another good reason to use pmc->vtable->fine_method in *all* lookups. So
>> the PMC has full control over the dispatch.
> How does one lookup the C method? That will remain a
> VTABLE, entry right?
Yes of course.
> All *external*
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Leo~
> Yup.
> From: James deBoer <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Date: Sat, 04 Dec 2004 15:50:36 -0500
> Subject: Re: [perl #32769] [PATCH] Standardizes and improves the
> formatting of internal_exception() calls
Is missing here. I'd appreci
On Mon, Dec 06, 2004 at 10:28:45PM -0600, Andy Lester wrote:
> I think even better than
>
> ok( $expr, "name" );
> or
> ok( $expr, "comment" );
> is
> ok( $expr, "label" );
>
> RJBS points out that "comment" implies "not really worth doing", and I
> still don't like "name" because it impli
Is there is anything in the Test::* hierarchy that allows callbacks to
be triggered on test failures? It would be nice to pass a sub that
automatically dies on warnings, prints stack traces, cleans up temp
files (or preserves them) or any of a number of things that I'd like to
be able to handle.
> Changing the subject slightly, is there any guidance on what people
> should write in the name/comment/label?
>
> I ask because several times I've been puzzled by a test failure
> where the message printed is ambiguous. Compare these two:
>
> not ok 42 - is red
>
> not ok 42 - sho
On Tue, Dec 07, 2004 at 12:48:01PM +, Tim Bunce ([EMAIL PROTECTED]) wrote:
> I ask because several times I've been puzzled by a test failure
> where the message printed is ambiguous. Compare these two:
>
> not ok 42 - is red
>
> not ok 42 - should be red
I always write tests and
On Tue, Dec 07, 2004 at 09:32:37AM -0800, Ovid ([EMAIL PROTECTED]) wrote:
> Is there is anything in the Test::* hierarchy that allows callbacks to
> be triggered on test failures? It would be nice to pass a sub that
> automatically dies on warnings, prints stack traces, cleans up temp
> files (or
--- Tim Bunce <[EMAIL PROTECTED]> wrote:
> Changing the subject slightly, is there any guidance on what people
> should write in the name/comment/label?
>
> I ask because several times I've been puzzled by a test failure
> where the message printed is ambiguous. Compare these two:
>
> not o
--- Andy Lester <[EMAIL PROTECTED]> wrote:
> Q&D way would be to confess.
>
> is( $nstooges, 3 ) or confess;
Yes, that works, but when I am doing heavy development on a bunch of
new code, it's nice to have generic hooks in place to handle such
issues even if I don't know before hand which tests
According to S12, it is possible to supply the object layout to bless(),
like so:
$object = $class.bless(:CREATE[:repr] :k1($v1) :k2($v2))
But in the section "Introspection", "layout" is a class trait. Does this
mean that classes have a default layout that can be overriden for
individual object
On Tue, 2004-12-07 at 18:07 +0100, Leopold Toetsch wrote:
> > From: James deBoer <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
> > Date: Sat, 04 Dec 2004 15:50:36 -0500
> > Subject: Re: [perl #32769] [PATCH] Standardizes and improves the
> > formatting of internal_exception() calls
>
> Is missing
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
Another good reason to use pmc->vtable->fine_method in *all* lookups. So
the PMC has full control over the dispatch.
How does one lookup the C method? That will remain a
VTABLE, entry right?
Yes of course.
So *all*
On Tue, Dec 07, 2004 at 09:32:37AM -0800, Ovid wrote:
> Is there is anything in the Test::* hierarchy that allows callbacks to
> be triggered on test failures? It would be nice to pass a sub that
> automatically dies on warnings, prints stack traces, cleans up temp
> files (or preserves them) or
I'm wondering if I'm the only one who would love to see
Devel::Cover::Regex? Many (most?) perl programs are pretty regex
heavy, and if we are honest with ourselves, we have to admit that each
regex is actually a program in itself. You can try to throw lots of
inputs at it and hope that you we
I'm reviewing the updated S05 (2 Dec 2004) and ran across this
in the "Hypothetical Variables" section:
# Pairs of repeated captures can be bound to hashes:
/ % := [ () = (\N+) ]* /
Actually, I see three captures there, so should this instead read...?
/ % := [ («ident») = (\
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Tuesday 07 December 2004 20:33, Kevin Scaldeferri wrote:
> I'm wondering if I'm the only one who would love to see
> Devel::Cover::Regex? Many (most?) perl programs are pretty regex
> heavy, and if we are honest with ourselves, we have to admit that ea
On Mon, 06 Dec 2004 12:22:22 GMT, Smylers <[EMAIL PROTECTED]> wrote:
David Green writes:
I guess we could always use prepend/append, pull/pop.
No! C and C are a well-defined pair, not just in Perl, for
dealing with stacks; we should keep those as they are. (And no
synonyms, before somebody sugges
> I'm wondering if I'm the only one who would love to see
> Devel::Cover::Regex? [...] I think this would be a very useful
> extension to Devel::Cover, although I imagine that it's pretty tricky
> to do. Even figuring out how to display the results might be tough
> to do well.
It's not a solution
On Tue, Dec 07, 2004 at 09:32:37AM -0800, Ovid wrote:
> Is there is anything in the Test::* hierarchy that allows callbacks to
> be triggered on test failures? It would be nice to pass a sub that
> automatically dies on warnings, prints stack traces, cleans up temp
> files (or preserves them) or a
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>
>> Further to my last response. If you have things set up so that you can
>> return multiple times from the same function invocation then the return
>> continuation should have been replaced with a full continu
I thought some of you might find this of interest and then I realized
that a Test::Cookbook might be useful. Here's a problem I recently
faced and how I solved it:
Problem:
POD is incomplete in a module but you still want to test POD coverage
with something like Test::Pod::Coverage::all_pod_cove
> > > I hope you're not emulating Test::More's exit code == # of
> > > tests failed "feature" that I'm planning on getting rid of.
> >
> > Right now that's exactly what I'm doing. The test suite for libtap
> > consists of a series of Test::More test files and a series of C files that
> > try and
On Tue, Dec 07, 2004 at 01:46:26PM -0800, Ovid wrote:
> I thought some of you might find this of interest and then I realized
> that a Test::Cookbook might be useful.
There is a Test::FAQ sitting unreleased in the Test-Simple repo.
http://svn.schwern.org/svn/CPAN/Test-Simple/trunk/lib/Test/FAQ.p
In S12, I see examples like:
role Pet[Type $petfood = TableScraps] {
method feed (::($petfood) $food) {...}
}
I assume that means lexicals declared as part of a parametric
specialization declaration block thingy are only visible within that
scope, like a formal subroutine parameter list?
--- "Clayton, Nik" wrote:
> Andrew Savige wrote:
> > 2) A uniform mechanism for test programs to handle command line
> > arguments would be nice. For example:
> >
> > int main(int argc, char* argv[])
> > {
> > tap_init(argc, argv); /* mythical new tap function */ // ...
> > }
> >
> > So
--- muppet wrote:
> writing your own printf-style macros is actually a very common idiom
> for getting around this sort of technical problem. they, of course,
> raise the further problem that GCC's vararg macros are not portable,
> and C99's vararg macros are not yet universally supported.
Ag
On Dec 6, 2004, at 6:27 PM, Matt Fowles wrote:
getters and setters
John Siracusa wanted to know if Perl 6 would allow one to expose a
member variable to the outside world, but then later intercept
assignments to it without actually having to switch to using
getters and
setters i
Matt Diephouse <[EMAIL PROTECTED]> wrote:
> On Tue, 7 Dec 2004 00:39:08 -0800, Brent 'Dax' Royal-Gordon
> > my Patient @byid[Int $id] {
> > select_patients("SELECT * FROM patients WHERE patientid = ?",
> > $id)[0];
> > }
> > multi my Patient %byname{String $last} {
> >
--- /-\ wrote:
> In an attempt to do varargs ok() without the magical __VA_ARGS__,
> I've come up with two little example solutions shown below.
> Improvements welcome.
Sorry, but curiosity got the better of me and I took a look at how
the very widely used and portable C++ ACE library does it.
Th
Ashley Winters writes:
> In S12, I see examples like:
>
> role Pet[Type $petfood = TableScraps] {
> method feed (::($petfood) $food) {...}
> }
>
> I assume that means lexicals declared as part of a parametric
> specialization declaration block thingy are only visible within that
> scope,
On Tue, Dec 07, 2004 at 12:11:18PM -0700, Patrick R. Michaud wrote:
: I'm reviewing the updated S05 (2 Dec 2004) and ran across this
: in the "Hypothetical Variables" section:
:
: # Pairs of repeated captures can be bound to hashes:
:
: / % := [ () = (\N+) ]* /
:
: Actually, I see th
62 matches
Mail list logo
