Hi all,
I'm gathering input on developer perspectives about CLAs and other
contribution policies. The primary motivation for the survey is an
active conversation around CLAs in the OpenStack project, but also some
personal curiosity on my part. It's been something like a decade since I
worked on
On 06/21/2013 10:07 AM, Jonathan Duke Leto wrote:
Howdy,
The future of Parrot and Rakudo Perl 6 are on divergent paths.
I am dedicated to a successful future for Parrot which is independent
of Rakudo Perl 6.
As soon as Rakudo Perl 6 works on MoarVM (the spiritual successor of
the m0 branch in
On 06/24/2013 04:34 PM, Darren Duncan wrote:
So you're saying then that Jonathan's post wasn't an official statement
from the Parrot dev team after the group decided what to do? It
certainly read that way to me.
Jonathan's statement on parrot-dev was the first I heard of it, and as
far as I
Okay, instead of just complaining about this, I want to do something
about it. The Rakudo packages are so fragile on Debian, that they need
special constraints to make sure the Parrot packages are held back until
the Rakudo packages are updated.
So, why is Rakudo so dependent on one specific
On 04/08/2012 10:01 AM, Alessandro Ghedini wrote:
The parrotapi-* thing would avoid an update of the parrot package, but there's
nothing that would avoid an update of, say, libdata-dumper-parrot, and it
would
leave the system with an older version of parrot and a newer version of the
On 04/08/2012 09:29 AM, Alessandro Ghedini wrote:
If we go down the split to different libraries path, those libraries should
depend on parrotapi-* too so that not only Parrot isn't updated but the
libraries aren't too. Or alternatively parrot should strictly depend on them.
Makes sense for
On 04/07/2012 12:34 PM, Jonathan Worthington wrote:
Easiest way to analyze it is just git log on
build/tools/PARROT_REVISION. Here I've done a very rough categorization
of the last 20 entries (which takes us back to October).
Some of them are to take advantage of Parrot feature additions:
On 04/08/2012 11:08 AM, Alessandro Ghedini wrote:
I think I don't understand... NQP and Rakudo *do* ship compiled bytecode, and
would of course need to be rebuilt when a new Parrot release is uploaded. The
whole point of parrotapi-* is to make sure that Parrot and its libraries are
not updated
On 04/08/2012 07:13 AM, Alessandro Ghedini wrote:
- Debian will package each supported release of Parrot.
Isn't this what's already happening? I mean, we already package stable Parrot
releases and therefore we can only package Rakudo releases that run on such
Parrot versions.
Just being
). Attached
git patch to fix the test target.
Allison
From 90672654a8f2600dbc8b67f4f46286d1ed2b7279 Mon Sep 17 00:00:00 2001
From: Allison Randal alli...@parrot.org
Date: Mon, 23 Feb 2009 18:03:30 -0800
Subject: [PATCH] Also fix t/harness to use installed Parrot executable when requested, instead
Christoph Otto wrote:
So you're saying that multiple inheritance in its current state should
be allowed to continue, and that there's only a problem with ATTRs if a
PMC tries to extend two PMCs, both of which have their own ATTRs?
I'm saying that multiple inheritance between two C-level
Christoph Otto wrote:
The PMC UnionVal deprecation can't be completed until Parrot has
improved ATTR
reuse between extending PMCs. I'm rewriting code to minimize dependence on
the PMC_x_val macros, but I can't eliminate them completely without better
inheritance support. I'd like to
Christoph Otto wrote:
Allison Randal wrote:
(Actually, at the moment you're required to declare
all parent attributes in the ATTR list before the child attributes, so
inherited attributes *are* child attributes.)
When I say attributes, I mean the things that are declared in .pmc
files right
Jonathan Worthington wrote:
I'm curious - is anyone else doing a HLL on Parrot that uses morph? If
nobody is, is it worth spending time on, or even worth keeping?
'morph' was added specifically for the Perl 5 behavior of changing types
when assigned to. But really, a more accurate
Patrick R. Michaud wrote:
Just for the record, AFAICT none of PGE/PCT/Rakudo make use of
morph any longer. We now have the 'copy' opcode to do what the
morph workaround was doing (and I don't think copy is using
VTABLE_morph).
We've been ripping out morph in all the core PMCs too. So, I'm
Christoph Otto via RT wrote:
I'm running into a snag trying to implement this. It turns out that
many lines which use the PMC_x_val macros use them on different types of
PMCs, especially parents and children (e.g. FixedPMCArray and
ResizablePMCArray). There are also some instances where the
Andrew Whitworth via RT wrote:
Okay, I did some work on this last night, and here's the current status.
1) Modified the behavior of the morph PIR override so that it takes a
string in trunk. We previously weren't able to override this method at
all, so nobody is used to the old way at the PIR
Bob Rogers wrote:
I can't log in, though that may just be because I've forgotten the
password. But the odd thing is that the Reset Password page says The
email and username do not match a known account, even though I know my
ID is rgrjr and there are only a few possible email addresses I would
Bob Rogers wrote:
What about those of us who can't log in? I can't even reset my
password, let alone update anything . . .
It won't let you log in at all? Or, once you log in it won't let you do
anything?
I just reset your password, let me know if you don't get an automated
email about
Our trac admins report that this is caused by users who don't have their
email authenticated (that is, Trac sends you a test email, and you
confirm that you got it, so Trac knows the address is valid). When we
upgraded, existing users needed to re-authenticate their email
addresses, but the
Allison Randal wrote:
Our trac admins report that this is caused by users who don't have their
email authenticated (that is, Trac sends you a test email, and you
confirm that you got it, so Trac knows the address is valid). When we
upgraded, existing users needed to re-authenticate their email
Will Coleda via RT wrote:
On Thu Aug 28 00:03:51 2008, alli...@perl.org wrote:
The plan is to make the regular variants (like 'add') create a new
destination PMC, and then deprecate the old n_* variants (like 'n_add').
Does this include n_not , n_bnot, and n_bnots ?
Yes. The 'not', 'abs',
Will Coleda via RT wrote:
Apparently remove the files isn't exactly what was meant here. This probably removes the
need for the remove_pic branch, which is in the process of taking this to its literal extreme.
We do need to remove the files, and the remove_pic branch is on the
right track.
Will Coleda via RT wrote:
I created a branch (remove_pic) to remove src/pic.c; This led to the removal of pic.ops, and
changes in imc, packfile... lots of references to PIC.
chromatic mentioned on #parrot that if we remove PIC, we're going to break all the
predereferenced runcores. After
chromatic wrote:
Within the cmp op bodies, we *know* the arity and most of the types of MMD-
participant arguments at compile time. We can get the types of PMC
participants within the body of the op itself. Thus we could avoid most of
the argument marshalling and counting and analysis if we
James Keenan via RT wrote:
On Wed Dec 17 13:29:59 2008, kjs wrote:
I thought I closed it last time. Trying again :-)
kjs
The ticket has 3 dependencies which are still open. Is it possible that
the ticket cannot be resolved until these dependencies are resolved?
Yes, but you can just remove
Will Coleda via RT wrote:
* Parrot_mmd_add_function
- src/inter_create.c //make_interpreter
Delete that line from src/inter_create.c. Also delete the line before
which initializes 'interp-binop_mmd_funcs' to NULL.
These two lines are initializing the storage for the old MMD subsystem,
Patrick R. Michaud via RT wrote:
Can (should) we do one or more of the following...?
1. Mark GC as a dependency for this ticket
2. Mark this ticket as stalled waiting for GC issues
3. Move this ticket to the new Trac ticket queue
This would help remove this from our active ticket queue,
Andrew Whitworth via RT wrote:
Since I'm monkeying around in the relevant code anyway, this might be
a good task for the next calling_conventions branch. Or, if you
prefer, we could create a second branch for this conversion and do the
work there.
The general consensus on this one is to wait
Will Coleda wrote:
Is the smoke server still used?
Can support for the smoke server be dropped?
+1 from me; I vote for smolder.
+1, on not maintaining two independent solutions for the same problem.
Allison
Will Coleda via RT wrote:
This appears to be the only .pragma; should we leave a placeholder or
just remove .pragma entirely when we remove this particular one?
Nuke it.
Allison
Martin D Kealey wrote:
What about keeping track of where the exception was originally created?
If we have lazy exceptions, then knowing where the fault they represent was
detected is probably more important than were (exactly) it was triggered.
Or does this all amount to the same thing? Is an
Andrew Whitworth via RT wrote:
On Tue Apr 22 10:05:57 2008, [EMAIL PROTECTED] wrote:
We've been kicking around the idea of removing new_from_string for a
while, but the pushback is always that it's useful to be able to create
a new PMC with some initialization data, without first creating a
Andrew Whitworth via RT wrote:
1) Rename this ticket to something more descriptive
2) Rename seatbelts.pod to something more descriptive, like
/docs/dev/C_Functions.pod or something.
3) Expand that documentation to include more cases (ARGIN, ARGMOD,
ARGOUT, all the *_NULLOK variants of those,
On Wed Oct 15 17:48:28 2008, Whiteknight wrote:
With the pdd27mmd branch merged in now, what's the status of this request?
The MMD table is now just a namespace, and namespaces are shareable
between interpreters. So, resolved.
Allison
Patrick R. Michaud wrote:
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
Exactly the word I was looking
Will Coleda wrote:
Allison Randal wrote:
...you expect 'rethrow' to keep the stack trace of the original 'die'?
Yes.
The way to do this is to add stack trace information to the Exception's
'stacktrace' attribute when the exception is first thrown, and print
that out for an unhandled
Will Coleda (via RT) wrote:
I would expect both of these programs to output the same thing, but it
looks like rethrow is generating the same output that throw would
here.
What is the difference supposed to be between these two ops?
The two ops are intentionally almost entirely the same. The
Ovid wrote:
I can't speak for Android, but I know one of the constraints on the
iPhone is memory. This, as I recall, is part of the reason why they
don't have garbage collection available and force people to manage
memory directly (this, I might add, is a pain). Since I generally
don't worry
chromatic (via RT) wrote:
Several tests fail with the CGP runcore (parrot -C) when multidispatch
re-enters bytecode -- in specific, anything that calls into src/pic.c from
Parrot_pcc_invoke_sub_from_sig_object causes failures.
The problem appears to be that CGP's PIC tries to poke into the
On Mon Sep 22 06:37:24 2008, Whiteknight wrote:
Sept 08 milestone came and went. Any updates on this ticket? Maybe this
ticket should be closed out (since it's vague) and replaced with another
ticket or tickets for individual places where exit_fatal should be
replaced with real_exception,
On Tue Sep 23 22:34:38 2008, cotto wrote:
I propose to reject this ticket. Reducing code duplication is a good
idea, but it's not at all clear to me what this ticket is referring to.
If someone cares to point out what code should be merged, great.
Otherwise this ticket is too vague to be
James Keenan via RT wrote:
On Sat Oct 18 16:28:22 2008, coke wrote:
I'm submitting some every night at midnight on my osx/x86 box; if it's
obviously a temp directory and the right time frame, it's probably me.
Coke, can you confirm that the test is failing for you now? And, what
version of
chromatic wrote:
On Wednesday 15 October 2008 17:33:58 Will Coleda via RT wrote:
With the attached patch, parrot builds and tests with no errors[0]. A
re-configure is necessary to regenerate a file.
[0] well, no additional or unexpected errors.
Works for me. +1 to apply.
+1
Allison
jerry gay wrote:
On Thu, Oct 16, 2008 at 10:12 AM, Andrew Whitworth via RT
[EMAIL PROTECTED] wrote:
On Sat Jun 11 13:08:49 2005, chip wrote:
Short version: Up through version 0.8 or so, we promise to break
everything constantly (but not until we have a good reason). After
that, we will
NotFound (via RT) wrote:
The Parrot_get_runtime_prefix in src/library.c return a char *,
forcing the places that currently uses it to be more complicated than
desired for no real gain. I added and used a STRING * variant named
Parrot_get_runtime_path (that name makes more sense to me) in r31216
Chris Davaz wrote:
Ahh, cool I didn't even know we had parrot.org. Publishing docs/book/*
would be nice.
On Tue, Sep 23, 2008 at 10:27 PM, Will Coleda:
On Tue, Sep 23, 2008 at 9:04 AM, via RT Chris Davaz:
I suggest we automate the publishing of everything under docs/* and
putting it under
Andrew Whitworth via RT wrote:
The pdd15oo branch was merged in and conversation on this ticket stopped
almost a year ago now. Is there still outstanding documentation work to
do on this topic, besides the general all documentation should be
improved work that always needs to be done? Are there
Andrew Whitworth via RT wrote:
After the pdd27mmd merge, all the n_* opcodes are gone now. I assume the
.pragma n_operators can disappear with them?
Yes. (The n_* opcodes aren't quite all gone yet, but nearly and soon.)
Allison
James Keenan via RT wrote:
Still failing on Darwin/PPC as of r32014:
http://smolder.plusthree.com/app/public_projects/tap_stream/6320/163
Looking at the specific test in question, this may be an integer size
problem.
And I should note that it's also been failing on Darwin/i386:
On Wed Oct 15 12:42:23 2008, coke wrote:
Here's yet another updated version (this time for the exception handler)
of the test that doesn't segfault, but still generates incorrect output
(generates both an OK line and a NOK line)
It looks like the exception handler is resuming after the
NotFound wrote:
Where to put a test for this? There is no t/ops/io.t and creating a
file for each io opcode seems excessive
Create a t/ops/io.t. We'll add to it in the I/O milestone (the next one
on the list, which I'll create a branch for later this week).
Allison
jerry gay wrote:
.\src\pmc\float.c(3340) : warning C4204: nonstandard extension used
: non-constant aggregate initializer
there are now hundreds of these warnings in that build. we do have
warnings ratcheted up pretty high, but i don't think it's worth
relaxing them for this construct unless
Moritz Lenz wrote:
jerry gay wrote:
A combined harness is much better in terms of reporting.
Yes.
the tests we expect to pass reliably should be the default tests we
run. we expect all spectest_regression tests to pass reliably. the
default test target should always be named 'test'. it seems
Christoph Otto (via RT) wrote:
In response to a question about comparison operators in Pipp*, Allison
suggested that I add a variant cmp VTABLE function which returns a PMC instead
of an INTVAL. This patch adds such a function, named pmc_cmp. It's named
pmc_cmp rather than cmp_pmc to try
jerry gay wrote:
i believe (without looking) that the pmc pdd calls them vtable functions.
i really wish the vtable methods meme would die. they're not
methods. they are a collection functions which define the api to
access the pmc, parrot's abstract data type.
Yup. vtable functions is what
Patrick R. Michaud wrote:
I'm not at all arguing that this automatically means we should call
them methods, but at a conceptual level they certainly seem a lot
like methods, and the vtable implementations contain references to
things like SELF and STATICSELF that make them look awfully
Stephen Weeks wrote:
Commit 31294 implements this behavior. Can I get confirmation that it's
correct?
Just looked over the diff. Perfect. Thanks!
Allison
chromatic wrote:
On Sunday 21 September 2008 03:17:18 [EMAIL PROTECTED] wrote:
+dod_unregister_pmc(interp, sig_object);
[...]
That's far away from registering the PMC; is there a way to move them closer
together?
We could register it after it's returned from
jerry gay wrote:
Patrick R. Michaud wrote:
Other languages have adopted the Perl shortname of hash as well,
including Ruby and this odd little creature known as Parrot. Perhaps
we should rename Parrot's Hash class to AssociativePMCArray? 1/2 ;-)
I wouldn't mind. I mean, various languages
Patrick R. Michaud wrote:
It's also a little unique that the take/yield can happen from called
subs deep within the coroutine, and doesn't have to occur within
the coroutine itself.
That's a general characteristic of all the control exceptions: they can
be caught by any outer dynamic scope,
Patrick R. Michaud wrote:
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 fixed.
Thanks, applied. I also updated parrot.org.
Allison
Patrick R. Michaud wrote:
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
James E Keenan wrote:
I set up the Google Group, because I know a number of people are
using it. Can I see a show of hands of people who are only using NNTP
and would have difficulty switching to a regular email subscription or
Google Group? (I can't send to a newsgroup from my email
James E Keenan wrote:
That's false. I replied to the newsgroup, which is mirrored by the
mailing list. Whenever I've posted to the list (independent of posts to
RT), the posts have been mirrored by the mailing list. You asked we to
forward this on, so I did exactly what I've done for
Andy Dougherty wrote:
I use NNTP. I much prefer the command-line news interface to Google
Groups, but I guess I wouldn't go so far as to say I would have
difficulty switching to a regular email subscription. Or, to put it
another way: If there were an NNTP interface, I would definitely use
Patrick R. Michaud 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. So, 'gather' is an aggregating coroutine and
Stephen Weeks wrote:
This has now been committed to trunk. I'm pretty sure that I updated
every exception handler in the tree.
Apologies if my comments on this thread and update to the exceptions PDD
weren't clear. The resume continuation should continue to live within
the exception
The new Parrot mailing list (replacing perl6-internals/parrot-porters)
is [EMAIL PROTECTED]. If you were subscribed to the old
list, you're now subscribed to the new list. If you were a digest
subscriber to the old list, you're now a digest subscriber to the new list.
More information about
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 suddenly becomes possible with Parrot) might
want to make use of gather/take semantics if they're readily available --
Bob Rogers wrote:
Yes, once we have the ability to have exception handlers only handle
specific types of exceptions, then they'll allow all other types of
exceptions to pass through. (Which means we won't end up with the
infinite exception handler loops we currently get if
Patrick R. Michaud wrote:
PDD23:67 has:
: =item Bthrow IEXCEPTION
:
: Throw an exception consisting of the given IEXCEPTION PMC. Active exception
: handlers (if any) will be invoked with IEXCEPTION as the only parameter.
:
:
: =item Bthrow IEXCEPTION [ , ICONTINUATION ]
:
: Throw an
Will Coleda (via RT) wrote:
[...]
I would expect one of the following things to happen here, either:
- an error is generated when test2 is parsed because there is no name
for the named parameter, or
- test2's blarg .param should default to being named 'blarg', so both
calls should work
Christoph Otto (via RT) wrote:
I was looking at #45357 ([TODO] Which exception should be thrown with register
overflow?) and found that Parrot doesn't like subs with more than 205 params.
This seems like a perfectly reasonable limit, but perhaps the behavior could
be more user-friendly.*
Stephen Weeks wrote:
ExceptionHandler currently has a can_handle method that checks whether
the EH has been disabled or not. I propose adding some attributes to
store the minimum severity the EH will handle and the list of exception
types the EH will handle, methods to set and get these
Klaas-Jan Stol wrote:
This ticket doesn't seem to be closeable as is.Would it be good enough
if pmc2c.pl spit out an error on the above definition, or is this even
something that pmc2c.pl should be concerned about?
The goal of the ticket should be for pmc2c.pl to entirely parse the
input PMC
Klaas-Jan Stol wrote:
Allison:
I made the following changes in pirc/new:
.arg - .set_arg
.result - .get_result
.return - .tailcall (in context of .return foo() , which thus is now:
.tailcall foo() )
.return - .set_return (in long-style returning : .begin/end_return
.yield - .set_yield ( in
NotFound wrote:
By the way, as mentioned in other thread there is a problem with plain
%s in parrot printf-alike functions. It does not handle well a NULL c
string. This must be fixed. And before, given the current
implementation, the behavior of string_make and his successor in the
strings
Reini Urban (via RT) wrote:
Old: Guess extensions, so that the user can drop the extensions
leaving it up to the build process/install whether or not
a .pbc, .pasm, .past or a .pir file is used.
New: Search only for .pbc, .pasm, and .pir in that order.
The .past file-extension is *long*
Patrick R. Michaud wrote:
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
execution to
Vasily Chekalkin wrote:
And another question. Should all lvalue occurences of PMC_*_val(SELF) be
replaced with VTABLE_set_*_native? (Except for VTABLE method
implementation of cause)
In general, yes. You'll have to check each PMC to see if they have the
appropriate VTABLE_set_*(_native)
Christoph Otto via RT wrote:
On Mon Oct 22 07:01:59 2007, pcoch wrote:
In src/pmc/hash.pmc:thaw() there is the todo item:
/* TODO make a better interface for hash creation
... do this.
Where do we want to go with this?
Ax the ticket. Vague plans for future change aren't useful.
Allison
chromatic wrote:
That C string leaks. We should have a diagnostic printf which supports
the %Ss format we use in exception formatting strings.
We have one, it's called PIO_fprintf. But, it's only used once in the
repository, in an STM macro.
Added to the I/O milestone tasklist.
Allison
NotFound wrote:
On Wed, Sep 10, 2008 at 9:21 AM, Allison Randal [EMAIL PROTECTED] wrote:
chromatic wrote:
That C string leaks. We should have a diagnostic printf which supports
the %Ss format we use in exception formatting strings.
We have one, it's called PIO_fprintf. But, it's only used
jerry gay wrote:
On Mon, Sep 8, 2008 at 1:09 AM, Allison Randal [EMAIL PROTECTED] wrote:
a) Do abstract base classes as currently implemented in Parrot serve any
useful purpose? If not, eliminate them.
can they be replaced by roles?
Potentially, yes. In the case of the scalar PMC it would
Google has graciously agreed to host the first ever Parrot Developer
Summit. November 15th and 16th, 2008 on Google's Mountain View campus.
You can find directions to the campus at:
http://code.google.com/events/visitors
More details to follow. Hope to see you there!
Allison
chromatic wrote:
t/op/calling_61.pir crashes because Parrot's trying to treat the number -1 as
a PMC. Why?
The desired MMD sub should take two PMCs and returns an INTVAL (frame #5,
signature PP-I), but the invoked MMD sub takes two PMCs and returns a PMC.
The crash comes in convert_arg,
Patrick R. Michaud wrote:
Just for clarification: IIUC, the n_* opcodes and their semantics
aren't really going away -- they're simply being renamed to not
have the leading n_ prefix. It's the existing add, sub,
mul, div, etc. opcodes that are being eliminated.
Yes. That is, calling
Will Coleda wrote:
Instead of spending time fixing a probe that isn't being used, we
should rip it out. If we eventually need it again, we can start from
here, but there's no point in probing for features that we never use.
It's wasting developer (and less importantly, CPU) time better spent
Christoph Otto wrote:
If those are your thoughts on the subject, then it seems to make sense
to add the pdd format test to make test. The attached patch does this.
I'll apply it and mark this ticket as resolved before the next
#parrotsketch unless there are any objections.
Excellent idea.
Christoph Otto via RT wrote:
If there isn't a technical reason why this is necessary, there's no
reason to create such a limitation. If there is such a reason, just
pick something big and make the code enforce it.
The PDD should of course be kept in sync with reality, but that simply
entails a
Christoph Otto via RT wrote:
Is this something we want to go ahead with or should this ticket be
rejected?
I've had it on my hiveminder todo list for over a month now. The problem
is, it's not only a matter of annoying fiddly bookkeeping work now, it's
also annoying fiddly bookkeeping work
chromatic wrote:
The scalar PMC is abstract, but it contains multis that need registration with
the MMD system at initialization time. PMCs containing multis register those
multis in their Parrot_PMC name_class_init() functions.
At least, non-abstract PMCs do.
I ran into a similar problem
Christoph Otto via RT wrote:
I'll sign up to do the grunt work to fix the failing tests if someone
makes a decision on what the consistent behavior should be.
This falls under the I/O PDD, the next milestone. Hold for a couple of
days. I've added it to the tasklist for the milestone:
Agreed that this particular ticket is not useful. Resolve it and replace
it with a [CAGE] ticket with explicit instructions on converting all
existing 'sprintf', 'strcat', etc calls with calls to 'snprintf',
'strlcat', etc. (Also include a list of all calls that should be converted.)
This can
NotFound wrote:
Given that the name will be mainly used via macros, a long and
meaningful name can be used, such as Parrot_PMCdata_PMCname
That's a good refinement, we can make the change after the next release.
The attached patch does it. There is a lot of changes, I suspect many
of them are
I've just committed an initial pass on the Installation PDD. It's
looking good, definitely a good start. I've included some comments to
seed further discussion and development of the draft.
Also, we'll need to include more details on the installation of Parrot
itself (the draft leans pretty
Ronald Schmidt wrote:
I applied for an account and built what seems to me to be an appropriate
Parrot Testing Status page. My proposed link target is
http://www.parrot.org/wiki/some-testing-status-tools . If someone wants
to set me up as a site editor I will fix the link myself otherwise the
Christoph Otto wrote:
The non-draft PDDs are all passing t/codingstd/pdd_format.t as of
r30810, but two of the draft PDDs aren't. Since they're still drafts
and as such are very likely to change, it doesn't seem worthwhile to
bring them into compliance or to have a test depend on them.
I
jerry gay wrote:
the sugar for what can be on the left side of an equals sign needs to
be changed. simply having a first parameter with OUT isn't enough. the
same thing happens for
$P0 = push $S1
which is legal pir syntax, but obscure at best.
ops must have some means of specifying (perhaps
1 - 100 of 980 matches
Mail list logo