banner discussion

[farvardin]

There is a discussion about the gforth banner there:

https://www.reddit.com/r/Forth/comments/151jmg7/hidding_banner_in_gforth_starting_a_fs_program/

the problem is by invoking gforth program.fs, it's starting first the informations within the program, or the result itself, and THEN the gforth banner. It's possible to use the bye or the quit command, but it might be more intuitive or logical to display the banner only when gforth is invoked alone.

[WraithGlade]

Incidentally, I came here to the GitHub issues page to suggest something very similar but not quite the same:

There should be a simple --quiet command line argument (with a -q abbreviation also available ideally) that makes it so that GForth doesn't display the banner (the intro help text).

When repeatedly reloading a script for testing, the banner rapidly becomes an eyesore that accomplishes nothing but mucking up the console logs and making them more tedious to read through.

Automated running of GForth is also negatively impacted by the banner, etc, in addition to the similar problems you've linked to.

So, I'm seconding the above suggestion and also suggesting that there should be a "quiet" flag of some kind to remove the banner completely in all cases.

The user shouldn't need to know esoteric things about GForth just to silence the extraneous banner.

Anyway, thanks for reading. Hopefully the devs will implement something like this.

[farvardin]

sure.
As a workaround, you can modify /usr/local/share/gforth/xx_version_xx/gforthrc.fs

and put at the end:
' noop is bootmessage

actually, gforth should recognise a ~/.config/gforthrc but on gforth 0.7.9_20221117 after setting export GFORTH_ENV=on, I got an error

*the terminal*:0:-94171544356399: error: Stack underflow
>>><<<
Backtrace:
/usr/local/share/gforth/0.7.9_20221117/gforthrc.fs:45:45:  0 $7F742084E928 drop 
/usr/local/share/gforth/0.7.9_20221117/gforthrc.fs:48:10:  1 $7F742084E988 load-rc0 

(edit: it looks like you can invoke additional commands in ~/.config/gforthrc0, it seems to work at least)

https://gforth.org/manual/Invoking-Gforth.html

[farvardin]

altering /usr/local/share/gforth/xx_version_xx/gforthrc.fs is not ideal, because the bootmessage word is calling the gforth and not the actual bootmessage, and there is also a process for loading the status bar and the ability to call back previous commands with the arrows.

[farvardin]

@WraithGlade

I've looked again at this problem. I still don't understand why the history isn't working when we have ' noop is bootmessage to the ~/.config/gforthrc0 because it seems this function is called by history-cold which itself is loaded from history.fs. I suppose this is configured in the gforth.fi image and not from the .fs files in to /usr/local/share/gforth

So here is a way to suppress the banner message and keep (apparently) the rest of the functionalities:

Add

 ' noop is bootmessage
 +status
 history-cold

into ~/.config/gforthrc0

now your scripts shouldn't display the gforth banner. You can also add "bye" (to exit) or "quit" (to go back to the gforth prompt) at the end of your scripts.

[WraithGlade]

Thanks for all the detailed info and for your efforts! 🙂

I still think that there should be a --quiet (and -q) command line argument that takes care of suppressing the banner.

Most languages (whether compiled or interpreted) have some kind of quiet mode (if/when applicable), so it is strange that GForth doesn't.

All the --quiet mode would require is adding a boolean flag and a conditional branch that check whether quiet mode is on when the banner would be displayed and then suppress it. It should be easy to implement unless something very strange is going on with the design/architecture of the startup system. I've been surprised before on what should be trivial things before though, given that even the most trivial of things can be made hard or unmanageable by strange architectural choices. I doubt this is one of those cases though.

I'm still largely new to GForth though and don't feel like I should be attempting changes to the language itself myself yet. I'm learning GForth because I want to get a clearer sense of what the original Forth language was like (but modernized reasonably of course, hence the choice to use GForth).

PS: I'm also wondering why the most recent version of GForth's pre-built Windows executable is from 2020. Doesn't GForth still support Windows? It says it does on the site. I don't think users should have to rebuild GForth just to use the most recent on Windows. Do the GForth devs realize how old the prebuilt Windows binaries are now? I feel like ideally the pre-built package(s) should be automatically updated and tested by human hands periodically too. I also noticed that the help command never successfully finds help docs on Windows and that the GForth banner mentions Linux-only help tools. True cross-platform support requires that such things are accounted for and not written to be only platform-specific, so really the banner also needs redesigned to actually be cross-platform and friendly to both Linux and Windows users and the binaries should be updated regularly. I also personally think that the format of the banner is currently not very readable and there should be more paragraph breaks in the text instead of slurring it all together in the less navigable/readable way embodied by the current banner.

[forthy42]

First of all, around 2019, Gforth on WSL became more usable than Gforth built native, and I was less motivated compiling it. Since then, WSL became even better and better. With WSLg, you have full OpenGL support, something I didn't manage in the native version.

Gforth is a GNU project, and the GNU project has a guideline on the support of proprietary operating systems, which bogs down to “don't waste your time” when you have better things to do. In early 2021 my son was born, and I simply have to trade in something.

And if you want a --quiet option, just add

in options : --quiet ['] +status is bootmessage ;

to ~/.config/gforthrc0 and then your Gforth will understand the --quiet switch (and still turn on the status line, which is also done in bootmessage).

And you really should add bye to the end of your scripts if you don't want to fall through to the Forth prompt including bootmessage greetings.

We discussed this problem and I suggested to make #! to automatically terminate a script at the end with bye, but this could result in surprises from users that are happy with the way it is, so we decided against this.

[farvardin]

@forthy42 that's a very interesting feature!

I couldn't find it in the online doc, and it didn't even work in my gforth-0.7.9 from 2022-01-27, so I've discovered it was a quite recent addition (and it's certainly not in the current "latest release", 0.7.3). I've picked latest dev release (20231012) and it's working fine.

@WraithGlade I suggest you try to compile the latest bleeding edge snapshot of gforth from WSL, and this way you'll get a more customisable gforth! Gforth is a very complete and modern Forth, which also follows the ANS standard, but it's also quite complex. It's a good idea to use gforth as the main forth, but it might also worth looking at how simpler forth are working as well.
Meanwhile, you can also inspect some gforth commands with the "see" word, you can for example check the difference between a word like "dup", which is made from assembly code, and "space", which is made from other forth words...
"help" is also useful, but is not implemented in gforth-0.7.3 I suppose, you'll have a get a more recent one.

[WraithGlade]

Thanks for the info and assistance @forthy42 and @farvardin. 🙂

It's of course very understandable that when time is limited a project maintainer should prioritize they find most suitable to themselves.

It sounds like as far is Windows development is concerned then GForth should only be used for playing around with Forth and not for real projects since it is very unclear that projects built on WSL can be actually ever be distributed and run on end users' Windows computers reliably and thus makes it far too risky as a platform for creating any real Windows applications. I was mostly intending to use GForth for learning anyway, so that's ok though not ideal. (Then again, I'm not familiar with WSL for real project use, so I could be wrong.)

It's also been surprising that the help feature currently only works on Android for the stable releases of GForth as far as I can tell. Very few distros seem to pack the bleeding edge (dev) version of GForth in the software managers. I suppose that GForth must currently be in a state of flux or instability then though, so such is life.

I do still think --quiet should be added as a default option built-in to GForth like all the other command line options. Thank you for providing an implementation workaround for it here though.

Anyway, thanks again for everyone's time and efforts.

I appreciate that GForth makes modern Forth available and featureful and admire the work and dedication you've put into it!

Have a good day/night! 😎🌄

[ruv]

What do you think about --batch command line argument that turns on the batch mode?

In the batch mode the Forth system shall:

• not show any boot message;
• output error messages only to stderr;
• terminate after processing command line options and stdin (if any);
• terminate with some nonzero exit status on any uncaught exception.