在 2006/7/12 下午 9:38 時,Chip Salzenberg 寫到:
On Wed, Jul 12, 2006 at 05:29:08PM -0700, [EMAIL PROTECTED] wrote:
* Apply heuristics that tells
.loadlib 'perl6_group' # HLL dynamic PMCs
and
.loadlib 'dynlexpad'# non-HLL dynamic PMCs
apart, by locating the '_group" substring inside
在 2006/7/12 下午 8:16 時,Allison Randal 寫到:
[EMAIL PROTECTED] wrote:
Modified: trunk/languages/perl6/perl6.pir
=
=
--- trunk/languages/perl6/perl6.pir (original)
+++ trunk/languages/perl6/perl6.pir Wed Jul 12 17
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #39807]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39807 >
[I looked in the RT database and didn't find a ticket for
this (known) issue, so I
At 7:25 PM +0300 7/12/06, Yuval Kogman wrote:
Over at #perl6 we had a short discussion on =:=, ===, and ~~, mostly raised by
ajs's discussion on Str items and ===.
Coincidentally, I raised almost the same questions there a week
earlier, and had a brief discussion with audreyt about it, though
David Landgren writes:
> Expected and actual has a long tradition in scientific endeavour,
They strike me as the teams most intuitively recognizable and least open
to misinterpretation.
Smylers
On 7/12/06, Smylers <[EMAIL PROTECTED]> wrote:
David Landgren writes:
> Expected and actual has a long tradition in scientific endeavour,
And are still sucky as they are different lengths meaning the two
outputs are offset on the screen making it harder to see the failure.
They strike me as
demerphq writes:
> On 7/12/06, Smylers <[EMAIL PROTECTED]> wrote:
>
> > David Landgren writes:
> >
> > > Expected and actual has a long tradition in scientific endeavour,
>
> And are still sucky as they are different lengths meaning the two
> outputs are offset on the screen making it harder to
On 7/13/06, Smylers <[EMAIL PROTECTED]> wrote:
demerphq writes:
> On 7/12/06, Smylers <[EMAIL PROTECTED]> wrote:
>
> > David Landgren writes:
> >
> > > Expected and actual has a long tradition in scientific endeavour,
>
> And are still sucky as they are different lengths meaning the two
> output
demerphq wrote:
On 7/12/06, Smylers <[EMAIL PROTECTED]> wrote:
David Landgren writes:
> Expected and actual has a long tradition in scientific endeavour,
And are still sucky as they are different lengths meaning the two
outputs are offset on the screen making it harder to see the failure.
Y
On 7/13/06, David Landgren <[EMAIL PROTECTED]> wrote:
demerphq wrote:
> On 7/12/06, Smylers <[EMAIL PROTECTED]> wrote:
>> David Landgren writes:
>>
>> > Expected and actual has a long tradition in scientific endeavour,
>
> And are still sucky as they are different lengths meaning the two
> output
demerphq wrote:
On 7/13/06, David Landgren <[EMAIL PROTECTED]> wrote:
[...]
>> They strike me as the teams most intuitively recognizable and least
open
>> to misinterpretation.
I choose to disagree.
If so i think you might be disagreing with yourself. :-)
That was a quote of Smylers agre
David Wheeler writes:
> On Jul 12, 2006, at 03:41, Gabor Szabo wrote:
>
> >perl -MModule -e'print $Module::VERSION'
>
> I have this alias set up:
>
> function pv () { perl -M$1 -le "print $1->VERSION"; }
Along similar lines, I have this one-liner as ~/bin/pmv:
#! /bin/sh
perl -m$1 -le 'prin
On 12/07/06, Smylers <[EMAIL PROTECTED]> wrote:
David Wheeler writes:
> On Jul 12, 2006, at 03:41, Gabor Szabo wrote:
>
> >perl -MModule -e'print $Module::VERSION'
>
> I have this alias set up:
>
> function pv () { perl -M$1 -le "print $1->VERSION"; }
Along similar lines, I have this one-line
On 7/13/06, Fergal Daly <[EMAIL PROTECTED]> wrote:
I could change it so that it tries to figure out whether it's being
used for real or not and disable the END block code but that's stress
and hassle. As a module author, as far as I'm concerned, if MakeMaker
can figure out my version then my job
On Thu, 13 Jul 2006 14:29:38 +0300, "Gabor Szabo" <[EMAIL PROTECTED]> wrote:
> On 7/13/06, Fergal Daly <[EMAIL PROTECTED]> wrote:
> > I could change it so that it tries to figure out whether it's being
> > used for real or not and disable the END block code but that's stress
> > and hassle. As a m
Fergal Daly writes:
> On 12/07/06, Smylers <[EMAIL PROTECTED]> wrote:
>
> > I have this one-liner as ~/bin/pmv:
> >
> > #! /bin/sh
> > perl -m$1 -le 'print '$1'->VERSION || die "No VERSION in '$1'\n"'
>
> These all fail for modules that do interesting things. For example
> Test::NoWarnings perf
On 13/07/06, Smylers <[EMAIL PROTECTED]> wrote:
Fergal Daly writes:
> On 12/07/06, Smylers <[EMAIL PROTECTED]> wrote:
>
> > I have this one-liner as ~/bin/pmv:
> >
> > #! /bin/sh
> > perl -m$1 -le 'print '$1'->VERSION || die "No VERSION in '$1'\n"'
>
> These all fail for modules that do interest
On Wed, 2006-07-12 at 17:52 -0700, Larry Wall wrote:
> On Wed, Jul 12, 2006 at 12:51:57PM -0400, Aaron Sherman wrote:
> : I would assume that all classes automatically define:
> :
> : multi submethod *infix: ($self: $?CLASS) { $self }
>
> Hmm, "as" is really only intended for explicit type mutat
On Thu, Jul 13, 2006 at 00:55:30 -0700, Darren Duncan wrote:
> So, in the general case, it would seem best if the binary operator === was
> just an ordinary method that each class provides, rather than requiring
> classes to defined a .id. Or
> in addition to this to help with performance, a .
Here's some questions I'd like to pose to the group:
(1) What key features you think should be in some sort of FOSS tool
suite involving a Perl 6 oriented IDE, RCP (rich client platform),
document processor, and so on.
(2) What major existing components would you recommend?
(3) How would you arc
Folks,
I'd like to get some insights into how to implement a PL/Parrot for
PostgreSQL. For those unfamiliar, PostgreSQL is an extensible DBMS
which allows people to plug in procedural languages. I'm thinking
that Parrot could provide a way to plug in lots and lots of
these--including Perl6--with
# New Ticket Created by Jerry Gay
# Please include the string: [perl #39823]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39823 >
=head1 NAME
tools/dev/run_indent.pl - Check indentation in C files
=head1 SYNOPSIS
%
# New Ticket Created by Jerry Gay
# Please include the string: [perl #39824]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39824 >
=head1 NAME
tools/dev/check_source_standards.pl - Check conformancs of C source
code to PD
Audrey has asked me to split S29 AKA Perl6/Spec/Functions.pod up due to
its rapidly expanding size. The strategy that she suggested is basically
what I'm leaning toward, but I wanted to get feedback (esp. from Larry
and other Synopsians).
I want to be clear, I'm not asking for help coming up with
While I agree with David, this argument is almost completely pointless.
Nobody reads the raw TAP output! If you want your TAP harness to
display "got" and "expected", let it. If you want it so say "foo" and
"bar" (so they line up :-P), then great.
The actual TAP is going to live in a protoc
Jonathan Rockway wrote:
> While I agree with David, this argument is almost completely pointless.
> Nobody reads the raw TAP output!
are you serious? listen to what they people here are saying - we _all_
read the raw TAP output, all the time, and not because we're TAP
developers interested in th
On 13/07/06, Geoffrey Young <[EMAIL PROTECTED]> wrote:
Jonathan Rockway wrote:
> While I agree with David, this argument is almost completely pointless.
> Nobody reads the raw TAP output!
are you serious? listen to what they people here are saying - we _all_
read the raw TAP output, all the tim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Moin,
On Thursday 13 July 2006 08:26, Adam Kennedy wrote:
> Tels wrote:
> > The DB backend shouldn't matter at all, it should be transparent and be
> > switchable without any noticable change at the front.
>
> Yep, right with you. Hence DBIx::Class.
On Thursday 13 July 2006 08:52, Jonathan Rockway wrote:
> Nobody reads the raw TAP output!
I would love to see your TAP diagnostic parser and reporter. I, unfortunately,
don't have one and must read the raw TAP output myself. :)
-- c
* Tels <[EMAIL PROTECTED]> [2006-07-12 19:00]:
> Using SQLite or similiar is what really creates the problems
> with CPANTS - you cant just access the raw database without the
> front-end.
All you need is one binary from www.sqlite.org – I don’t follow
why this is a problem. And I certainly prefe
A. Pagaltzis wrote:
> * Tels <[EMAIL PROTECTED]> [2006-07-12 19:00]:
>> Using SQLite or similiar is what really creates the problems
>> with CPANTS - you cant just access the raw database without the
>> front-end.
>
> All you need is one binary from www.sqlite.org – I don’t follow
> why this is
Thanks, applied (with a MANIFEST update) as r13280
# New Ticket Created by Jerry Gay
# Please include the string: [perl #39826]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39826 >
there are many scripts (ack reports 189, below) that contain 'perl -w'.
D:\usr\local\par
On Thu, Jul 13, 2006 at 02:29:38PM +0300, Gabor Szabo wrote:
> On 7/13/06, Fergal Daly <[EMAIL PROTECTED]> wrote:
> >I could change it so that it tries to figure out whether it's being
> >used for real or not and disable the END block code but that's stress
> >and hassle. As a module author, as far
* Smylers <[EMAIL PROTECTED]> [2006-07-13 10:50]:
> When you first suggested those terms earlier in this thread I
> did find that I had to slow down when reading them to work out
> which is which.
>
> I had no such slowdown on reading David Landgren's mail.
Same here.
> I think it's just that "w
On Jul 13, 2006, at 05:56, Fergal Daly wrote:
That's funny, it looks like I did put some code in to disable the END
block if it's "require"d rather than "use"d. Turns out I did this to
make MakeMaker happy, so MakeMaker does actually do a full require,
Well, IIRC, both MakeMaker and Module::Bu
# New Ticket Created by Will Coleda
# Please include the string: [perl #39827]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39827 >
Need a C-level routine to determine if a given path is an absolute
path on the current
So, Larry assisted by Audrey explained the purpose of === vs eqv vs
=:=.
It makes sense now, but I still feel that as far as ergonomics go
this is not perfect. Then again, I trust that Larry's opinion is
probably better and at the very least more likely to be accepted
than mine ;-) [1]
So, this
* Michael Peters <[EMAIL PROTECTED]> [2006-07-13 19:50]:
> And if you use DBD::SQLite you don't even need that. I has
> everything you'd need.
Actually that’s more of a hassle. If you install DBI::Shell you
get close, but having to specify a DSN is still a hassle. With
the SQLite binary you just s
are you serious? listen to what they people here are saying - we _all_
read the raw TAP output, all the time, and not because we're TAP
developers interested in the underlying implementations. as users, the
(current) raw TAP diagnostics helps us figure out why a test failed, and
if it doesn't
I asked "How does a programming language stagnate?" a couple of weeks ago.
Peter Scott responded with wisdom, in particular:
Modules like SUPER and NEXT are pragmata designed to make Perl behave
the way
we (for large values of "we") think it should have behaved to begin with.
Attribut
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Moin,
On Thursday 13 July 2006 19:40, A. Pagaltzis wrote:
> * Tels <[EMAIL PROTECTED]> [2006-07-12 19:00]:
> > Using SQLite or similiar is what really creates the problems
> > with CPANTS - you cant just access the raw database without the
> > front-e
* Tels <[EMAIL PROTECTED]> [2006-07-13 21:50]:
> On Thursday 13 July 2006 19:40, A. Pagaltzis wrote:
> > * Tels <[EMAIL PROTECTED]> [2006-07-12 19:00]:
> > > Using SQLite or similiar is what really creates the
> > > problems with CPANTS - you cant just access the raw
> > > database without the fron
On 7/13/06, Jonathan Rockway <[EMAIL PROTECTED]> wrote:
> are you serious? listen to what they people here are saying - we _all_
> read the raw TAP output, all the time, and not because we're TAP
> developers interested in the underlying implementations. as users, the
> (current) raw TAP diagn
* chromatic <[EMAIL PROTECTED]> [2006-07-13 21:10]:
> Why is there not a Bundle::PerlPlus (and yes, I've lathered up
> my yak with that name) that downloads and installs the modules
> that should have been in the box?
I thought that’s called “the core distribution.” NEXT is already
in there. So is
在 2006/7/13 上午 3:35 時,Audrey Tang 寫到:
If Leo's comment about .loadlib being compile-and-runtime is
already implemented, then you should be able to eliminate that
runtime call to the loadlib opcode too.
Indeed, though as I tested it (both at the time of the commit and
at this moment), that
wow, my code is being used in a flame war! *blush* :-)
Sorry! I didn't want this to come across as a flame. I just wanted to
make sure I (and other people ;) have the distinction between TAP and
uses of TAP clear in their minds. The sooner we can agree over what the
protocol should call "g
I'm told that I did a terrible job of making my point in the === thread,
and nothingmuch asked me on IRC to re-state my concerns. I'll do so
briefly, and then give examples. Please do have a look at the examples,
just in case I'm not clear.
Overview:
~~ is great. It matches on all kinds of useful
On Thu, Jul 13, 2006 at 09:32:08PM +0300, Yuval Kogman wrote:
: [1] My preferred ergonomics:
:
: 1. eqv goes away
: 2. what was eqv is renamed to ===
: 3. === becomes =:=, which has a "constant" feel to it
: 4. =:= is rarely useful IMHO, so you can just type
: variabl
On Thu, Jul 13, 2006 at 12:50:19PM -0700, Larry Wall wrote:
: Then $a eqv $b and $a leg $b both just default to a signature that selects
: everything.
Though arguably P5's string-forcing semantics should be C and the
polymorphic semantics should probably be C.
Larry
On Thu, Jul 13, 2006 at 15:44:33 -0400, Aaron Sherman wrote:
> Now, let's look at some of the good that ~~ does for us:
>
> $a ~~ "Some string" # sameness
> $a ~~ 5 # sameness
> $a ~~ ->{...} # test
> $a ~~ /.../ # regex matching
>
> That's g
On Thursday 13 July 2006 13:32, A. Pagaltzis wrote:
> I thought that’s called “the core distribution.” NEXT is already
> in there. So is List::Util (a big deal for me).
Maybe for Perl 5.9.x... but how long will it be between someone
realizing "Hey, SUPER should have been in Perl 5 from the start
Wheeling back over to the extra diagnostic output that Schwern
originally proposed, I agree with Adam in that any additions we make
to TAP must be completely backward-compatible.
I hereby recant my burblings. After reading Adam's replies, I think I
might have pushed the thread in the wrong direct
On 7/13/06, chromatic <[EMAIL PROTECTED]> wrote:
Why is there not a Bundle::PerlPlus (and yes, I've lathered up my yak with
that name) that downloads and installs the modules that should have been in
the box?
Sure, a Bundle::PerlPlus would be fun. Installing it wouldn't be.
Perl module instal
* chromatic <[EMAIL PROTECTED]> [2006-07-13 23:25]:
> On Thursday 13 July 2006 13:32, A. Pagaltzis wrote:
> >I thought that’s called “the core distribution.” NEXT is
> >already in there. So is List::Util (a big deal for me).
>
> Maybe for Perl 5.9.x... but how long will it be between someone
> rea
On Thursday 13 July 2006 15:40, A. Pagaltzis wrote:
> People would install these modules anyway even if they
> never get into core or a Bundle::PerlPlus, if they knew that
> these modules are important to them in the first place.
That's really the point. Instead of saying, "Go install X and Y an
* chromatic <[EMAIL PROTECTED]> [2006-07-14 00:55]:
> Sure, but it's only one thing people need to remember. One
> thing is easier than N things, especially as N changes every
> time the core changes.
Yes, I agree. Don’t get me wrong, I’m not saying Bundle::PerlPlus
is a bad idea (though in addin
David Wheeler wrote:
On Jul 13, 2006, at 05:56, Fergal Daly wrote:
That's funny, it looks like I did put some code in to disable the END
block if it's "require"d rather than "use"d. Turns out I did this to
make MakeMaker happy, so MakeMaker does actually do a full require,
Well, IIRC, both Ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Heya Tim,
afte seeing the recent discussion about CPANDB and CPAN::Index, I don't
think I want to work on that project anymore for two reasons:
* announced to early - now everybody tells me how I have to implement it and
why my way wont work
* ano
Whoops, re-opening.
This apparently isn't quite ready yet, as converting tcl to use the new syntax
results in a nearly-
complete fail of the test suite.
Per Audrey: .loadlib 'dynlexpad' stopped working, because Parrot_register_HLL
breaks on non-
HLL-group .so files.
# New Ticket Created by Will Coleda
# Please include the string: [perl #39831]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39831 >
$ ../../parrot ../../compilers/tge/tgc.pir --output=src/grammar/
post2pir.pir src/gramma
At 5:36 PM +0300 7/13/06, Yuval Kogman wrote:
> User defined types can choose on their own whether to override
=== and/or .id or not, and they would use their own knowledge of
their internal structures to do an appropriate
deep comparison. There is no need to try to generate some kind of
uni
On 7/13/06, Yuval Kogman wrote:
So, Larry assisted by Audrey explained the purpose of === vs eqv vs =:=.
It makes sense now, but I still feel that as far as ergonomics go
this is not perfect.
I think I understand it... (my only quibble with the syntax is that
=== and eqv look like spin-offs o
David Green wrote:
I think I understand it... (my only quibble with the syntax is that
=== and eqv look like spin-offs of == and eq, but I don't know what
to suggest instead (we're running short of combinations of = and : !))
Agreed.
So there are three basic kinds of comparison: whether the v
On Thu, Jul 13, 2006 at 12:50:19 -0700, Larry Wall wrote:
> On Thu, Jul 13, 2006 at 09:32:08PM +0300, Yuval Kogman wrote:
> : [1] My preferred ergonomics:
> :
> : 1. eqv goes away
> : 2. what was eqv is renamed to ===
> : 3. === becomes =:=, which has a "constant" feel to it
> : 4.
Yuval Kogman wrote:
Jonathan Lang wrote:
> Apparently, there are _four_ basic kinds of comparison: the ones
> mentioned above, and == (I believe that eq works enough like == that
> whatever can be said about one in relation to ===, =:=, or eqv can be
> said about the other). I'd be quite interes
On Thu, Jul 13, 2006 at 21:55:15 -0700, Jonathan Lang wrote:
> Apparently, there are _four_ basic kinds of comparison: the ones
> mentioned above, and == (I believe that eq works enough like == that
> whatever can be said about one in relation to ===, =:=, or eqv can be
> said about the other). I
At 10:36 PM -0700 7/13/06, Jonathan Lang wrote:
So the purpose of === is to provide a means of comparison that doesn't
implicitly coerce its arguments to a particular type?
Yes, absolutely. The === takes 2 arguments exactly as they are,
without changing anything, and says if they are two appe
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #39833]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39833 >
Namespace support has been added to Tcl, but [rename] doesn't have it
yet. See [proc
> On Thu, 13 Jul 2006 19:36:52 -0400, "Randy W. Sims" <[EMAIL PROTECTED]>
> said:
> David Wheeler wrote:
>> On Jul 13, 2006, at 05:56, Fergal Daly wrote:
>>
>>> That's funny, it looks like I did put some code in to disable the END
>>> block if it's "require"d rather than "use"d. Tu
On 7/14/06, Tels <[EMAIL PROTECTED]> wrote:
afte seeing the recent discussion about CPANDB and CPAN::Index, I don't
think I want to work on that project anymore for two reasons:
Hey Tels,
Please ignore the other people in the thread. Instead spend a little
bit of time to do something simple t
71 matches
Mail list logo