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]
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.0 or newer? (see
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
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:
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
==
---
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
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 not affect
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 particularly
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 coretest:
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #47924]
# in the subject line of all future correspondence about this issue.
# URL: 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
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 make coretest
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 base
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 coretest
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 staring
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
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
==
---
Committed patch in r23209, including refactoring $(RUNCORE_TEST_FILES)
out of the root Makefile and into t/harness.
Pm
# New Ticket Created by James Fuller
# Please include the string: [perl #47926]
# in the subject line of all future correspondence about this issue.
# URL: 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
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #47930]
# in the subject line of all future correspondence about this issue.
# URL: 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
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
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. :-)
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
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.
Yes.
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:
It looks like 23100
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
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
# New Ticket Created by Will Coleda
# Please include the string: [perl #47940]
# in the subject line of all future correspondence about this issue.
# URL: 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
27 matches
Mail list logo