Darren Duncan wrote:
So filter is now my preference for a new name, and if
grep is kept, then that can be an alias for it;
We've also had a policy of removing synonyms (e.g. for/foreach),
so I think we should have only one name for any one function.
Damian
Hi Bernhard,
thanks for adding the codas in the Perl files.
No worries! I actually found some more perl files so will make the
necessary changes when I get the tuits.
Could you also provide a test in t/codingstd/code_coda.t, so that future
Perl files will automatically be checked?
Will do
# New Ticket Created by Dmitry Karasik
# Please include the string: [perl #40360]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40360
dlopen(NULL,...) on linux returns NULL, and consequently dlsym(NULL,...) can be
Darren Duncan writes:
At 6:26 AM +0200 9/19/06, Damian Conway wrote:
... *if* we're going to change it from grep, we ought to change it
to filter.
I agree. So filter is now my preference for a new name, and if
grep is kept, then that can be an alias for it;
No: no aliases. Perl
Damian Conway writes:
I don't object in principle to renaming grep to something more self
explanatory (except for the further loss of backwards compatability
and historical Unix reference...though that didn't stop us with
switch vs given ;-)
But while Cswitch had precedence in computer
On 9/19/06, Trey Harris [EMAIL PROTECTED] wrote:
In a message dated Mon, 18 Sep 2006, Darren Duncan writes:
@filtered = @originals.where:{ .foo eq $bar };
Note that this can be written:
@filtered = any(@originals) ~~ { .foo eq $bar};
This doesn't seem to be correct.
According to S03
Smylers wrote:
Damian Conway writes:
I don't object in principle to renaming grep to something more self
explanatory (except for the further loss of backwards compatability
and historical Unix reference...though that didn't stop us with
switch vs given ;-)
But while Cswitch had precedence
Jonathan Lang schrieb:
IMHO, syntax should be left alone until a compelling reason to change
it is found. While I think it would be nice to have a more intuitive
name for grep
What would be the disadvantage of renaming it to a more intuitive name?
I can only see advantages.
I don't think that
Smylers == Smylers [EMAIL PROTECTED] writes:
Smylers No: no aliases. Perl does not have a tradition of these,
except for/foreach. :)
But I agree with the rest of your position.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
merlyn@stonehenge.com
HaloO,
After re-reading about the typing of mixins in
http://www.jot.fm/issues/issue_2004_11/column1
I wonder how the example would look like in Perl6.
Here is what I think it could look like:
role GenEqual
{
method equal( : GenEqual $ -- Bool ) {...}
}
role GenPointMixin
{
has Int $.x;
In a message dated Tue, 19 Sep 2006, Markus Laire writes:
On 9/19/06, Trey Harris [EMAIL PROTECTED] wrote:
In a message dated Mon, 18 Sep 2006, Darren Duncan writes:
@filtered = @originals.where:{ .foo eq $bar };
Note that this can be written:
@filtered = any(@originals) ~~ { .foo eq
Randal L. Schwartz writes:
Smylers == Smylers [EMAIL PROTECTED] writes:
Smylers No: no aliases. Perl does not have a tradition of these,
except for/foreach. :)
I don't reckon one instance is enough to be labelled a tradition!
(Um ... actually I forgot about that one. But if I had
On Tue, Sep 19, 2006 at 04:38:38PM +0200, Thomas Wittek wrote:
Jonathan Lang schrieb:
IMHO, syntax should be left alone until a compelling reason to change
it is found. While I think it would be nice to have a more intuitive
name for grep
What would be the disadvantage of renaming it to a
As a random alternative, I note that Ruby's analog to grep is called
find_all (though it also has a grep that behaves differently from
Perl's). Personally, I'm not enamored of filter because it has
connotations of removal...
On 9/19/06, Jonathan Scott Duff [EMAIL PROTECTED] wrote:
On Tue, Sep
What happens to a program that creates a thread with a shared variable
between it and the parent, and then the parent modifies the class from
which the variable derives? Does the shared variable pick up the type
change? Does the thread see this change?
Smylers wrote:
Randal L. Schwartz writes:
Smylers == Smylers [EMAIL PROTECTED] writes:
Smylers No: no aliases. Perl does not have a tradition of these,
except for/foreach. :)
I don't reckon one instance is enough to be labelled a tradition!
(Um ... actually I forgot about that one. But
(by the way, newbies don't use grep because list transforms confuse and
intimidate, not because of the name).
I dispute that. List transforms and grep are wholly separate beast,
having nothing to do with each other besides the fact that the list
transform idiom happens to use grep. It also
Mark J. Reed wrote:
(by the way, newbies don't use grep because list transforms confuse and
intimidate, not because of the name).
I dispute that. List transforms and grep are wholly separate beast,
This was a minor side-comment. Let's stay focused and not rat-hole on
our respective
From: [EMAIL PROTECTED]
Date: Tue, 19 Sep 2006 14:26:30 -0400
As a random alternative, I note that Ruby's analog to grep is called
find_all (though it also has a grep that behaves differently from
Perl's). Personally, I'm not enamored of filter because it has
connotations of
Jonathan Scott Duff wrote:
On Tue, Sep 19, 2006 at 04:38:38PM +0200, Thomas Wittek wrote:
Jonathan Lang schrieb:
IMHO, syntax should be left alone until a compelling reason to change
it is found. While I think it would be nice to have a more intuitive
name for grep
What would be the
On 9/19/06, Aaron Sherman [EMAIL PROTECTED] wrote:
This was a minor side-comment. Let's stay focused and not rat-hole on
our respective definitions of list transform.
Fair enough. Sorry for the distraction. To return to the topic at
hand (STAY ON TARGET! STAY ON TARGET!), so far we have
On 9/19/06, Bob Rogers [EMAIL PROTECTED] wrote:
Hmm. Is this because Perl 5 grep can be used to modify a list in place?
Does Perl 6 grep also allow that? The Lisp equivalent is remove-if-not,
which otherwise seems like a perfect description of what Perl grep does.
Except that Perl lists,
At 5:48 PM -0400 9/19/06, Bob Rogers wrote:
From: [EMAIL PROTECTED]
Date: Tue, 19 Sep 2006 14:26:30 -0400
As a random alternative, I note that Ruby's analog to grep is called
find_all (though it also has a grep that behaves differently from
Perl's). Personally, I'm not enamored
Oh, here's a thought ...
In signal processing electronics and such, filters are
often/sometimes named after what they let through. For example,
high pass filter or low pass filter to allow through either high
or low frequencies, for example.
On that note, if this isn't causing another
On Tue, Sep 19, 2006 at 05:38:32PM -0400, Mark J. Reed wrote:
: I have no horse in this race. My personal preference would be to
: leave grep as grep. My second choice is select, which to me is
: more descriptive than filter; it also readily suggests an antonym of
: reject to do a grep -v (cf.
On 9/19/06, Larry Wall [EMAIL PROTECTED] wrote:
But which *ect do we call the one that returns both? One would like to
be able to say:
@stuff.direct(
{ .wanted } == my @accepted;
default == my @rejected;
);
Well, sure, but at that point you've moved beyond the
Larry Wall wrote:
Mark J. Reed wrote:
: I have no horse in this race. My personal preference would be to
: leave grep as grep. My second choice is select, which to me is
: more descriptive than filter; it also readily suggests an antonym of
: reject to do a grep -v (cf. if ! vs unless). But
I envision a select, reject, and partition, where
@a.partition($foo)
Returns the logical equivalent of
[EMAIL PROTECTED]($foo), @a.select($foo)]
But only executes $foo once per item. In fact. I'd expect partition
to be the base op and select and reject to be defined as
partition()[1] and
[EMAIL PROTECTED] wrote:
I envision a select, reject, and partition, where
@a.partition($foo)
Returns the logical equivalent of
[EMAIL PROTECTED]($foo), @a.select($foo)]
But only executes $foo once per item. In fact. I'd expect partition
to be the base op and select and reject to be defined
Jonathan Lang wrote:
Larry Wall wrote:
Mark J. Reed wrote:
: I have no horse in this race. My personal preference would be to
: leave grep as grep. My second choice is select, which to me is
: more descriptive than filter; it also readily suggests an antonym of
: reject to do a grep -v (cf.
On Tue, Sep 19, 2006 at 04:39:35PM -0700, Jonathan Lang wrote:
Anyway, it's not clear to me that grep always has an exact opposite.
I don't see why it ever wouldn't: you test each item in the list, and
the item either passes or fails. 'select' would filter out the items
that fail the test,
On Tue, Sep 19, 2006 at 07:56:44PM -0400, [EMAIL PROTECTED] wrote:
I envision a select, reject, and partition, where
@a.partition($foo)
Returns the logical equivalent of
[EMAIL PROTECTED]($foo), @a.select($foo)]
But only executes $foo once per item. In fact. I'd expect partition
to
On 9/19/06, via RT Paul Cochrane [EMAIL PROTECTED] wrote:
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40361]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40361
This is a patch of more
Jerry,
firstly, line endings are unrelated to this effort and should be a
separate patch. that's no biggie, and alone wouldn't stop me from
applying.
I can do that in a separate patch if you want. That's not a major
problem, and probably a good idea.
snip - tests and coda
I'd not realised
On 9/19/06, Paul Cochrane [EMAIL PROTECTED] wrote:
firstly, line endings are unrelated to this effort and should be a
separate patch. that's no biggie, and alone wouldn't stop me from
applying.
I can do that in a separate patch if you want. That's not a major
problem, and probably a good
Jerry,
oh, and yes, i believe the shebang should be in all perl files... but
this isn't specified *yet* in pdd07. if you can enter the ticket, that
would be fantastic, and we'll get a ruling from chip.
This is going to sound rather silly, but... how does one enter a new
ticket to RT? I've
On 9/19/06, Paul Cochrane [EMAIL PROTECTED] wrote:
This is going to sound rather silly, but... how does one enter a new
ticket to RT? I've got an account, but can't see anywhere on
rt.perl.org where one can add a new ticket. There's also no help link
I can go to to work out what to do.
Jerry,
all new rt tickets are created via parrotbug. it may not be sexy, but
it's what we've got :-)
I'm not 100% sure if it worked, as parrotbug gave this warning:
Use of uninitialized value in concatenation (.) or string at
./parrotbug line 525, STDIN line 7.
and the ticket doesn't seem to
On 9/19/06, Paul Cochrane [EMAIL PROTECTED] wrote:
Jerry,
all new rt tickets are created via parrotbug. it may not be sexy, but
it's what we've got :-)
I'm not 100% sure if it worked, as parrotbug gave this warning:
Use of uninitialized value in concatenation (.) or string at
./parrotbug
On Tuesday 19 September 2006 07:56, jerry gay wrote:
~ all non-perl test files must have a shebang
i strongly suggest that this be extended to cover all test files.
then, as you say, it can easily be tested, and it's value can be used
in other tests to determine it's file type. if you wish
http://www.parrotcode.org/misc/parrotsketch-logs/irclog.parrotsketch-200609/irclog.parrotsketch.20060918
or, for the browser- or email-client- newline-challenged:
http://xrl.us/rs3n
enjoy.
~jerry
/irclog.parrotsketch.20060919
is more interesting.
Regards,
Bernhard
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40364]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40364
Hi,
This patch changes the line endings of the files listed below from dos to
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #40367]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40367
Some of the SDL examples are still subject of bitrot. Especially the more
Well, I forgot one preliminary:
We need a config test first, if SDL is present and working, which shall
define:
C defines perl5
PARROT_HAS_SDL HAS_SDL
PARROT_HAS_SDL_imageHAS_SDL_image
(It's not given that libSDL_image is present, *if* libSDL is
I just recently got interested in Perl 6 (within the past two months), and I
found that reading the book was a good kick-start. Sure, lots of stuff has
changed, but many of the general ideas still seem to hold true.
Michael
On 9/18/06, Agent Zhang [EMAIL PROTECTED] wrote:
On 9/19/06, [EMAIL
Michael Snoyman wrote:
I just recently got interested in Perl 6 (within the past two
months), and I found that reading the book was a good kick-start.
Sure, lots of stuff has changed, but many of the general ideas still
seem to hold true.
Yes, the book is still an OK primer on the high-level
On 9/19/06, Aaron Sherman [EMAIL PROTECTED] wrote:
Yes, the book is still an OK primer on the high-level concepts, it just
needs to be made clear that on both the Parrot and Perl sides, it's
quite a bit out of date. Even the names have changed in some cases (e.g.
IMCC is now known as PIR).
David == David Cantrell [EMAIL PROTECTED] writes:
But don't throw out the simplicity of CGI.pm's basic task handling: parsing
the incoming parameters (including file upload), and generating sticky forms
and other common HTML elements.
David That's two tasks. It should be two modules.
No,
(Randal L. Schwartz) schrieb:
David == David Cantrell [EMAIL PROTECTED] writes:
David That's two tasks. It should be two modules.
No, it's an *integrated* task. The form-generation stuff needs tight
coupling
with the getting (and setting) of the incoming param values.
A separate module,
Randal L. Schwartz wrote:
David == David Cantrell [EMAIL PROTECTED] writes:
But don't throw out the simplicity of CGI.pm's basic task handling: parsing
the incoming parameters (including file upload), and generating sticky forms
and other common HTML elements.
David
Randal L. Schwartz skribis 2006-09-19 8:16 (-0700):
No, it's an *integrated* task. The form-generation stuff needs tight coupling
with the getting (and setting) of the incoming param values.
Integrated task? Tight coupling? If I didn't know you, I'd immediately
say you have no idea what
Juerd wrote:
It does make sense to have a single toolkit that does all this. It does
not make sense to have a single .pm that does all this. There's
absolutely no need for having all these different tasks in one module.
There's not even any benefit. You can just as well use a couple of
* Randal L. Schwartz merlyn@stonehenge.com [2006-09-19 21:25]:
The form-generation stuff needs tight coupling with the getting
(and setting) of the incoming param values. You couldn't just
use two random modules for that... they'd have to specifically
know about each other and work together.
* Amir E. Aharoni [EMAIL PROTECTED] [2006-09-17 16:25]:
WordPress is an example of a webserver software tool that does
try to produce standard XHTML. It does it by default and very
few bloggers who use it care about it or, for that matter,
notice it.
Psh, whatever. Everyone serves their XHTML
55 matches
Mail list logo
