ns with both "make -j2" and a plain "make".
>
> ../../parrot -o TGE/Tree.pbc --output-pbc TGE/Tree.pir
> ../../parrot -o ../../runtime/parrot/library/TGE.pbc --output-pbc TGE.pir
> make -C compilers/nqp
> ../../parrot
> /opt/src/perl6/build-2008
Tonight I resolved RT#52838 and RT#52840, eliminating the saveall/restoreall
opcodes, the register stack, and fixing up tests and other items
to avoid save/restore/etc. opcodes.
I've also created a "userstack" branch where I've got the details
for removing the rest of stack.ops . I've already im
# New Ticket Created by Bob Rogers
# Please include the string: [perl #53168]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53168 >
Here's what I get when I attempt "make headerizer" in r27087:
. . .
ad
rrot/library/TGE.pbc --output-pbc TGE.pir
make -C compilers/nqp
../../parrot
/opt/src/perl6/build-20080421-b/runtime/parrot/library/PGE/Perl6Grammar.pir
\
--output=src/Grammar_gen.pir src/Grammar.pg
make[1]: *** [nqp.pbc] Bus error
make: *** [compilers.dummy] Error 2
herodotus:build-
Done as of r27113.
Pm
As of r27105 these have all been recoded to avoid the stack.ops .
The only exception is t/op/stacks.t, which can be removed when we remove
the stack.ops in RT#52842 .
Closing ticket, and thanks!
Pm
On Mon, Apr 21, 2008 at 11:04:13PM -0400, Bob Rogers wrote:
Content-Description: message body text
> t/op/jit.t 1 256621 1.61% 55
This one requires removing saveall and restoreall handling from imcc
(done in the stacks branch).
> t/op/stacks.t
I found the results of an experiment (done in r26933) where I used
the attached patch to disable all stack ops, and then did "make test".
(I had misplaced it, which is why I didn't post it earlier; sorry about
that.) Here are the failing tests:
Failed Test Stat Wstat Tota
On Monday 21 April 2008 19:17:34 Bob Rogers wrote:
> The hack is attached; it isn't headerized, has some coding standards
> failures, and leaks memory, so it's incomplete. Disappointingly, it
> produces an overall speedup of less than 4% in building gen_actions.pir
> in r27087 (which has chromati
From: "Patrick R. Michaud via RT" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 18:00:31 -0700
On Sat, Apr 12, 2008 at 08:26:34PM -0700, Bob Rogers wrote:
>The ops in src/ops/stack.ops are holdovers from the bad old days of
> limited registers. In modern times, it is more versatil
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 18:54:19 -0400
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 15:42:27 -0500
. . . If it looks like having a separate stack for bsr/ret is
workable then I'll go at it that way.
Fai
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 18:54:19 -0400
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 15:42:27 -0500
. . . If it looks like having a separate stack for bsr/ret is
workable then I'll go at it that way.
Fai
On Sat, Apr 12, 2008 at 08:26:34PM -0700, Bob Rogers wrote:
>The ops in src/ops/stack.ops are holdovers from the bad old days of
> limited registers. In modern times, it is more versatile (and probably
> faster) to create an array and use it as an explicit stack via push and
> pop operations.
On Monday 21 April 2008 17:02:27 Mark Glines wrote:
> Another note, slightly off-topic: does OpenGL actually need a
> configuration/detection step at all? I notice neither SDL or
> PostgreSQL seem to have one. Maybe they're detecting everything at
> runtime, or maybe their generated stuff runs f
On Mon, 2008-04-21 at 17:02 -0700, Mark Glines wrote:
> 1. It seemed more relevant than some stuff that's already in
> parrot. (I have more machines with OpenGL installed than have
> postgresql, for example.)
Ditto, but of course, I'm biased. :-)
> 2. The author (Geoff) was responsive, willin
1. If you have had a Parrot- or Rakudo-oriented presentation accepted
at YAPC::NA::2008 in Chicago, please add your name and presentation's
name to: http://www.perlfoundation.org/parrot/index.cgi?yapc_na_2008
2. The Parrot/Rakudo buildfest workshop has been accepted. If you are
able to be
Bob Rogers wrote:
I don't expect to be able to co-lead (since, for one thing, that would
require putting in significant time in advance), but I would be willing
to help TA such a thing. I suspect it would be valuable to have a
number of TAs with diverse areas of trouble-shooting expertise, sin
On Mon, 2008-04-21 at 17:06 -0700, James Keenan via RT wrote:
> I'm mostly in agreement. It just seems to me that the configuration
> ought to be settling down as we near 1.0.
Absolutely. However, as of 0.6.1 we are at the stage where outsiders
like myself can finally meaningfully contribute --
On Mon Apr 21 17:02:58 2008, [EMAIL PROTECTED] wrote:
[snip]
>
> > * Is new configuration step X::X *necessary* for the functioning
> > of the Parrot virtual machine?
>
> Frankly, probably nothing but the basic "does the compiler exist, and is
> it sane" type of tests meet that qualification.
>
On Sun, 2008-04-20 at 19:28 -0700, James Keenan via RT wrote:
> As to the question of whether people know how to write tests: I think
> there is empirical evidence that people know how to write tests for the
> configuration steps. For example, when François earlier submitted
> config/auto/crypto.
On Mon Apr 21 16:21:18 2008, geoff wrote:
>
> As a non-core contributor, my impression is that there is no top-down
> plan. Parrot's development appears very much guided by dynamic tension
> between the real bottom-up work, docs ranging from prescriptive to
> descriptive to imaginative, and a *de
On Sun, 20 Apr 2008 19:01:44 -0700
James Keenan (via RT) <[EMAIL PROTECTED]> wrote:
Hi! As one of the guilty parties, I'm not sure whether I get a vote,
but...
> * Is new configuration step X::X *necessary* for the functioning
> of the Parrot virtual machine?
Frankly, probably nothing but the
On Mon Apr 21 16:21:18 2008, geoff wrote:
>
> Two of these are from me (auto::opengl and gen::opengl). I had
> attempted to discuss OpenGL bindings on p-p and in IRC multiple times in
> the past; in each case the discussion either veered off into technical
> details or was Warnocked.
>
> No, I d
On Mon Apr 21 07:11:23 2008, [EMAIL PROTECTED] wrote:
>
> I prefer the die behavior, because with it, I don't forget to add tests
> with auto::crypto.
>
So I'm not alone, after all ;-)
> Now, I think the name gen::digest is not good.
> I prefer gen::crypto because :
> 1) same as auto::crypto
On Sun, 2008-04-20 at 19:01 -0700, James Keenan wrote:
> auto::gettext (r26100 | particle | 2008-02-27)
> auto::crypto (r26359 | fperrad | 2008-03-14)
> auto::glibc (r26946 | particle | 2008-04-12)
> auto::opengl (r27022 | infinoid | 2008-04-18)
> gen::opengl (r27022 | infinoid | 2008-04-18)
> gen:
On Monday 21 April 2008 10:26:21 Clark Cooper wrote:
> Using Parrot 0.6.1 on Fedora Core 5, linux 2.6.15-1.2054_FC5
>
> The program, classinfo.pir :
> #
> .const string Indent=' '
> .const int MaxDepth = 6
>
> .sub main :m
Author: pmichaud
Date: Mon Apr 21 15:58:26 2008
New Revision: 27092
Modified:
trunk/docs/pdds/draft/pdd06_pasm.pod
Log:
[docs]:
* PDD06: Remove documentation of some opcodes that have been absent for
a long time.
Modified: trunk/docs/pdds/draft/pdd06_pasm.pod
==
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 15:42:27 -0500
On Mon, Apr 21, 2008 at 04:31:17PM -0400, Bob Rogers wrote:
>There is another solution that ought to speed up "bsr" dramatically:
> Give the "bsr" return addresses their own stack.
I thou
# New Ticket Created by "Clark Cooper"
# Please include the string: [perl #53156]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53156 >
Using Parrot 0.6.1 on Fedora Core 5, linux 2.6.15-1.2054_FC5
The program, classinfo.p
Am Montag, 21. April 2008 22:49 schrieb chromatic:
> On Monday 21 April 2008 13:44:44 Patrick R. Michaud wrote:
> > On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote:
> >
> > Thanks again. I was misreading from comments in stack_push, which
> > say that it pushes things onto the "generic
On Monday 21 April 2008 13:44:44 Patrick R. Michaud wrote:
> On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote:
> Thanks again. I was misreading from comments in stack_push, which
> say that it pushes things onto the "generic stack" when in reality
> it seems to use whatever stack is pa
On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Mon, 21 Apr 2008 14:25:53 -0500
>
>. . . this seems to be the case for everything using the
>"generic stack", which AFAICT is the &interp->dynamic_env structure.
>
>
On Mon, Apr 21, 2008 at 04:31:17PM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Mon, 21 Apr 2008 14:55:21 -0500
>
>> On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]>
> wrote:
>> > I think we'd get a BIG win if we changed t
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 14:25:53 -0500
. . . this seems to be the case for everything using the
"generic stack", which AFAICT is the &interp->dynamic_env structure.
Your point is correct, except that you are talking about the "dynamic
envi
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 14:55:21 -0500
> On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]>
wrote:
> > I think we'd get a BIG win if we changed the dynamic_env stack to
> > have an approach similar to ResizableInt
On Mon, Apr 21, 2008 at 02:25:53PM -0500, Patrick R. Michaud wrote:
>
> The parts of the stack code we've discussed eliminating is actually
> the user_stack, used for push/pop/saveall/restoreall opcodes.
I inadvertently wrote push/pop here where I really meant save/restore.
The push/pop opcode
On Mon, Apr 21, 2008 at 8:41 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 08:34:49PM +0100, Klaas-Jan Stol wrote:
> > hi,
> >
> > Currently, the pct tutorial language is "out there", mostly on the
> > parrotblog entries, and I uploaded a .zip onto the wiki.
> >
>
I've applied the patch from RT#52838 which updates the documentation.
I'm now working on eliminating the restoreall/saveall opcodes themselves
from Parrot, as well as working on the related user stack ops in RT#52842.
Pm
Author: pmichaud
Date: Mon Apr 21 13:08:48 2008
New Revision: 27082
Modified:
trunk/docs/pdds/draft/pdd06_pasm.pod
Changes in other areas also in this revision:
Modified:
trunk/editor/kate_syntax.pl
trunk/languages/BASIC/compiler/compile.pl
Log:
[core]:
* Updates for the restoreall/save
On Mon, Apr 21, 2008 at 08:48:10PM +0100, Klaas-Jan Stol wrote:
> On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > I think we'd get a BIG win if we changed the dynamic_env stack to
> > have an approach similar to ResizableIntegerArray, where we allocate
> > arra
On Monday 21 April 2008 12:25:53 Patrick R. Michaud wrote:
> To me, the scary part of src/stacks.c is at the beginning:
>
> The stack is stored as a linked list of chunks (C),
> where each chunk has room for one entry.
>
> Eek! For something like bsr_ic, which is really just pushing a
> r
On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 10:19:08AM -0700, chromatic wrote:
> > I'm still exploring the Rakudo build progress as a profiling target for
> likely
> > optimizations. After this weekend's work, I have src/gen_actions.p
On Mon, Apr 21, 2008 at 08:34:49PM +0100, Klaas-Jan Stol wrote:
> hi,
>
> Currently, the pct tutorial language is "out there", mostly on the
> parrotblog entries, and I uploaded a .zip onto the wiki.
>
> However, updating it is now a pain, because I have to recreate a .zip
> and replace it on the
hi,
Currently, the pct tutorial language is "out there", mostly on the
parrotblog entries, and I uploaded a .zip onto the wiki.
However, updating it is now a pain, because I have to recreate a .zip
and replace it on the wiki.
What do people think about adding it in the examples directory? At
firs
On Mon, Apr 21, 2008 at 10:19:08AM -0700, chromatic wrote:
> I'm still exploring the Rakudo build progress as a profiling target for
> likely
> optimizations. After this weekend's work, I have src/gen_actions.pir
> generation down to 27,788,055,796 instructions (with an optimized Parrot). A
>
I'm still exploring the Rakudo build progress as a profiling target for likely
optimizations. After this weekend's work, I have src/gen_actions.pir
generation down to 27,788,055,796 instructions (with an optimized Parrot). A
big chunk of that time goes to support bsr_ic:
7,784,136,854 core.
On Mon, Apr 21, 2008 at 12:25 AM, Mark Glines <[EMAIL PROTECTED]> wrote:
> (Still debatable whether the rest of that #else clause in parrot.h is
> valid, if it's causing issues like this one.)
This patch can avoid future problems, by defining and using using
specific macros.
I searched the sou
On Mon Apr 21 07:11:23 2008, [EMAIL PROTECTED] wrote:
>
> Previously, the generation was done by src/dynpmc/Makefile (generated
> from config/gen/makefiles/dynpmc.in) and use some perl -pe "s///" from a
> template src/dynpmc/mdx.pmc.
> So it was not the standard way, and it was not enought smart
James Keenan (via RT) a écrit :
# New Ticket Created by James Keenan
# Please include the string: [perl #53126]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53126 >
I noticed that a new step, auto::digest, has been adde
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Apr 21 13:00:02 2008 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with m
# New Ticket Created by François PERRAD
# Please include the string: [perl #53120]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53120 >
2008/4/20 James E Keenan <[EMAIL PROTECTED]>:
> This morning I noticed that the foll
51 matches
Mail list logo
