James E Keenan wrote:
But I didn't actually implement this. What I actually implemented was
specifying the configuration step name *as an alternative to* specifying
a portion of the step's description. While this satisfied particle's
original request, it led to some ugly code in
Parrot::Co
Joshua Hoblitt wrote:
The issue is here is that there is nothing in Configure.pl's output to
correlate the package name of the step with the output seen from a
typical run.
[snip]
Possible ways forward:
[snip]
7) have every configure step print it's package name as part of it's
output
Ba
Patrick R. Michaud wrote:
In pdd15oo, there seems to be an issue about using load_bytecode
to load :method subs after a class has been created.
Working now for both load_bytecode and the eval case. Turns out to be
very few lines of code to make it work. I also added Patrick's examples
as test
Resolving ticket.
Patch applied to trunk in revision 21896.
Stefan Parvu wrote:
What is the future of Parrot and GC systems ? Are we gonna have in near
future similar GCs what the JVM has at this moment:
- serial collector
- parallel collector
- concurrent collector ?
The design document for Parrot's GC system is scheduled to be completed
Jan 15
On Oct 5, 2007, at 1:35 PM, Maria Fedotova wrote:
Hello folks,
I wonder if the community would be interested in attaching another
garbage collector to the parrot VM. For example, Apache Harmony
contains implementation of a parallel garbage collector [1] which is
quicker on modern multi-core an
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46129]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46129 >
In src/debug.c:PDB_hasinstruction() there is the todo item:
XXX TODO:
=over 4
=item
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46127]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46127 >
In src/debug.c:PDB_disassemble() there is the todo item:
/* TODO: free allocated memor
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46125]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46125 >
In src/debug.c:PDB_check_condition() there is the todo item:
* TODO verify register is
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46123]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46123 >
In src/debug.c:PDB_cond() there is the todo item:
else if (condition->type & PDB_cond_
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46121]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46121 >
In src/debug.c:PDB_cond() there is the todo item:
/* XXX Does /this/ have to do with t
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46119]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46119 >
In src/debug.c:PDB_next() there is the todo item:
* FIXME this doesn't handle resume o
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46117]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46117 >
In src/debug.c:PDB_script_file() there is the todo item:
/* TODO: handle command error
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46115]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46115 >
In src/debug.c:PDB_script_file() there is the todo item:
* TODO: avoid this verbose ou
On Fri, Oct 05, 2007 at 12:08:03PM -0700, Allison Randal wrote:
> Patrick R. Michaud wrote:
> >
> >In the case of dynamically generated code, using add_method is
> >somewhat more challenging because we can't perform the add_method
> >until after the PIR source has been compiled and loaded into t
Patrick R. Michaud wrote:
>
In the case of dynamically generated code, using add_method is
somewhat more challenging because we can't perform the add_method
until after the PIR source has been compiled and loaded into the
namespace.
Aye. There's a dividing line that's more a matter of style
On Friday 05 October 2007 11:55:21 Patrick R. Michaud wrote:
> In the case of dynamically generated code, using add_method is
> somewhat more challenging because we can't perform the add_method
> until after the PIR source has been compiled and loaded into the
> namespace. That means that in addi
On Fri, Oct 05, 2007 at 11:05:50AM -0700, Allison Randal wrote:
> Patrick R. Michaud wrote:
> >
> >At any rate, pgc.pir and Perl6Grammar.pir (used to compile
> >grammars into PIR) both want the ability to compile and install rules
> >at runtime, so we really need the eval version to work before
> >
Patrick R. Michaud wrote:
At any rate, pgc.pir and Perl6Grammar.pir (used to compile
grammars into PIR) both want the ability to compile and install rules
at runtime, so we really need the eval version to work before
we can progress much. Either that or I'll come up with a workaround
for those.
It's worth exploring, and may lead to other experiments in parallel GC..
Parrot allows multiple different GC systems, so you shouldn't encounter
significant problems on the Parrot side, but if you do, let us know and
we'll fix them. I don't know if Harmony's parallel GC was designed to be
plugg
On Fri, Oct 05, 2007 at 10:30:03AM -0700, Allison Randal wrote:
> I'll work on this today, but if you want the quick fix, just call
> load_bytecode before newclass. (The quick fix won't work for your eval
> example.)
This is the workaround I'm using to get the PGE tests to pass,
but it's not alw
Hello folks,
I wonder if the community would be interested in attaching another
garbage collector to the parrot VM. For example, Apache Harmony
contains implementation of a parallel garbage collector [1] which is
quicker on modern multi-core and SMP systems.
If you think this may be technically f
It's a timing issue. Methods are currently loaded into the class from
the namespace when the class is created. So, if you call load_bytecode
after newclass, it helpfully inserts the methods into the namespace, but
the class doesn't pick them up. (This has been on my radar for a while,
I just ha
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46109]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46109 >
In src/debug.c:PDB_get_command() there is the todo item:
/* XXX who frees that */
c =
On Fri, Oct 05, 2007 at 03:12:07AM -0500, Patrick R. Michaud wrote:
> In pdd15oo, there seems to be an issue about using load_bytecode
> to load :method subs after a class has been created.
The :method pragma also seems to not work for code that is
compiled using the built-in PIR compiler. Here'
In pdd15oo, there seems to be an issue about using load_bytecode
to load :method subs after a class has been created.
Here's my test code. The main file is 'foo.pir':
$ cat foo.pir
.sub 'main' :main
$P0 = newclass 'Foo'
$P1 = new 'Foo'
$P1.'foo_method'()
Author: kjs
Date: Thu Oct 4 05:27:44 2007
New Revision: 21823
Modified:
trunk/docs/pdds/draft/pdd19_pir.pod
Log:
pdd19_pir.pod:
* add note about issue of op-names as identifiers.
Modified: trunk/docs/pdds/draft/pdd19_pir.pod
===
On 05/10/2007, chromatic <[EMAIL PROTECTED]> wrote:
> On Thursday 04 October 2007 23:10:14 [EMAIL PROTECTED] wrote:
>
> > Modified:
> >trunk/src/pmc/parrotio.pmc
> >
> > Log:
> > [pmc] An input argument to the open() method was freed just before it was
> > used. Thanks to Coverity (CID 131) fo
29 matches
Mail list logo
