From @cognominal

The error message is "No such caller depth"

Having it working would be a additional tool.
Indeed, I wanted to tweak the code manually to see the code I needed
the rakudo compiler to generated.

I have not investigated but I suppose some setting code is missing.

--
cognominal stef

From @pmichaud

On Fri, Apr 18, 2008 at 06​:30​:24AM -0700, Stephane Payrard wrote​:

The error message is "No such caller depth"

Having it working would be a additional tool.
Indeed, I wanted to tweak the code manually to see the code I needed
the rakudo compiler to generated.

I have not investigated but I suppose some setting code is missing.

The code produced by --target=pir won't run standalone, it also
needs support code for loading the Perl 6 runtime libraries
(i.e., perl6.pbc).

Pm

The RT System itself - Status changed from 'new' to 'open'

From @chromatic

On Friday 18 April 2008 07​:45​:43 Patrick R. Michaud wrote​:

On Fri, Apr 18, 2008 at 06​:30​:24AM -0700, Stephane Payrard wrote​:

The error message is "No such caller depth"

Having it working would be a additional tool.
Indeed, I wanted to tweak the code manually to see the code I needed
the rakudo compiler to generated.

I have not investigated but I suppose some setting code is missing.

The code produced by --target=pir won't run standalone, it also
needs support code for loading the Perl 6 runtime libraries
(i.e., perl6.pbc).

Is it useful to add code to HLLCompiler for this purpose? I've wanted
something similar in Pheme for a while, and I suspect it would help with
debugging Tcl and Lua as well.

-- c

From @coke

On Fri, Apr 18, 2008 at 12​:47 PM, chromatic <chromatic@​wgz.org> wrote​:

On Friday 18 April 2008 07​:45​:43 Patrick R. Michaud wrote​:

On Fri, Apr 18, 2008 at 06​:30​:24AM -0700, Stephane Payrard wrote​:

The error message is "No such caller depth"

Having it working would be a additional tool.
Indeed, I wanted to tweak the code manually to see the code I needed
the rakudo compiler to generated.

I have not investigated but I suppose some setting code is missing.

The code produced by --target=pir won't run standalone, it also
needs support code for loading the Perl 6 runtime libraries
(i.e., perl6.pbc).

Is it useful to add code to HLLCompiler for this purpose? I've wanted
something similar in Pheme for a while, and I suspect it would help with
debugging Tcl and Lua as well.

-- c

FYI, tcl doesn't (yet?) use HLLCompiler, and rolls its own PIR
generation. If you run​:

../../parrot tcl.pbc --pir -e 'puts hi'

you should get PIR that can run standalone.

--
Will "Coke" Coleda

From @pmichaud

On Fri, Apr 18, 2008 at 09​:47​:06AM -0700, chromatic wrote​:

On Fri, Apr 18, 2008 at 06​:30​:24AM -0700, Stephane Payrard wrote​:

Having it working would be a additional tool.
Indeed, I wanted to tweak the code manually to see the code I needed
the rakudo compiler to generated.

I have not investigated but I suppose some setting code is missing.

The code produced by --target=pir won't run standalone, it also
needs support code for loading the Perl 6 runtime libraries
(i.e., perl6.pbc).

Is it useful to add code to HLLCompiler for this purpose? I've wanted
something similar in Pheme for a while, and I suspect it would help with
debugging Tcl and Lua as well.

I'm not certain it belongs mainly in HLLCompiler. To get a .pir
file to run standalone we essentially need an anonymous :main sub
somewhere in the --target=pir output that does​:

1. load the runtime library (e.g. load_bytecode 'perl6.pbc')
2. process command line arguments similar to what HLLCompiler and
  the HLL would do
3. invoke the primary sub that was generated by --target=pir

For #​1, it would be good if the runtime library is kept in a
standard location -- I don't think that hardcoding the languages/perl6
path is good for this. I suppose the compiler .pbc files could
go into .../runtime/parrot/library/ but that feels a little wrong to
me. (See also RT#​47992, which discusses providing a standard location
for compiler runtimes.)

For #​2 we can't just call the 'command_line' method provided by HLLCompiler,
because that's processing --target= and other options that really aren't
applicable to an already-compiled .pir file. Also, some command line
options may end up being specific to the HLL, and thus are better handled
by the HLL runtime rather than HLLCompiler itself.

Anyway, this is something would be good to research achieving in Rakudo,
but it will require a fair bit of refactoring in perl6.pir to move things
out of the current :main and into :load :init subs. Again, the trickiest
part at the moment is getting command-line arguments into the appropriate
location (I have a few ideas about this that I'll try shortly).

Pm

From @chromatic

On Friday 18 April 2008 07​:45​:43 Patrick R. Michaud wrote​:

On Fri, Apr 18, 2008 at 06​:30​:24AM -0700, Stephane Payrard wrote​:

The error message is "No such caller depth"

Having it working would be a additional tool.
Indeed, I wanted to tweak the code manually to see the code I needed
the rakudo compiler to generated.

I have not investigated but I suppose some setting code is missing.

The code produced by --target=pir won't run standalone, it also
needs support code for loading the Perl 6 runtime libraries
(i.e., perl6.pbc).

Is it useful to add code to HLLCompiler for this purpose? I've wanted
something similar in Pheme for a while, and I suspect it would help with
debugging Tcl and Lua as well.

-- c

From @pmichaud

As of r30764, code generated by --target=pir now runs directly from parrot​:

$ cat hello.pl
sub foo() { say 'hello'; }

foo();
$ ./parrot perl6.pbc --target=pir --output=hello.pir hello.pl
$ ./parrot hello.pir
hello
$

Pm

@pmichaud - Status changed from 'open' to 'resolved'