dynclasses/py*.pmc need some work. At the time Sam Ruby created these
PMCs, Parrot didn't provide all the semantics necessary to support
Python. This situation is by far better now but the transition of Parrot
internals isn't yet finished.
Anyway, the following issues are existing (at least):
On Thu, Jun 30, 2005 at 08:03:32AM +0200, demerphq wrote:
> Yitzchak pointed me to this thread. I thought I'd add that
> Data::Dump::Streamer v1.14 has the capability to Dump closures
> properly, that is including bound lexical state.
Interesting. is_deeply() can try to use Data::Dumper::Streamer
Hi,
Yitzchak pointed me to this thread. I thought I'd add that
Data::Dump::Streamer v1.14 has the capability to Dump closures
properly, that is including bound lexical state. (Albeit with a few
minor caveats, its possible to deliberately construct pathological
closures that wont be eval'able, howe
To me Mr. Clean has always been a symbol of facism. It's this big
strong guy who enforces cleanliness using chemicals. How mean is
that?
Whatever.
Perl 6 is all about getting along with others. There is one aspect
of perl 6 that doesn't get along - people who want to write strongly
typed perl 6,
Currently, does this:
sub foo (::T $x, ::T $y) { }
and this:
sub foo (T $x, T $y) { }
Means the same thing, namely
a) if the package T is defined in scope, use that as the
type constraint for $x and $y
b) otherwise, set ::T to be the most immediate common supertype
o
On Wed, Jun 29, 2005 at 03:05:47PM -0400, Vsevolod (Simon) Ilyushchenko wrote:
> I've just stumbled upon Test::WWW::Mechanize and tried to use version
> 1.05_02, but the very first test gave me the following error:
1.06 was just uploaded to CPAN today, but I don't think it fixes your
problem.
ht
Hi,
I've just stumbled upon Test::WWW::Mechanize and tried to use version
1.05_02, but the very first test gave me the following error:
1) /opt/software/perl/lib//Test/WWW/Mechanize.pm:103 - frontPage(MCTests)
You tried to run a test without a plan! Gotta have a plan.
The Test::WWW::Mechaniz
On Wed, Jun 29, 2005 at 09:00:05AM +0100, Clayton, Nik wrote:
> > > homedir_ok() verifies that the home directory for the given
> > > user exists, is owned/group owned by that user, and has a given
> > > set of permissions.
> > >
> > > homedir_ok(name => nik, uid => 1000, gid => 1000, perm =>
On Wed, 2005-06-29 at 10:59 -0400, Matt Fowles wrote:
> Would it be reasonable to not run tests that are known to leave core
> files? I feel like after a successful build there should not be
> evidence like this left around...
People could set ulimit (though we'd have to tell them all to do that
Leo~
On 6/29/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
>
> > Core was generated by `./parrot --gc-debug
> > /home/mfowles/perl6/parrot/t/pmc/io_1.pir'.
>
> Ah. ok. That's a TODO tests that is supposed to fail. It is testing io
> opcodes with undefs and integer PMCs.
>
On Wednesday 29 June 2005 15:24, Matt Fowles wrote:
> t/pmc/io_1.pir
Ah, yes. This is a failing todo test. The useage of IO ops on non IO-PMCs is
not specced yet.
jens
#6 0x08128193 in PIO_putps (interpreter=0x826e050, pmc=0x82a93e8,
s=0x843c7d8) at io/io.c:1011
1006INTVAL
1007PIO_put
Matt Fowles wrote:
Core was generated by `./parrot --gc-debug
/home/mfowles/perl6/parrot/t/pmc/io_1.pir'.
Ah. ok. That's a TODO tests that is supposed to fail. It is testing io
opcodes with undefs and integer PMCs.
As soon as the io opcodes are methods in ParrotIO we get type safety and
ap
Patrick~
On 6/29/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 28, 2005 at 08:11:24PM -0400, Matt Fowles wrote:
> >Parrot Loses with Fedora Core 4
> > Patrick reported that Fedora Core 4 and Parrot don't get along well. Leo
> > suggested a possible solution. No respon
On Tue, Jun 28, 2005 at 08:11:24PM -0400, Matt Fowles wrote:
>Parrot Loses with Fedora Core 4
> Patrick reported that Fedora Core 4 and Parrot don't get along well. Leo
> suggested a possible solution. No response from Patrick.
An update:
Patrick submitted a patch based on Leo's sug
On Tue, Jun 28, 2005 at 11:02:48AM +0200, Gerd Pokorra wrote:
> I am using pugs 6.2.7. Is it already possible to find out if a
> subroutine was called in a void context. Does the want function
> provide this feature.
In the interactive shell you can try it out:
pugs> want
'Void'
However
Jens~
On 6/29/05, Jens Rieks <[EMAIL PROTECTED]> wrote:
> > #13 0x0808588e in main (argc=1, argv=0xb8ac) at imcc/main.c:637
> Can you please run
> print ((char**)0xb8ac)[1]
> to find out which file causes the coredump??
Sure!
> gdb ./parrot core
Core was generated by `./parrot --gc-debu
# New Ticket Created by Will Coleda
# Please include the string: [perl #36424]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36424 >
The wonderful simple grammar that was demo'd at YAPC::NA via demo.pir should
be added
> #13 0x0808588e in main (argc=1, argv=0xb8ac) at imcc/main.c:637
Can you please run
print ((char**)0xb8ac)[1]
to find out which file causes the coredump??
jens
On Wed, 2005-06-29 at 10:01 +, Leopold Toetsch via RT wrote:
> >PARENT_1 # adds attribute 'foo'
> > ^
> > |
> >PARENT_2 # adds attribute 'foo', hiding the inherited one
> > ^
> > |
> > CHILD# adds attribute 'bar'
>
> The first question is of course:
>
Roger Browne (via RT) wrote:
Here's the inheritance hierarchy:
PARENT_1 # adds attribute 'foo'
^
|
PARENT_2 # adds attribute 'foo', hiding the inherited one
^
|
CHILD# adds attribute 'bar'
The first question is of course:
a) should we fully hide PARENT
> On Tue, Jun 28, 2005 at 03:24:51PM +0100, Clayton, Nik wrote:
> > user_ok(name => 'nik', uid => 1000, shell => '/bin/tcsh',
> > 'Check nik\'s account');
>
> My only thought is I would use a hash ref.
>
> user_ok( { name => 'nik', uid => 1000, shell => '/bin/tcsh' },
>
21 matches
Mail list logo
