2 2008, s1n wrote:
>> > > > When trying to use the --optimize flag, building perl6 causes parrot
>> > > to
>> > > > segfault. Attached is the Configure.pl script output.
>> > >
>> > >
>> > > s1n - this original re
On Tue, 22 Sep 2009, Nicholas Clark wrote:
> On Tue, Sep 22, 2009 at 02:22:17PM -0400, Andy Dougherty wrote:
> > On Tue, 22 Sep 2009, Will Coleda via RT wrote:
> >
> > > On Tue Jul 08 20:56:02 2008, s1n wrote:
> > > > When trying to use the --optimize flag, bu
On Tue, Sep 22, 2009 at 02:22:17PM -0400, Andy Dougherty wrote:
> On Tue, 22 Sep 2009, Will Coleda via RT wrote:
>
> > On Tue Jul 08 20:56:02 2008, s1n wrote:
> > > When trying to use the --optimize flag, building perl6 causes parrot
> > to
> > > segfault.
On Tue, 22 Sep 2009, Will Coleda via RT wrote:
> On Tue Jul 08 20:56:02 2008, s1n wrote:
> > When trying to use the --optimize flag, building perl6 causes parrot
> to
> > segfault. Attached is the Configure.pl script output.
>
>
> s1n - this original report is over
On Tue, Dec 09, 2008 at 03:43:59PM -0800, Moritz Lenz wrote:
> After a 'make realclean' I ran 'perl Configure --optimize && make'. It
> dies like this:
>
> ../../parrot -o PGE.pbc --output-pbc PGE.pir
> ../../parrot ../../runtime/parrot/libr
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #61242]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=61242 >
After a 'make realclean' I ran 'perl Configure --optimize &&
On Tuesday 08 July 2008 20:56:03 jason switzer wrote:
> When trying to use the --optimize flag, building perl6 causes parrot to
> segfault. Attached is the Configure.pl script output. Below is a backtrace
> by manually performing the make step from gdb. You'll notice the second run
On Sunday 17 August 2008 11:16:08 Reini Urban wrote:
> Without --optimize ./parrot t/pmc/namespace_65.pir works fine.
> It prints
> bar
> 2
> With --optimize ./parrot t/pmc/namespace_65.pir hangs after the 2.
>
> Attaching the debugger to a non-debug build is too heavy for
gcc
---
Flags:
category=core
severity=high
ack=no
---
Without --optimize ./parrot t/pmc/namespace_65.pir works fine.
It prints
bar
2
With --optimize ./parrot t/pmc/namespace_65.pir hangs after the 2.
Attaching the debugger to a non-debug build is too heavy for me now,
I
Parrot via RT schrieb:
A useful optimization would be to remove the run-time access to
include/config.pir for linked installable's, where the frozen
config.fpmc is already linked.
There the sub _config should use some config detection logic
(suggestion: new config key 'installed') to omit
.i
# New Ticket Created by Reini Urban
# Please include the string: [perl #57418]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57418 >
---
osname= cygwin
osvers= 1.5.25(0.15642)
arch= cygwin-thread-multi-64int
cc= gcc
On Sun Jul 20 17:52:49 2008, [EMAIL PROTECTED] wrote:
> On Sunday 20 July 2008 17:37:28 James Keenan via RT wrote:
>
> > If no one currently has any more ideas on the subject of this
> ticket, I
> > will close it.
>
> Running it less frequently -- over all PMCs at once -- would speed it
> up,
I
On Sunday 20 July 2008 17:37:28 James Keenan via RT wrote:
> If no one currently has any more ideas on the subject of this ticket, I
> will close it.
Running it less frequently -- over all PMCs at once -- would speed it up,
especially on Windows. Unfortunately, that would introduce a bottleneck
On Thu Jun 26 12:46:10 2008, coke wrote:
>
> In that case, Memoize will not help, you're absolutely right. (Might
> be worth seeing if the code is amenable to a refactor that -would- be
> amenable to this, but that's probably more work.)
>
If no one currently has any more ideas on the subject of
# New Ticket Created by "jason switzer"
# Please include the string: [perl #56712]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56712 >
When trying to use the --optimize flag, building perl6 causes parro
On Thu, Jun 26, 2008 at 2:50 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> On #parrot I had some discussion about tools/build/pmc2c.pl with bacek
> and DietCoke. I pasted some output from dprofpp:
>
> http://nopaste.snit.ch/13401
> http://nopaste.snit.ch/13402
>
> On the basis of these
On #parrot I had some discussion about tools/build/pmc2c.pl with bacek
and DietCoke. I pasted some output from dprofpp:
http://nopaste.snit.ch/13401
http://nopaste.snit.ch/13402
On the basis of these pastes, I was advised to consider using Memoize.pm
to memoize the most frequently called f
This ticket has been open for nearly 2-1/2 years now. I'm wondering if
we could reformulate it to more specifically identify ways pmc2c.pl
could be optimized, break those specific objectives into separate RTs,
and close this ticket.
Otherwise, this ticket is likely to be uncloseable.
Can those w
On Sun Mar 23 21:32:47 2008, [EMAIL PROTECTED] wrote:
>
> Off hand, that sounds right. To see real gains here we need to avoid
> loading FindBin.pm completely. So it'll need to be require()'d if the
> correct information hasn't been passed in.
>
> -J
>
> --
Okay. I am going to apply my pat
On Sunday 23 March 2008 21:46:23 jerry gay wrote:
> On Sun, Mar 23, 2008 at 9:39 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > On Sunday 23 March 2008 20:58:24 jerry gay wrote:
> > > why not put the location of parrot's lib dir in
> > > Parrot::Config::Generated, and look it up when needed?
>
On Sun, Mar 23, 2008 at 9:39 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Sunday 23 March 2008 20:58:24 jerry gay wrote:
>
> > why not put the location of parrot's lib dir in
> > Parrot::Config::Generated, and look it up when needed?
>
> Isn't Parrot::Config::Generated *in* Parrot's lib dir?
>
On Sunday 23 March 2008 20:58:24 jerry gay wrote:
> why not put the location of parrot's lib dir in
> Parrot::Config::Generated, and look it up when needed?
Isn't Parrot::Config::Generated *in* Parrot's lib dir?
-- c
On Sun, Mar 23, 2008 at 06:21:38PM -0700, James Keenan via RT wrote:
> On Sat Mar 22 10:38:42 2008, doughera wrote:
>
> > Just be careful that 'use lib' doesn't look outside of the parrot source
> > tree. If pmc2c.pl is normally invoked from the root directory, then
> > ../lib and ../../lib are
On Sun, Mar 23, 2008 at 6:21 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> On Sat Mar 22 10:38:42 2008, doughera wrote:
>
> > Just be careful that 'use lib' doesn't look outside of the parrot source
> > tree. If pmc2c.pl is normally invoked from the root directory, then
> > ../lib and ..
On Sat Mar 22 10:38:42 2008, doughera wrote:
> Just be careful that 'use lib' doesn't look outside of the parrot source
> tree. If pmc2c.pl is normally invoked from the root directory, then
> ../lib and ../../lib are looking outside of the parrot source. This is
> wrong, since there is no gua
On Fri, 21 Mar 2008, James Keenan via RT wrote:
> On Mon Jan 09 17:05:30 2006, [EMAIL PROTECTED] wrote:
> > Simple profile suggests that pmc2c.pl is spending about 25% of it's
> > total execution time loading FindBin. The lib path use of FindBin::Bin
> > can be replaced with 'use lib qw( . lib ..
On Mon Jan 09 17:05:30 2006, [EMAIL PROTECTED] wrote:
> Simple profile suggests that pmc2c.pl is spending about 25% of it's
> total execution time loading FindBin. The lib path use of FindBin::Bin
> can be replaced with 'use lib qw( . lib ../lib ../../lib );' while the
> other uses of FindBin::Bin
James,
Profiling is generally done with Devel::Profile.
http://search.cpan.org/~jaw/Devel-Profile-1.05/Profile.pm
Since pmc2c.pl is invoked so many times in the build process improving
it's performance would sustainably speed up the overall build time.
Cheers,
-J
--
On Mon, Mar 17, 2008 at 04
On Mon Jan 09 17:05:30 2006, [EMAIL PROTECTED] wrote:
> Simple profile suggests that pmc2c.pl is spending about 25% of it's
> total execution time loading FindBin. The lib path use of FindBin::Bin
> can be replaced with 'use lib qw( . lib ../lib ../../lib );' while the
> other uses of FindBin::Bin
tem:
/* these 2 opcodes change the register base pointer
* restart NEXT() reloads cached base pointers, and works with
* arbitrary branch opcodes too. While it's a bit of overkill,
* we don't have an opcode annotation to reload just the base pointers
* TODO OPTIMIZE later
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #38194]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38194 >
Simple profile suggests that pmc2c.pl is spending about 25% of it's
total execution t
The handling of --optimize was begging to be cleanup already. This
should be fixed in r10876. Thanks for reporting.
-J
--
On Tue, Jan 03, 2006 at 10:20:32AM -0800, Andy Dougherty wrote:
> # New Ticket Created by Andy Dougherty
> # Please include the string: [perl #38139]
> # in th
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #38139]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38139 >
The $optimize flag no longer shows up in the root Makefile anywhere.
Configure
At 06:22 19/09/2005 -0700, you wrote:
François PERRAD (via RT)" <[EMAIL PROTECTED]> wrote:
>
> This patch allows Configure.pl --optimize and
> Configure.pl --optimize=flags
> with MinGW.
> (And typo in CREDITS)
>
Thanks, applied (r9210). I think it was me that got
François PERRAD (via RT)" <[EMAIL PROTECTED]> wrote:
This patch allows Configure.pl --optimize and
Configure.pl --optimize=flags
with MinGW.
(And typo in CREDITS)
Thanks, applied (r9210). I think it was me that got your name wrong when I
added it to the CREDITS too - sorry
# New Ticket Created by François PERRAD
# Please include the string: [perl #37197]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37197 >
This patch allows Configure.pl --optimize and Configure.pl --optimize=flags
w
On Tue, 18 Feb 2003 [EMAIL PROTECTED] wrote:
>
> I think --optimize alone is busted.
>
You'd be right: the code adding the optimization flags to the list of
compiler flags is only executed if 'debugging' is defined, which is
only the case when the --debugging flag has
> > In tracking down a gc bug, I realized that the current throwaway
> > implementation of the print op could be replaced with a faster
> > throwaway implementation that avoids doing a string_to_cstring.
> >
> > Note that both the original and new implementations are still buggy
> > with respect t
> In tracking down a gc bug, I realized that the current throwaway
> implementation of the print op could be replaced with a faster
> throwaway implementation that avoids doing a string_to_cstring.
>
> Note that both the original and new implementations are still buggy
> with respect to supporting
# New Ticket Created by Steve Fink
# Please include the string: [perl #16855]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16855 >
In tracking down a gc bug, I realized that the current throwaway
implementation of the pr
40 matches
Mail list logo
