[perl #39856] TODO: Produce Single PBC from Multiple PIR Files with -o

[Chromatic]

# New Ticket Created by chromatic
# Please include the string: [perl #39856]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39856 >

After discussing the idea with Allison, we both believe that Parrot should be
able to produce a single PBC file from a command like:

parrot -o all_files.pbc file1.pir file2.pir ... filen.pir

-- c

[Joshua Hoblitt]

On Mon, Jul 17, 2006 at 12:11:55PM -0700, chromatic wrote:
> After discussing the idea with Allison, we both believe that Parrot should be
> able to produce a single PBC file from a command like:
>
> parrot -o all_files.pbc file1.pir file2.pir ... filen.pir

It'd probably make sense to define some clear rules on how symbol
conflicts are handled up front. As it's always nice to know which :main
to invoke. :) A possible rule could be "the version of the symbol that
appears in 'left most" file has precedence". Alternatively, a symbol
collision could just be a fatal error.

-J

--

[Leopold Toetsch]

Am Montag, 17. Juli 2006 21:11 schrieb chromatic:

>
> After discussing the idea with Allison, we both believe that Parrot should
> be able to produce a single PBC file from a command like:
>
> parrot -o all_files.pbc file1.pir file2.pir ... filen.pir

Well, that exists already and is named pbc_merge. pbc_merge takes .pbc input
only, but this shouldn't be a problem.

leo

[Allison Randal]

pbc_merge doesn't allow multiple :load routines. What we're looking for
is more of a Parrot version of .par/.jar/.pkg: bundle up all the files
you need for a particular application into a single file. Not a PBC, but
some form of "archive" or "package" format.

Allison

[Chip Salzenberg]

On Tue, Aug 08, 2006 at 06:19:18PM -0700, Allison Randal wrote:
> Leopold Toetsch wrote:
> >Am Montag, 17. Juli 2006 21:11 schrieb chromatic:
> >
> >>After discussing the idea with Allison, we both believe that Parrot should
> >>be able to produce a single PBC file from a command like:
> >>
> >> parrot -o all_files.pbc file1.pir file2.pir ... filen.pir
> >
> >Well, that exists already and is named pbc_merge. pbc_merge takes .pbc
> >input only, but this shouldn't be a problem.
>
> pbc_merge doesn't allow multiple :load routines.

That's a bug, Shirley.

> What we're looking for is more of a Parrot version of .par/.jar/.pkg:
> bundle up all the files you need for a particular application into a
> single file. Not a PBC, but some form of "archive" or "package" format.

I don't see any harm in .zip and .tar and [archive method of choice]
plugins.
--
Chip Salzenberg <ch...@pobox.com>

[Allison Randal]

Chip Salzenberg wrote:
>> pbc_merge doesn't allow multiple :load routines.
>
> That's a bug, Shirley.

Currently it's a feature. Only one :load routine is allowed per PIR
file, and pbc_merge basically just packs all the compiled code together.
I could argue that maybe we should allow multiple :load routines, but
what about :main routines?

>> What we're looking for is more of a Parrot version of .par/.jar/.pkg:
>> bundle up all the files you need for a particular application into a
>> single file. Not a PBC, but some form of "archive" or "package" format.
>
> I don't see any harm in .zip and .tar and [archive method of choice]
> plugins.

Seems like a good way to approach it.

Allison

[Jerry Gay]

On 8/9/06, Allison Randal <all...@perl.org> wrote:
> Chip Salzenberg wrote:
> >> pbc_merge doesn't allow multiple :load routines.
> >
> > That's a bug, Shirley.
>
> Currently it's a feature. Only one :load routine is allowed per PIR
> file, and pbc_merge basically just packs all the compiled code together.
> I could argue that maybe we should allow multiple :load routines, but
> what about :main routines?
>

i don't think you're correct about C<:load> here, at least not from my
reading of the (somewhat hard-to-find) docs (see
F<docs/imcc/calling_conventions.pod>):

=head2 Subpragma

This is a list of zero or more items with the following meanings:

=over 4

=item :main

Define "main" entry point to start execution. If multiple subroutines
are marked as B<:main>, the B<last> marked subroutine is entered.

=item :load

Run this subroutine during the B<load_library> opcode.
B<:load> is ignored, if another subroutine in that file is marked with
B<:main>. If multiple subs have the B<:load> pragma, the subs are
run in source code order.

=cut

please also see the tests, at F<t/pmc/sub.t:558-605> (inline below)
which seem to match the docs.

open S, ">$temp" or die "Can't write $temp";
print S <<'EOF';
.pcc_sub :load _sub1:
print "in sub1\n"
returncc
.pcc_sub :load _sub2:
print "in sub2\n"
returncc
EOF
close S;

pasm_output_is(<<'CODE', <<'OUTPUT', "load_bytecode autorun both");
.pcc_sub _main:
print "main\n"
load_bytecode "temp.pasm"
print "loaded\n"
find_global P0, "_sub1"
invokecc P0
print "back\n"
end
CODE
main
in sub1
in sub2
loaded
in sub1
back
OUTPUT

system(".$PConfig{slash}parrot$PConfig{exe} -o temp.pbc $temp");

pasm_output_is(<<'CODE', <<'OUTPUT', "load_bytecode autorun both in pbc");
.pcc_sub _main:
print "main\n"
load_bytecode "temp.pbc"
print "loaded\n"
find_global P0, "_sub1"
invokecc P0
print "back\n"
end
CODE
main
in sub1
in sub2
loaded
in sub1
back
OUTPUT

hope that helps clarify the current behavior a bit.
~jerry