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.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40360 >
dlopen(NULL,...) on linux returns NULL, and consequently dlsym(NULL,...) can be
used t
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 al
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 C had precedence in computer sc
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 C had precedenc
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 t
> "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
http://www.stoneheng
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.
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
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 Tu
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 o
(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 happ
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 definiti
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
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 b
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, un
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 enamor
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 h
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 -
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 "unl
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 part
[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 -
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 t
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 partit
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.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40361 >
This is a patch of more Pe
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.
I'd not realised some of the issues you b
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 got
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. Shou
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, line 7.
and the ticket doesn't seem to have
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 w
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.
# 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 unix.
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #40367]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40367 >
Some of the SDL examples are still subject of bitrot. Especially the more
complex on
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
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 co
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
(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 se
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.
Dav
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 you'
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 [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.
Err, no. They jus
* 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
54 matches
Mail list logo
