Luke Palmer <[EMAIL PROTECTED]> wrote:
> Okay, I seriously have to see an example of a submethod in use.
Likewise. As far as I've seen, submethods are a kludge wedged in for
cases where you're actually calling all the way up the inheritence
tree. Personally, I've always thought a "cascade method
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #37430]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37430 >
In r9445 Leo added code to special-case the get_*_keyed_int
and set_*_keyed_int m
Here's a patch to implement the split opcode such that it splits on
strings rather than regular expressions. I've also added a test to
t/op/string.t
Files affected:
M ops/string.ops
M t/op/string.t
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
=== ops/string.ops
===
On 10/12/05, David Landgren <[EMAIL PROTECTED]> wrote:
> Fergal Daly wrote:
> > http://www.nntp.perl.org/group/perl.cpan.testers/257538
> >
> > shows a fail for Test-Benchmark but the fail seems to be caused by
> > CPANPLUS not installing dependencies:
>
> Apparently it's a bug in CPANPLUS that sto
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #37428]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37428 >
- Forwarded message from Nick Glencross <[EMAIL PROTECTED]> -
From: Nick Gle
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #37431]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37431 >
REVISED-REVISED-REVISED
In r9445 Leo added code to special-case the get_*_keyed_
I've added this patch to ticket #32544.
Thanks, Applied.
> [coke - Thu Oct 13 05:20:53 2005]:
>
> Here's a patch to implement the split opcode such that it splits on
> strings rather than regular expressions. I've also added a test to
> t/op/string.t
>
> Files affected:
> M ops/string.ops
>
Patrick R.Michaud (via RT) wrote:
This patch (which replaces the patch I sent earlier in #37430)
adds support for the other *_keyed_int methods (needed for PGE).
The patch also updates the corresponding test in t/pmc/object_meths.t .
Looks good. Just ci it - thanks.
leo
All~
On 10/13/05, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Okay, I seriously have to see an example of a submethod in use.
>
> Likewise. As far as I've seen, submethods are a kludge wedged in for
> cases where you're actually calling all the
On 10/13/05, James E Keenan <[EMAIL PROTECTED]> wrote:
> David Landgren wrote:
> > Fergal Daly wrote:
> >
> >> http://www.nntp.perl.org/group/perl.cpan.testers/257538
> >>
> >> shows a fail for Test-Benchmark but the fail seems to be caused by
> >> CPANPLUS not installing dependencies:
> >
> >
> >
On Oct 13, 2005, at 9:47 AM, Matt Fowles wrote:
On 10/13/05, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
Okay, I seriously have to see an example of a submethod in use.
Likewise. As far as I've seen, submethods are a kludge wedged in for
cases
Folks watching SVN checkins have already seen some patches floating by
with:
"Variable-sized reg frames" in the log head line.
The complete plan is now available at: http://perlcabal.org/~lt/VR.txt
There will be no visible impact on the surface of Parrot, all code will
continue to run, *except*
> I think this is an opportune time for me to express that I think the
> ability to close-source a module is important. I love open source,
> and I couldn't imagine writing anything by myself that I wouldn't
> share. But in order for Perl to be taken seriously as a commercial
> client-side langua
Joshua Hoblitt schrieb:
It looks like the CREDITS file hasn't been getting updated. I'd like
to revise that check-list to:
- add the patch author to CREDITS or update the authors entry in CREDITS
- add correspondence to the bug stating that the patch was applied AND
the svn revision number.
-
On Thu, Oct 13, 2005 at 03:01:29PM -0400, Rob Kinyon wrote:
> > I think this is an opportune time for me to express that I think the
> > ability to close-source a module is important. I love open source,
> > and I couldn't imagine writing anything by myself that I wouldn't
> > share. But in order
HaloO,
Stevan Little wrote:
On Oct 11, 2005, at 8:47 PM, Larry Wall wrote:
You seem to be arguing that a class has no state, but my view is that,
in the abstract, a class encompasses the state of *all* its objects.
It just hasn't picked one particular object to be at the moment.
I love this n
(ref: http://svn.openfoundry.org/pugs/docs/notes/theory.pod)
>theory Ring{::R} {
>multi infix:<+> (R, R --> R) {...}
>multi prefix:<-> (R --> R){...}
>multi infix:<-> (R $x, R $y --> R) { $x + (-$y) }
>multi infix:<*> (R, R --> R) {...}
># on
On Oct 13, 2005, at 6:45 PM, Dave Whipp wrote:
I started thinking about the "in general, unverifiable
programmatically" bit. While obviously true, perhaps we can get
closer than just leaving them as comments. It should be possible to
associate a unit-test-generator with the theory, so I ca
I've sent this before just to Leo, but this time I though it might be
better to send to all people.
I (and I think nobody more) is having malloc library complaining about a
wrong free somewhere. I'm trying to debug it.
In attach you can see the .pir I tried to compile, and the leaks log
file
On Wed, Oct 12, 2005 at 13:08:27 -0700, chromatic wrote:
> Closed classes should not exist.
>
> At least, they should only exist if the person *running* Perl 6 wants
> them to exist -- never if merely the class writer wants to close them.
In theory I agree, and I hope that will be the defacto way
In article <[EMAIL PROTECTED]>, Andy Lester
<[EMAIL PROTECTED]> wrote:
> On Mon, Oct 10, 2005 at 02:52:49PM -0700, chromatic ([EMAIL PROTECTED]) wrote:
> > > I do NOT want to see that sort of thing as patches to Test::Harness.
> > I have a few ideas myself on how to make T::H a little more clean
On Oct 13, 2005, at 4:45 PM, TSa wrote:
No, not that class has no state, but that with the currently
specced classes we have inherited behaviors (class methods) but
they do not inherit the accompanying state (class attributes) as
well. I see this as potentially very problematic.
What
David Storrs wrote:
While I like the idea, I would point out that 1000 tests with randomly
generated data are far less useful than 5 tests chosen to hit boundary
conditions.
I come from a hardware verification background. The trend in this
industry is driven from the fact that the computer
Well, I suspected there would not be much support for my initial
proposal on class methods, but I felt I had to try. Not being the
type of person who gives up easily, I want to revise the proposal
(incorporating some of the ideas in the responses).
I propose that class methods are inheritab
On 10/13/05, John Macdonald <[EMAIL PROTECTED]> wrote:
> Just because you can't make locking perfect does not mean it
> has no value.
Acme::Bleach it is!
On Fri, 2005-10-14 at 02:18 +0200, Yuval Kogman wrote:
> On Wed, Oct 12, 2005 at 13:08:27 -0700, chromatic wrote:
> > Closed classes should not exist.
> >
> > At least, they should only exist if the person *running* Perl 6 wants
> > them to exist -- never if merely the class writer wants to clos
On Thu, Oct 13, 2005 at 06:13:09PM -0700, chromatic wrote:
> I just don't want people who merely write a module or class to be
> able to prevent people who actually use that module or class from
> using, extending, or poking around in it.
Sounds kind of like Linus's opinion of close-source modules
Since this is a community, you can also work with
him to make it all work out.
Shlomi and I have already discussed this.
I don't think anyone should have to get
anyone's permission to play with open source code.
That's exactly right, they don't, and I would never presume to tell
them that
On 14/10/05, Stevan Little <[EMAIL PROTECTED]> wrote:
> So anyway, here are a few ideas, in no particular order:
>
>method bark (::Dog $d:) { ... }
># not sure if this notation is already taken or not
>
>method bark ($Dog $d:) { ... }
># not sure I like this one myself, but to me it
I retract my opposition to "err". After coding this:
try
{
try { path = f.getCanonicalPath(); }
catch (Exception e) { path = f.getAbsolutePath(); }
}
catch (Exception e) { path = f.toString(); }
I am now a convert. To the extent that we are
Hey All,
So, given the abundance of positive responses ;) for my "class
methods don't inherit" proposal, I have decided to withdraw that
proposal (see my last response on the thread). Of course, this means
we now have to work out the details of exactly *how* they get
inherited in all situ
On Thu, 2005-10-13 at 18:36 -0700, Chip Salzenberg wrote:
> On Thu, Oct 13, 2005 at 06:13:09PM -0700, chromatic wrote:
> > I just don't want people who merely write a module or class to be
> > able to prevent people who actually use that module or class from
> > using, extending, or poking around
On 10/13/05, Dave Whipp <[EMAIL PROTECTED]> wrote:
> I started thinking about the "in general, unverifiable programmatically"
> bit. While obviously true, perhaps we can get closer than just leaving
> them as comments. It should be possible to associate a
> unit-test-generator with the theory, so I
33 matches
Mail list logo
