# New Ticket Created by Will Coleda
# Please include the string: [perl #47940]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=47940 >
mk_native_pbc has, 2x:
make -s progclean
make -s -C imcc clean
Both of which are invali
On Mon Oct 29 11:11:03 2007, bernhard wrote:
> In pdd17_pmc.pod it is stated that 'new_from_string' is deprecated.
> The existing use of 'new_from_string' can probably be achieved with
> 'init' or
> 'set_string_native'.
>
> TODO:
> Hunt down existing use of 'new_i_s' and either replace or remove
The intent of Aldo's patch is even closer than I first thought to what I
proposed last night ... as is evident from this question:
For a given instance of perl on a given OS, can I assume that the two
commands below will *always* produce the same output?
[parrot] 506 $ perl -MConfig -le 'print $C
On Tue Nov 27 22:57:38 2007, [EMAIL PROTECTED] wrote:
> On Sunday 25 November 2007 17:49:19 Will Coleda wrote:
>
> > Yet another tcl segfault, this time on feather. (linux)
> >
> > Revision: 23055
> >
> > 1) build tcl.
> >
> > 2) run "../../parrot tcl.pbc"
> >
> > 3) boom
> >
> > backtrace via gdb
On Wed Nov 28 15:48:32 2007, [EMAIL PROTECTED] wrote:
> Bernhard Schmalhofer wrote:
>
> >>
> > James,
> >
> > could you look into this patch and apply it if appropriate?
> > Obviously you are the person that knows best, whether
> > it can be applied right away or needs some fiddling or merging
Bernhard Schmalhofer wrote:
James,
could you look into this patch and apply it if appropriate?
Obviously you are the person that knows best, whether
it can be applied right away or needs some fiddling or merging.
Yes. In line with my second post in RT 47902, I'm thinking that in step
#2
Appears to be fixed as of r23207 - made smoke w/ 99.99% ok (failed 1 of 4
for stm/basic_mt.t (line 168))
a
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
VOICE: (608) 261-5738 FAX 264-5932
Remember, the first rule of optimisation is: don't do it yet. :-)
James Keenan via RT schrieb:
(I'm surprised this patch slipped beneath my radar, as it refers to
files I've been staring at for months.)
This is very consistent with what I've recommended for %Config in
http://rt.perl.org/rt3//Public/Bug/Display.html?id=47902, so I recommend
this patch be applie
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #47930]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=47930 >
hi,
IMCC allows for writing
$P0 = $P1[10, 20]
Looking into the yacc file, it seems
# New Ticket Created by "James Fuller"
# Please include the string: [perl #47926]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=47926 >
after building parrot (and doing a make realclean to ensure all is
well) having a prob
Committed patch in r23209, including refactoring $(RUNCORE_TEST_FILES)
out of the root Makefile and into t/harness.
Pm
Author: kjs
Date: Wed Nov 28 08:04:01 2007
New Revision: 23196
Modified:
trunk/docs/pdds/draft/pdd19_pir.pod
Log:
[pdd19] remove .pcc_ prefix.
Modified: trunk/docs/pdds/draft/pdd19_pir.pod
==
--- trunk/docs/pdds/draft
But one more thought ...
How will creating an 'osname' key from $^O affect/be affected by all the
fiddling done with OS and platform names in config/auto/jit.pm?
[parrot] 512 $ grep -n osname config/auto/jit.pm
49:my ( $cpuarch, $osname ) = split( /-/, $archname );
56:if ( !defined $osna
On 28/11/2007, Patrick R. Michaud via RT
<[EMAIL PROTECTED]> wrote:
> The attached coretest.patch file adds a "make coretest" target to
> Parrot. This target runs a smaller subset of tests than the normal
> "make test" target. On my system, "make test" completes in ~290
> seconds, while "make cor
On Sat Nov 10 03:07:27 2007, bernhard wrote:
>
> This patch hasn't been applied yet.
> It make sense to me as it is a prerequisite for cross-compilation.
>
> Should I go ahead and try to apply the patch ?
>
(I'm surprised this patch slipped beneath my radar, as it refers to
files I've been sta
Todd Olson via RT <[EMAIL PROTECTED]> on 2007/11/28 Wed AM 08:39:24 CST wrote:
>
>One feature I have been exploiting extensively in my Perl 5 installs
>is cpan.pm's MyConfig.pm which permits me to overlay Perl's %Config
>and to swap sets of config changes in and out with out messing with
>the ba
On Wednesday 28 November 2007 09:19:51 Patrick R. Michaud via RT wrote:
> The attached coretest.patch file adds a "make coretest" target to
> Parrot. This target runs a smaller subset of tests than the normal
> "make test" target. On my system, "make test" completes in ~290
> seconds, while "mak
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #47924]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=47924 >
I'm getting two test failures in t/oo/mro-c3.t (output below).
It's not clear when
The attached coretest.patch file adds a "make coretest" target to
Parrot. This target runs a smaller subset of tests than the normal
"make test" target. On my system, "make test" completes in ~290
seconds, while "make coretest" completes in ~200.
The following tests are not included in make core
On Tue, Nov 27, 2007 at 08:30:38PM -0800, chromatic wrote:
> On Tuesday 27 November 2007 19:49:26 James Keenan wrote:
>
> > Since this patch affects 16 configuration modules, I would like to
> > have it tried out on as many platforms as possible. Reports from
> > Linux and OpenBSD would be partic
On Nov 10, 2007 3:07 AM, Bernhard Schmalhofer via RT
<[EMAIL PROTECTED]> wrote:
> On Fr. 23. Feb. 2007, 07:28:38, acalpini wrote:
> > this patch adds an 'osname' key to Parrot's own $conf->data, which is
> > used in the configure process instead of $^O (and $Config{osname}).
> >
> > this patch does
Hi
>One recurring problem -- though not the only problem -- is the fact
>that to jump-start its understanding of the state of a user's system,
>Parrot's Configure.pl relies on the presence of a Perl 5 Config.pm --
>and its exported variable %Config -- to perform initial population of
>many ele
Author: kjs
Date: Wed Nov 28 03:16:34 2007
New Revision: 23177
Modified:
trunk/docs/pdds/draft/pdd19_pir.pod
Log:
[pdd19] remove .sym from pdd19 - pir.
Modified: trunk/docs/pdds/draft/pdd19_pir.pod
==
--- trunk/docs/p
Heh, ok, grammar fixed and resubmitted. And yes, I've tested it on
Linux (Fedora 7) and Windows with MSVC 2005. I don't have a non-glibc
unix to try it out with however.
Joe
On Mon Nov 26 09:50:28 2007, [EMAIL PROTECTED] wrote:
> On Sunday 25 November 2007 21:48:01 Joe Sadusk via RT wrote:
>
>
On Nov 28, 9:04 am, [EMAIL PROTECTED] (Joshua Isom) wrote:
> How can you know what opcodes a dynamically loaded library provides at
> compile time? If there's no other method than interp, then you'll have
> to use interp to find out what's valid and what's not, without
> redesigning how dynops are
On Tue, Nov 27, 2007 at 08:52:32PM -0800, Will Coleda via RT wrote:
> On Wed Apr 04 05:59:18 2007, [EMAIL PROTECTED] wrote:
> > For me, running the attached PIR file outputs:
> > Sub
> > String
> >
> > instead of:
> > Sub
> > Sub
>
> Can anyone reproduce this on the original platform with
> 0.5.
How can you know what opcodes a dynamically loaded library provides at
compile time? If there's no other method than interp, then you'll have
to use interp to find out what's valid and what's not, without
redesigning how dynops are handled.
On Nov 27, 2007, at 1:15 PM, [EMAIL PROTECTED] wrote
27 matches
Mail list logo
