It is still using sendmail though I am working on a Net::SMTP version for
the next release. If you can give me a few days I'll have it up on CPAN.
Thanks for volunteering to contribute.
Zach
On 1/23/02 7:15 PM, "Melvin Smith" <[EMAIL PROTECTED]> wrote:
>
>> different colors mean. There are als
>different colors mean. There are also no clients for windows or other rare
>OS's now. It would be great if we could get one going. I'll do the best that
>I can to help get it setup.
I remember trying a month or so ago and it appeared that the Tinderbox
module used sendmail wrapper for sending t
I just wanted to give everyone a quick summary of the status of tinderbox
and bonsai. Tinderbox is up and running at tinderbox.perl.org. If people
would like, I can configure a little bot for #parrot so that it will let
everyone know if the tinderbox state changes (but won't annoy people in
other
> "Larry" == Larry Wall <[EMAIL PROTECTED]> writes:
Larry> I think our terminology is getting sloppy here. What do you mean by
Larry> "inherit from that method"? If the derived method overrides the base
Larry> method, it will manage its own resources, and doesn't need the base
Larry> method
Chris Dale writes:
: Does the alias operator, C<< -> >>, work for C blocks too?
:
: if $a * $b / $c + $d -> $abcd { ... }
:
: Where $abcd would be lexically scoped to the if block and else block,
: if defined. I expect it could be used with any block statement,
: since Apoc 4
On Wed, Jan 23, 2002 at 06:06:00PM +0200, Kai Henningsen wrote:
> People do get confused sometimes.
I'm confused as to why this is still on p6i. Followups to alt.usage.german?
Thanks.
--
DESPAIR:
It's Always Darkest Just Before it Gets Pitch Black
>Damian Conway [mailto:[EMAIL PROTECTED]] wrote:
>
>You *could* instead consider reversing the arguments to all the list
>manipulation operators:
>
> @result = map @data { mapping() }
> @result = grep @data { selector() };
> @result = sort @data { comparison() };
> @result
Does the alias operator, C<< -> >>, work for C blocks too?
if $a * $b / $c + $d -> $abcd { ... }
Where $abcd would be lexically scoped to the if block and else block,
if defined. I expect it could be used with any block statement,
since Apoc 4 demonstrates it with for, g
Graham Barr wrote:
>
> On Wed, Jan 23, 2002 at 02:25:35PM -0800, Glenn Linderman wrote:
> > I think you just said the same thing I did. To be more explicit, using
> > the terminology you seem to want to use, I'll point out that I was only
> > talking about the case of an inherited method, not a
At 05:01 PM 1/23/2002 -0600, Jonathan Scott Duff wrote:
>On Wed, Jan 23, 2002 at 02:45:21PM -0800, Glenn Linderman wrote:
> > Final seems to be a way of sealing off a class or method from future
> > inheritance. Generally, the arguments I've seen on OO lists seem to
> > indicate that regardless o
On Wed, Jan 23, 2002 at 02:45:21PM -0800, Glenn Linderman wrote:
> Final seems to be a way of sealing off a class or method from future
> inheritance. Generally, the arguments I've seen on OO lists seem to
> indicate that regardless of how omniscient the original designer is,
> someone will get a
At 02:45 PM 1/23/2002 -0800, Glenn Linderman wrote:
>Melvin Smith wrote:
> > Referring to final, private, etc. modifiers that you can use in C++/Java
> > whenever you don't want someone reimplementing or overriding something.
>
>final and private are completely different concepts as I understand
>
> [final, private]
I detest what these modifiers have done to me
in the past. They seem very unperlish to me.
> I think our terminology is getting sloppy here.
Ok, I (think I) understand. It's simple:
If you declare a derived method, then preconditions
and postconditions may or may not be inherited, and
independently, the code may or may not be inherited.
By default, the conditions are inherited and th
On Wed, Jan 23, 2002 at 02:25:35PM -0800, Glenn Linderman wrote:
> I think you just said the same thing I did. To be more explicit, using
> the terminology you seem to want to use, I'll point out that I was only
> talking about the case of an inherited method, not a _replacement_
> method. In ot
Melvin Smith wrote:
>
> > > If you wouldn't want the base implementation to be ignore there is usually
> > > some mechanism in C++ and Java for this, how it applies to Perl6 I'm not
> > > sure.
> >
> >I'm not sure either. In fact, I'm not sure what you mean by this
> >sentence at all. If it matt
At 02:25 PM 1/23/2002 -0800, Glenn Linderman wrote:
>Melvin Smith wrote:
> > I'm not comfortable with this sort of concept. Typically "inheritance" is
> > going to either take the base implementation or _replace_ the
> implementation.
> > The replacement can decide to {call|ignore} the base metho
Melvin Smith wrote:
>
> >Methinks (that's me, not you) that if me thinks (that's you, not me)
> >that my argument is an argument *for* it being pretty odd *not* to
> >inherit them, that there is an assumption by me or me (that's one or the
> >other of us) that is clearly wrong about the way inher
David Whipp writes:
: Peter Haworth [mailto:[EMAIL PROTECTED]] wrote:
: > This is all very sensible, and I completely agree with it.
: > However, don't we
: > need some restrictions on what can go in PRE and POST blocks
: > to ensure that they are still valid in inherited methods?
:
:
: There'
>Methinks (that's me, not you) that if me thinks (that's you, not me)
>that my argument is an argument *for* it being pretty odd *not* to
>inherit them, that there is an assumption by me or me (that's one or the
>other of us) that is clearly wrong about the way inheritance of methods
>(should) wo
At 01:43 PM 1/23/2002 -0800, you wrote:
>i need help on making it into an auction that will
>work.
Ok I thought so.
You might try [EMAIL PROTECTED] for some beginner
tips but I doubt you want to submit a whole script, maybe
rephrase your stuff into specific problems you are having.
Good luck,
Me wrote:
>
> > The problem I see with inheriting subblocks such as
> > FIRST/LAST/etc, is that they are tied in with the logic
> > ... of their enclosing block...
>
> Surely this is an argument *for* it being pretty odd
> *not* to inherit them.
>
> Let's say you add a LAST block to a method. I
On Wed, Jan 23, 2002 at 01:39:09PM -0800, frank crowley wrote:
:
:see attached file.
Hi frank,
This mailing list is not designed to help folks get their Perl 5
programs working. EverySoft, the company that built the program you
attatched has their own online forum for helping you.
Home Page:
At 01:39 PM 1/23/2002 -0800, frank crowley wrote:
>see attached file.
>
>
>=
>frank crowley
What is it that you wanted us to see?
-Melvin
Me writes:
: > The problem I see with inheriting subblocks such as
: > FIRST/LAST/etc, is that they are tied in with the logic
: > ... of their enclosing block...
:
: Surely this is an argument *for* it being pretty odd
: *not* to inherit them.
:
: Let's say you add a LAST block to a method. In
see attached file.
=
frank crowley
__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
#!/usr/bin/perl
use vars qw(%config %category %form);
use strict;
#-
From: David Whipp [mailto:[EMAIL PROTECTED]]
> Peter Haworth [mailto:[EMAIL PROTECTED]] wrote:
> > This is all very sensible, and I completely agree with it.
> > However, don't we
> > need some restrictions on what can go in PRE and POST blocks
> > to ensure that they are still valid in inherite
From: Me [mailto:[EMAIL PROTECTED]]
>
> > The problem I see with inheriting subblocks such as
> > FIRST/LAST/etc, is that they are tied in with the logic
> > ... of their enclosing block...
>
> Surely this is an argument *for* it being pretty odd
> *not* to inherit them.
>
> Let's say you add a
> The problem I see with inheriting subblocks such as
> FIRST/LAST/etc, is that they are tied in with the logic
> ... of their enclosing block...
Surely this is an argument *for* it being pretty odd
*not* to inherit them.
Let's say you add a LAST block to a method. In the
LAST block you write cl
[EMAIL PROTECTED] (Russ Allbery) wrote on 22.01.02 in
<[EMAIL PROTECTED]>:
> Kai Henningsen <[EMAIL PROTECTED]> writes:
>
> > A case that (in a slightly different context) recently came up on
> > alt.usage.german (I don't remember if this particular point was made,
> > but it belongs):
>
> > "b
Ok, here is the updated schemepair-patch.
The diff is agains a fresh update of anoncvs and should hopefully apply
clean.
A Pair is implemented as an array with exact 2 elements. This elements
may be PMC values, especially other Pairs. The car-element is index 0,
the cdr-element is index 1.
Li
Casey West:
# On Wed, Jan 23, 2002 at 01:45:44PM -0600, Jonathan Scott Duff wrote:
# :
# :On Wed, Jan 23, 2002 at 11:50:54AM +, Tim Bunce wrote:
# :> Early on in the life of Perl 5 Larry adopted the convention that
# :> subroutines that Perl calls automatically for you should have
# :> all-cap
On Wed, Jan 23, 2002 at 03:21:37PM -0500, Casey West wrote:
:
:On Wed, Jan 23, 2002 at 01:45:44PM -0600, Jonathan Scott Duff wrote:
::
::On Wed, Jan 23, 2002 at 11:50:54AM +, Tim Bunce wrote:
::> Early on in the life of Perl 5 Larry adopted the convention that
::> subroutines that Perl calls a
On Wed, Jan 23, 2002 at 01:45:44PM -0600, Jonathan Scott Duff wrote:
:
:On Wed, Jan 23, 2002 at 11:50:54AM +, Tim Bunce wrote:
:> Early on in the life of Perl 5 Larry adopted the convention that
:> subroutines that Perl calls automatically for you should have
:> all-caps names[*].
:
:Not early
Modified version of last patch. Fixed in case -f flag wasn't provided a
file or "-" arg.
-Melvin
Index: test_main.c
===
RCS file: /cvs/public/parrot/test_main.c,v
retrieving revision 1.36
diff -u -r1.36 test_main.c
--- test_main.c
Eek, don't apply that, I see a bug, I'll post a new one in a sec.
-Melvin
At 02:52 PM 1/23/2002 -0500, Melvin Smith wrote:
>test_main needed an overhaul on options handling, and if/then/else was
>breeding like rabbits. This one is 41 lines shorter and easier to read.
>
>Please test before I commi
test_main needed an overhaul on options handling, and if/then/else was
breeding like rabbits. This one is 41 lines shorter and easier to read.
Please test before I commit.
-Melvin
Index: test_main.c
===
RCS file: /cvs/public/parro
On Wed, Jan 23, 2002 at 11:50:54AM +, Tim Bunce wrote:
> Early on in the life of Perl 5 Larry adopted the convention that
> subroutines that Perl calls automatically for you should have
> all-caps names[*].
Not early enough to catch import() though. Oh well ... Perl 6 will
fix that. (For va
Peter Haworth [mailto:[EMAIL PROTECTED]] wrote:
> This is all very sensible, and I completely agree with it.
> However, don't we
> need some restrictions on what can go in PRE and POST blocks
> to ensure that they are still valid in inherited methods?
There's another issue: sometimes we don't
On Tue, 22 Jan 2002 10:03:08 -0800 (PST), Larry Wall wrote:
> At the moment, I see this:
>
> -2. PRE in order, inherited, no side effects
> -1. FIRST in order
> 0. inline code normal flow
> 1. CATCH, CONTROLsingular
>
Early on in the life of Perl 5 Larry adopted the convention that
subroutines that Perl calls automatically for you should have
all-caps names[*].
I'm not uncomfortable with the apparent try/CATCH inconsistency.
I suspect that having CATCH etc. be lowercase would create a greater
inconsistency in
41 matches
Mail list logo
