> And when your user does want to, essentially say "Nah, you screwed up
> designing
> that object protocol, children shouldn't've been protected." it's the work of
> a
> moment to write:
>
>thing.send(:children, *args)
I told you I'm still learning. I hadn't gotten to that part of the Pickax
HaloO,
Larry Wall wrote:
At the moment, I think the weakest word choice is "subtype".
People from certain cultures will confuse subtypes with subclasses.
Not to mention submethods and subroutines!
The notion of constraints or limitations is already conveyed by
"where", and some subtypes may
HaloO,
Larry Wall wrote:
On Wed, Oct 26, 2005 at 04:56:23PM -0600, Luke Palmer wrote:
: > Then ^T $x binds T to the kind of $x. And $x.kind == $y.kind asks
: > if two objects are of the same type,
:
: Don't you mean $x.kind eqv $y.kind?
I start to dislike the eqv name as generic value compar
On Fri, Nov 04, 2005 at 08:14:11PM +0100, TSa wrote:
: HaloO,
:
: Larry Wall wrote:
: >On Tue, Oct 25, 2005 at 10:25:48PM -0600, Luke Palmer wrote:
: >: Yeah, I didn't really follow his argument on that one. I, too, think
: >: that the one() junction in general is silly, especially for types.
: >
On Fri, Nov 04, 2005 at 12:37:04PM +0100, TSa wrote:
: The above also describes my perception of the $. twigil notation which
: are variables bound through the invocant(s). My mental picture beeing
: one where a method is instanciated as a not yet invoked sub after selecting
: the target code body
"Joshua Isom" <[EMAIL PROTECTED]> wrote:
But why should the result be an unportable/undocumented parrot op? If
parrot's aiming for portability, so long as external libraries aren't
used, shouldn't parrot treat code the same way for all platforms?
Otherwise, each compiler for parrot would have
On Nov 4, 2005, at 18:24, Joshua Isom wrote:
[ please top-post ]
But why should the result be an unportable/undocumented parrot op? If
parrot's aiming for portability, so long as external libraries aren't
used, shouldn't parrot treat code the same way for all platforms?
Otherwise, each com
On Nov 4, 2005, at 12:06, Leopold Toetsch wrote:
The opcode is currently implemented as $1 = 0.0 - $2; But
this is not the same as $1 = -$2 in the case of $2 being 0.0. The
former gives 0.0, the version with negate gives -0.0.
Implemented now including an additional test for the Float PMC (
Pete Krawczyk <[EMAIL PROTECTED]> writes:
> Does anyone have a better way of checking whether an object is blessed
> that's backportable through core?
I recently used UNIVERSAL::isa($ref, 'UNIVERSAL') for this purpose.
It was good enough for me, but I have not considered how generic it
may be
On Fri, 2005-11-04 at 22:53 +0100, A. Pagaltzis wrote:
> b) Who cares? We just want to know whether calling ->isa() is
>safe, and UNIVERSAL::can answers that handily.
But it's *wrong* and you oughtn't ever use it where someone else might
see it and think that it's okay, because it's *wrong* a
* Ricardo SIGNES <[EMAIL PROTECTED]> [2005-11-03 19:20]:
> * Pete Krawczyk <[EMAIL PROTECTED]> [2005-11-03T12:46:48]
> >
> > The solution I see is to make sure the object can() isa(),
> > thus avoiding the die in the process:
> >
>
> It was using ->isa instead of UNIVERSAL::isa because isa might
I was building a custom test harness and wanted to capture diagnostic
messages produced by a few venerable Test::* modules. Unfortunately
Test::Harness::Straps redirects only reads from stdout when capturing
the output of .t files.
- As far as I can tell, Test::* modules send diagnostic info t
On Fri, 2005-11-04 at 21:49 +0100, Tels wrote:
> Not sure if a ref() check will suffice, but you could also always call:
>
> $object->can();
>
> if it is not defined, it would use UNIVERSAL::can, otherwise the overriden
> one. Or do I miss something?
There are two caveats. First, if $ob
Subject: Re: Test::More behavior issue with Devel::Cover + patch
From: Tels <[EMAIL PROTECTED]>
Date: Fri, 4 Nov 2005 21:49:49 +0100
}Not sure if a ref() check will suffice, but you could also always call:
}
} $object->can();
}
}if it is not defined, it would use UNIVERSAL::can, other
Subject: Re: Test::More behavior issue with Devel::Cover + patch
From: chromatic <[EMAIL PROTECTED]>
Date: Fri, 04 Nov 2005 12:59:14 -0800
}First, if $object is a class name, it may succeed.
If $object is a class name in this case, the !ref($object) in the code
will catch it and guide it away fr
Rob Kinyon <[EMAIL PROTECTED]> writes:
> On 11/4/05, Michele Dondi <[EMAIL PROTECTED]> wrote:
>> I'm still convinced my remark _partly_ applies in the sense that the
>> overall impression is that a vast majority of most common needs is
>> addressed by a *subset* of the current features and trying
A05 currently says:
The first space in
/[:w foo bar]/
matches \s* before "foo". That's usually what you want,
but if it's not what you want, you have a little problem.
Unfortunately you can't just say:
/[:wfoo bar]/
That won't work because it'll look for
On Fri, Nov 04, 2005 at 11:31:59AM -0800, Larry Wall wrote:
> On Fri, Nov 04, 2005 at 09:53:07AM -0600, Patrick R. Michaud wrote:
> : Quick summary: I'm thinking that \n should be defined as
> : the equivalent of
> :
> : rule nl { [ \015\012 | <[\015\012\f\x85\x{2028}\x{2029}]> ]: }
>
> Tha
Juerd <[EMAIL PROTECTED]> writes:
> Michele Dondi skribis 2005-11-04 14:58 (+0100):
>> Let me explain: we all know that Perl5 has a very simple parameter
>> passing mechanism for subs and an even more rudimentary
>> {prototyping,signature} mechanism that one actually seldom uses.
>
> It is unused
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Friday 04 November 2005 21:39, Pete Krawczyk wrote:
> Subject: Re: Test::More behavior issue with Devel::Cover + patch
> From: Ricardo SIGNES <[EMAIL PROTECTED]>
> Date: Thu, 3 Nov 2005 13:14:34 -0500
>
> }It was using ->isa instead of UNIVERSAL::isa be
Subject: Re: Test::More behavior issue with Devel::Cover + patch
From: Ricardo SIGNES <[EMAIL PROTECTED]>
Date: Thu, 3 Nov 2005 13:14:34 -0500
}It was using ->isa instead of UNIVERSAL::isa because isa might be
}overridden. Surely the same could apply to ->can.
I've been thinking about it, and it
On Fri, Nov 04, 2005 at 09:53:07AM -0600, Patrick R. Michaud wrote:
> I'm of the opinion that the sequence "\015\012" should always
> be treated as a single newline, in which case the last
> expression above would not match because the target string contains
> only two newlines. But I want to chec
On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote:
> If roles are interfaces, do we want any class that provides an interface
> consistent with a role to implicitly do the role? That is, if a class
> fulfills all of the interface requirements of a role without actually
> saying it does the
On Fri, Nov 04, 2005 at 09:53:07AM -0600, Patrick R. Michaud wrote:
: Synopsis 5 says that "C<\n> now matches a logical (platform independent)
: newline not just C<\012>". But the devil is in the details, and I'm
: wanting confirmation (or discussion) of the details on \n so I can
: implement it
On Fri, 2005-11-04 at 04:14 -0800, Nick Glencross wrote:
> As hinted in an earlier email, I'd like to propose the addition of a
> return type to the new_callback signature. This will add consistency,
> and prevent breakage when we support other NCI backends.
Does this need documentation?
-- c
But why should the result be an unportable/undocumented parrot op? If
parrot's aiming for portability, so long as external libraries aren't
used, shouldn't parrot treat code the same way for all platforms?
Otherwise, each compiler for parrot would have to add in code to find
out the size of i
HaloO,
Larry Wall wrote:
On Tue, Oct 25, 2005 at 10:25:48PM -0600, Luke Palmer wrote:
: Yeah, I didn't really follow his argument on that one. I, too, think
: that the one() junction in general is silly, especially for types.
Well, I think it's silly too. I'm just trying to see if we need to
# New Ticket Created by jerry gay
# Please include the string: [perl #37611]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37611 >
it's been noticed that there are a number of languages that have been
left unmaintained fo
On Fri, Nov 04, 2005 at 03:49:05PM +0100, Juerd wrote:
> sub dosomething { $^a blah $^b }
I think the $^ variables are only allowed in bare (or ->) blocks. (As a
guard against san.. er, madness.)
--
Ilmari Vacklin (wolverian)
On 11/4/05, Austin Frank <[EMAIL PROTECTED]> wrote:
> Hello!
>
> If roles are interfaces, do we want any class that provides an interface
> consistent with a role to implicitly do the role? That is, if a class
> fulfills all of the interface requirements of a role without actually
> saying it does
Hello!
If roles are interfaces, do we want any class that provides an interface
consistent with a role to implicitly do the role? That is, if a class
fulfills all of the interface requirements of a role without actually
saying it does the role, does it do the role anyway?
role Documente
Synopsis 5 says that "C<\n> now matches a logical (platform independent)
newline not just C<\012>". But the devil is in the details, and I'm
wanting confirmation (or discussion) of the details on \n so I can
implement it in PGE...
Quick summary: I'm thinking that \n should be defined as
the eq
Here's another update to the ffcall POC that I posted a week or two
ago. It's now got a Configure test to work out which backend to use
(and an --ask option to override).
It still needs more work (which is fine as there's a feature freeze),
and some work on memory allocation and stuff. I also need
On Fri, Nov 04, 2005 at 11:02:42AM -0500, Will Coleda wrote:
> The mail list strips out .t attachments (Robert? is this necessary?)
This was changed on perl5-porters a few weeks ago, and since then I
don't recall seeming a marked increase in troff spam.
--
Paul Johnson - [EMAIL PROTECTED]
http:
On 11/4/05, Michele Dondi <[EMAIL PROTECTED]> wrote:
> I'm still convinced my remark _partly_ applies in the sense that the
> overall impression is that a vast majority of most common needs is
> addressed by a *subset* of the current features and trying to stuff all
> them in has brought in quite a
> It will buy you 400% in saving typing, 4000% in less debubbing and
> 4% in maintainability(==readability).
I think this is the main point here. With @_ and bless() you could do
cool things, but again it happened at the expense of repetition and
all those other buzzwords (maintainability, et
> Rejigging NCI to use the ffcall library
> Nick Glencross wondered about rejigging NCI, the parrot Native Call
> Interface to use the ffcall library. In fact he went so far as to offer
> up a proof of concept implementation. Apparently the ffcall approach
> makes it much easier to write callba
We're long overdue for a status update on the grammar engine
(aka PGE), so here's a quick summary of recent changes and
improvements. My thanks go out to many people on irc #parrot
who have been helping with testing and feature implementations,
and especially particle for the incredible tests he's
>Please refer to attached souce and test case.
Sorry, I miss test case -- attached.
No, it isn't. =)
The mail list strips out .t attachments (Robert? is this necessary?)
Please follow the instructions at http://www.parrotcode.org/
patchfaq.html, or inline the file to the list.
Thanks.
On Nov 4, 2005, at 8:36 AM, Tomo wrote:
Please refer to attached souce and test case.
On Fri, 4 Nov 2005, Juerd wrote:
for simple subs in Perl6 I will probably still use @_
You'd be a fool to do so, with the sole exception of list manipulation,
[snip]
Compare:
sub dosomething { @_[0] blah @_[1] }
sub dosomething ($a, $b) { $a blah $b }
sub dosomething { $^a blah $
The Perl 6 Summarizer skribis 2005-11-04 14:34 (+):
> $_ defaulting for mutating ops
Probably I have not been clear enough about that I no longer think this
is a good idea.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution
Michele Dondi skribis 2005-11-04 14:58 (+0100):
> Let me explain: we all know that Perl5 has a very simple parameter
> passing mechanism for subs and an even more rudimentary
> {prototyping,signature} mechanism that one actually seldom uses.
It is unused because it sucks.
> With this simple mech
The Perl 6 Summary for the week ending 2005-10-30
Hmm... Thursday afternoon and I've only just started writing the
summary... What happened to professionalism? What happened to rigid,
albeit self-imposed deadlines?
Um... I've had a cold. The cats ate my homework.
This week in perl
> $ perl -le '$u=1; ($y=$u*=5)++; print $y'
> 6
It's interesting to note that this parse (due to precedence) as
($y=($u*=5))++, not (($y=$u)*=5)++
This is important for overloaded operators (which are going to become
much easier to do in Perl6). The importance arises if Perl6 allows
assignment to
On Fri, 4 Nov 2005, TSa wrote:
"derived" from C. But Perl's C<++> already allows an extended syntax wrt
that of those other languages, that is: I'm not really sure, but I don't
[snip]
Actually I'm not sure if Perl 6 allows
($u *= 5)++;
Since I wrote "already", I was referring to Perl5..
Nick Glencross (via RT) wrote:
Guys,
As hinted in an earlier email, I'd like to propose the addition of a
return type to the new_callback signature. This will add consistency,
and prevent breakage when we support other NCI backends.
I've also made a change to the 'unhandled signature' which di
.t files seem to be routinely stripped when sending to the list.
If you follow: http://www.parrotcode.org/patchfaq.html, then the
files still won't make it to the list, but they *will* be added to
the generated ticket.
Regards.
On Nov 4, 2005, at 8:58 AM, Leopold Toetsch wrote:
Tomo wro
Matt Fowles (via RT) wrote:
This patch fixes a warning in main.c by removing an unnecessary strdup
and following free. One test fails, t/p6rules/modifiers.t, but I
think it is unrelated.
Good catch. Thanks, applied - r9772.
leo
On Thu, 20 Oct 2005, Nate Wiger wrote:
just to be sure we're on the same page: You say that the thing that
is going to hinder migration to Perl 6 is the fact that it's different
from Perl 5.
Intentionally trite oversimplification. My problem is that it's
different in some ways which are no
Tomo wrote:
Hello,
I enjoy Parrot and tried to write new two opcodes -- suspend and resume.
suspend opcode is to halt interpreter and resume opcode is to restart
interpreter from where it suspended.
Hmm. How does the C opcode execute, when the runloop was left?
Please refer to attached souce
The next release 0.3.1. will happen at Sun 6th. I'll start the release
procedure around 12:00 UTC - please no checkins at all after this time
until further notice.
There is kind of a feature freeze from now on, which means: please make
sure that nothing breaks. Parrot corrently tests 100% on x
# New Ticket Created by Nick Glencross
# Please include the string: [perl #37609]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37609 >
Guys,
As hinted in an earlier email, I'd like to propose the addition of a
return ty
Hello,
I enjoy Parrot and tried to write new two opcodes -- suspend and resume.
suspend opcode is to halt interpreter and resume opcode is to restart
interpreter from where it suspended.
Please refer to attached souce and test case.
Thank you for reading.
#include "parrot/dynext.h"
VERSION = PARR
HaloO,
Luke Palmer wrote:
Well, it's possible that I'm abusing the terms, since I first heard
the terms from you and inferred what they meant.
I'm honoured. Thanks. Please don't get me wrong. I appreciate the
document you wrote. I just want to help with peer reviewing it.
However, there is
HaloO,
Michele Dondi wrote:
And yes: there are lots of languages having (e.g.) a ++ operator, mostly
"derived" from C. But Perl's C<++> already allows an extended syntax wrt
that of those other languages, that is: I'm not really sure, but I don't
think that in C you can do (the equivalent of)
Finally :-)
Leopold Toetsch wrote:
The opcode is currently implemented as $1 = 0.0 - $2; But this
is not the same as $1 = -$2 in the case of $2 being 0.0. The former
gives 0.0, the version with negate gives -0.0.
$ gcc -o neg -g neg.c && ./neg # [1] ppc, x86, amd64
0 - f = 0.00
- f
The opcode is currently implemented as $1 = 0.0 - $2; But
this is not the same as $1 = -$2 in the case of $2 being 0.0. The
former gives 0.0, the version with negate gives -0.0.
$ gcc -o neg -g neg.c && ./neg # [1] ppc, x86, amd64
0 - f = 0.00
- f = -0.00
It looks like JIT/ppc i
On Nov 4, 2005, at 1:26, Luke Palmer wrote:
On 11/3/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Shifting anything by >= the bits of the int isn't portable nor
specified.
Why isn't it specified? It seems to me that it should be zero.
C standard (actually from a draft of C99)
If the v
On Wed, 2 Nov 2005, Rob Kinyon wrote:
I think the difference comes from the Principle of Least Surprise. The
various operators being discussed in this thread are all operators
which are in languages that have common use - C, C++, Java, the .Net
stack, etc. Regexen and the various built-ins are g
On Wed, 2 Nov 2005, John Williams wrote:
surprises including operandless operators. Including mutating operandless
operators. What is s/// after all? Or is there a good reason for an
asymmetry between different classes of operators?
Well, s/// is a term, for one thing.
It is not so much an op
# New Ticket Created by Matt Fowles
# Please include the string: [perl #37604]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37604 >
All~
This patch fixes a warning in main.c by removing an unnecessary strdup
and followi
# New Ticket Created by Matt Fowles
# Please include the string: [perl #37605]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37605 >
All~
This time with the attachment.
Matt
--
"Computer Science is merely the post-Turin
63 matches
Mail list logo
