Installing gForth on the Raspberry Pi

Two possibilities here

One is that the archive is corrupt - unlikely...

The other is more probably - some of these packages have been updated, or their dependancies have and have changed name/paths.

Try this:

sudo apt-get update sudo apt-get install gforth

You might want to do a full update anyway:

sudo apt-get upgrade sudo apt-get dist-upgrade

The latter isn't normally needed, but the foundation have added some additional stuff into Raspbian to support the new web browser (IIRC)

Gordon

The error messages said to try sudo apt-get upgrade so I did and it didn't help. What exactly is that supposed to do? Does it update data on my machine that points to the files?

I'll try your suggestions. :)

Yes, that worked. Seems I had trouble with the SUDO thing. Last night I first used the apt-get command without SUDO and then had a series of errors that messed up when I tried to add SUDO. Like I said, a total noob. But I have learned a few things from this.

Now I need to learn how to use gforth to open a serial port and open a window from and send text to it to be displayed.

Thanks :)

You need to do the update first - that updates the local Pi's idea of the package names and versions - then the upgrade/install knows the name (and version) of the packages to pull.

Other languages are avalable ... :-)

Gordon

Is this a new version of Trivial Pursuit? :-)

Forth... sweet baby Jesus what an abomination of a language. 'Coz people don't write unreadable code as it is without using a "write-once-read-never" language like Forth.

It's 2014 and soon will 2015. Must be time to let Forth rest in peace now and move to a modern language.

Meaning what? Is using OS functions somehow easier in other languages?

Always easiest in C because that's what the OS functions are written in, but many other languages (which might be easier for some people to use) can come close enough that other things can sway it in their favor.

You could do what you suggest by using tip or cu in a terminal window (such as xterm) - no programming required other than typing the commands into a shell, because the OS already contains the programs (originally written in C).

OTOH, if your objective is to learn forth, that won't help one bit.

Pyserial (3rd party library) is pretty easy to work with if you want to mess with serial ports from Python.

In either Forth or Python, you should be able to just launch a terminal and run your program from inside it, so your program can write to the terminal, rather than opening a window from within your program.

I'm still not following. How does the language the OS was written in have any impact on the interfaces the OS provides? This is an OS interface issue that does not require any recoding of the OS. So why would I care what language the OS was written in?

I don't think you have grasped what I am trying to do. I have a program that controls a device over a serial port. It was written in Forth using OS specific calls (Windows). It also opens a socket to communicate with a Telnet client to display bi-directional serial port data for debugging. Again, this uses OS specific calls.

Now I wish to port this program to the rPi. Rather than mess with sockets and a separate program as a terminal emulator, I am thinking it might be cleaner to keep it self contained and display the message traffic in a separate window opened by the Forth program.

Or maybe I am not following what you are saying. How does tip or cu get what I want with no programming? It sounds like they are terminal emulators. I still have to code an interface to them.

No, Forth is already one of my tools. Now I'm trying to learn the rPi environment from the viewpoint of Forth.

I'm not sure what you mean by launching a terminal and running my program inside it. Please remember I am not conversant with Linux. The Forth I use under Windows has a command line interface which I use as the user console. So I don't want to display the message traffic there as well. I believe that is what you are suggesting, no? Or would gforth provide its own window for interaction with the user and the "terminal" window would be separate? If so, how do I display data in it?

There is always one in every crowd. lol

There's one that's considerably worse - Ken Iverson's APL.

For starters, it evaluates an expression strictly right to left and does not use either operator precedence or grouping, i.e. brackets, to let the programmer deviate from this evaluation order.

Although there are, apparently ASCII implementations, the preferred ones use a special charset and keyboard which have no other known use:

Advantage: You can write compact code: Ken Iverson once wrote a text editor in 25 lines

Disadantage: the ultimate write-only programming language: when Ken Iverson needed to modify that text editor six months later, even he couldn't understand it.

Maybe so, but I wouldn't be surprised to find there's still a lot of it still running in radio-astronomy labs.

To the OP: Pardon my digression.

What, exactly do you want to do with Forth now you have it installed? IOW, are you expecting to run somebody else's Forth code, or are you intending to teach yourself Forth and write a program yourself that uses a serial port to read and write data?

Forth is an interactive system that contains its own command line interpreter and runtime environment, so running gforth from the RPi command line should cause it to prompt for input exactly as if you'd started a BASIC interpreter or another bash shell.

gforth may or may not use the Linux filing system to store programs - that depends on the way it has implemented Forth. Years ago I dabbled with a traditional Forth implementation on a 6809 microcomputer that ran Flex 09 (a CP/M contemporary). Traditional Forth systems stored programs as a set of one or more numbered screens, each of 1KB (i.e. 16 lines of

To drive something external, such as a serial line, you need to write or download a set of words that can read from and write to a serial port. Again, the details at the lowest level of words used for this will depend on the Forth implementation you're using. Unfortunately, because these will need to use the Linux i/o system you may find that they have system dependencies.

My Forth books date from 1983 and 1985, which shows how long it is since I last looked at it. As a result I have no suggestions about more recent reference material though

HTH

Actually sudo is superfluous. The raspberry in an embedded setting is a single user system. Making that single user a sudoer doesn't make sense. I would suggest to remove sudo altogether.

Then when you have to do a system action, just do it as superuser, aka root. Make that terminal a red background and be careful. A lot of caveats disappear.

A security tool requiring to absorb 10 pages of information doesn't make a system safer for novices. The caveats for being a super user are super simple. You can do everything, so watch out!

Groetjes Albert

That is a good point. For serial i/o you need a c structure called termio. It has a field that specifies a a timeout in centiseconds. Now in c you just use the c-name for that field. In Forth you've to figure out whether the termio is an address or it contains the address of the struct and what the offset of the field is.

c-based Forth have a lot of facilities around this, e.g. to interpret c include files

Most of them are piles of ...

#ifdef __USE_GNU ... #endif

#ifdef __USE_BSD #include #endif

chasing you from the cupboard to the wall, as we say in Holland. ]

Groetjes Albert

Funny, when I did it in Win32Forth I didn't use any of that. Someone provided some sample code and I tweaked it for my own use. I'll be looking for similar sample programs in gForth.

Uh, a keyboard is a keyboard. You just tell the OS that the keys mean what you want them to mean and the rest is just typing.

That is entirely possible in any language. It is how you write the code and how you document it.

It is still in use in many places. I won't bore you with the details.

I think you must have glossed over some of the posts. To save me retyping, please read my post of 3:14 and 3:18.

Yes.

Yes, that is called blocks and is pretty old school. The fundamental words for that are still part of the standard, but not used very often. Not sure what you are saying about mixing blocks and source. I guess you are saying some of the Forth system you used stored the source in the blocks file, perhaps because it was loaded when the Forth program started? That is not unusual. Only a core of Forth has to be coded natively to the target system. The rest can be defined in Forth.

Yes, again I think you have not read my posts very well. I essentially said all this very early on. I'm looking for info on this under gForth.

I'm not asking for info on coding in Forth. I'm asking for info on using gForth under Linux to control a serial port and display the message traffic from that port.

My remark was intended to be somewhat tongue-in-cheeck - hence the :-) in it.

The Pi world seems to be full of Python-heads, so a lot of the Pi users will be using Python and there's a lot of support for that. Linux (and Unix in-general) probably has more C support than anything else though.

But I see you're a Forth programmer and have an existing Forth program to port, so that's great - read the fine manual for GNU Forth about how it interfaces with things like the serial port, and X windows.

Gordon

I don't know about 10 pages of info. Using SUDO is easier than learning how to switch between user and superuser. One of the SUDO references said it was used on systems where root is a locked account. Sudo lets you execute one command as superuser to save the trouble of changing your login or when it is impossible such as when root is a locked account. I may not have the words exactly right, but I think using Sudo is not one of my real concerns right now. Thanks anyway.

The OS is written in C because the developers were C programmers and they were the ones who got to choose the language. They also got to design the interfaces, so they designed them for the convenience of other C programmers. If they had been Forth programmers it would have worked out about the same way. Similarly for Ada or whatever.

I see what you mean now, but what you're describing is much harder than just having a socket listener in your program, and telnetting into it from another terminal window. The point is that Linux comes with decent terminal emulation apps (similar to the C:> prompt in DOS) and they handle stuff like character i/o, scrolling, etc. for you. If you wanted to do all that in your application you'd have to deal with an immensely complicated GUI library and reimplement the terminal in your program.

A middle ground migh be to launch a terminal window (xterm etc) from your program and connect it up to a pseudo-teletype (pty) using the xterm -S command line option. Pty is a socket-like interface that simulates a serial port and allows the system serial driver to handle stuff like erase characters. It's slightly complicated to program but not horrendous like writing a full-on GUI. I haven't done this particular thing with xterm but it looks doable.

If this is just a developer app for your own use, I'd say it's simplest launch both terminal windows manually.

Note: I've programmed lots of stuff on Linux, but nothing directly on a raspberry pi, so I might miss some issues.