Re: Problem with lexical scoping
this is very interesting. I think we should store this example somewhere in
proper documentation format, maybe in docs/compiler_faq.pod
kjs
On Feb 12, 2008 8:50 PM, Andrew Parker <[EMAIL PROTECTED]> wrote:
> So that works in this situation because the outer lexpad that I want
> is the same as the caller's lexpad. Thanks for the tip :) After
> poking around a bit at what "getinterp" does I found some good reading.
>
> * docs/ops/core.pod - getinterp returns the ParrotInterpreter
> * src/pmc/parrotinterpreter.pmc - the list of PMC keys is very
> interesting
>
> Now to kick it up a notch! From that I learned that the getinterp and
> then lexpad works in this case since the wanted lexical pad is the
> caller's. This doesn't work when the wanted lexical pad is the
> lexically enclosing scope (not the caller). Here is an example:
>
> # equivalent to:
> #
> # sub f {
> # my $x = 1;
> # return sub { my $x = $x + 1; return $x; };
> # }
> # print f()->(), "\n"
> #
> .namespace
> .sub "main"
> get_global $P18, "outer"
> $P17 = $P18()
> $P16 = $P17()
> print $P16
> print "\n"
> .end
>
> .sub "outer" :outer("main")
> new $P12, "Integer"
> assign $P12, 1
> .lex "x", $P12
> get_global $P18, "inner"
> newclosure $P18, $P18
> .return ($P18)
> .end
>
> .sub "inner" :outer("outer")
> $P0 = getinterp
> $P1 = $P0['outer'; 'lexpad']
> $P14 = $P1['x']
> n_add $P15, $P14, 1
> .lex "x", $P15
> .return ($P15)
> .end
>
> There is also the 'outer' lexpad which is the actuall enclosing one.
> So it looks like my complaint that there was something lacking was
> wrong. It is more that I didn't look enough and parrot has so much
> that it was hard to find :P
>
> Thanks for the patience and the help.
>
> Andrew Parker
>
> On Feb 12, 2008, at 8:00 PM, Patrick R. Michaud wrote:
>
> > On Mon, Feb 11, 2008 at 10:27:27PM +0100, Andrew Parker wrote:
> >> .namespace
> >> .sub "outer"
> >>new $P12, "Integer"
> >>assign $P12, 1
> >>.lex "x", $P12
> >>get_global $P18, "inner"
> >>newclosure $P18, $P18
> >>$P17 = $P18()
> >>print $P17
> >>print "\n"
> >> .end
> >>
> >> .sub "inner" :outer("outer")
> >>find_lex $P14, "x"
> >>n_add $P15, $P14, 1
> >>.lex "x", $P15
> >>.return ($P15)
> >> .end
> >
> > A PIR subroutine can get at its caller's lexpad by doing:
> >
> >$P0 = getinterp
> >$P1 = $P0['lexpad'; 1]
> >
> > So, in the 'inner' sub above, it can get to outer's 'x' lexical
> > by doing:
> >
> >$P0 = getinterp
> >$P1 = $P0['lexpad'; 1]
> >$P2 = $P1['x']
> >
> > Pm
>
>
Re: Problem with lexical scoping
> > On a more rational note, has any thought been given to what "good enough > performance for release" will be? Should we perhaps add a performance benchmark to the tests? Normalising it to account for hardware variations might be a problem. -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
[perl #50770] [PATCH] for RT#48276
# New Ticket Created by "Andrew Whitworth" # Please include the string: [perl #50770] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50770 > This is a patch for RT#48276 "Warn when failure occurs in Parrot_setenv()". I apologize in advance if this is not the correct way to submit patches for specific tickets. Files affected: config/platform/win32/env.c I updated Parrot_setenv() to call Parrot_warn() for the two failure modes. I also made note of the fact that a warning might not be enough, because a failure of malloc or _putenv might be an indicator of a big problem. --Andrew Whitworth mywin32env.patch Description: Binary data
Re: Problem with lexical scoping
On Wed, 2008-02-13 at 14:21 +, [EMAIL PROTECTED] wrote: > > > > On a more rational note, has any thought been given to what "good enough > > performance for release" will be? > > Should we perhaps add a performance benchmark to the tests? > > Normalising it to account for hardware variations might be a problem. There are existing benchmarks in examples/benchmarks/ , which have mostly solved the problem of hardware variations [1] by comparing instead against the performance of other dynamic language implementations. Certainly different versions of those other language implementations will have varying performance, but we can standardize our comparison on, say, the most recent release of each. There is also the language shootout, which has quite a few more comparisons available. My personal feeling is that for each comparison benchmark, we should be comparing PIR and Rakudo performance against the fastest other language implementation for that benchmark. Then we should be looking for two problems -- relatively consistent poor performance (indicating a general implementation design problem), and particular benchmarks that do unusually poorly (indicating some particular axis of pain). Some of these problems will be solveable, others will be amenable to workarounds, and others will probably just need to be documented. But we should really make sure we know as much as possible what the problems *are* before the first production release. -'f [1] Mind you, we still need to know if for example PPC handles method calls way slower than Intel, so we can determine if there is something we can do about that. But that is another story.
s/string_equal/string_compare/g
string_equal() is misnamed. It should be string_compare() like strcmp() and memcmp(). Objections? xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Functions that malloc()
There's now a make target to show all the functions that are PARROT_MALLOC: "make malloclist" xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
[perl #50768] [PATCH] Update Win32 platform documentation.
# New Ticket Created by "Andrew Whitworth" # Please include the string: [perl #50768] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50768 > I've updated some of the documenation and comments in config/platform/win32. It's nothing fancy. There were some functions that I legitimately could not figure out what they do, like Parrot_stat_info_floatval, which I assume should return a 64-bit value from stat, but currently only returns -1. I assume that this is just not implemented, and so I haven't added documentation for them until they are implemented. Files updated are: config/gen/platform/win32/dl.c config/gen/platform/win32/env.c config/gen/platform/win32/exec.c config/gen/platform/win32/misc.c config/gen/platform/win32/stat.c The exception to my statement above occurs in dl.c, where I assume Parrot_dlerror is supposed to return a NULL value (because that's the return code from LoadLibrary when a file load fails). Some of the documentation in that file depends on that assumption, so it may need to be redone. This is my first patch, so I appologize in advance if it is teh suxxor. --Andrew Whitworth mywin32docs.patch Description: Binary data
[perl #50776] myops alarm test failure
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #50776] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50776 > Hi, I still get this test failure, as shown below. (I checked in rt and saw that a patch was applied unrolling some loop in this test somewhere in June 2007.) kjs === t/dynpmc/sub.ok t/dynpmc/subclass_with_pir_methodok t/dynoplibs/dan..ok t/dynoplibs/myopsok 6/10 t/dynoplibs/myopsNOK 7/10# Failed test (t/dynoplibs/myops.t at line 148) # Exited with error code: 255 # Received: # alarm # alarm # alarm # alarm # # Expected: # /alarm # alarm # alarm/ # t/dynoplibs/myopsok 8/10# Looks like you failed 1 test of 10. t/dynoplibs/myopsdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 7 Failed 1/10 tests, 90.00% okay
Re: Problem with lexical scoping
On Wed, Feb 13, 2008 at 11:26:36AM +0100, Klaas-Jan Stol wrote:
>this is very interesting. I think we should store this example somewhere
>in proper documentation format, maybe in docs/compiler_faq.pod
FWIW, the information about using getinterp to get at a caller's
lexpad is already in pdd20, so perhaps we can just add the information
about the 'outer' example there as well.
Pm
>On Feb 12, 2008 8:50 PM, Andrew Parker <[EMAIL PROTECTED]> wrote:
>
> So that works in this situation because the outer lexpad that I want
> is the same as the caller's lexpad. Thanks for the tip :) After
> poking around a bit at what "getinterp" does I found some good reading.
>
> * docs/ops/core.pod - getinterp returns the ParrotInterpreter
> * src/pmc/parrotinterpreter.pmc - the list of PMC keys is very
> interesting
>
> Now to kick it up a notch! From that I learned that the getinterp and
> then lexpad works in this case since the wanted lexical pad is the
> caller's. This doesn't work when the wanted lexical pad is the
> lexically enclosing scope (not the caller). Here is an example:
>
> # equivalent to:
> #
> # sub f {
> # my $x = 1;
> # return sub { my $x = $x + 1; return $x; };
> # }
> # print f()->(), "\n"
> #
> .namespace
> .sub "main"
> get_global $P18, "outer"
> $P17 = $P18()
> $P16 = $P17()
> print $P16
> print "\n"
> .end
>
> .sub "outer" :outer("main")
> new $P12, "Integer"
> assign $P12, 1
> .lex "x", $P12
> get_global $P18, "inner"
> newclosure $P18, $P18
> .return ($P18)
> .end
>
> .sub "inner" :outer("outer")
> $P0 = getinterp
> $P1 = $P0['outer'; 'lexpad']
> $P14 = $P1['x']
> n_add $P15, $P14, 1
> .lex "x", $P15
> .return ($P15)
> .end
>
> There is also the 'outer' lexpad which is the actuall enclosing one.
> So it looks like my complaint that there was something lacking was
> wrong. It is more that I didn't look enough and parrot has so much
> that it was hard to find :P
>
> Thanks for the patience and the help.
> Andrew Parker
> On Feb 12, 2008, at 8:00 PM, Patrick R. Michaud wrote:
>
> > On Mon, Feb 11, 2008 at 10:27:27PM +0100, Andrew Parker wrote:
> >> .namespace
> >> .sub "outer"
> >>new $P12, "Integer"
> >>assign $P12, 1
> >>.lex "x", $P12
> >>get_global $P18, "inner"
> >>newclosure $P18, $P18
> >>$P17 = $P18()
> >>print $P17
> >>print "\n"
> >> .end
> >>
> >> .sub "inner" :outer("outer")
> >>find_lex $P14, "x"
> >>n_add $P15, $P14, 1
> >>.lex "x", $P15
> >>.return ($P15)
> >> .end
> >
> > A PIR subroutine can get at its caller's lexpad by doing:
> >
> >$P0 = getinterp
> >$P1 = $P0['lexpad'; 1]
> >
> > So, in the 'inner' sub above, it can get to outer's 'x' lexical
> > by doing:
> >
> >$P0 = getinterp
> >$P1 = $P0['lexpad'; 1]
> >$P2 = $P1['x']
> >
> > Pm
Re: Problem with lexical scoping
On Tue, Feb 12, 2008 at 08:59:46PM -0800, Geoffrey Broadwell wrote:
> Here's my fear: Parrot will near production release, we'll start
> finding performance problems, and everyone will be so incredibly ready
> to get 1.0 out the door that we'll release before fixing them ("correct
> now, fast later" and all that). Unfortunately, we'll find out after the
> release that the only way to fix the performance problems is to make
> some deeply incompatible change, and suddenly we'll be staring down the
> barrel of the production release compatibility shotgun.
>
> I dunno how likely that is -- fears are irrational beasts after all --
> but there it is.
FWIW, I'm not too fearful of this particular scenario coming to pass.
At the moment there are sufficient layers of abstraction (some might
say "too many") that if we do discover a deep change is needed, I think
we'll be able to adjust the various intermediate layers to keep it
from significantly affecting production-release level items. At the
very least, compilers and translators built using the compiler tools
shouldn't see significant structural changes due to changes in Parrot
internals, unless the compilers are using lots of inlined PIR and/or
making some big assumptions about Parrot internals. (And even for
those compilers that are making such assumptions, I still think
we'd be able to manage it.)
Pm
Re: s/string_equal/string_compare/g
On Wednesday 13 February 2008 08:26:43 Andy Lester wrote: > string_equal() is misnamed. It should be string_compare() like > strcmp() and memcmp(). +1
Performance (was Re: Problem with lexical scoping)
On Wednesday 13 February 2008 06:21:32 [EMAIL PROTECTED] wrote: > Should we perhaps add a performance benchmark to the tests? > > Normalising it to account for hardware variations might be a problem. That's somewhat difficult, as it's the performance of languages hosted on Parrot that's most important. I profile Rakudo once in a while. If I ever get the time and energy and brains to figure out where the weird Lua segfaults come from, I'll profile it too. If we were really fortunate, someone would write a Parrot runloop that emits callgrind-compatible output, so that we could profile Parrot at the sub and op level with callgrind_annotate. -- c
Re: Performance (was Re: Problem with lexical scoping)
On Feb 13, 2008 1:41 PM, chromatic <[EMAIL PROTECTED]> wrote: > On Wednesday 13 February 2008 06:21:32 [EMAIL PROTECTED] wrote: > > > Should we perhaps add a performance benchmark to the tests? > > > > Normalising it to account for hardware variations might be a problem. > > That's somewhat difficult, as it's the performance of languages hosted on > Parrot that's most important. > > I profile Rakudo once in a while. If I ever get the time and energy and > brains to figure out where the weird Lua segfaults come from, I'll profile it > too. > > If we were really fortunate, someone would write a Parrot runloop that emits > callgrind-compatible output, so that we could profile Parrot at the sub and > op level with callgrind_annotate. > > -- c > > One of the thing tcl needs to be fully supported is the ability to add sub hooks that execute on enter/exit of a particular sub[1]; adding this would give us the ability to profile which PIR subs we were spending most of our time (by using the pre-post hooks to capture timing information), which as more people are using PCT, would help us concentrate our efforts on speedups that could potentially improve things for many HLLs at once. [1] http://www.tcl.tk/man/tcl8.5/TclCmd/trace.htm -- Will "Coke" Coleda
Re: Performance (was Re: Problem with lexical scoping)
On Wednesday 13 February 2008 10:59:41 Will Coleda wrote: > One of the thing tcl needs to be fully supported is the ability to add > sub hooks that execute on enter/exit of a particular sub[1]; adding > this would give us the ability to profile which PIR subs we were > spending most of our time (by using the pre-post hooks to capture > timing information), which as more people are using PCT, would help us > concentrate our efforts on speedups that could potentially improve > things for many HLLs at once. > [1] http://www.tcl.tk/man/tcl8.5/TclCmd/trace.htm That sounds much like .wrap in Perl 6. -- c
Re: Performance (was Re: Problem with lexical scoping)
Will Coleda wrote: On Feb 13, 2008 1:41 PM, chromatic <[EMAIL PROTECTED]> wrote: On Wednesday 13 February 2008 06:21:32 [EMAIL PROTECTED] wrote: Should we perhaps add a performance benchmark to the tests? Normalising it to account for hardware variations might be a problem. That's somewhat difficult, as it's the performance of languages hosted on Parrot that's most important. I profile Rakudo once in a while. If I ever get the time and energy and brains to figure out where the weird Lua segfaults come from, I'll profile it too. If we were really fortunate, someone would write a Parrot runloop that emits callgrind-compatible output, so that we could profile Parrot at the sub and op level with callgrind_annotate. -- c One of the thing tcl needs to be fully supported is the ability to add sub hooks that execute on enter/exit of a particular sub[1]; adding this would give us the ability to profile which PIR subs we were spending most of our time (by using the pre-post hooks to capture timing information), which as more people are using PCT, would help us concentrate our efforts on speedups that could potentially improve things for many HLLs at once. Lua has too this kind of hooks in his Debug library (see http://www.lua.org/manual/5.1/manual.html#5.9). These features could be very VM specific. François. [1] http://www.tcl.tk/man/tcl8.5/TclCmd/trace.htm
What are "identifier extensions"?
S02 mentions "identifier extensions" in the section describing adverbial
pairs with non-identifier keys (see the table reproduced below).
What are identifier extensions? I'm guessing that : and :<+> are
both acting as identifier extensions in these examples:
statement_control:
infix:<+>
But what's really going on there? Are we effectively creating an
identifier with non-identifier characters, or what? I've been reading
such things subconsciously as operator definitions with precedence and
associativity modifiers. But modifiers ought to be written after the
modified quantity, as adverbs, so that would more properly be written as
if:statement_control
+:infix
except, of course, + isn't a valid identifier.
Another interpretation is that, for example, statement_control: is
the "if" token defined inside the statement_control grammar. Its
similarity to hash access makes it look likes it grabbing something from
out of a container.
And yes, I have tried to find in the synopses a discussion of the real
meaning of references like infix:<+>, but I've been unsuccessful. Can
anybody help me find the relevant synopsis?
And, if I've guessed wrong, and "identifier extensions" have nothing to
do with infix:<+> and friends, then what ARE identifier extensions?
Here's the table, reproduced from S02, the uses the phrase "identifier
extension":
Simple pair DIFFERS fromwhich means
=== ===
2 => <101010> :2<101010> radix literal 0b101010
8 => <123> :8<123> radix literal 0o123
16 => :16 radix literal 0xdeadbeef
16 => $somevalue:16($somevalue) radix conversion function
'' => $x:($x) arglist or signature literal
'' => ($x,$y) :($x,$y)arglist or signature literal
'' =>:identifier extension
'' => «x» :«x»identifier extension
'' => [$x,$y] :[$x,$y]identifier extension
'' => { .say } :{ .say } adverbial block
=thom
--
Larry Niven's Laws
#6: It is easier to destroy than create.
Bin Laden tore down the World Trade Center? Let's see him build one. If
human beings didn't have a strong preference for creation, nothing would
get built, ever.
[perl #50302] [TODO]: Refactor internals of t/harness
Patches applied to trunk in r25705.
[perl #50800] Update PIR coda?
# New Ticket Created by Will Coleda # Please include the string: [perl #50800] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50800 > >From PDD07: PIR source files should end with this coda: # Local Variables: # mode: pir # fill-column: 100 # End: # vim: expandtab shiftwidth=4: However, there are files that are now checked that weren't before[1] that have a slightly different version: # Local Variables: # mode: pir # fill-column: 100 # End: # vim: expandtab shiftwidth=4 ft=pir: Note the added 'ft' directive. We need to choose one of: 1) ruthlessly eliminate this upstart coda[2] 2) update all other PIR codas, the test, and the PDD to match this new style (take that, Eurasia...) 3) Make the test a little more lenient. Once the test passes again, we can add it back to the list of codingstd tests that are automatically run in 'lib/Parrot/Harness/DefaultTests.pm' [1] we are now checking all .t files that claim to be PIR as well; before it was just .pir [2] 25084 petdance # vim: expandtab shiftwidth=4 ft=pir: -- Will "Coke" Coleda
[perl #50802] .t files lying about their type..
# New Ticket Created by Will Coleda # Please include the string: [perl #50802] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50802 > the pir_code_coda.t is now checking both .pir files *and* .t files that claim to be PIR. The test for .t files is basically "does the shebang contain parrot" AND "does the shebang NOT contain a .pir or .pbc file?" (the second condition to avoid the one or two cases where this is used to interpret the file in another language.) However, some files are specifying this shebang improperly: compilers/nqp/t/01-literals.t, for example, has a shebang of: #!./parrot but contains a test file written in NQP, not PIR. Before we can re-enable the pir_code_coda test, these files need to be updated to have a proper shebang. This may involve updated the aforementioned test found in Parrot::Distribution->is_pir() -- Will "Coke" Coleda
