Re: [perl #36098] Solaris - Large number of tests fail under jit
On Tue, Oct 04, 2005 at 09:04:57PM -0700, Joshua Hoblitt via RT wrote:
I do not have access to the same machine any longer so I have retested
with solaris 2.8 , gcc 3.2.1 and the 2005-10-05_071500 parrot
snapshot. This fails during make with the following
perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? >> 8;'
dynclasses
make[1]: Entering directory `/tmp/parrot/dynclasses'
perl /tmp/parrot/build_tools/pmc2c.pl --dump matchrange.pmc
Can't write 'classes/default.dump' at /tmp/parrot/build_tools/pmc2c.pl
line 664.
pmc2c dump failed (512)
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/parrot/dynclasses'
make: *** [dynclasses.dummy] Error 2
I do not have time to look at it now but will try to take a look
latter on today or tomorrow.
Peter
> > [psinno - Thu Jun 02 15:56:20 2005]:
> >
> > ---
> > osname= solaris
> > osvers= 2.9
> > arch= sun4-solaris
> > cc= gcc 3.3.1
> > ---
> > Flags:
> > category=core
> > severity=high
> > ack=no
> > ---
> > A large number of tests are failing under jit on solaris but pass
> > using other
> > cores
> >
> > Failed Test Stat Wstat Total Fail Failed List of Failed
> >
> ---
> > imcc/t/reg/spill.t 5 1280 95 55.56% 3 6-9
> > imcc/t/syn/bsr.t1 256131 7.69% 8
> > imcc/t/syn/file.t 4 1024124 33.33% 5-8
> > imcc/t/syn/objects.t3 768113 27.27% 2-3 9
> > imcc/t/syn/pcc.t 27 691247 27 57.45% 1-2 4-7 9 11-27
> > 32-33 40
> > t/dynclass/pyclass.t3 768 63 50.00% 2 5-6
> > t/dynclass/pyfunc.t 4 1024 44 100.00% 1-4
> > t/op/debuginfo.t1 256 81 12.50% 5
> > t/op/gc.t 4 1024194 21.05% 10-11 13-14
> > t/op/interp.t 4 1024114 36.36% 7-10
> > t/op/string_cclass.t6 1536 66 100.00% 1-6
> > t/pmc/coroutine.t 8 2048138 61.54% 1 4 6-10 12
> > t/pmc/delegate.t4 1024 94 44.44% 2 6 8-9
> > t/pmc/eval.t 11 281611 11 100.00% 1-11
> > t/pmc/exception.t 1 256301 3.33% 21
> > t/pmc/hash.t1 256361 2.78% 9
> > t/pmc/mmd.t16 409626 16 61.54% 1-4 7-8 10-17 24-
> > 25
> > t/pmc/namespace.t 2 512142 14.29% 13-14
> > t/pmc/nci.t 8 2048568 14.29% 38-45
> > t/pmc/object-meths.t7 1792287 25.00% 11 13-15 23-24 28
> > t/pmc/objects.t10 256062 10 16.13% 29-31 48-52 55-56
> > t/pmc/pmc.t 1 256231 4.35% 5
> > t/pmc/sub.t14 358451 14 27.45% 3-4 7 17-20 29-34
> > 48
> > t/pmc/sys.t 1 256 11 100.00% 1
> > 5 tests and 68 subtests skipped.
> > Failed 24/126 test scripts, 80.95% okay. 146/2231 subtests failed,
> > 93.46% okay.
> >
> >
> > The failures seem to have a few distinct types
> >
> > 1. Null PMC access
> >
> > t/op/debuginfo.ok 4/8
> > t/op/debuginfo.NOK 5# Failed test
> > (t/op/debuginfo.t at line 116)
> > # 'ok 1
> > # ok 2
> > # ok 3
> > # Null PMC access in find_method()
> > # current instr.: 'Test1 :: foo' pc -1 ((unknown file):-1)
> > # called from Sub 'Test1 :: main' pc -1 ((unknown file):-1)
> > # '
> > # doesn't match '/^ok 1
> > # ok 2
> > # ok 3
> > # Method 'nosuchmethod' not found
> > # current instr.: 'Test1 :: foo' pc (\d+|-1) \(.*?:(\d+|-1)\)
> > # called from Sub 'Test1 :: main' pc (\d+|-1) \(.*?:(\d+|-1)\)$/
> > # '
> > # './parrot -j --gc-debug
> > "/var/tmp/tinder/parrot/t/op/debuginfo_5.pir"' failed with exit code
> > 43
> > t/op/debuginfo.ok 8/8# Looks like you failed 1 test of
> > 8.
> > t/op/debuginfo.dubious
> > Test returned status 1 (wstat 256, 0x100)
> > DIED. FAILED test 5
> > Failed 1/8 tests, 87.50% okay (less 3 skipped tests: 4 okay,
> > 50.00%)
> >
> >
> > 2. Functions not found
> >
> > t/pmc/exceptionok 20/30
> > t/pmc/exceptionNOK 21# Failed test
> > (t/pmc/exception.t at line 460)
> > # got: 'MMD function __add not foundfor types (1, -100)
> > # current instr.: 'b :: b11' pc -1 ((unknown file):-1)
> > # called from Sub 'main' pc -1 ((unknown file):-1)
> > # '
> > # expected: 'ok 1
> > # 99
> > # '
> > # './parrot -j --gc-debug
> > "/var/tmp/tinder/parrot/t/pmc/exception_21.pir"' failed with exit code
> > 1
> > t/pmc/exceptionok 30/30# Looks like you failed 1 test
> > of 30.
> > t/pmc/exceptiondubious
> > Test returned status 1 (wstat 256, 0x100)
> > DIED. FAILED test 21
> > Failed 1/30 tests, 96.67% okay
> >
> > 3. Seg faults
> >
> > 4. No obvious error message but output does not match expected output
> >
> >
> > ---
> > Summary of my parrot 0.2.0 (r0) configuration:
> > configdate='Th
Re: zip: stop when and where?
On Tue, 4 Oct 2005, Eric wrote: I'd just like to say that I find B a bit misleading because you couldn't tell that the first list ended, it could just have undef's at the end. I Well, OTOH undef is now a more complex object than it used to be, so there may be cheap workarounds. Of course one would still like reasonable defaults and dwimmeries on commonly used idioms... Michele -- Darl MacBride, is that you? They said over at Groklaw that the folks at SCO were trying to discredit Open Source. SCO, a company traditionally run by Mormons, but they had to downsize the second m? Well, they still have M for capital. - David Kastrup in comp.text.tex, "Re: Is Kastrup..."
Re: Perl 6 Summary for 2005-09-26 through 2005-10-02
On Oct 5, 2005, at 1:17, Matt Fowles wrote: Here Doc in PIR Will Coleda revived a thread from February about PIR here doc syntax. Looks like the syntax is ok. Jonathan Worthington has already implemented here doc syntax. Data::Escape::String Dislikes Unicode Will noticed that Data::Escape::String doesn't work on Unicode strings. This is fixed. Calling Vtable Functions from PIR Roger Browne found he can no longer call vtable functions from PIR directly. Leo felt that it was no longer necessary, The 'Vtable' function actually was a MMD infix function (__add) - I should have mentioned this in the first place. 'is no longer necessary' isn't quite correct. Usually there is no need to call any of these builtins directly, as Parrot's MMD system handles operator overloading. And finally: the bug is fixed. Thanks for the summary, leo
A listop, a block and a dot
Playing with pugs, I ran into this corner case:
sub f($x) { say $x; }
f {1}.(); # ok, outputs 1
sub f([EMAIL PROTECTED]) { say @_; }
f {1}.(); # outputs block, tries to call a method from the return of say,
dies
Whitespace after f doesn't change the behaviour (in either case). Is this
behaviour a bug in pugs? Should . bind stronger than non-parenthesised
function call regardless of slurpy?
Miro
Re: my $key is sensitive;
Brent 'Dax' Royal-Gordon wrote in perl.perl6.language : > > I would like "is sensitive" to be defined to mean that any data stored > in that variable, at any level of recursion, will be zeroed out as > soon as it is garbage collected. Particular implementations can add > extra features on top of that--such as stopping the VM from swapping > it or even actively encrypting that area of memory--but without a > minimum standard there's no point in supporting the feature at all. That really sounds like an unportable feature that should go in a module. On in many modules (Linux::VolatileVariables, etc etc)
Re: Kwalitee and Perl::Critic
On Oct 4, 2005, at 1:04 PM, Nik Clayton wrote: I don't have strong opinions about this yet, but has anyone else looked at the Perl::Critic suite of modules on CPAN? It occurs to me that: a) Kwalitee metrics could quite easily be implemented as Perl::Critic plugins. b) The plugins that it ships with (based on Perl Best Practices) may form good kwalitee indicators. As a framework, yes, it has potential for being useful for kwalitee metrics. The PPI foundation that Perl::Critic uses is a very powerful tool for parsing Perl without actually running Perl. Some of the plugins would be good for kwalitee, but many of them are just very well-reasoned opinions. I'm a fan of most of PBP, but many of the ideas are too strict to impose on all of CPAN. Things that PPI/Perl::Critic could judge that might lead to quantitative, non-controversial metrics: * are the variables/functions consistently named? (i.e. all of them in_underscore_style or allInCamelCase) * what's the ratio of globals to subroutines? (smaller is better) * is there a SYNOPSIS section and is it valid Perl? * do OO-style modules bless into a hardcoded package or a passed package name? (former kills subclassing) * are there any undeclared, non-core dependencies? * does the module use Perl 5.6.x+ constructs without declaring "use 5.006"? * does the module use platform directory syntax or portable tools? (e.g. File::Spec, Path::Class) All of these would be very hard to judge without parsing the module. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Kwalitee and Perl::Critic
Unless someone wants to start helping implement this right now, I'd ask that you not spend too much time on anything that relates to Kwalitee/PPI integration (which includes Perl::Critic). There's a couple of steps that have to be taken in order to make this happen, and I'm working through them at the moment. I'm hoping to release Perl::Metrics before the end of the month, which will have a ::Critic and ::Kwalitee plugin very very early on. Once that is done, you should have something more concrete to play with in this regard. But there's a lot of stuff that hasn't been released yet. So just hold this thought for a few weeks. Adam K Nik Clayton wrote: I don't have strong opinions about this yet, but has anyone else looked at the Perl::Critic suite of modules on CPAN? It occurs to me that: a) Kwalitee metrics could quite easily be implemented as Perl::Critic plugins. b) The plugins that it ships with (based on Perl Best Practices) may form good kwalitee indicators. N
Re: my $key is sensitive;
Brent, Why not post the original query to p6compiler for their take on it? Carl
Re: A listop, a block and a dot
On 10/4/05, Miroslav Silovic <[EMAIL PROTECTED]> wrote:
> Playing with pugs, I ran into this corner case:
>
> sub f($x) { say $x; }
> f {1}.(); # ok, outputs 1
>
> sub f([EMAIL PROTECTED]) { say @_; }
> f {1}.(); # outputs block, tries to call a method from the return of say,
> dies
>
> Whitespace after f doesn't change the behaviour (in either case). Is this
> behaviour a bug in pugs? Should . bind stronger than non-parenthesised
> function call regardless of slurpy?
I think that's what it should do, yes.
Luke
Re: Kwalitee and Perl::Critic
* Chris Dolan <[EMAIL PROTECTED]> [2005-10-05 12:20]:
> Things that PPI/Perl::Critic could judge that might lead to
> quantitative, non-controversial metrics:
Pretty good suggests, but I think the following may have to be
lessened:
> * what's the ratio of globals to subroutines? (smaller is better)
Does that include file-scoped lexicals? ’Cause in that case I
disagree – I’m just overhauling a module, in which process I’m
also moving it to inside-out object style, and so I’ve got about
20 file-scoped lexical hashes. But that doesn’t at all mean the
code is really full of globals.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
[perl #37354] [PATCH] pcre.t
# New Ticket Created by François PERRAD # Please include the string: [perl #37354] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37354 > This patch updates t/library/pcre.t. 'isnull' becomes 'if_null'. François Perrad pcre.patch2 Description: Binary data
Re: Kwalitee and Perl::Critic
On Oct 5, 2005, at 6:18 AM, A. Pagaltzis wrote: * what's the ratio of globals to subroutines? (smaller is better) Does that include file-scoped lexicals? ’Cause in that case I disagree – I’m just overhauling a module, in which process I’m also moving it to inside-out object style, and so I’ve got about 20 file-scoped lexical hashes. But that doesn’t at all mean the code is really full of globals. My fault for sloppy terminology -- I did not mean to include lexicals. I meant 'use vars qw(...)' and 'our ...' variables specifically. Chris -- Chris Dolan, Software Developer, www.chrisdolan.net Public key: http://www.chrisdolan.net/public.key
Re: A listop, a block and a dot
HaloO,
Luke Palmer wrote:
On 10/4/05, Miroslav Silovic <[EMAIL PROTECTED]> wrote:
Playing with pugs, I ran into this corner case:
sub f($x) { say $x; }
f {1}.(); # ok, outputs 1
IIRC, this puts f into the named unary precedence level
which is below method postfix. Thus we get
(f ({1}.()))
sub f([EMAIL PROTECTED]) { say @_; }
f {1}.(); # outputs block, tries to call a method from the return of say,
dies
Which is because now f is on the listop precedence above method postfix
and the parens are
((f {1}).())
Whitespace after f doesn't change the behaviour (in either case).
You mean in the defining special form? There I think is no
difference between 'sub f(' and 'sub f ('.
Is this
behaviour a bug in pugs? Should . bind stronger than non-parenthesised
function call regardless of slurpy?
I think that's what it should do, yes.
So you mean to lower listop in precedence below method postfix?
BTW, has listop always been top precedence? And where exactly should
it go? Actually there is a precedence level called 'list op (rightward)'
which in my eyes naturally is below comma which in turn is below the
assignment ops.
--
$TSa.greeting := "HaloO"; # mind the echo!
Re: A listop, a block and a dot
On 10/5/05, TSa <[EMAIL PROTECTED]> wrote:
> IIRC, this puts f into the named unary precedence level
> which is below method postfix.
We're trying to stop using the words "below" and "above" for
precedence. Use "looser" and "tighter" instead, as there is not
ambiguity with those.
>(f ({1}.()))
>
>((f {1}).())
Listop application has always had looser precedence than unary op
application. Eg.
% perl -le 'print(length "foo" < 4)'
1
% perl -le 'print 3 < 4'
1
With parentheses:
print((length "foo") < 4)
print(3 < 4)
So this was quite a disturbing bug.
Re: seeing the end of the tunnel
HaloO, Luke Palmer wrote: On 10/1/05, David Storrs <[EMAIL PROTECTED]> wrote: All in all, I think that might just be the end of the tunnel up ahead. Go us for getting here, and loud applause to @Larry for guiding us so well! Applause for p6l for hashing out the issues that we didn't think of. I think this is a good opportunity for me to drop out of the list. Not that I expect anyone to care. Consider this just me talking to myself in public. But since I'm not *doing* anything on Perl6, why should I bother you with ranting about it. I've always taken the 'what type of expression' approach to programming languages and thus have an affinity to type systems and type theory. With 'type' in general and 'data type' in particular beeing too misleading or used in too many different meanings in other programming languages I propose to coin the notion of 'kind' which has the nice double meaning of nice and sort. And as such gives the nice pun Perl 6, the kind language with the two "meanings" Perl 6, a kind of language , the language of kind(ness) Here are attempts to translate this to German Perl 6, die artige Sprache , eine Art Sprache , eine Art-Sprache , eine Artsprache , die Sprache der Art Well, take it or leave it. I recently wrote a "Perl 6 design TODO", which was surprizingly small, which enumerated the things to be done before I considered the design of Perl 6 to be finished. Larry replied with a couple more items. The type system is not on this list, right? -- $TSa.greeting := "HaloO"; # mind the echo!
Re: A listop, a block and a dot
Luke Palmer wrote:
With parentheses:
print((length "foo") < 4)
print(3 < 4)
So this was quite a disturbing bug.
This is now also quite a fixed bug. :-)
However:
f:{1}.()
still parses as
(&f(:{1})).()
as the "adverbial block" form takes precedence. Is that also wrong?
/Autrijus/
Spurious CPAN Tester errors from Sep 23rd to present.
The new version of Test::More from Sep 23rd improved the STDERR output on test failure. Unfortunately, this has accidentally broken Test::Builder::Tester's test_fail function. (and maybe other test-testing modules) http://rt.cpan.org/NoAuth/Bug.html?id=14936 T:B:Tester is used by about 26 other testing modules, and from there it cascades out to 500+ other distributions, including LWP and almost the entire web section of CPAN. A certain unknown percentage of these (probably very low at this point) will be failing spuriously in CPAN tester reports starting at around report number 250,000 upwards... the pattern should look something like this. http://testers.cpan.org/show/Test-SubCalls.html#Test-SubCalls-0.01 It will probably start as a trickle of failures and gradually increase. Please ignore these bad reports. I've contacted Schwern to get that specific change to Test::More backed out ASAP. These problem, if you get any, should go away shortly. Given that the repair alternatives are to backout the Test::More change and increment the T:B:Tester Test::More version to the newest (or at least, NOT the current) or to change all 26 other modules, backing out seems the sanest option at this point Adam K
Re: my $key is sensitive;
On Mon, Oct 03, 2005 at 22:58:28 -0700, Brent 'Dax' Royal-Gordon wrote: > For the last couple days, I've been implementing a cryptographic > cipher framework for Perl 6. (It's in the Pugs repository if you want > to see it.) Dealing with this sort of algorithm has brought forward a > feature that I think Perl 6 and Parrot ought to support. > > Basically, I'd like to be able to mark a variable as "sensitive" or > "secret". This implies that the language should overwrite the memory > it uses before deallocating it, and that if possible it should tell > the virtual memory system to avoid swapping it out. Moreover, it > should probably do so recursively, and to any value that has ever been > stored in the variable. (In essence, the *variable* marks all > *values* it ever contains as sensitive.) This relates to the ideas I had about generalizing the taint mechanism. The idea was basically: every interaction between two pieces of data triggers a multimethod that is the event handler for that interaction With the assumption that static typing will make the calls to these things be compiled only when necessary. Once you have that then you can implement 'is sensitive' as a taint-oriented-role, that installs an event handler for the tainting container and any value, marking a runtime specific flag that means "sensitive". That way the implementation of the role is simple. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: uhm, no, I think I'll sit this one out..: neeyah! pgpWfYlGlm9JS.pgp Description: PGP signature
Re: Exceptuations
On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
> Piers Cawley wrote:
> >>Exactly which exception is continued?
> > The bottommost one. If you want to return to somewhere up its call
> > chain, do:
> >
> > $!.caller(n).continue(42)
>
> Whow, how does a higher level exception catcher *in general* know
> what type it should return and how to construct it? The innocent
> foo() caller shouldn't bother about a quux() somewhere down the line
> of command. Much less of its innards.
Well said.
> Think of receiving a 'shelf picker died of lung cancer' exception
> when you just ordered a book from your favorite book dealer.
> Irrespective of the seriousness to the shelf picker, but how would
> you expect a customer to handle such an exception?
This kind of exception should never get so far up the call chain,
except possibly as a nested cause of a more general exception. The
customer is in no position to get the book dealer to choose a
different stock picker - that's up to the order picking department of
the book shop. If it doesn't get handled there, then maybe the book
shop can try sourcing the book externally, and if that fails, they may
defer your order until later. The shop could ask the customer's
opinion as to the suitability of each of these options, but the
customer shouldn't have to know how the shop is implemented and make
such decision unprompted.
Even given a continuation to some low level routine, anything the
caller does is likely to be too far removed to make it sensible to
resume the continuation.
Eiffel deals with this by brutally its Design By Contract magic
bullet: Since all the code catching the exception knows about is its
own implementation, the only sane option it has is to try performing
the subtask in a different way. Here's how Eiffel's rescue/retry might
work in perl6, where "rescue" is spelled "CATCH".
class Picker{
# An individual order picker can pick a book, but may unfortunately
# die of lung cancer, or just fail to find the book
method pick($book){
fail Err::LungCancer if .is_smoker();
...
fail Err::BookNotFound if ...;
}
}
class PickingDept{
# The picking department employs pickers to pick books
# If an employee dies of lung cancer while picking an order,
# they are removed from the roster, and a different picker is chosen
# If the department doesn't have enough free pickers,
# it just throws a "too busy" exception
# Due to the retry semantics, the department will keep choosing pickers
# until one of them can pick the book, or they all die of lung cancer,
# (or they're all busy doing something else)
method pick($book){
my $picker=.find_free_picker();
$picker.pick($book);
...
CATCH{
when Err::NoPickersAvailable { fail Err::DeptTooBusy; }
when Err::LungCancer {
.fire_picker($picker); # Harsh, but we won't find him again
retry; # This re-runs the tried block (method) from the top
}
when Err::BookNotFound { fail Err::OutOfStock; } # Optimistic, maybe
default { fail; }
}
}
}
class BookStore{
# The book store has multiple picking departments, so if one of them fails
# to find a book, the others can be tried. If that fails, they could order
# the book from the wholesaler and defer the order, but I'm too lazy
method order($book){
for @.depts -> $dept {
try{
$dept.pick($book);
return;
CATCH{ 1; } # We'll just try the next one
}
}
fail Err::BookNotFound;
}
...
}
class Customer{
# The customer doesn't have any say in how bookshops are run, so all
# they can do if their order is refused, all they can do is try another
# shop, or give up and go home
method buy_book($book){
$random_bookshop.order($book);
CATCH{ fail Err::BookObviouslyDoesntExist; }
}
}
--
Peter Haworth [EMAIL PROTECTED]
Hestons' First Law: I qualify virtually everything I say.
Re: zip: stop when and where?
From: Luke Palmer <[EMAIL PROTECTED]>
Date: October 5, 2005 1:48:54 AM EDT
To: David Storrs <[EMAIL PROTECTED]>
Subject: Re: zip: stop when and where?
Reply-To: Luke Palmer <[EMAIL PROTECTED]>
On 10/4/05, David Storrs <[EMAIL PROTECTED]> wrote:
How about:
@foo = ('a', 'b', 'c');
for @foo ¥ 1..6 :fillin(undef)# a 1 b 2 c 3 undef 4 undef 5
undef 6
for @foo ¥ 1..6 :fillin('') # a 1 b 2 c 3 '' 4 '' 5 '' 6
for @foo ¥ 1..6 :fillin(0)# a 1 b 2 c 3 0 4 0 5 0 6
for @foo ¥ 1..6 :fillin(return) # same as: return ('a', 1, 'b', 2
'c', 3);
A couple of things bother me about this, though:
- Bad endweight on the adverb. It looks like you are modifying the
second list, not the ¥ op
That's because you are.
Good. That makes sense. I did it this way because it seemed like
others on the thread were doing it this way...but it felt wrong at
the time. Glad to see my intuition is not totally useless.
for @foo ¥ 1..6 :fillin(last) # a 1 b 2 c 3
Uh, I don't think that works.
I know it doesn't, I was proposing it as new functionality. The idea
in my head was a bit fuzzy and I probably should have crystallized it
before writing. Had I done so, it might have come out as something
more like this:
@foo = ;
for @foo ¥ 1..6 :fillin(undef)
# a 1 b 2 c 3 undef 4 undef 5 undef 6
for @foo ¥ 1..6 :fillin('x')
# a 1 b 2 c 3 x 4 x 5 x 6
for @foo ¥ 1..6 :fillin(exception but last)
# a 1 b 2 c 3
FOR_LOOP:for @foo ¥ 1..6 :fillin(exception but last FOR_LOOP)
# zips the lists, never enters the for loop body
for @foo ¥ 1..6 :fillin(exception but return)
# same as: return ; i.e., it returns from a sub
Perhaps 'exception' is spelled 'fail' or 'die' or something like that.
Off the top of my head, I can't think of why you would want to use
the 'exception but return' that I show above--it would return from
the enclosing subroutine, without ever entering the loop body. It
would be a highly obfuscated way to return. However, my
understanding of the current design is that 'return' is just an
exception with a built-in handler, so this is a logical corner case
of what I'm suggesting.
Could something like this syntax be made to work?
for (@foo ¥:fillin(undef) 1..6) but true # a but true, 1 but
true...undef but true, 6 but true
I think you've stumbled upon the reason why we made adverbs come
after
operators.
I'm not quite sure how you are using 'come after operators' here,
since in both of the following the adverb comes after the op (it's
just that in the second, there's something between them):
for (@foo) Y (1..6) :fillin(undef) {...}
for (@foo ¥:fillin(undef) 1..6){...}
The important thing is the zip, not the fact that you're
filling in with undef.
I would phrase it as "the important thing is what you are doing with
the lists". That encompasses both the operator you are using (zip)
and how that operator will behave (fill in with, in this case, undef).
--Dks
Re: [perl #37308] Parrot gobbles up all the memory
On Tue, 4 Oct 2005, Leopold Toetsch via RT wrote:
> On Oct 4, 2005, at 19:06, Andrew Dougherty wrote:
> > src/inter_create.c:400: warning: dereferencing type-punned pointer
> > will
> > break strict-aliasing rules
>
> The line reads:
>
> LVALUE_CAST(char *, p) += ALIGNED_CTX_SIZE;
>
> The intent is of course, to bump the context pointer by the needed
> size. The problem is that the needed size does not correlate with the
> size of the struct.
>
> Anyway, does:
>
> p = (struct Parrot_Context *) ( (char *) p + ALIGNED_CTX_SIZE );
>
> help, or better is it "more correct"?
While this does indeed replace the warning by a different warning ("cast
increases required alignment of target type"), it doesn't fix the problem
-- parrot still panics. (And since we're not accessing the memory through
a (char *), I'm not sure it should make any difference. I'm not a
language lawyer, and I haven't read the standard closely.)
Anyway, from what I've been able to gather, gcc's warnings on aliasing are
neither complete nor always 100% on-the-mark. In this case, for example,
I took the apparently offending function, moved it to a different file
(inter_create2.c) and recompiled that function with and without
-fno-strict-aliasing. It made no difference. However, recompiling the
remaining functions in inter_create.c with -fno-strict-aliasing *did* make
the problem go away.
So the compiler's doing some optimization somewhere else in the file that
it's not warning about, and that optimization only happens with
-fstrict-aliasing. I suspect by continuing my divide and conquer strategy
on inter_create.c, one could probably isolate it to a single function, and
then, perhaps, understand whether it's a compiler optimizer error or
whether it's a programming error.
Since this can be reproduced with gcc-3.4 on Intel, I'd appreciate it if
someone with a faster machine and/or a deeper understanding of what the
code is actually trying to do could hunt it down.
> We have a lot of similar code e.g. inside GC, where pointers to PMCs or
> to PObjs are icnremented by the actual size of the object and not by
> the size of some structure.
Yes, I know, but I'm not fluent enough with parrot's internals to follow
it well, so I get lost every time I try to dig in deeply.
--
Andy Dougherty [EMAIL PROTECTED]
Re: zip: stop when and where?
Damian Conway skribis 2005-10-05 10:05 (+1000): > I suspect that the dwimmiest default would be for C to stop zipping at > the length of the shortest finite argument. And to fail unless all finite > arguments are of the same length. This is a nice compromise. But what if you cannot know whether a list is finite? my @foo = slurp ...; # lazy, but can be either finite or infinite my @bar = 1..10; say @foo Y @bar; # ? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: zip: stop when and where?
I guess nobody mentioned this, so I don't know how people on perl-language feel about 'do it the same was as ', but I took a small jump into Haskell a while back (barely enough to consider myself a beginner), but even after just a little bit of time with it, I think I'd almost expect the default zip behavior to stop zipping after the least amount of elements. On 10/5/05, Juerd <[EMAIL PROTECTED]> wrote: > > Damian Conway skribis 2005-10-05 10:05 (+1000): > > I suspect that the dwimmiest default would be for C to stop zipping > at > > the length of the shortest finite argument. And to fail unless all > finite > > arguments are of the same length. > > This is a nice compromise. > > But what if you cannot know whether a list is finite? > > my @foo = slurp ...; # lazy, but can be either finite or infinite > my @bar = 1..10; > > say @foo Y @bar; # ? > > > Juerd > -- > http://convolution.nl/maak_juerd_blij.html > http://convolution.nl/make_juerd_happy.html > http://convolution.nl/gajigu_juerd_n.html >
Re: seeing the end of the tunnel
On Wed, 2005-10-05 at 16:26 +0200, TSa wrote: > > I recently wrote a "Perl 6 design TODO", which was surprizingly small, > > which enumerated the things to be done before I considered the design > > of Perl 6 to be finished. Larry replied with a couple more items. > > The type system is not on this list, right? It actually is, both in syntax and semantics. -- c
Re: Exceptuations
On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
> On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
> > Piers Cawley wrote:
> > >>Exactly which exception is continued?
> > > The bottommost one. If you want to return to somewhere up its call
> > > chain, do:
> > >
> > > $!.caller(n).continue(42)
> >
> > Whow, how does a higher level exception catcher *in general* know
> > what type it should return and how to construct it? The innocent
> > foo() caller shouldn't bother about a quux() somewhere down the line
> > of command. Much less of its innards.
>
> Well said.
No! Not well said at all!
The exception handler knows *EVERYTHING* because it knows what
exception it caught:
CATCH {
when some_kind_of_error {
$!.continue($appropriate_value_for_some_kind_of_error)
}
}
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me climbs a brick wall with his fingers: neeyah!
pgpLLTJwCUxTl.pgp
Description: PGP signature
Re: Spurious CPAN Tester errors from Sep 23rd to present.
On Wed, Oct 05, 2005 at 11:22:40PM +1000, Adam Kennedy wrote: > Please ignore these bad reports. I've contacted Schwern to get that > specific change to Test::More backed out ASAP. These problem, if you get > any, should go away shortly. > > Given that the repair alternatives are to backout the Test::More change > and increment the T:B:Tester Test::More version to the newest (or at > least, NOT the current) or to change all 26 other modules, backing out > seems the sanest option at this point I'm disinclined to back this change out. See the bug for reasoning. http://rt.cpan.org/NoAuth/Bug.html?id=14936 To sum up: * There was ample warning. * You shouldn't be relying on screen scraping. * The fix to Test::Builder::Tester is trivial. * Rolling back the change is a pain in my ass. The bug for this in Test::Builder::Tester is here: http://rt.cpan.org/NoAuth/Bug.html?id=14931 -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Stabbing you in the face for your own good.
Re: Spurious CPAN Tester errors from Sep 23rd to present.
On Thu, Oct 06, 2005 at 03:43:50AM +1000, Adam Kennedy wrote: > >>* Rolling back the change is a pain in my ass. > > BTW, this shouldn't be true. It shouldn't because I should have long ago writen a routine to check my diagnostics instead of hard coding it all over the tests. > Just grab the previous stable tarball, unroll it, change the version to > a higher one, and release. If it's a bitch to backout that one path, > backout the entire stable release to the previous one. Did you see the number of bug fixes between 0.60 and 0.61? No, I'm not rolling back the entire release. Take a stab at fixing Test::Builder::Tester. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern You know what the chain of command is? It's the chain I go get and beat you with 'til you understand who's in ruttin' command here. -- Jayne Cobb, "Firefly"
[perl #37357] [TODO] Check and split up 'examples/assembly'
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #37357] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37357 > Hi, currently 'examples/assembly' contains PASM and PIR code. As this is mildly confusing, 'assembly' should be split up into e.g. 'pir', 'pasm' and 'library'. In the course of splitting up, the broken examples can be fixed, or converted to PIR. Scripts without user interaction can also easily be tested by 't/examples/*.t'. CU, Bernhard
Re: Spurious CPAN Tester errors from Sep 23rd to present.
On Thu, Oct 06, 2005 at 03:39:59AM +1000, Adam Kennedy wrote: > If we start with everything broken and try to gradually fix it, we're > going to have little errors here and there for a long time. AFAIK there is only one module of consequence which does screen scraping on Test::More and that's Test::Builder::Tester (Test::Warn, it turns out, fails because of Test::Builder::Tester). Fix that, upload a new version and the problem goes away. > If we can back the change out for 6 months or so, there's time to get > all the potential scrapers audited for problems As far as I'm concerned scrapers already have a problem: They're scraping, they're relying on it and they didn't think to check against the alphas. I'm not particularly inclined to back out three months of Test::More fixes and hold up new releases until next spring to accomodate them. > At the present time you cannot install anything of consequence onto a > fresh Perl install. Of course you can, it comes with Test::More! 5.8.7 comes with 0.54 which is just two releases ago. You'd be hard pressed to find anything which relies on anything newer. Test::Builder::Tester wants Test::Builder 0.12 which is rather old. The fact that you're the first person to report this problem, two weeks after Test::More was released, that its not nearly as widespread as you think. I'm done talking about this until I see some attempt at fixing Test::Builder::Tester. It could have been done by now. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Stabbing you in the face so you don't have to.
Re: A listop, a block and a dot
On 10/5/05, Autrijus Tang <[EMAIL PROTECTED]> wrote:
> However:
> f:{1}.()
>
> still parses as
>
> (&f(:{1})).()
>
> as the "adverbial block" form takes precedence. Is that also wrong?
No, that seems right to me, much in the same way that:
$x.{1}.{2}
Binds to the left.
Luke
Re: Exceptuations
On 10/5/05, Yuval Kogman <[EMAIL PROTECTED]> wrote: > On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote: > > On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote: > > > Whow, how does a higher level exception catcher *in general* know > > > what type it should return and how to construct it? The innocent > > > foo() caller shouldn't bother about a quux() somewhere down the line > > > of command. Much less of its innards. > > > > Well said. > > > No! Not well said at all! > > The exception handler knows *EVERYTHING* because it knows what > exception it caught: I don't think it was a "how is this possible", but more of a "what business does it have?". And as far as I gathered, they're saying pretty much what you've been saying, but in a different way. It's about the continuation boundary; that is, if you're outside a module, you have no say in how the module does its business. You can continue only at the module boundary, replacing a return value from its public interface. Of course, exactly how this "public interface" is declared is quite undefined. Luke
Roles and Trust
Apocalypse 12 has the following to say about roles and trust
(http://www.perl.com/pub/a/2004/04/16/a12.html?page=10)
It's not clear whether roles should be allowed to grant
trust. In the absence of evidence to the contrary, I'm
inclined to say not.
In Perl 5, I recently found myself in the annoying position of having a
method which could accept scalar, array, or hash references. My
primary code looked similar to this (simplified for clarity):
sub _attributes {
my ($self, $attrs) = @_;
return $$attrs if UNIVERSAL::isa( $attrs, 'SCALAR' );
my @attributes = UNIVERSAL::isa( $attrs, 'HASH' )
? %$attrs : @$attrs;
return unless @attributes;
# more code here
}
This was a private method, but $attrs is an argument that is passed in
by the person using my class. It would be nice if I could just assign
an "attributes" role to the SCALAR, ARRAY, and HASH classes and say
that only my class could see the method(s) it provides. Thus, my
caller would be blissfully unaware that I am doing this:
$attrs->attributes; # even if it's an array reference
This would get rid of all of the bad UNIVERSAL::isa type of code and
allow Perl to handle the dispatching instead of the programmer. While
most probably don't do stuff like this, I think it's a great example of
why role should be allowed to specify trust. I've been using
"role-like" behavior quite a bit in a large test suite I'm working on
and it would be nice to be able to do stuff like this.
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Exceptuations
Luke Palmer wrote:
Of course, exactly how this "public interface" is declared is quite undefined.
Reading this thread, I find myself wondering how a resumable exception
differs from a dynamically scropted function. Imagine this code:
sub FileNotWriteable( Str $filename ) {
die "can't write file: $filename";
}
sub write_file (Str $filename) {
FileNotWriteable($filename) unless -w $filename;
...
}
sub my_program {
temp sub FileNotWriteable( Str $filename ) {
return if chmod "+w", $filename;
OUTER::FileNotWriteable( $filename );
}
...
write_file("foo.txt");
...
}
Ignoring syntactic sugar, what semantics does exception handling have
that a dynamically scoped function does not?
In the case of non-resumable exceptions, we see things like deferred
handling -- the exception is passed as a property of an undef value. I
assume such an exception cannot be resumed, so it does appear to me that
there are fundamental differences between resumable things, and
non-resumable, deferrable, exceptions. What is the benefit of unifying
them under a common syntax (CATCH blocks)?
Larry suggested that the exception mechanism might be a way of unifying
errors and warnings; but perhaps the opposite is true. Perhaps what we
see is a needed to generalize the distinction between warnigns and errors.
Dave.
Re: Roles and Trust
On 10/5/05, Ovid <[EMAIL PROTECTED]> wrote:
> sub _attributes {
> my ($self, $attrs) = @_;
> return $$attrs if UNIVERSAL::isa( $attrs, 'SCALAR' );
>
> my @attributes = UNIVERSAL::isa( $attrs, 'HASH' )
> ? %$attrs : @$attrs;
> return unless @attributes;
> # more code here
> }
>
> This was a private method, but $attrs is an argument that is passed in
> by the person using my class. It would be nice if I could just assign
> an "attributes" role to the SCALAR, ARRAY, and HASH classes and say
> that only my class could see the method(s) it provides. Thus, my
> caller would be blissfully unaware that I am doing this:
>
> $attrs->attributes; # even if it's an array reference
sub _attributes($ref) {
my multi attributes ($scalar) { $$scalar }
my multi attributes (@array) { @array }
my multi attributes (%hash) { %hash }
attributes($ref)
}
That attributes look suspiciously indentityish. There is some context
magic going on.
Or doesn't this solve your problem?
Luke
Re: Roles and Trust
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> sub _attributes($ref) {
> my multi attributes ($scalar) { $$scalar }
> my multi attributes (@array) { @array }
> my multi attributes (%hash) { %hash }
> attributes($ref)
> }
>
> That attributes look suspiciously indentityish. There is some
> context magic going on.
>
> Or doesn't this solve your problem?
Offhand, it does solve my problem. It might get more problematic if I
needed that method available for those types in a variety of classes,
but for right now, I can't see that it would be an issue. Still, I'm
not entirely convinced that not allowing roles to assign trust is a
good thing. It feels a bit arbitrary.
Is there a compelling reason why roles should not do this?
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: [PATCH] Add BROKEN.pod
On Mon, 2005-10-03 at 17:05 -1000, Joshua Hoblitt wrote: > I'm wondering if this wouldn't be better split up into RT tickets > similar to the way TODOs are handled. Having everything in one coherent > document is great but I suspect that significantly lowers the odds of > the individual items being kept up to date. Maybe so. The difference between this and a list of bugs is that these are higher-level problems that prevent various people from making progress on important things. Generating this list out of RT is probably fine though, if it's quick and easy. -- c
Re: Spurious CPAN Tester errors from Sep 23rd to present.
Michael G Schwern wrote: AFAIK there is only one module of consequence which does screen scraping on Test::More and that's Test::Builder::Tester (Test::Warn, it turns out, fails because of Test::Builder::Tester). Fix that, upload a new version and the problem goes away. Nit: does Test::Harness count as a "module of consequence"? - David Golden
Re: zip: stop when and where?
I've been thinking about this issue some more and it occurs to me that we
might be thinking about this the wrong way.
Providing a :fillin() adverb on C is a suboptimal solution, because it
implies that you would always want to fill in *any* gap with the same value.
While that's likely in a two-way zip, it seems much less likely in a multiway zip.
So I now propose that C works like this:
C interleaves elements from each of its arguments until
any argument is (a) exhausted of elements I (b) doesn't have
a C property.
Once C stops zipping, if any other element has a known finite
number of unexhausted elements remaining, the fails.
In other words, you get:
@i3 = 1..3 ;
@i4 = 1..4 ;
@a3 = 'a'..'c' ;
zip(@a3, @i3) # 'a', 1, 'b', 2, 'c', 3
zip(@i3, @i4) # fail
zip(100..., @a3, @i3) # 100, 'a', 1, 101, 'b', 2, 102, 'c', 3
zip(100..., @a3, @i4) # fail
zip(@a3 but fill(undef), @i4) # 'a', 1, 'b', 2, 'c', 3, undef, 4
zip(1..6, @i3 but fill(3), @i4 but fill('?'))
# 1,1,1,2,2,2,3,3,3,4,3,4,5,3,'?',6,3,'?'
Damian
Re: zip: stop when and where?
On Oct 5, 2005, at 7:49 PM, Damian Conway wrote:
Providing a :fillin() adverb on C is a suboptimal solution,
because it implies that you would always want to fill in *any* gap
with the same value. While that's likely in a two-way zip, it seems
much less likely in a multiway zip.
I actually have no problem with the solution you suggest (although I
rather like my idea about being able to 'fill in' with a control
exception), but I do have a question. If you want a multiway zip
with differing fillins, can't you do this?
@foo = 1..10 ¥:fill(0) 'a'..c' ¥:fill('x') ¥ 1..50;
Assuming, of course, that it is possible to stick an adverb on the op
as I was requesting.
--Dks
Re: zip: stop when and where?
David Storrs asked:
If you want a multiway zip with
differing fillins, can't you do this?
@foo = 1..10 ¥:fill(0) 'a'..c' ¥:fill('x') ¥ 1..50;
I don't think that works. For example, why does the :fill(0) of the first ¥
apply to the 1..10 argument instead of to the 'a'..'c' argument? Especially
when it's the 'a'..'c' argument that's the shorter of the two!
Besides which, adverbs, being optional, come at the end of an operator's
argument list. Moreover, it's unclear to me where how they are applied at all
to an n-ary operator like ¥.
On top of which, even if it did work, that formulation doesn't help at all if
you don't have Unicode available and are therefore forced to use C.
Assuming, of course, that it is possible to stick an adverb on the op
as I was requesting.
My recollection is that $Larry has previously said that this is not the
case...that adverbs are suffixed.
Damian
Re: zip: stop when and where?
On 10/5/05, Damian Conway <[EMAIL PROTECTED]> wrote: > So I now propose that C works like this: > > C interleaves elements from each of its arguments until > any argument is (a) exhausted of elements I (b) doesn't have > a C property. > > Once C stops zipping, if any other element has a known finite > number of unexhausted elements remaining, the fails. Wow, that's certainly not giving the user any credit. I'm just wondering why you feel that we need to be so careful. Luke
Re: zip: stop when and where?
Luke wrote:
>>Once C stops zipping, if any other element has a known finite
>>number of unexhausted elements remaining, the fails.
>
> Wow, that's certainly not giving the user any credit.
Actually, I want to be careful because I give the users too much credit. For
imagination.
> I'm just wondering why you feel that we need to be so careful.
Because I can think of at least three reasonable and useful default behaviours
for zipping lists of differing lengths:
# Minimal (stop at first exhausted list)...
for @names ¥ @addresses -> $name, $addr {
...
}
# Maximal (insert undefs for exhausted lists)...
for @finishers ¥ (10..1 :by(-1)) -> $name, $score {
$score err next;
...
}
# Congealed (ignore exhausted lists)...
for @queue1 ¥ @queue2 -> $server {
...
}
Which means that there will be people who expect each of those to *be* the
default behaviour for unbalanced lists. Which means there shouldn't be any
default for unbalanced lists, since whatever that default is won't DWIM for
2/3 of the potential users. Which means that unbalanced lists ought to produce
an error, unless the user specifies how to deal with the imbalance.
Damian
Re: [perl #36200] Parrot on Linux/m68k test failures
On Oct 5, 2005, at 12:11 AM, Joshua Hoblitt via RT wrote:
[EMAIL PROTECTED] - Tue Jun 07 02:29:24 2005]:
A 'make test' of parrot failed some tests on Linux/m68k.
Here is the contents of myconfig:
Summary of my parrot 0.2.1 (r8279) configuration:
configdate='Mon Jun 6 03:37:27 2005'
Would you mind retesting with the latest sources from SVN?
Parrot itself builds successfully, but 'make' fails here:
...
./parrot -o runtime/parrot/library/Stream/Sub.pbc
runtime/parrot/library/Stream/Sub.imc
./parrot -o runtime/parrot/library/Stream/Writer.pbc
runtime/parrot/library/Stream/Writer.imc
./parrot -o runtime/parrot/library/YAML/Parser/Syck.pbc
runtime/parrot/library/YAML/Parser/Syck.imc
/usr/bin/perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? >>
8;' dynclasses
make[1]: Entering directory `/home/jjuran/src/parrot/dynclasses'
/usr/bin/perl /home/jjuran/src/parrot/build_tools/pmc2c.pl --dump
match.pmc
Can't write 'classes/default.dump' at
/home/jjuran/src/parrot/build_tools/pmc2c.pl line 664.
pmc2c dump failed (512)
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/jjuran/src/parrot/dynclasses'
make: *** [dynclasses.dummy] Error 2
My guess is that the absence of directory
'/home/jjuran/src/parrot/dynclasses/classes' is causing open to fail,
and that the trivial fix is to open '../classes/default.dump' instead.
Or not change directories.
Josh
[perl #37361] [BUG] Parrot 0.3.0 Tru64 core dump t/examples/japh.t #10
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #37361]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37361 >
Didn't notice this earlier because the whole japh.t is
reported as succeeding even though a core dump happens
for the subtest #10.
1 pthread_kill(0x0, 0x11fffb038, 0x0, 0x11fffc010, 0x3ff0001)
[0x3ff805c0ed0]
2 (unknown)() [0x3ff805c7908]
3 (unknown)() [0x3ff80633994]
4 exc_raise_signal_exception(0xb0ffe0003, 0x86, 0x0, 0x12013b8ac,
0x1) [0x3ff80633d80]
5 clone_regs_interp(d = (nil), s = 0x140136000, dest = 0x1404ed080)
["classes/parrotinterpreter.pmc":48, 0x12013b8ac]
6 clone_regs(d = (nil), s = 0x140136000, dest = 0x1404ed080)
["classes/parrotinterpreter.pmc":175, 0x12013bbec]
7 clone_interpreter(dest = 0x1404ed080, self = 0x140180310)
["classes/parrotinterpreter.pmc":202, 0x12013bcb4]
8 pt_thread_run(interp = 0x140136000, dest_interp = 0x1404ed080, sub
= 0x1404ecf00) ["src/thread.c":156, 0x1200cb118]
9 pt_thread_run_3(interp = 0x140136000, dest_interp = 0x1404ed080,
sub = 0x1404ecf00) ["src/thread.c":230, 0x1200cb2b4]
10 pcf_v_JOP( = 0x1200b887c, = 0x1200b887c, = 0x1200b887c,
interpreter = 0x140136000, self = 0x140181810) ["src/nci.c":3312,
0x1201df350]
11 Parrot_NCI_invoke(interpreter = 0x140136000, pmc = 0x140181810,
next = 0x1404f0310) ["classes/nci.c":144, 0x120187788]
12 Parrot_invokecc_p(cur_opcode = 0x1404f0300, interpreter =
0x140136000) ["ops/core.ops":417, 0x1200e1e04]
13 runops_slow_core(interpreter = 0x140136000, pc = 0x1404f0300)
["src/runops_cores.c":153, 0x12015e5d8]
14 runops_int( = 0x1404f0200, = 0x1404f0200, interpreter =
0x140136000, offset = 0) ["src/interpreter.c":750, 0x1201070f0]
15 runops(interpreter = 0x140136000, offs = 0) ["src/inter_run.c":81,
0x1200b4a20]
16 runops_args(interpreter = 0x140136000, sub = 0x1404ecff0, obj =
0x140137ba0, meth = (nil), sig = 0x140067458 = "vP", ap = struct {
_a0 = 0x11fffbef0_offset = 24}) ["src/inter_run.c":181, 0x1200b4d50]
17 Parrot_runops_fromc_args(interpreter = 0x140136000, sub =
0x1404ecff0, sig = 0x140067458 = "vP") ["src/inter_run.c":275, 0x1200b4f28]
18 Parrot_runcode(interpreter = 0x140136000, argc = 1, argv =
0x11fffc020) ["src/embed.c":841, 0x120093c20]
19 Parrot_runcode(interpreter = 0x140136000, argc = 1, argv =
0x11fffc020) ["src/embed.c":772, 0x1200939d8
20 main(argc = 1, argv = 0x11fffc020) ["imcc/main.c":643, 0x120092770]
