Re: [perl #60070] [BUG] make opsrenumber causes build to fail
On Wed, Oct 22, 2008 at 10:49 PM, Patrick R. Michaud (via RT)
[EMAIL PROTECTED] wrote:
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #60070]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60070
In the lex branch I'm trying to add a new opcode, but
I'm running into a build issue with opcode renumbering --
after adding an opcode and running make opsrenumber,
attempting to rebuild parrot fails with:
/usr/bin/perl tools/build/ops2pm.pl src/ops/core.ops src/ops/bit.ops
src/ops/cmp.ops src/ops/debug.ops src/ops/experimental.ops src/ops/io.ops
src/ops/math.ops src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops
src/ops/set.ops src/ops/stm.ops src/ops/string.ops src/ops/sys.ops
src/ops/var.ops
skipped opcode is also in src/ops/ops.num at lib/Parrot/Ops2pm.pm line 145,
$op line 11.
make: *** [lib/Parrot/OpLib/core.pm] Error 9
In fact, this failure appears even if a new opcode isn't added --
simply performing make opsrenumber followed by make results in
the same error:
$ svn up
At revision 32122.
$ make opsrenumber
/usr/bin/perl tools/dev/opsrenumber.pl src/ops/core.ops src/ops/bit.ops
src/ops/cmp.ops src/ops/debug.ops src/ops/experimental.ops src/ops/io.ops
src/ops/math.ops src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops
src/ops/set.ops src/ops/stm.ops src/ops/string.ops src/ops/sys.ops
src/ops/var.ops
$ make
[...]
/usr/bin/perl tools/build/ops2pm.pl src/ops/core.ops src/ops/bit.ops
src/ops/cmp.ops src/ops/debug.ops src/ops/experimental.ops src/ops/io.ops
src/ops/math.ops src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops
src/ops/set.ops src/ops/stm.ops src/ops/string.ops src/ops/sys.ops
src/ops/var.ops
skipped opcode is also in src/ops/ops.num at lib/Parrot/Ops2pm.pm line 145,
$op line 11.
make: *** [lib/Parrot/OpLib/core.pm] Error 9
$
Since a number of steps have changed since the last time I worked
with adding/removing opcodes (April 2008), and I have little idea
what might be causing this, I'm filing this ticket in hopes that
someone can clear things up for me.
this is definitely fallout from the mmd branch merge. seems ops.skip
hasn't been modified, and make opsrenumber was never run after opcodes
were modified.
i wrote a hack that suggests all ops from ops.skip should be removed:
#!perl
use strict;
use warnings;
open my($NUM), '', 'ops.num'
or die $!;
open my($SKIP), '', 'ops.skip'
or die $!;
my $seen = {};
while ($SKIP) {
next unless m/^(\w+)/;
$seen-{$1}++;
}
while ($NUM) {
next unless m/^(\w+)/;
--$seen-{$1}
if defined $seen-{$1};
}
print $seen-{$_} ? ($_,$/) : ()
for keys %$seen;
=
c:\usr\local\parrot\main\src\opsseen.pl
c:\usr\local\parrot\main\src\ops
=
it returns no results, suggesting that all ops be removed from ops.skip.
indeed, after this, i am able to rebuild parrot, even with an added
opcode to core.ops (and running make opsrenumber).
however, i'm too tired to wait for the test suite to finish running,
so i'm reporting this before i hit the sack and will pick it up on the
morrow if nobody beats me to it.
~jerry
Re: Parrot on mobile platforms?
On Wednesday 22 October 2008 23:23:46 Gabor Szabo wrote: I am totally lack of relevant knowledge so I'd like to get some from you. There are many mobile platforms out there. Linux based, Symbian, Blackberry, iPhone, Windows, Palm, Android, etc.. I wonder what are the chances of Parrot running on any of these? Decent, with some work. Has anyone tried? Not to my knowledge. What needs to be done in order to get Parrot on these devices? With the iPhone or Android-based phones, someone would have to crack the phone such that we have access to what passes for bare OS, instead of the Objective C/NeXT runtime or Dalvik. For the other platforms, we need to: 1) Figure out a cross-compilation strategy (which means improving our configuration system such that it takes hints from a file, not from direct probes and Perl 5's Config.pm) 2) Disable certain features (different runcores, JIT, much of NCI) 3) Add architecture and platform-specific files for the parts of POSIX they don't already support 4) Figure out an installation and execution strategy for bytecode 5) Revisit #2, to get the installation size down further (500k for a Parrot binary seems like a maximum) -- c
Re: Parrot on mobile platforms?
Thanks for the quick answer. Then I have another few questions :-) Don't you think it would be important to start working in this direction? Maybe to try to get someone work on this or to get sponsorship in that direction? Gabor On Thu, Oct 23, 2008 at 8:33 AM, chromatic [EMAIL PROTECTED] wrote: On Wednesday 22 October 2008 23:23:46 Gabor Szabo wrote: I am totally lack of relevant knowledge so I'd like to get some from you. There are many mobile platforms out there. Linux based, Symbian, Blackberry, iPhone, Windows, Palm, Android, etc.. I wonder what are the chances of Parrot running on any of these? Decent, with some work. Has anyone tried? Not to my knowledge. What needs to be done in order to get Parrot on these devices? With the iPhone or Android-based phones, someone would have to crack the phone such that we have access to what passes for bare OS, instead of the Objective C/NeXT runtime or Dalvik. For the other platforms, we need to: 1) Figure out a cross-compilation strategy (which means improving our configuration system such that it takes hints from a file, not from direct probes and Perl 5's Config.pm) 2) Disable certain features (different runcores, JIT, much of NCI) 3) Add architecture and platform-specific files for the parts of POSIX they don't already support 4) Figure out an installation and execution strategy for bytecode 5) Revisit #2, to get the installation size down further (500k for a Parrot binary seems like a maximum) -- c
Re: [perl #60070] [BUG] make opsrenumber causes build to fail
On Wednesday 22 October 2008 23:06:22 jerry gay wrote: this is definitely fallout from the mmd branch merge. seems ops.skip hasn't been modified, and make opsrenumber was never run after opcodes were modified. i wrote a hack that suggests all ops from ops.skip should be removed: That's wrong. ops.skip is right. make opsrenumber is doing something wrong. Run it, then check the diff against ops.num. make opsrenumber adds ops that we specifically want to exclude. They're not in Parrot trunk for a reason. -- c
Re: Parrot on mobile platforms?
On Wednesday 22 October 2008 23:47:23 Gabor Szabo wrote: Thanks for the quick answer. Then I have another few questions :-) Don't you think it would be important to start working in this direction? Sure, but I think a lot of things are important. My top priority is to fix anything that blocks people who are trying to build things with Parrot (that includes answering questions and fixing documentation). My secondary priority is to clean up existing code to make future blockers impossible. My tertiary priority is to add new features. Maybe to try to get someone work on this or to get sponsorship in that direction? I'm happy to offer guidance to anyone who'd like to do this. -- c
Re: [perl #60070] [BUG] make opsrenumber causes build to fail
On Wednesday 22 October 2008 22:49:37 Patrick R. Michaud (via RT) wrote:
Since a number of steps have changed since the last time I worked
with adding/removing opcodes (April 2008), and I have little idea
what might be causing this, I'm filing this ticket in hopes that
someone can clear things up for me.
This patch fixes things for me, with minimal fuss and without inadvertently
adding back in ops that we explicitly blacklist via src/ops/ops.skip.
Note that I had to manually rebuild the PGE, TGE, and JSON compilers because
op numbers changed in bytecode. 'make realclean' will do.
I didn't run the Perl 5 tests of the Parrot::Ops2pm modules. They'll probably
fail, because the Perl 5 code was wrong.
-- c
=== lib/Parrot/OpsRenumber.pm
==
--- lib/Parrot/OpsRenumber.pm (revision 32155)
+++ lib/Parrot/OpsRenumber.pm (local)
@@ -1,4 +1,4 @@
-# Copyright (C) 2007, The Perl Foundation.
+# Copyright (C) 2007-2008, The Perl Foundation.
# $Id$
package Parrot::OpsRenumber;
use strict;
@@ -77,7 +77,6 @@
my $file = scalar(@_) ? shift : $self-{num_file};
if ($major_version == 0) {
-
# Pre-Parrot 1.0 case
# We open up the currently existing ops.num and file and read it
@@ -91,7 +90,7 @@
# pushed into %fixed as well. Nothing happens to the (opcode) lines
# below the DYNAMIC line.
-my ( $name, $number, @lines, %fixed, $fix );
+my ( $name, $number, @lines, %seen, %fixed, $fix );
$fix = 1;
open my $OP, '', $file
or die Can't open $file, error $!;
@@ -104,7 +103,8 @@
s/^\s*//;
next unless $_;
( $name, $number ) = split( /\s+/, $_ );
-$fixed{$name} = $number if ($fix);
+$seen{$name} = $number;
+$fixed{$name} = $number if $fix;
}
close $OP;
@@ -148,7 +148,7 @@
# For all other opcodes, we'll print the opcode, increment the
# index, then print the index on that same line.
-else {
+elsif ( $seen{ $_-full_name } ) {
printf $OP %-31s%4d\n, $_-full_name, ++$n;
}
}
Re: Parrot on mobile platforms?
--- On Thu, 23/10/08, Gabor Szabo [EMAIL PROTECTED] wrote: Don't you think it would be important to start working in this direction? Maybe to try to get someone work on this or to get sponsorship in that direction? I can't speak for Android, but I know one of the constraints on the iPhone is memory. This, as I recall, is part of the reason why they don't have garbage collection available and force people to manage memory directly (this, I might add, is a pain). Since I generally don't worry about memory, I've no idea if Parrot is a memory hog. That being said, I can't imagine Apple would be terribly keen to endorse anything which requires jail breaking the phone. Don't we have contacts in Apple? Getting official approval for trying this out might be a nice thing. In fact, I already know an iPhone developer who would be a great fit for a challenge like this (if he's interested). Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
[perl #39760] [CAGE] make warnings (r13197 - x86-msvc-7.1)
The warning of inconsistent dll linkage no longer occurs on microsoft visual studio, which resolves this issue. kjs
[perl #48014] [DEPRECATED] PMC union struct
On Mo. 08. Sep. 2008, 13:59:08, julianalbo wrote: Done in r30914: changed name to Parrot_type_attributes, fixed codingstd, changed also pmc in languages lua and perl6, and updated pdd17_pmc.pod Does this mean that this ticket can be closed and the deprecation item in DEPRECATED.pod be removed? -- /* [EMAIL PROTECTED] */
[perl #60060] [BUG] Parrot_readbc() does too many stat()s
# New Ticket Created by Stephane Payrard # Please include the string: [perl #60060] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60060 This results in 4 stat()s per pbc. opening the file and using Parrot_fstat_info_intval() instead of Parrot_stat_info_intval() will be less costly. this means retooling readbc() that now stats the file to verify it can open it. -- cognominal stef
Re: Parrot on mobile platforms?
Don't you think it would be important to start working in this direction? Maybe to try to get someone work on this or to get sponsorship in that direction? I think the easier step towards this goal may be to make cross compiling works with two well-known platforms. For example, targeting mingw from linux, using the cross mingw package from the distro. -- Salu2
Re: [perl #48014] [DEPRECATED] PMC union struct
On Wed, Oct 22, 2008 at 6:28 PM, Bernhard Schmalhofer via RT [EMAIL PROTECTED] wrote: Done in r30914: changed name to Parrot_type_attributes, fixed codingstd, changed also pmc in languages lua and perl6, and updated pdd17_pmc.pod Does this mean that this ticket can be closed and the deprecation item in DEPRECATED.pod be removed? No, this was just a helper step. -- Salu2
Re: [perl #60060] [BUG] Parrot_readbc() does too many stat()s
On Thu, Oct 23, 2008 at 1:43 AM, via RT Stephane Payrard [EMAIL PROTECTED] wrote: This results in 4 stat()s per pbc. opening the file and using Parrot_fstat_info_intval() instead of Parrot_stat_info_intval() will be less costly. this means retooling readbc() that now stats the file to verify it can open it. I think will be faster and cleaner to have a function that takes a file handler. That way the search functions can just try to open a file instead of doing stat call for any directory in the search paths, and then pass a file path to do even more stat on it. -- Salu2
Re: [perl #60070] [BUG] make opsrenumber causes build to fail
On Thu, Oct 23, 2008 at 12:38:36AM -0700, chromatic wrote: On Wednesday 22 October 2008 22:49:37 Patrick R. Michaud (via RT) wrote: This patch fixes things for me, with minimal fuss and without inadvertently adding back in ops that we explicitly blacklist via src/ops/ops.skip. Patch works for me, and applied in r32134. I also regenerated the ops.num file, updated PBC_COMPAT, and fixed(?) a few other items relating to adding/removing opcodes that I encountered while working with this patch. Closing ticket, thanks! Pm
Re: [perl #60044] [BUG?] rethrow just throwing?
Will Coleda (via RT) wrote: I would expect both of these programs to output the same thing, but it looks like rethrow is generating the same output that throw would here. What is the difference supposed to be between these two ops? The two ops are intentionally almost entirely the same. The only difference is that 'throw' creates a new iterator of exception handlers, while 'rethrow' pulls the next exception handler off the iterator. So, 'rethrow' cannot be called on an exception that hasn't been thrown before. And if 'throw' is called on an exception that's already been thrown before, it will return to the first exception handler again, instead of the next exception handler in the chain of handlers. $ cat foo.pir sub foo :main bar() end sub bar baz() end sub baz die eek end $ ../../parrot foo.pir eek current instr.: 'baz' pc 24 (foo.pir:10) called from Sub 'bar' pc 19 (foo.pir:6) called from Sub 'foo' pc 7 (foo.pir:2) $ cat bar.pir sub foo :main push_eh eh bar() pop_eh end eh: .get_results($P0) rethrow $P0 end sub bar baz() end sub baz die eek end $ ../../parrot bar.pir eek current instr.: 'foo' pc 16 (bar.pir:9) I don't understand the problem. Is it that you expect 'rethrow' to keep the stack trace of the original 'die'? Allison
Re: Parrot on mobile platforms?
Ovid wrote: I can't speak for Android, but I know one of the constraints on the iPhone is memory. This, as I recall, is part of the reason why they don't have garbage collection available and force people to manage memory directly (this, I might add, is a pain). Since I generally don't worry about memory, I've no idea if Parrot is a memory hog. It's light on memory compared to other virtual machines, but would require some work to get it down to mobile phone size. That being said, I can't imagine Apple would be terribly keen to endorse anything which requires jail breaking the phone. Don't we have contacts in Apple? Getting official approval for trying this out might be a nice thing. In fact, I already know an iPhone developer who would be a great fit for a challenge like this (if he's interested). Yes, but the mobile group is completely separate from the open source group. Still, it's worth asking. Allison
Re: [perl #60048] CGP Does Not Work with PCC Runcore Reentry
chromatic (via RT) wrote: Several tests fail with the CGP runcore (parrot -C) when multidispatch re-enters bytecode -- in specific, anything that calls into src/pic.c from Parrot_pcc_invoke_sub_from_sig_object causes failures. The problem appears to be that CGP's PIC tries to poke into the bytecode directly to find get_params and similar opcodes, while parameter-passing information is in a context after Parrot_pcc_invoke_sub_from_sig_object. One workaround is to enforce the use of the normal runcore only for calls back into Parrot from Parrot_pcc_invoke_sub_from_sig_object, but that's just a workaround. A better solution is to fix the PIC code to look in the appropriate place in the context for return values. That seems like a good task for the calling conventions branch. I've been debating whether src/pic.c should be removed entirely. It's a swodge of code that only gives a tiny speedup for 4 opcodes: 'infix', 'get_params', 'set_args', and 'set_returns'. And the 'infix' opcode has been deprecated and will be removed in the calling conventions branch (it was a nasty hack for the old MMD system). And it's not even really the right speedup for 'get_params', 'set_args', and 'set_returns'. There are also a pile of old, nasty MMD functions that should be deleted and are only called from src/pic.c. Allison
