Author: allison
Date: Fri Sep 14 23:35:56 2007
New Revision: 21301
Modified:
trunk/docs/pdds/pdd15_objects.pod
Log:
[pdd] Add a reference to the object model diagram from PDD 15.
Modified: trunk/docs/pdds/pdd15_objects.pod
=
Author: allison
Date: Fri Sep 14 23:30:20 2007
New Revision: 21300
Modified:
trunk/docs/pdds/draft/pdd17_pmc.pod
Log:
[pdd] Expand and cleanup reference on vtable functions and core PMC types in
PMC PDD.
Modified: trunk/docs/pdds/draft/pdd17_pmc.pod
=
On Sep 14, 2007, at 6:51 AM, Klaas-Jan wrote:
On Sep 14, 1:47 pm, [EMAIL PROTECTED] (Joshua Isom) wrote:
I may be slow in understanding sometimes, but I really don't know what
you mean.. :-) Could you elaborate a bit more?
Do you mean you want to get unique local variables (as the macro magic
On Fri Sep 14 16:22:57 2007, [EMAIL PROTECTED] wrote:
>
> I have agreed (in another thread), that these should be unified. So,
> it's more a matter of TUITs than anything else.
>
> > But having a good design would also be useful.
>
> A good place to start is with a PDD-like summary of how it cu
This thread and RT ticket (41168) have been under way since Jan 03 2007
and I'm afraid that the discussion is collapsing under its own weight.
May I make an attempt at summarizing the issues? Let's proceed from the
outermost inwards.
1. Should the Parrot configuration process come to a halt if
Andy Dougherty wrote:
Trivial example: Configure.pl currently supports many incompatible ways
to say "no" (excerpts from Configure.pl --help)
--nomanicheckDon't check the MANIFEST
--cgoto=0Don't build cgoto core - recommended when short of mem
--without-gdbm
Nicholas Clark wrote:
On Thu, Sep 13, 2007 at 10:37:59PM -0700, Allison Randal wrote:
The conclusion after a good bit of discussion earlier this year was that
returning a status object for every synchronous operation was far too
heavyweight. Exceptions don't get a high vote as an alternative,
On Friday 14 September 2007 13:36:25 [EMAIL PROTECTED] wrote:
> Modified:
>trunk/src/dynext.c
> Modified: trunk/src/dynext.c
> ===
>=== --- trunk/src/dynext.c (original)
> +++ trunk/src/dynext.cFri Sep 14 13:3
Author: allison
Date: Fri Sep 14 13:37:17 2007
New Revision: 21298
Modified:
trunk/docs/pdds/draft/pdd17_pmc.pod
Log:
[pdd] Brushing away alternate timelines from PDD 17, and making cleanups.
Modified: trunk/docs/pdds/draft/pdd17_pmc.pod
==
Author: allison
Date: Fri Sep 14 13:14:02 2007
New Revision: 21293
Modified:
trunk/docs/pdds/draft/pdd17_pmc.pod
Log:
[pdd] Radical simplification for inheriting from low-level PMCs in high-level
classes.
Modified: trunk/docs/pdds/draft/pdd17_pmc.pod
I just checked in (r21293) a substantial change to the PDD 17 section
"PMCs and high-level objects", detailing the inheritance strategy from
low-level PMCs to high-level classes.
We've been poking around the edges of the problem since we started the
new metamodel, but this is a radical simplif
Author: larry
Date: Fri Sep 14 11:14:45 2007
New Revision: 14463
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S04.pod
doc/trunk/design/syn/S06.pod
doc/trunk/design/syn/S09.pod
doc/trunk/design/syn/S11.pod
doc/trunk/design/syn/S12.pod
Log:
typos and nobreak spaces
Author: smash
Date: Fri Sep 14 06:38:12 2007
New Revision: 21278
Modified:
trunk/docs/pdds/draft/pdd19_pir.pod
Log:
[pdd]: some small reviews including:
* marked off items to review and proposals from RT
* some directives/ops/... revisited
* some updates from DEPRECATED
* updated 'type'
Author: larry
Date: Fri Sep 14 10:34:57 2007
New Revision: 14462
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S03.pod
doc/trunk/design/syn/S04.pod
doc/trunk/design/syn/S12.pod
Log:
Expunge references to largely redundant "long dot" concept
Modified: doc/trunk/design/s
On Sep 14, 1:47 pm, [EMAIL PROTECTED] (Joshua Isom) wrote:
> On Sep 13, 2007, at 9:00 PM, Allison Randal wrote:
>
> > Joshua Isom wrote:
> >> And while we're add it, can we add the magic to do the same thing we
> >> to do labels to variables as well?
>
> > What thing?
>
> > Allison
>
> It's the lit
On Thu, 13 Sep 2007, James E Keenan wrote:
> Andy Dougherty wrote:
>
> > (If cc_build and cc_run do get meaningful exit codes, inter::progs needs to
> > be revisited anyway to actually use those codes.)
>
> If you do revisit config/inter/progs.pm, please bear in mind that I have
> written some
Author: paultcochrane
Date: Fri Sep 14 08:45:45 2007
New Revision: 21279
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Log:
[pdd] (pdd07) Added an example of splitting a long line before an operator.
Modified: trunk/docs/pdds/pdd07_codingstd.pod
==
On Thu Sep 13 22:39:32 2007, [EMAIL PROTECTED] wrote:
>
> On Sep 13, 2007, at 8:21 PM, Jerry Gay (via RT) wrote:
>
> > # New Ticket Created by Jerry Gay
> > # Please include the string: [perl #45437]
> > # in the subject line of all future correspondence about this issue.
> > # http://rt.perl.o
Hi all,
me again! I found a few things in PDD13 - Parrot Bytecode which need
work. Again, this is just an email to start of discussion and to then
generate any refinements necessary for a complete(d) design.
=item Key Constants
Within this section there is the todo item:
{{ TODO: Figure out
Author: paultcochrane
Date: Fri Sep 14 05:06:20 2007
New Revision: 21275
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Log:
[pdd] Minor formatting and English changes.
Modified: trunk/docs/pdds/pdd21_namespaces.pod
Hi all,
Here is the next installment of the current outstanding issues I've
found in the PDDs. This time in PDD20 - Lexical Variables
=item Conceptual Model
Under the subsection "LexPad PMC" there is the comment:
TODO: Describe how lexical naming system interacts with non-ASCII character
s
Author: paultcochrane
Date: Fri Sep 14 06:04:36 2007
New Revision: 21276
Modified:
trunk/docs/pdds/pdd20_lexical_vars.pod
Log:
[pdd] Minor formatting changes.
Modified: trunk/docs/pdds/pdd20_lexical_vars.pod
==
--- t
Author: paultcochrane
Date: Fri Sep 14 06:30:25 2007
New Revision: 21277
Modified:
trunk/docs/pdds/pdd13_bytecode.pod
Log:
[pdd] Correction of typos and English. Minor formatting changes. Removed a
podchecker warning.
Modified: trunk/docs/pdds/pdd13_bytecode.pod
===
Hi everyone!
Continuing with the theme of discussing the PDDs, here is a starter
email to kick off discussion of PDD07 - the coding standards of
Parrot. Coding standards can often be a really touchy subject, so I
hope we can amicably come to consensus decisions about the various
points I'm about
Hi all,
Continuing on with my mentioning of discussion points within PDDs,
here are the relevant items from PDD21 - Parrot Namespaces.
=item *
Under the Compiler PMC API section within the explanation of the
C method there is the text:
On failure, an exception is thrown. {XXX - I'd settle fo
On Thu, Sep 13, 2007 at 10:37:59PM -0700, Allison Randal wrote:
> The conclusion after a good bit of discussion earlier this year was that
> returning a status object for every synchronous operation was far too
> heavyweight. Exceptions don't get a high vote as an alternative, but
Even if the
26 matches
Mail list logo
