On Mon, Nov 13, 2006 at 10:27:19PM -0800, chromatic wrote:
> On Monday 13 November 2006 21:49, Patrick R. Michaud wrote:
> > On Mon, Nov 13, 2006 at 07:33:18PM -0800, [EMAIL PROTECTED] wrote:
> > > Log:
> > > Fix size mismatch errors, at least on Linux/PPC. If this breaks
> > > other platforms, th
Author: chip
Date: Tue Nov 14 09:40:26 2006
New Revision: 15527
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Incremental improvement to pdd07 "coding standards":
* Prefer "char *p" to "char* p".
* Pref
Am Dienstag, 14. November 2006 07:27 schrieb chromatic:
> Does this patch do anything for you? I sort of really hate it, but I'm
> curious about the results.
I've now ci'ed that, as it obviosly fixes x86_64 so far.
Thanks for invetigating it.
leo
I don't know if this was cc'ed to p2p, so just in case.
leo
--- Begin Message ---
Leo,
We have PMCs in the pirate repo at the moment. They are based off of
the python pmcs in parrot's repo, but work with recent versions of
parrot. Not all features are enabled at the moment, but I haven't had
a lo
[ I'll post this to use.perl.org when CPAN has had a chance to mirror. ]
On behalf of the Parrot team, I'm proud to announce Parrot 0.4.7, "Caique"!
What is Parrot? Parrot is a virtual machine aimed at running all dynamic
languages. The Parrot project home page is parrotcode.org.
You may now (
# New Ticket Created by Chip Salzenberg
# Please include the string: [perl #40884]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40884 >
All those cute release names seem to have been lost to history. Please
somebody chec
jerry gay wrote:
ick -- that feels wrong for parrot. we've always tried to make parrot
act in a consistent way across platforms wherever possible, so i'd
rather see the fix in Parrot_sprintf rather than in t/op/sprintf.t.
For the record: we decided in the weekly meeting yesterday to go with a
Matt Diephouse wrote:
Would anyone be inconvenienced if the set_pmc vtable and the
setref and deref opcodes were removed? Note that if you are using set
_pmc but are not using assign_pmc, then you may not be
inconvenienced because right now the default assign_pmc vtable calls
set_pmc.
These op
Patrick R. Michaud wrote:
>
Or, in claiming that compilers have an API, should we instead
say that the canonical compilation sequence is to use compreg
to obtain a compiler object (not an invokable sub), and then
compile the source via a 'compile' method on the compiler object?
For example:
On 11/9/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> Opinions welcome. Personally I think I favor the "a compiler is
> an object with a 'compile' method" model, and that C gives
> us back a compiler object as opposed to a subroutine-like thing.
For the record, it was decided (Allison++) du
On Tue, Nov 14, 2006 at 08:52:47PM -0800, Allison Randal wrote:
>
> Also for the record from the weekly meeting (which was actually today,
> just a very long today): Yes, compilers are objects and compilation is a
> method call. The compiler for TGE tree grammars is implemented this way,
> and
I just finished reviewing docs/dev/pmc_object_design_meeting_notes.pod,
which is a summary of a design discussion I asked particle to lead at
the hackathon last weekend. It's a fantastic piece of work, and nicely
organizes the ideas we've been kicking around the past few months.
Thanks to part
On Tuesday 14 November 2006 22:28, Allison Randal wrote:
> I've added responses after each recommendation, if you have any
> questions or comments pull them onto the mailing list.
Properties:
I don't remember what problem these try to solve. It's difficult to
discuss
one way or the oth
13 matches
Mail list logo
