src/Perl6/Compiler.nqp: Show "Star" in the version output

[AntonOks]

Add "Star" in the various raku version outputs...

So, instead now:

• Welcome to Rakudo v2023.12
  something like:
• Welcome to Rakudo Star v2023.12
  will be shown in raku -v (and similar commands)

[AntonOks]

@lizmat @coke

What do you think? Can I merge those quick&dirty additions to make clear it's a "Star" release, people use?
That i.e. would help users to differentiate between the Raku and the Star release in case of issues and help them to open such an issue in the correct GitHub repo or ask for help / infos in the fitting IRC chat channel...

[coke]

I'm not sure this will help avoid confusion, but instead drive more rakudo tickets to r* - І think if we can transfer tickets between repos that helps more.

Also: there's a star channel?

[lizmat]

#raku-star on Libera.chat

[AntonOks]

“Transferring issues” works for someone, who has proper permissions on both involved GitHub repos… as long as we have our repos and CI’s on this platform 😊 Nevertheless, from some last posted issues, I want to add more clarification what Star is today… and what not. Actually, making clear it’s just Raku + some modules right now.

[AntonOks]

#raku-star on Libera.chat

@lizmat - do you plan to "review" and / or comment on this pull?
So, shall I therefore wait for your feedback here and/or now and then check on #raku-star @ Libera, or are you just fine with whatever...

[patrickbkr]

I don't like this. The rakudo itself is not different between star and plain. This change will add to the confusion if the raku(do) executable reports itself as star. Star is a bundle of modules, nothing more nothing less. You would have essentially the same result with a rakudo installed via other means and zef install-ing the respective set of modules.

[lizmat]

@AntonOks I was merely reacting to @coke's question: "Also: there's a star channel?"

[lizmat]

I would not be against modifying the raku version output. But I would be against modifying src/Perl6/Compiler.nqp for this. 1. because I don't like distributions to change source code of the compiler, and 2. this file is basically EOL in the RakuAST world.

I was more thinking about a text file somewhere that would be read for the information to be added to the "Rakudo(tm)" string, so that e.g. rakubrew could also use that. Something that would be added around line 165. And that Rakudo Star would add that file then, with the content "Star".

Hope that made sense?

[AntonOks]

I would not be against modifying the raku version output. But I would be against modifying src/Perl6/Compiler.nqp for this. 1. because I don't like distributions to change source code of the compiler, and 2. this file is basically EOL in the RakuAST world.

I was more thinking about a text file somewhere that would be read for the information to be added to the "Rakudo(tm)" string, so that e.g. rakubrew could also use that. Something that would be added around line 165. And that Rakudo Star would add that file then, with the content "Star".

Hope that made sense?

Thanks. Both do make sense for me :)

1. "text file somewhere"

   • as this file could be anywhere in the directory tree (remember, the "Rakudo source" and therefore "Compiler.nqp", can also be anywhere in a local directory tree... most of the time "git cloned", but also un-zipped or the like) we need to agree on
     1. the "file name"
     2. file location(s) to check for this file and
     3. the syntax of the file content
        • on the "syntax", I'd say, we take something line the first string / word, i.e. [\w+]

2. Right now, the "Compiler.nqp" file still would have to be changed to adopt this "text file" info, right? But now in "Raku core" centrally instead of in the "Star" repo, as proposed? That's what you mean with "would be added around line 165"?

   • adding a new IF loop, checking for the "text file" and then including the found word/string after the "Rakudo(tm)" string?!

3. As "Compile.nqp" is EOL, where is the "release information" coming from with/after RakuAST? :O And how to implement this kind of "opportunity"/enhancement for different version infos there?

Thanks & regards

[AntonOks]

I don't like this. The rakudo itself is not different between star and plain. This change will add to the confusion if the raku(do) executable reports itself as star. Star is a bundle of modules, nothing more nothing less. You would have essentially the same result with a rakudo installed via other means and zef install-ing the respective set of modules.

So, "Star" is unneeded and can be discontinued?

[lizmat]

Some answers:

As file name, I would suggest "SYNDICATION".

Please suggest a file location: I think you have a better idea for that than I can have atm.

The file content would be inserted verbatim.

adding a new IF loop, checking for the "text file" and then including the found word/string after the "Rakudo(tm)" string?!

Yes, with a space inbetween.

As "Compile.nqp" is EOL, where is the "release information" coming from with/after RakuAST?

I don't know yet. But this would put the burden of maintaining compatibility with the Raku Core team, rather than with each syndication.

[patrickbkr]

No! That's not what I wanted to say! I believe there is a place for the Star bundle. That's also evident from the stable user base. Just the rakudo executable itself in the Star bundle is not different to any other rakudo executable. And when it's not different it shouldn't say it's different.

…

On January 7, 2024 4:15:36 PM GMT+01:00, Anton Oks ***@***.***> wrote: > I don't like this. The rakudo itself is not different between star and plain. This change will add to the confusion if the raku(do) executable reports itself as star. Star is a bundle of modules, nothing more nothing less. You would have essentially the same result with a rakudo installed via other means and `zef install`-ing the respective set of modules. So, "Star" is unneeded and can be discontinued? -- Reply to this email directly or view it on GitHub: #198 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[lizmat]

Just the rakudo executable itself in the Star bundle is not different to any other rakudo executable. And when it's not different it shouldn't say it's different.

They may be the same, but the originated from a different "source". I think there's value in being able to tell that if you run raku -v it will tell you whether it is from a vanilla install, or a Rakudo Star, or from a rakubrew install. Especially if you have multiple rakudos installed on a system and you get your PATHs mixed up. Been there, done that :-(

[AntonOks]

No! That's not what I wanted to say! I believe there is a place for the Star bundle. That's also evident from the stable user base.

Ok, thanks. And sorry, I misunderstood it then...

Just the rakudo executable itself in the Star bundle is not different to any other rakudo executable. And when it's not different it shouldn't say it's different.

Well, the "[official Star] rakudo executable" is (currently) build (on GitHub via "Actions") from the same source code, see "NQP, MoarVM and Raku release git tags", as "Raku core", that's true, but...

• everyone can build a "Star release" on any Rakudo, NQP and MoarVM source
• even if the current "Star" is build on the same source code as "Raku core", the "build host" and it's environment (say, system OS version / release, compiler version and the like, can be very different for every build... so the binaries between "Raku core" and "Star" are somehow different
  • even binaries for the same "Star" version, build on different "build hosts", can be different...

Anyhow, all this may be too much of unneeded details for this pull request anyhow...

[AntonOks]

As file name, I would suggest "SYNDICATION".

Thanks for your suggestion.
"SYNDICATION" somehow makes my brain spinning... haven't seen this kind of name for something like "enhanced release of something else". My brain would calm down with a very "obvious logical file name"... but I do not have an idea / suggestion myself right now :|

Please suggest a file location: I think you have a better idea for that than I can have atm.

Need to think about this. Too many choices and "building Raku ways" to consider...

The file content would be inserted verbatim.

adding a new IF loop, checking for the "text file" and then including the found word/string after the "Rakudo(tm)" string?!

Yes, with a space inbetween.

If this has to be done in "Compiler.nqp", do I need to use "nqp", or can it be done in Perl5 and/or Raku code there?

• Where / how is the "Compiler.nqp" file / scripts used within the Raku build process?
  Any example available, where a "config file content" is read-in and then worked-with in any other "nqp" script or during the Raku build process?

As "Compile.nqp" is EOL, where is the "release information" coming from with/after RakuAST?

I don't know yet. But this would put the burden of maintaining compatibility with the Raku Core team, rather than with each syndication.

[lizmat]

On 13 Jan 2024, at 16:50, Anton Oks ***@***.***> wrote: If this has to be done in "Compiler.nqp", do I need to use "nqp", or can it be done in Perl5 and/or Raku code there?

It can just be added to the code in Compiler.nqp. As NQP code, which would mean an nqp::open, nqp::read and an nqp::close. Since the reading would be done at runtime, and only when someone does -v, the file location would need to be connected to *that* installation of Rakudo.

[AntonOks]

It can just be added to the code in Compiler.nqp. As NQP code, which would mean an nqp::open, nqp::read and an nqp::close. Since the reading would be done at runtime, and only when someone does -v, the file location would need to be connected to that installation of Rakudo.

Can NQP also deal with system / shell variables, so (at least) reading them?
If so, how (examples, please)?

[AntonOks]

It can just be added to the code in Compiler.nqp. As NQP code, which would mean an nqp::open, nqp::read and an nqp::close. Since the reading would be done at runtime, and only when someone does -v, the file location would need to be connected to that installation of Rakudo.

Can NQP also deal with system / shell variables, so (at least) reading them? If so, how (examples, please)?

Ok, think I found an example. So, this does work:
say(nqp::getenvhash()<Path>);

[lizmat]

I'd write nqp::say(nqp::getenvhash<PATH>), but yeah :-)

[AntonOks]

As file name, I would suggest "SYNDICATION".

Thanks for your suggestion. "SYNDICATION" somehow makes my brain spinning... haven't seen this kind of name for something like "enhanced release of something else". My brain would calm down with a very "obvious logical file name"... but I do not have an idea / suggestion myself right now :|

Please suggest a file location: I think you have a better idea for that than I can have atm.

Need to think about this. Too many choices and "building Raku ways" to consider...

The file content would be inserted verbatim.

adding a new IF loop, checking for the "text file" and then including the found word/string after the "Rakudo(tm)" string?!

Yes, with a space inbetween.

If this has to be done in "Compiler.nqp", do I need to use "nqp", or can it be done in Perl5 and/or Raku code there?

* Where / how is the "Compiler.nqp" file / scripts used within the Raku build process?
  Any example available, where a "config file content" is read-in and then worked-with in any other "nqp" script or during the Raku build process?

As "Compile.nqp" is EOL, where is the "release information" coming from with/after RakuAST?

I don't know yet. But this would put the burden of maintaining compatibility with the Raku Core team, rather than with each syndication.

@lizmat

Before I start something, which will dead-end again... would it be "ok" for you if I go for an environment / shell variable instead of a ("SYNDICATION") file for this change? So, checking if an (to be defined) environment var is set and if so, using its value?

For an environment variable, how about "RAKUDO_FLAVOR" or "RAKUDO_EDITION"? Would one of those make sense for you?

[AntonOks]

I'd write nqp::say(nqp::getenvhash<PATH>), but yeah :-)

Is this statement outdated / wrong then... or is it all about "personal gusto"?

[AntonOks]

Since the reading would be done at runtime, and only when someone does -v, the file location would need to be connected to that installation of Rakudo.

@lizmat

I'm somehow confused due to your explanation above... and rakudo/rakudo#5516. What you say, is, raku runs NQP stuff like Compiler.nqp at runtime, right?

So raku -v | raku --version (compiles and then) runs nqp Compiler.nqp each and every time the CLI command is run with those version options ?

Due to doc's or "courses" this sounds different to me!? Understanding, the referred documents are old and maybe outdated... it there something recent | actual, which describes the rakudo "compile time" and "run time" stuff?

[lizmat]

What you say, is, raku runs NQP stuff like Compiler.nqp at runtime, right?

Right

So raku -v | raku --version (compiles and then) runs nqp Compiler.nqp each and every time the CLI command is run with those version options ?

(compiles and then) Compiler.nqp is compiled into the rakudo binary. Every time you run Raku, a Perl6::Compilerobject is created, and if no other arguments are specified, the command_eval method is called. Or the version method is called, whenever you specify --version.

Hope that helps!

[AntonOks]

Some answers:

As file name, I would suggest "SYNDICATION".

As I wrote before, I would go with FLAVOR at the file name for this.

Please suggest a file location: I think you have a better idea for that than I can have atm.

I did squeeze my head and also looked around in current Windows and UBUNTU (Star) installations... and found only one file, which may have something similar in mind: $RAKUDO_PREFIX\share\perl6\site\version, where a simple 2 is in.

So, if you don't have a better file location on your mind by now, I would go with $RAKUDO_PREFIX\share\perl6\site\FLAVOR.

Hope, you are ok with those suggestions?

[lizmat]

+1