search

rakudo / star

Rakudo Star (Raku distribution)
https://rakudo.org/
Artistic License 2.0
265 stars 41 forks source link

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

Closed AntonOks closed 2 months ago

AntonOks commented 8 months ago

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

So, instead now:

AntonOks commented 8 months ago

@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 commented 8 months ago

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 commented 8 months ago

raku-star on Libera.chat

AntonOks commented 8 months ago

“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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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

lizmat commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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: https://github.com/rakudo/star/pull/198#issuecomment-1880086949 You are receiving this because you commented.

Message ID: @.***>

lizmat commented 8 months ago

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 commented 8 months ago

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...

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

AntonOks commented 8 months ago

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?

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 commented 8 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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

AntonOks commented 7 months ago

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 commented 7 months ago

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

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

AntonOks commented 7 months ago

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 https://github.com/rakudo/rakudo/pull/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 commented 7 months ago

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 commented 4 months ago

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 commented 4 months ago

+1