On Wed, Jul 09, 2008 at 01:27:29AM -0400, Bob Rogers wrote:
>What "foo" should do is create a closure and call that:
>
> .const .Sub inner = 'inner'
> inner = newclosure inner
> inner()
If I understand what you're saying, and then take it to what I see
as its ultimate conclu
[typo clarification]
On Wed, Jul 09, 2008 at 08:25:52AM -0500, Patrick R. Michaud wrote:
> [...] If we now say that a newclosure op is required to invoke 'foo',
> then that means that the 'foo()' HLL subroutine has to be generated as:
>
> .local pmc $P0
>
On Wed, Jul 09, 2008 at 04:46:19PM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>...
>If we now say that a newclosure op is required to invoke 'foo',
>then that means that the 'foo()' HLL subroutine
On Wed, Jul 09, 2008 at 03:45:31PM -0700, chromatic wrote:
>
> That example is fine with me. I almost deleted all of the hijinks necessary
> in Closure PMC to attach to a never-initialized outer lexical scope before I
> read the lexical spec again and realized that someone designed it that way.
On Wed, Jul 09, 2008 at 04:46:19PM -0400, Bob Rogers wrote:
Content-Description: message body text
>In effect this is little different from having 'foo' as an immediate
>block. If we now say that a newclosure op is required to invoke 'foo',
>then that means that the 'foo()' HLL subrou
On Thu, Jul 10, 2008 at 12:29:57AM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Wed, 9 Jul 2008 18:49:53 -0500
>
>On Wed, Jul 09, 2008 at 04:46:19PM -0400, Bob Rogers wrote:
>> Not true. The compiler always k
On Thu, Jul 10, 2008 at 11:20:44AM -0700, Will Coleda wrote:
> # New Ticket Created by Will Coleda
> # Please include the string: [perl #56806]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=56806 >
>
>
> pynie's test s
On Thu, Jul 10, 2008 at 09:35:29PM -0400, Bob Rogers wrote:
> Hmm. I have been assuming that when you say "taking a closure", that is
> equivalent to "using *the* closure" for a given :outer context. It's
> beginning to dawn on me that this might not be what you mean; more
> below.
I think I'm n
On Thu, Jul 10, 2008 at 06:50:51PM -0700, chromatic wrote:
>
> Here's a first approach. It breaks a couple of tests, but it's a start:
>
> t/pmc/object-meths (Wstat: 1280 Tests: 37 Failed: 5)
> Failed tests: 1-4, 16
> t/oo/proxy (Wstat: 256 Tests: 5 Fai
On Thu, Jul 10, 2008 at 09:51:40PM -0500, Patrick R. Michaud wrote:
> Perl 6 disallows having multiple subs of the same
> name unless they are explicitly declared 'multi' or
> the later subs provide the "is instead" trait [1].
Oops, I cut off the reference while send
On Thu, Jul 10, 2008 at 11:23:03PM -0400, Bob Rogers wrote:
>All I'm really wanting to know is what
>PIR the compilers and tools should be emitting for these very
>common Perl 6 constructs, and to have that PIR work in Parrot.
>
> Seriously, though, I've been wanting to learn more abou
On Thu, Jul 10, 2008 at 11:06:55PM -0500, Patrick R. Michaud wrote:
>
> I _think_ [methods and subs] are the only two cases where we
> have to do something like this, and I guess they aren't too onerous.
I was wrong, the third case is MultiSubs, and at the moment
it's _ver
On Fri, Jul 11, 2008 at 04:49:55PM -0400, Bob Rogers wrote:
>Based on what Bob has been saying, I can't now think of a case where
>an inner closure _shouldn't_ go ahead and have its outer_ctx set
>whenever an outer sub is invoked . . .
>
> Foul! That's exactly what r28763 does to break
On Fri, Jul 11, 2008 at 04:49:55PM -0400, Bob Rogers wrote:
Content-Description: message body text
>This is certainly not the case for recursive subs. Consider the
> attached example, a lightweight Perl 5 dumper. (It is slightly
> artificial to break the recursive step out into a sub, but tha
On Sat, Jul 12, 2008 at 01:11:12AM +0200, Jonathan Worthington wrote:
> This is consistent with my view of the specified Perl 6 semantics[1] for
> closure handling. I translated Bob's Perl 5 example into PIR and put
> newclosure where the Perl 6 specification would suggest to put it and it
> pro
On Sat, Jul 12, 2008 at 03:29:31AM +0200, Jonathan Worthington wrote:
> But I'm not convinced that
> we always take clones on referencing a block in Rakudo (OK, I've not
> gone and looked, but I can't remember seeing anything that explicitly
> does that, and I spend a lot of time staring at Raku
On Fri, Jul 11, 2008 at 10:04:54PM -0400, Bob Rogers wrote:
> Absolutely, but that's not where the problem lies. The problem is that
> r28763 did so implicitly and unconditionally, overwriting anything
> newclosure might have done. If you meant "have its outer_ctx set
> I whenever an outer sub is
On Fri, Jul 11, 2008 at 08:00:40PM -0700, Bob Rogers via RT wrote:
>Of course, if cloning works the same as newclosure than we don't
>need an explicit newclosure for the examples given, because
>assignment already makes a clone.
>
> Assignment seems to do assign_pmc, which for a clos
On Sat, Jul 12, 2008 at 01:07:20AM -0700, chromatic wrote:
> > And again, under my proposal I've been saying (apparently
> > ineffectively) that "autoclose" would be gone entirely, and
> > invoking a Closure that hasn't already had its context captured
> > (i.e, outer_ctx is NULL) will throw an exc
On Sat, Jul 12, 2008 at 12:30:02AM -0400, Bob Rogers wrote:
> ... But, as I quoted you:
>
> . . . if cloning works the same as newclosure than we don't need
> an explicit newclosure . . .
>
> Which seems to say something entirely different. So I thought I should
> point out that clon
On Sat, Jul 12, 2008 at 08:50:44AM -0700, chromatic wrote:
> On Saturday 12 July 2008 08:06:33 Patrick R. Michaud wrote:
>
> > Short answer: cloning is what will enable the following to work:
> >
> > for 1..10 -> $x {
> > sub foo() { say $
On Sat, Jul 12, 2008 at 11:05:35AM -0500, Patrick R. Michaud wrote:
> On Sat, Jul 12, 2008 at 08:50:44AM -0700, chromatic wrote:
> > On Saturday 12 July 2008 08:06:33 Patrick R. Michaud wrote:
> > > Short answer: cloning is what will enable the following to work:
> > >
On Sat, Jul 12, 2008 at 08:47:32PM -0500, Patrick R. Michaud wrote:
> On Sat, Jul 12, 2008 at 11:05:35AM -0500, Patrick R. Michaud wrote:
> > On Sat, Jul 12, 2008 at 08:50:44AM -0700, chromatic wrote:
> > > On Saturday 12 July 2008 08:06:33 Patrick R. Michaud wrote:
> > &g
On Sat, Jul 12, 2008 at 11:00:29AM -0700, James Keenan via RT wrote:
> On Sat Jul 12 09:33:35 2008, coke wrote:
> >
> > Another solution here would be to not run them by default. The purpose
> > of 'make test'
> > should be to verify that the parrot functionality works on the target
> > system.
>
On Tue, Jul 15, 2008 at 11:17:23PM +0200, Leopold Toetsch wrote:
> 21:51 < pmichaud> so unicode:"«" and unicode:"\xab" would produce
> exactly
> the same result.
> 21:51 < pmichaud> even down to being the same .pbc output.
> 21:51 < allison> pmichaud: exactly
>
> The former is a valid char
On Sun, Jul 27, 2008 at 10:08:06AM -0700, Geoffrey Broadwell wrote:
> In the source repository, the 'parrot' in runtime/parrot/foo is
> pointless. It's a singleton directory, and it's redundant.
I think that the point of runtime/parrot/ is that we may also
someday have runtime/perl6/, runtime/pyn
On Thu, Jul 31, 2008 at 10:07:49AM +0100, Klaas-Jan Stol wrote:
> On Wed, Jul 30, 2008 at 9:06 PM, via RT Will Coleda wrote
> > From PDD19:
> >
> > =item .pragma n_operators [deprecated]
>
> does this mean that by default all ops will have the n_ prefix by default?
> That would imply some variants
On Sat, Aug 02, 2008 at 09:31:44AM -0700, Allison Randal via RT wrote:
> > Committed a fix to tcl in branch (r29940) to pull from the correct
> > slot. All tests now pass. I'd like to see this segfault/assert/boom
> > addressed before we merge back, just in case.
>
> Resolved in r29941, by throwin
On Tue, Aug 05, 2008 at 10:51:08AM -0700, Klaas-Jan Stol wrote:
> From pdd19:
>
> The optional C<:unique_reg> modifier will force the register allocator to
> associate the identifier with a unique register for the duration of the
> subroutine.
>
>
> This, however, does not document /why/ you wou
On Thu, Aug 07, 2008 at 10:15:24AM -0400, Will Coleda wrote:
> Now, if the problem is that the register allocator is broken, then
> let's fix the register allocator. If :unique_reg is just a workaround
> because fixing it is hard, let's document it as deprecated with the
> expectation that it will
On Tue, Aug 12, 2008 at 02:14:07PM +0200, Allison Randal wrote:
> Will Coleda wrote:
>> I agree that any removed feature should have a deprecation cycle;
>> Here's my pitch for how we've already done that; the list of
>> deprecated features has RTs; the RT listed what was going to have to
>> happen
On Sat, Aug 16, 2008 at 07:16:19PM -0700, mhelix wrote:
> Passing PMCs as named arguments fails when the called sub accepts
> optional positional arguments unless all optional arguments are
> passed. On my tests this bug only affected PMC arguments.
> Passing an int, float or string works flawle
On Sun, Aug 17, 2008 at 10:21:18PM -0400, Bob Rogers wrote:
>From: James E Keenan <[EMAIL PROTECTED]>
>Date: Sun, 17 Aug 2008 19:55:02 -0400
>
>Yes, when one of the 'make codingstd_tests' accumulates sufficient
>PASSes, we promote it to 'make test'. Those that are not yet passing
Here's a simple test for resumable exceptions that I'm trying
to get to work. I'm probably coding/understanding something wrong,
so any suggestions or pointers would be greatly appreciated.
.sub main :main
push_eh catcher
'foo'()
pop_eh
say 'ok 4'
.ret
On Fri, Aug 22, 2008 at 02:27:12PM -0700, Stephen Simmons wrote:
> ---
> make failed on the following compilation, on revisions 30353 and 30457
> (and a couple of others in between). Additional information follows
> this output listing.
>
> --
> gcc -o miniparrot src/main.o src/null_c
On Tue, Aug 26, 2008 at 11:42:51PM +0300, luben karavelov wrote:
> I can run the NQP generated PIR after addition of:
>
> load_bytecode 'compilers/nqp/nqp.pbc'
>
> in the first sub. But I can not find how to run rakudo generated PIR
> code. The "load_bytecode" seems no be not enought (some months
On Thu, Aug 28, 2008 at 02:10:27PM +0200, Reini Urban wrote:
> Open problem:
> For language pbc's a new dir like script_dir or lib_dir/parrot/bin
> would be required.
> They could also pollute $(DESTDIR)@lib_dir@/parrot/library where the other
> pbc's are.
> The language group and op shared libs go
Two other items that ought to be taken into consideration:
- We need an implementation of the :lookahead flag for Rakudo.
(See discussion thread at [1].)
- Per a conversation with Allison and Jonathan at YAPC::EU, it might
be useful to have a :capture flag on parameters and return
valu
On Thu, Aug 28, 2008 at 11:10:47PM +0200, Allison Randal wrote:
> That's backwards. Loading the language module is what registers the
> compiler. The user never needs to access the compiler object for a
> particular language directly unless they're compiling code from a string.
...or if they w
On Fri, Aug 29, 2008 at 06:10:21PM +0200, Reini Urban wrote:
> 2008/8/29 Allison Randal:
> > Reini Urban wrote:
> >> Current exceptions for the "parrot-" prefix:
> >> perl6
> >
> > Actually, that probably won't be an exception to the "parrot-" prefix on the
> > package name, since there are multip
On Sat, Aug 30, 2008 at 07:45:08AM -0700, Allison Randal via RT wrote:
> As mentioned in RT #49168, I'm in favor of a --language flag,
> that selects the default PBC/PIR file to run, and passes all other
> arguments to the ':main' sub in that file. It can also select default
> paths based on the
On Thu, Sep 04, 2008 at 09:48:09AM -0700, chromatic via RT wrote:
> > I don't think we need any specialized opcodes for this -- simply
> > being able to introspect and dynamically modify the current
> > interpreter's HLL mapping tables ought to be sufficient.
> >
> > (Introspection of HLL mappings
On Thu, Sep 04, 2008 at 08:31:10AM -0700, James Keenan via RT wrote:
> On Thu Sep 04 06:33:41 2008, pmichaud wrote:
> > I just wanted to comment that I see this problem on my Kubuntu system as
> > well -- when running Configure.pl, I consistently get to the step for
> > AIO and things hang (until I
On Thu, Sep 04, 2008 at 12:25:36PM -0500, Patrick R. Michaud wrote:
> On Thu, Sep 04, 2008 at 09:48:09AM -0700, chromatic via RT wrote:
> > > I don't think we need any specialized opcodes for this -- simply
> > > being able to introspect and dynamically modify the curre
On Thu, Sep 04, 2008 at 04:52:34PM -0700, James Keenan via RT wrote:
> I applied the patch attached, aio.in.revised.patch.txt, in r30771. I
> set the 'sleep' to 4 seconds. All the tests have been reactivated.
Thanks.
> This is a patch in the sense of "bandaid". What is it about the letter
> 'K
PDD23:41 says
: =item B>
:
: Push an invocable PMC -- usually a closure or, in rarer cases, a subroutine or
: continuation -- onto the exception handler stack.
: ...
: If a I is provided, Parrot pushes the pmc which will execute
: if invoked, which has the effect of unconditionally handling all e
PDD23:67 has:
: =item B>
:
: Throw an exception consisting of the given I PMC. Active exception
: handlers (if any) will be invoked with I as the only parameter.
:
:
: =item B [ , I ]>
:
: Throw an exception consisting of the given I PMC after taking
: a continuation at the next opcode. When
On Mon, Sep 08, 2008 at 09:28:47AM -0700, NotFound via RT wrote:
> The code in this ticket does not parse. Is using obsolete syntax? Can
> someone provide an updated version?
Perhaps:
.sub main
.local pmc foo
foo = get_global 'foo'
foo('x' => 1, 'y' => 2)
On Tue, Sep 09, 2008 at 08:46:33AM -0400, Andy Dougherty wrote:
> Parrot's also not using AIO anywhere either, so the whole probe is kind of
> pointless right now. Mainly, I was just hoping that a minor fix would
> help solve Patrick's problem of Configure.pl hanging during the aio probe.
> I
On Fri, Sep 05, 2008 at 05:20:45PM -0700, Christoph Otto via RT wrote:
> > On Tue, May 13, 2008 at 9:48 AM, via RT Patrick R. Michaud
> > > The infix and n_infix opcodes cause segfaults when invoked with
> > > string arguments. (Kubuntu 8.04, x86, r27472)
> > &
Patch rejected; the patch appears to eliminate "Perl6Scalar"
entirely from the 'is copy' semantics, this means we'd be without
an appropriate Scalar container for something like
sub foo($a is copy) { ... }
In general I think much of the signature handling in Rakudo needs
a significant refact
On Thu, Sep 11, 2008 at 08:11:50AM -0400, James E Keenan wrote:
> Is it just me ...?
>
> When I went to rt.perl.org just now to reply to a ticket, I could not
> find the toggle for automatically CC-ing [EMAIL PROTECTED] I
> know it was there just last night. I am clearly logged in to RT. Wh
On Wed, Sep 10, 2008 at 07:53:13PM -0700, James Keenan via RT wrote:
> Patrick:
>
> Where do we stand in the deprecation cycle re these three methods?
I probably just need to remove the methods from the code,
see what breaks, and fix what breaks. I'll try to do that this
weekend before the relea
On Fri, Sep 12, 2008 at 03:47:27PM +0200, NotFound wrote:
> >> Defining the hash entries for the subs in PIR syntax is awful.
> >> So I envision Makefile.pl, Makefile.nqp or Makefile.p6 for this syntax.
> >> For p6 we must ensure that every parrot package has a perl6 also then. Not
> >> good.
> >>
On Sat, Sep 13, 2008 at 09:09:58AM -0400, Will Coleda wrote:
> > --- trunk/include/parrot/exceptions.h (original)
> > +++ trunk/include/parrot/exceptions.h Fri Sep 12 21:05:37 2008
> > @@ -87,7 +87,8 @@
> > CONTROL_OK,
> > CONTROL_BREAK,
> > CONTROL_CONTINUE,
> > -
On Sat, Sep 13, 2008 at 01:55:05PM -0400, Will Coleda wrote:
> >> > +CONTROL_TAKE
> >> > } exception_type_enum;
> >>
> >> Tcl can currently deal with OK, CONTINUE, BREAK, ERROR, and RETURN.
> >>
> >> What's TAKE?
> >
> > TAKE is like CONTROL_RETURN except that it signals that we expect
> >
On Sun, Sep 14, 2008 at 12:41:42AM -0700, Christoph Otto via RT wrote:
>
> I got impatient and committed this as r31101. I'm marking this ticket
> as resolved.
According to [1], r31101 causes Rakudo to stop building with the
following error:
$ make
../../parrot
/home/pmichaud/parrot/trunk/ru
On Tue, Sep 16, 2008 at 10:14:24PM +0200, Allison Randal wrote:
>
> Okay, PDD cleaned up. The code to directly support throwing any
> arbitrary type would require significant circumlocution (read:
> inefficient, difficult to maintain), so it's not desirable.
> [...]
> But, an individual HLL ca
On Tue, Sep 16, 2008 at 11:45:17PM +0200, Allison Randal wrote:
> Patrick R. Michaud wrote:
>>>>> What's TAKE?
>>>> TAKE is like CONTROL_RETURN except that it signals that we expect
>>>> execution to continue after the point of the TAKE. It
On behalf of the Parrot team, I'm proud to announce Parrot 0.7.1
"Manu Aloha." Parrot (http://parrotcode.org/) is a virtual machine aimed
at running all dynamic languages.
Parrot 0.7.1 is available via CPAN (soon), or follow the download
instructions at http://parrotcode.org/source.html . For tho
On Wed, Sep 17, 2008 at 10:57:31AM +0200, Allison Randal wrote:
> Patrick R. Michaud wrote:
>>
>> I'm not sure about this last comment -- I think I can imagine
>> that other language implementations (including new ones we haven't
>> thought of yet but suddenl
On Wed, Sep 17, 2008 at 08:08:47PM +0200, Reini Urban wrote:
> http://www.parrotcode.org/release/devel still points to 0.7.0
I sent the appropriate patch to the webmaster, but it hasn't
been applied yet (and I lack a commit bit for the parrotcode.org site).
Once that's applied, the url should be f
On Thu, Sep 18, 2008 at 09:23:50AM +0200, Allison Randal wrote:
>>
>> What's the language-agnostic term for this, then?
>
> Well, 'gather' is basically a clever use of a coroutine, and 'take' is
> basically a 'yield'. But, what's unique about the construct is that it
> aggregates the results. S
On Thu, Sep 18, 2008 at 09:06:44AM -0700, jerry gay wrote:
> On Thu, Sep 18, 2008 at 8:37 AM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote:
> > On Thu, 2008-09-18 at 07:34 -0500, Patrick R. Michaud wrote:
> >> > "Aggregating coroutine" and "aggregati
On Thu, Sep 18, 2008 at 11:00:31AM +0200, Allison Randal wrote:
> We'll likely end up with messages scattered between both lists for a
> little while, but the perl6-internals/parrot-porters addresses are
> deprecated and will be disabled after a sensible deprecation cycle (and
> after the automa
I've put together a draft with my ideas and design for
(re-)implementing lexicals in Parrot -- now available at
http://www.pmichaud.com/perl6/lexical.txt .
It's a first draft and might be a bit confusing in places,
but overall I think it's a far cleaner design than the
current implementation but
On Tue, Sep 23, 2008 at 08:47:15PM -0700, chromatic wrote:
> On Thursday 18 September 2008 06:13:30 Patrick R. Michaud (via RT) wrote:
> > When generating PIR output (e.g., from the compiler tools), we
> > often need to convert a Float value into an equivalent representat
On Wed, Sep 24, 2008 at 12:09:37PM +0200, François Perrad wrote:
> Currently, the bigger issue in Lua on Parrot is lexical or upvalue in
> Lua jargon (the reason for Lua on Parrot is not really Lua).
> The following Lua code doesn't give the expected result (from
> languages/lua/t/closure.t) :
On Tue, Sep 23, 2008 at 03:45:37AM -0500, Patrick R. Michaud wrote:
> I've put together a draft with my ideas and design for
> (re-)implementing lexicals in Parrot -- now available at
> http://www.pmichaud.com/perl6/lexical.txt .
Earlier today chromatic asked about recursion in
On Wed, Sep 24, 2008 at 10:05:25PM +0200, Stéphane Payrard wrote:
> One of parrot current limitation is that eval is always a closure.
> When using rakudo interactively, one want to introduce new
> lexical variable that are not lost when accessing them from the
> next prompt.
> Pugs gets that rig
On Thu, Sep 25, 2008 at 12:10:35AM +0200, Reini Urban wrote:
> 2008/9/24 Patrick R. Michaud <[EMAIL PROTECTED]>:
> > So, in order to get the behavior you're describing from the interactive
> > prompt, we'll probably need more than just Perl 6's 'eval
On Wed, Sep 24, 2008 at 05:00:31PM -0700, jerry gay wrote:
> On Wed, Sep 24, 2008 at 4:31 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > They're not really methods in any PIR or C sense though (I usually use the
> > term "entry"), as they're not really inherited nor invoked through a
> > dispatch sc
On Wed, Sep 24, 2008 at 10:11:07PM -0400, Bob Rogers wrote:
> Just a few:
>
>1. In the translation of your Perl 6 example in "Runtime part 3:
> Closures and cloning", I notice that you do "get_global 'bar'" twice:
>
> .sub 'foo'
> ## bind inner sub 'bar' to current lexical envir
On Wed, Sep 24, 2008 at 10:44:23PM -0600, Tom Christiansen wrote:
> In-Reply-To: Message from Geoffrey Broadwell <[EMAIL PROTECTED]>
> > Don't we have to solve all this to get the Perl 6 debugger
> > working anyway?
>
> Although I'm unsure why that might be, I also recognize the possibility
> th
On Thu, Sep 25, 2008 at 05:05:16AM -0700, Vasily Chekalkin via RT wrote:
> This bug caused by "runops_args" which doesn't populcate
> interp->current_args which used in "mmd_arg_tuple_func" to calculate
> signature for MMD.
chromatic has suggested that we should wait for the pdd27mmd branch
to mer
On Fri, Sep 26, 2008 at 07:25:35AM -0700, Chris Davaz wrote:
> Fixed a bug in the doc where the method name and doc where mismatched.
Thanks.
> Fixed a small bug where, even if the user sets the prompt, a default
> prompt '> ' is still printed. Changed it so that a default prompt is
> only printe
> Cardinal's works fine, but with this patch, rakudo hangs while building.
> Specifically, on parrot -o perl6.pbc perl6.pir.
Oddly, if I comment out the builtins (line 25):
.include 'src/gen_builtins.pir'
then perl6.pbc compiles just fine. It doesn't run, of course,
because the builtins are
On Thu, Oct 02, 2008 at 04:51:32PM +0100, Nick Glencross wrote:
> NotFound,
>
> That would look cleaner, wouldn't it? I'll give it a go.
>
> Nick
>
> On Thu, Oct 2, 2008 at 3:35 PM, NotFound <[EMAIL PROTECTED]> wrote:
> > I think will be better the other way, using the return value to flag
> > e
On Thu, Oct 02, 2008 at 02:16:01PM -0700, I Sop wrote:
>
> I just copied the 'attribute' method, renamed everything, and changed the
> parameter order for the 'getprop' op.
Why should this be a PAST::Var node as opposed to simply using a
PAST::Op node with :pirop('getprop') and/or :pirop('setpr
On Fri, Oct 03, 2008 at 01:23:14AM -0700, [EMAIL PROTECTED] wrote:
> +parrotclass = split '::', $S0
> +$P0 = getinterp
> +$P0 = $P0['namespace';1]
> +$P0 = $P0.get_name()
> +$P0 = shift $P0
> +unshift parrotclass, $P0
> +parrotclass = get_root_namespace [parrotclass]
Th
On Fri, Oct 03, 2008 at 06:23:42AM -0700, I Sop wrote:
> > From: Patrick R. Michaud via RT <[EMAIL PROTECTED]>
> > On Thu, Oct 02, 2008 at 02:16:01PM -0700, I Sop wrote:
> > >
> > > I just copied the 'attribute' method, renamed
> > &
We seem to have lost the svn-commit mail updates, I haven't seen
a svn-commit message since r31606 on October 3 (parrot is
currently at r31676).
Any chance we get could this back? For me it's much easier to
review commits and patches arriving by email than to have to
go manually look them up via
On Mon, Oct 06, 2008 at 06:05:20AM -0700, NotFound via RT wrote:
> I've done some work in this problem. The attached patch is a way to make
> the examples work but I think this is not the way to go, or a lot of
> functions in a lot of pmc will need changes.
> [...]
I agree this really isn't the wa
Just for the record, I went ahead and added a version of my
test script in this ticket to the test suite (t/pmc/complex.t).
(The test still fails as of r31755, let me know if it should
be marked 'todo'.)
Thanks,
Pm
On Tue, Oct 07, 2008 at 05:47:57PM -0700, Mark Glines via RT wrote:
> On Tue Oct 07 08:14:04 2008, pmichaud wrote:
> > Just for the record, I went ahead and added a version of my
> > test script in this ticket to the test suite (t/pmc/complex.t).
> >
> > (The test still fails as of r31755, let me
On Sat, Oct 11, 2008 at 07:59:31PM -0700, Will Coleda wrote:
> After building parrot, cd compilers/tge && make test;
>
> Test Summary Report
> ---
> ../../t/compilers/tge/basic.t (Wstat: 256 Tests: 3 Failed: 1)
> Failed test: 1
> Non-zero exit status: 1
> ../../t/compilers/tg
I'm a little reluctant to commit to any specific modifications
to optables at the moment because much of this will be significantly
refactored in the relatively near future as part of implementing
protoregexes and longest token matching into PGE.
As that's being done, I suspect we may discover a
On Wed, Oct 15, 2008 at 10:02:39AM -0700, chromatic wrote:
> On Wednesday 15 October 2008 05:54:59 Will Coleda wrote:
>
> > The namespace of the generated file should be changed, the subclass
> > should probably be updated. (TGE itself should probably be updated to
> > not live a namespace with a
On Mon, Oct 20, 2008 at 09:42:12AM -0700, jerry gay wrote:
> >> However, in digging further, I found this:
> >>
> >> perl t/harness --verbosity 1 t/02-test-pm/1-basic.t
> >>
> testtest and 02-test-pm/ should either be ripped out or heavily modified.
> it was intended to be tests required to pass
> >> The big hangup for this ticket is that various parts of PCT and the
> >> CodeString PMC do not support empty brackets, and therefore PCT does not
> >> emit ".namespace []" in these situations.
> >> [...]
> >> I know pmichaud was talking about a major rewrite of PGE in the future,
> >> maybe t
On Sat, Oct 18, 2008 at 07:40:36AM -0700, Andrew Whitworth via RT wrote:
> On Sat Oct 18 07:38:32 2008, Whiteknight wrote:
> > > On Wed Sep 17 09:50:10 2008, kjs wrote:
> > I've added ".tailcall" syntax to IMCC. It is supposed to be used instead
> > of ".return" in tailcall context. Using ".return"
On Tue, Oct 21, 2008 at 12:21:24AM -0700, Ovid wrote:
> --- On Tue, 21/10/08, James Keenan via RT <[EMAIL PROTECTED]>
> Thanks. Hopefully this time there will be some traction because there
> does appear to be a bug in Perl 6, as evidenced by this one-liner:
>
> perl6 $ ../../parrot perl6.pbc
On Tue, Oct 21, 2008 at 11:01:21AM -0700, Andrew Whitworth via RT wrote:
> On Tue Oct 21 10:47:43 2008, Whiteknight wrote:
> > On Tue Oct 21 07:53:35 2008, pmichaud wrote:
> > > As of r31667 (pre-mmd), the following worked:
> > >$P0 = subclass 'Integer', 'MyInt'
> > >$P1 = new 'MyIn
On Thu, Oct 23, 2008 at 12:38:36AM -0700, chromatic wrote:
> On Wednesday 22 October 2008 22:49:37 Patrick R. Michaud (via RT) wrote:
>
> This patch fixes things for me, with minimal fuss and without inadvertently
> adding back in ops that we explicitly blacklist via src/ops/ops.
On Thu, Oct 23, 2008 at 08:04:41PM -0700, Allison Randal wrote:
>
> I don't understand the problem. Is it that you expect 'rethrow' to keep
> the stack trace of the original 'die'?
...this is what I would expect. If I catch and then rethrow an
exception, I'd expect the stack trace to continue t
On Fri, Oct 24, 2008 at 12:18:40PM -0700, Allison Randal wrote:
> (I suppose technically we should stop calling this a "stack trace" since
> it's not a stack. But "return continuation chain trace" is just too
> verbose.)
"backtrace"
Pm
On Sun, Oct 26, 2008 at 09:37:36PM -0400, Bob Rogers wrote:
> .sub 'main' :main
> foo('Hello')
> .end
> .sub foo :multi(String)
> .param pmc s
>
> say s
> .end
> [...]
>Which brings us to an interesting question: How can you decide wha
On Sat, Oct 25, 2008 at 06:50:29AM -0700, François PERRAD via RT wrote:
>
> In fact, perl6.exe contains some dependencies on build tree.
> Just after a build, perl6.exe works :
This is a known item -- see line 32 of languages/perl6/README:
This binary executable feature is still somewhat exp
On Sun, Oct 26, 2008 at 10:05:21PM -0700, Vasily Chekalkin wrote:
> Exception handling in parrot doesn't unwind used stack frames.
>
> Simple example:
>
> .sub 'main'
> .local pmc i
> i = new 'Integer'
>do_loop:
> say i
> push_eh do_inc
> $P0 = find_method i, "succ"
>
On Tue, Oct 28, 2008 at 10:15:32PM -0500, Patrick R. Michaud wrote:
> ... As discussed in #parrotsketch
> earlier today and summarized at [1], the correct form of the
> above loop would have the "pop_eh" line after the do_inc label,
> so that every exception handler created
1 - 100 of 830 matches
Mail list logo
