On Wed, Dec 15, 2004 at 01:06:36PM -, Orton, Yves wrote:
> Primary key fingerprint: B484 04B8 E9D5 93A2 5CA8 F1AA 4F82 E2DC 2C3F
> 3F34
> ==> SKIPPED CHECKING 'Makefile'! (run Makefile.PL to ensure its integrity)
> <===
Ok, talked to Autrijus.
But what's that "SKIPPED CHECKING" th
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
>> Why do we have the special notion of current_object in the first place?
>> Why not just pass all in as P5, P6, ...?
> I agree that this is the way to go. Especially if we have some marker
> somewhere that tells us that we were ca
Sam Ruby <[EMAIL PROTECTED]> wrote:
> I don't understand this. At all. But the test case added to pyclass.t
> (motivated by test 4 in pie/b3.t) only passes if this change to the
> get_repr op is made.
[ ... ]
> -op get_repr(out STR, in PMC) {
> -$1 = $2->vtable->get_repr(interpret
Steve Hay wrote:
> And this program (500,000 small extensions to a string):
>
> my $a = '';
> my $start = time;
> for my $i (1 .. 50) {
> print "$i\n" if $i % 1000 == 0;
> $a .= '.' x 20;
> }
> printf "OK (%d seconds)\n", time - $start;
>
> is even worse: 1 second again on 5.8.6/perl-malloc
Paul Hodges writes:
> That said, it's the strange and usually VERY old script that doesn't
> start with
>
> use strict;
> use warnings;
Moreover, it should be a clue to us that there's a shirt stating:
#!/usr/bin/perl -w
use strict;
Hinting that this is the way you start a perl prog
On Wed, Dec 15, 2004 at 01:06:36PM -, Orton, Yves wrote:
> Also Schwern, ive been trying to get it to build from the zip file linked
> above. The first time I build i get the following test failure:
>
> t\00signature.WARNING: This key is not certified with a
> trusted signature!
--- David Storrs <[EMAIL PROTECTED]> wrote:
> . . . .
> Obviously, however @Larry decide it should be, is the way it'll be
> and nothing I can say will change that.
Au contraire -- that's what this list is for.
State your opinion, man! :)
> That said: this would suck. Badly.
> We should not be
On Dec 15, 2004, at 6:11 PM, Abhijit Mahabal wrote:
David Storrs wrote:
On Dec 15, 2004, at 5:36 PM, Abhijit Mahabal wrote:
I think that "slackness-on-demand" is a better policy than
"strictness-on-demand", but that, again, is just my opinion
Until now, the policy in Perl has always been that
David Storrs wrote:
On Dec 15, 2004, at 5:36 PM, Abhijit Mahabal wrote:
I think that "slackness-on-demand" is a better policy than
"strictness-on-demand", but that, again, is just my opinion
Until now, the policy in Perl has always been that it is as slack and
forgiving as possible, and you
On Dec 15, 2004, at 5:36 PM, Abhijit Mahabal wrote:
I think that "slackness-on-demand" is a better policy than
"strictness-on-demand", but that, again, is just my opinion
Until now, the policy in Perl has always been that it is as slack and
forgiving as possible, and you have to ask if you w
David Storrs wrote:
Incidentally, I just want to go on record as saying that the verbosity
of class declarations in P6 is really starting to skeeve me. I keep
reminding myself that these are the edge cases that are being discussed,
that you don't need all this stuff for the common case (right?)
> Not quite. I'm saying: "Unless you need fork you're probably
> better off using a perl without PERL_IMPLICIT_SYS" [on Win32,
> obviously]. There's no problem with having ithreads enabled;
> it's PERL_IMPLICIT_SYS that requires perl's malloc to be disabled.
Got it. Ok, sorry to be so thick.
> Your patch needs to account for PERL_IMPLICIT_SYS too like
> t/op/fork.t does, as Schwern just pointed out.
Ok, ill look into that test to see how it works.
> I should have mentioned that rather than just "ithreads" in my mail.
> PERL_IMPLCIT_SYS is, in fact, also the reason that I don't bu
Orton, Yves wrote:
>>Your patch needs to account for PERL_IMPLICIT_SYS too like
>>t/op/fork.t does, as Schwern just pointed out.
>>
>>
>
>Ok, ill look into that test to see how it works.
>
>
>
>>I should have mentioned that rather than just "ithreads" in my mail.
>>PERL_IMPLCIT_SYS is, in
Leopold Toetsch writes:
> Why do we have the special notion of current_object in the first place?
> Why not just pass all in as P5, P6, ...?
I agree that this is the way to go. Especially if we have some marker
somewhere that tells us that we were called as a method.
Luke
On Dec 10, 2004, at 11:05 AM, Abhijit Mahabal wrote:
Consider a class (e.g., the hypothetical Geometry::Triangle) that can
have several attributes (side1, side2, side3, angle1, ang_bisector1,
side_bisector, altitude1 and so forth), most of which will not be
needed for most instances of Geometry
Michael G Schwern wrote:
> http://svn.schwern.org/svn/CPAN/Test-Simple/trunk
> or
> svn://svn.schwern.org/CPAN/Test-Simple/trunk
> or
> http://www.pobox.com/~schwern/src/Test-Simple-0.54.tar.gz
> or
> a CPAN near you.
Thanks, bleadperl upgraded (as change #23654).
On Tue, 14 Dec 2004 14:21:40 -0800, Kevin Scaldeferri
<[EMAIL PROTECTED]> wrote:
> On Dec 14, 2004, at 2:10 PM, H.Merijn Brand wrote:
> > Yes. Ditch emacs. It knows only the *wrong* styles.
>
> uh... yeah... okay. You realize elisp is Turing-complete, right?
Um, yeah. Right. My cat is Turing
At 9:31 AM + 12/15/04, Leopold Toetsch via RT wrote:
Dan Sugalski wrote:
Or not. (I've got too many versions of parrot around at the moment) I
see this bug happening against yesterday morning's parrot.
imcc/CVS/Entries shows a date of Mon Dec 13 12:19:33 2004 for reg_alloc.c.
I still can't r
> http://svn.schwern.org/svn/CPAN/Test-Simple/trunk
> or
> svn://svn.schwern.org/CPAN/Test-Simple/trunk
> or
> http://www.pobox.com/~schwern/src/Test-Simple-0.54.tar.gz
> or
> a CPAN near you.
Should the t/fork.t tests should still be skipped on Win32? Win32 Perl has
been able to fork since at lea
Orton, Yves wrote:
>>http://svn.schwern.org/svn/CPAN/Test-Simple/trunk
>>or
>>svn://svn.schwern.org/CPAN/Test-Simple/trunk
>>or
>>http://www.pobox.com/~schwern/src/Test-Simple-0.54.tar.gz
>>or
>>a CPAN near you.
>>
>>
>
>Should the t/fork.t tests should still be skipped on Win32? Win32 Perl ha
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The note here is that Parrot's MMD function signature for binary ops
> doesn't match what Python needs. Parrot is:
> void binary_mmd_op(pmc left, pmc right, pmc dest)
> where Python is:
> pmc dest = left.add(pmc right)
Perl6 allows (according
Orton, Yves wrote:
>>Yves Orton wrote:
>>
>>
>>
http://svn.schwern.org/svn/CPAN/Test-Simple/trunk
or
svn://svn.schwern.org/CPAN/Test-Simple/trunk
or
http://www.pobox.com/~schwern/src/Test-Simple-0.54.tar.gz
or
a CPAN near you.
>>>Should
> Yves Orton wrote:
>
> >>http://svn.schwern.org/svn/CPAN/Test-Simple/trunk
> >>or
> >>svn://svn.schwern.org/CPAN/Test-Simple/trunk
> >>or
> >>http://www.pobox.com/~schwern/src/Test-Simple-0.54.tar.gz
> >>or
> >>a CPAN near you.
> >>
> >>
> >
> >Should the t/fork.t tests should still be skipped on
On Wed, Dec 15, 2004 at 12:23:46PM -, Orton, Yves wrote:
> > http://svn.schwern.org/svn/CPAN/Test-Simple/trunk
> > or
> > svn://svn.schwern.org/CPAN/Test-Simple/trunk
> > or
> > http://www.pobox.com/~schwern/src/Test-Simple-0.54.tar.gz
> > or
> > a CPAN near you.
>
> Should the t/fork.t tests
http://svn.schwern.org/svn/CPAN/Test-Simple/trunk
or
svn://svn.schwern.org/CPAN/Test-Simple/trunk
or
http://www.pobox.com/~schwern/src/Test-Simple-0.54.tar.gz
or
a CPAN near you.
This release is mostly all minor Test::Builder bugs exposed by writing
Test::Legacy. There are two things of note.
*
http://svn.schwern.org/svn/CPAN/Test-Legacy/trunk
or
svn://svn.schwern.org/CPAN/Test-Legacy/trunk
or
http://www.pobox.com/~schwern/src/Test-Legacy-1.2501.tar.gz
or
a CPAN near you.
Test::Legacy is a Test.pm work-alike. It strives to emulate Test.pm as
closely as possible. The difference is it us
# New Ticket Created by Dave Brondsema
# Please include the string: [perl #33043]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33043 >
IRC info (host, channels) should be in the main FAQ, especially since
the IMCC FA
Hi,
I am urgently in need of some study material that deals with using perl in QA
process.
How is functionality testing done using perl.
How is performance testing done using perl.
How does perl help in automation. Please give some examples.
Please let me know if there are any books or tutors th
On Tue, 14 Dec 2004 23:10:51 +0100, H.Merijn Brand <[EMAIL PROTECTED]> wrote:
>
> Yes. Ditch emacs. It knows only the *wrong* styles.
>
Way to totally make a cogent argument. Next I suppose we'll hear about
how the Sun compilers totally pwn gcc2.
--
Shawn Boyette
<[EMAIL PROTECTED]>
H.Merijn Brand wrote:
Just only today I hit an M$Access database with a table named
`./onderw`.`"Bus"; "Taxi"; "Auto"`
My mail client inexplicably just quit. I assume because it was so
disgusted.
--
David Cantrell
# New Ticket Created by Dave Brondsema
# Please include the string: [perl #33044]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33044 >
PDDs 4-6 (maybe more) are not generated properly on parrotcode.org
--
Dave Brond
On Dec 14, 2004, at 2:10 PM, H.Merijn Brand wrote:
On Tue 14 Dec 2004 21:49, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Here's what I have to say about clever bracing/spacing styles.
Your bracing/spacing style should not be a detriment. It should not
be a limitation. If common editors have trou
Dan Sugalski wrote:
Or not. (I've got too many versions of parrot around at the moment) I
see this bug happening against yesterday morning's parrot.
imcc/CVS/Entries shows a date of Mon Dec 13 12:19:33 2004 for reg_alloc.c.
I still can't reproduce it. CVS fetches either to P16 or even P3 for the
Nicu Ionita <[EMAIL PROTECTED]> wrote:
> Hi all,
> I'm trying to compile Parrot on Win XP (with MS Visual C++ authoring edition
> installed) and - after cvs update, nmake realclean, perl Configure.pl -
> nmake works for a while and stops with:
> ...
> astlexer.c
> ast\astlexer.c(1433) : fatal err
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>But that still doesn't solve the problem that a file-handle (after
>>cleaning lexicals) is still in a PMC register, when the C
>>opcode is run.
> True but, and this is the good part, that's not our problem. It is, I
> think, safe to assume that language c
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Below is a rather straightforward patch, but as it represents an
> interface change (albeit a fully backwards compatible one), I thought I
> would post it for discussion.
[ ... ]
> This patch brings Parrot_runops_fromc to parity by providing access to
> thos
37 matches
Mail list logo
