attached is a testfile.

file "imm.pir" contains:

============
.sub main
.end

.sub foo :postcomp
   print "postcomp\n"
.end

.sub bar :immediate
    print "immediate\n"
.end
=============

and file "main.pir" contains:

===========
.sub main2 :main
    load_bytecode "imm.pir"
    print "ok\n"
.end
===========

There are different options to run:

parrot imm.pir outputs:

immediate
postcomp


Now, in main.pir the file imm.pir is loaded, so something should happen when
running main.pir:
parrot main.pir outputs:

immediate
ok

So, apparently the :postcomp tagged sub is not run when loaded by another
file.

My conclusion is (and please correct me if I'm wrong):

1. use :immediate if the sub must be run after compilation, no matter what
the compilation caused (whether running the file containing that sub, or the
file containing that sub was "load_bytecode"-ed.

2. use :postcomp if the sub must be run after compilation ONLY if the file
in which the sub was defined is compiled explicitly (by running "parrot
<file>"). The sub is NOT run when the sub is compiled due to a load_bytecode
operation.

I don't really see a use-case right now, but I guess there is /some/ use for
it.

regards,
kjs

On 9/18/07, jerry gay <[EMAIL PROTECTED]> wrote:
>
> On 9/18/07, Will Coleda via RT <[EMAIL PROTECTED]> wrote:
> > On Wed Sep 12 08:28:27 2007, kjs wrote:
> > > Hello,
> > >
> > > From:
> > > http://www.parrotcode.org/docs/pdd/pdd06_pasm.html
> > >
> > > The following flags are available: :main to indicate that execution
> should
> > > start at the specified subroutine; :immediate or :postcomp to indicate
> > that
> > > the sub should be run immediately after compilation; :load to indicate
> > that
> > > the sub should be executed when its bytecode segment is loaded; :init
> to
> > > indicate the sub should be run when the file is run directly.
> > >
> > >
> > > THere are two flags, ":immediate" and ":postcomp" that have the same
> > > behaviour.
> > > IMO, it'd be nice to remove such redundancies from IMCC.
> > >
> > > My proposal is to remove either :immediate or :postcomp. I'd vote for
> > > keeping :immediate, thus removing :postcomp.
> > >
> > > regards,
> > > kjs
> >
> > As long as :postcomp has no meaning aside from what :immediate provides,
> > I agree, it should be removed.
> >
> yep, :postcomp and :immediate are the same, let's settle on :immediate
> and remove :postcomp.
> ~jerry
>

Attachment: imm.pir
Description: Binary data

Attachment: main.pir
Description: Binary data

Reply via email to