On May 21, 2007, at 5:56 PM, Will Coleda wrote:
I was talking to a colleague (who wishes to remain anonymous), and
s/he had a list of questions about the state of parrot that I think
should end up in the FAQ or elsewhere in the repo. I wanted to post
them here to get some discussion - I don't
If you have a Sub PMC (or subclass), you can invoke that PMC from C code using
Parrot_call_sub() or a similar function. Of course, if you want to pass
arguments to that PMC, something needs to translate those arguments from C's
calling conventions to Parrot's calling conventions.
That somethin
On Tue, May 22, 2007 at 10:32:23PM -0400, Will Coleda wrote:
>
> On May 22, 2007, at 10:05 PM, Patrick R. Michaud wrote:
>
> >And I'm really
> >not sure how to create a Perl6Sub from PIR source code.
>
> We're already doing this in tcl.
>
> See src/class/tclproc.pir for the PIR class which has
On May 22, 2007, at 10:05 PM, Patrick R. Michaud wrote:
And I'm really
not sure how to create a Perl6Sub from PIR source code.
We're already doing this in tcl.
See src/class/tclproc.pir for the PIR class which has Sub for a
parent class.
runtime/builtin/proc.pir then puts this to use:
On May 21, 2007, at 7:15 PM, James E Keenan wrote:
Will Coleda wrote:
If you notice any missing documentation, please open an RT ticket
with [DOCS] in the subject. ((It won't be processed specially by
RT, but will help me search.)) Ask on the list. Send patches,
either to the parrot repo
On Tue, May 22, 2007 at 04:42:15PM -0700, Allison Randal wrote:
> Patrick R. Michaud wrote:
> >
> >Now then, this assumes that every type knows how to morph itself
> >into an .Undef and that .Undef can handle assignment from any type.
> >For many PMC classes this isn't (or hasn't been) the case; fr
chromatic wrote:
Instead of printing "done" at the end of code, the *_output_*() test functions
now check that Parrot's exit code is zero. This prevents the test suite from
eating segfaults, as it used to.
If you want to test that Parrot exits with an error given buggy code, use the
*_err
On Sunday 20 May 2007 15:45:57 James Keenan wrote:
> The patch attached reflects the approach we've been taking over the
> last half-year or so in testing the Perl 5 components of Parrot.
> Feedback encouraged.
Instead of printing "done" at the end of code, the *_output_*() test functions
now ch
This file implements most of the Parrot debugger. The interpreter struct has
a slot called pdb that contains a PDB_t (parrot/debug.h).
This file is somewhat messy. It has some string manipulation functions
(nextarg(), skip_ws(), parse_int(), parse_string()) that should probably go
elsewhere.
On Friday 18 May 2007 08:49:20 Klaas-Jan Stol wrote:
> Attached a new version of the patch, I did some more work on cleaning up
> and commenting where I could (going top-down, so not for long finished...
> hint hint)
Thanks, applied as r18623 with some mangling because I forgot to apply this
bef
On Saturday 19 May 2007 23:55:57 Mehmet Yavuz Selim Soyturk wrote:
> file: editor/kate_syntax.pl
>
> * .ops files are now searched in the correct path
> * single-quoted string literals are ended correcty
Thanks, applied as r18626.
-- c
Steve Peters wrote:
# New Ticket Created by Steve Peters
# Please include the string: [perl #43031]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43031 >
Creating new instance variables after a new is never good. The at
Leo,
In the discussion around RT #41291, I think I heard you say something about
the code:
CONTEXT(interp->ctx)->constants =
PMC_sub(sub)->seg->const_table->constants;
(seen for example in Parrot_call_sub() in src/extend.c). Do I remember
correctly that you called this an optimiza
On Tuesday 22 May 2007 13:41:47 Steve Peters wrote:
> Creating new instance variables after a new is never good. The attached
> patch is needed before things can start to be moved around.
I moved the 'defines' initialization too.
Thanks, applied as r18625.
-- c
On Friday 18 May 2007 15:40:30 Eric Hanchrow wrote:
> Add a new TODO test for iterator cloning: make sure that we're not
> accidentally copying the entire array. (Since this test currently
> fails, I fear that we _are_ copying the entire array :-( )
I have the same fear.
Thanks, applied as r186
# New Ticket Created by Steve Peters
# Please include the string: [perl #43033]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43033 >
free() assumes its passed a void *. mem_sys_free() should take the same type
of argumen
On Tue, May 22, 2007 at 01:41:32PM -0700, Allison Randal wrote:
> Oh, could someone capture that IRC discussion we just had and paste it
> on the list?
Here it is (long, 247 lines).
Pm
19:45 I know I should already know this, but is there a way to make
a named function that is global to al
Oh, could someone capture that IRC discussion we just had and paste it
on the list?
Allison
# New Ticket Created by Steve Peters
# Please include the string: [perl #43031]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43031 >
Creating new instance variables after a new is never good. The attached
patch is needed
Some additional suggestions for S02:
--
@@ -740,9 +740,9 @@
Range A pair of Ordered endpoints; gens immutables when iterated
Set Unordered group of values that allows no duplicates
Bag Unordered group of values that allows duplicates
-JunctionSets with a
Author: chromatic
Date: Tue May 22 13:29:31 2007
New Revision: 18622
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/include/parrot/objects.h
trunk/src/objects.c
trunk/src/ops/var.ops
trunk/src/pmc/fixedpmcarray.pmc
Log:
On Tue, May 22, 2007 at 08:20:19AM -0500, Patrick R. Michaud wrote:
> On Tue, May 22, 2007 at 01:25:33PM +0100, Nicholas Clark wrote:
> >
> > And how often does the type of a PMC change, such that its internal
> > data layout changes? In Perl 5 this morphing happens everywhere,
> > but in Parrot
On Tue, May 22, 2007 at 01:25:33PM +0100, Nicholas Clark wrote:
>
> And how often does the type of a PMC change, such that its internal
> data layout changes? In Perl 5 this morphing happens everywhere,
> but in Parrot?
Actually, until/unless we have a "scalar container" or "reference"
PMC of s
On Mon, May 21, 2007 at 06:48:25PM -0700, Allison Randal wrote:
> On variable-sized PMCs, I generally agree with the goals the proposal is
> trying to accomplish, but I want to tackle these goals in a simpler way.
> One of the goals mentioned for the proposal was to shrink down the size
> of PM
24 matches
Mail list logo
