It seems to me that the correct code in HLL/Backend.nqp should be:

my $temppath := nqp::getcomp("nqp").config()<libdir> ~ '/profiler/template.html';

@vrurg I gave that a try. It fails with: X::AdHoc: Cannot call method 'config' on a null object.

Not really sure where to continue from here. I tried a few things but it seems the nqp compiler is not always available.

Ok, I see. I didn't know that rakudo uses profiling code from nqp. nqp::getcomp("nqp") makes sense under nqp runtime only. For rakudo the line would look like:

nqp::getcomp("Raku").config<nqp-home> ~ 'lib/profiler/template.html'

So, the problem would be to know which compiler to use. @lizmat do you have an idea?

Try both, and see which one yields something to work with?

@lizmat the first thought. But what if somebody writes another nqp-based compiler?

Actually, as I look into it, the place where template.html gets installed is incorrect because the file is moar-backend specific and as such should be installed under some kind of backend subdir.

So far, it looks like the proper solution would be to add compiler parameter to run_profiled, dump_profile_data, and dump_instrumented_profile_data methods. Then instead of nqp::getcomp(...).config $compiler.config can be used.

Then, there is minor discrepancy to be taken care of somehow. NQP config has nqp_home key. But in Rakudo it is named nqp-home. I think this should be solved by renaming nqp_home into nqp-home or providing both variants for nqp compiler.

If nqp_home is something that can be set by environment variables, then I would choose to to rename the nqp-home to nqp_home instead of vice-versa: you cannot use hyphens in environment variables afaik.

No, it is purely our implementation detail thing. It is only affected by Configure.pl command line. If there is

Changing it to nqp-home would also go in line with source-digest key in the compiler config.

So far, it looks like the proper solution would be to add compiler parameter to run_profiled, dump_profile_data, and dump_instrumented_profile_data methods. Then instead of nqp::getcomp(...).config $compiler.config can be used.

This seems overly complicated. When configuring NQP, we already know where it is going to be installed into, so we should be able to just get the path in there.

What about making hll-config, which is the function generated by gen-version.pl, part of the core setting? Then we can just call that and extract nqp-home or even libdir.

Nevermind, this has to be done because nqp-home can be overridden with the NQP_HOME environment variable when invoking Rakudo. I’ll see if passing the compiler config around works.

And if the environment variable is called NQP_HOME, I think it should be called "nqp_home" internally as well.

@lizmat I disagree. By this logic we should use uppercase too. As well as rakudo-home key.

Snake case would make it inconsistent with other keys in the config. It's even more confusing, than the difference from the environment. Whereas if one already knows what's the rule of thomb he'd expect the key to be kebab-lower-cased.