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
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
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
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
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
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 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
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 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!
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
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
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
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 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
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 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
(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
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
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
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.
-
> 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
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*
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
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:
> >
> >
> >
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
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
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
>
# 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_
# 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
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
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
===
# 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
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
33 matches
Mail list logo
