Installing gForth on the Raspberry Pi

[rickman]

I have an rPi working on my desk and thought I would install gForth on
it. I found suggestions that this command should work...

sudo apt-get install gforth

But it didn't... :( Here are the error messages. Any suggestions? As
you can likely tell I am a complete noob with Linux.


pi@raspberrypi ~ $ sudo apt-get install gforth
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
gforth-common gforth-lib libffcall1
The following NEW packages will be installed:
gforth gforth-common gforth-lib libffcall1
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 979 kB of archives.
After this operation, 2,703 kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Err http://mirrordirector.raspbian.org/raspbian/ wheezy/main gforth-lib
armhf 0.7.0+ds1-7
404 Not Found
Err http://mirrordirector.raspbian.org/raspbian/ wheezy/main
gforth-common all 0.7.0+ds1-7
404 Not Found
Err http://mirrordirector.raspbian.org/raspbian/ wheezy/main gforth
armhf 0.7.0+ds1-7
404 Not Found
Get:1 http://mirrordirector.raspbian.org/raspbian/ wheezy/main
libffcall1 armhf 1.10+cvs20100619-2 [12.9 kB]
Fetched 12.9 kB in 1s (12.6 kB/s)
Failed to fetch
http://mirrordirector.raspbian.org/raspbian/pool/main/g/gforth/gforth-lib_0.7.0+ds1-7_armhf.deb
404 Not Found
Failed to fetch
http://mirrordirector.raspbian.org/raspbian/pool/main/g/gforth/gforth-common_0.7.0+ds1-7_all.deb
404 Not Found
Failed to fetch
http://mirrordirector.raspbian.org/raspbian/pool/main/g/gforth/gforth_0.7.0+ds1-7_armhf.deb
404 Not Found
E: Unable to fetch some archives, maybe run apt-get update or try with
--fix-missing?

--

Rick

[Gordon Henderson]

In article <m2j5vj$rem$1...@dont-email.me>, rickman <gnu...@gmail.com> wrote:
>I have an rPi working on my desk and thought I would install gForth on
>it. I found suggestions that this command should work...
>
>sudo apt-get install gforth
>
>But it didn't... :( Here are the error messages. Any suggestions? As
>you can likely tell I am a complete noob with Linux.
>
>
>pi@raspberrypi ~ $ sudo apt-get install gforth
>Reading package lists... Done
>Building dependency tree
>Reading state information... Done
>The following extra packages will be installed:
> gforth-common gforth-lib libffcall1
>The following NEW packages will be installed:
> gforth gforth-common gforth-lib libffcall1
>0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
>Need to get 979 kB of archives.
>After this operation, 2,703 kB of additional disk space will be used.
>Do you want to continue [Y/n]? y
>Err http://mirrordirector.raspbian.org/raspbian/ wheezy/main gforth-lib
>armhf 0.7.0+ds1-7
> 404 Not Found

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

[rickman]

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

--

Rick

[rickman]

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 :)

--

Rick

[Gordon Henderson]

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.

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

Other languages are avalable ... :-)

Gordon

[mm0fmf]

On 26/10/2014 16:44, rickman wrote:
> 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.

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.

[rickman]

On 10/26/2014 1:09 PM, Gordon Henderson wrote:
>
>> 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.
>
> Other languages are avalable ... :-)

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

--

Rick

[Andrew Gabriel]

In article <m2jfg5$ulh$1...@dont-email.me>,

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.

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
>>> 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.
>> Other languages are avalable ... :-)
> Meaning what? Is using OS functions somehow easier in other languages?

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.

[rickman]

On 10/26/2014 2:57 PM, Andrew Gabriel wrote:
> In article <m2jfg5$ulh$1...@dont-email.me>,
> rickman <gnu...@gmail.com> writes:
>> On 10/26/2014 1:09 PM, Gordon Henderson wrote:
>>>
>>>> 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.
>>>
>>> Other languages are avalable ... :-)
>>
>> 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.

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?

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

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.

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

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

--

Rick

[rickman]

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?

--

Rick

[rickman]

There is always one in every crowd. lol

--

Rick

[Martin Gregorie]

On Sun, 26 Oct 2014 18:06:42 +0000, mm0fmf wrote:

> On 26/10/2014 16:44, rickman wrote:
>> 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.
>
> 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.
>

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.

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

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
64 characters). The version I used kept these in a large, randomly
accesses file along with the set of words[1] that defined the Forth
runtime/command interpreter/compiler/standard library.

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.

[1] 'word' is a Forth term that roughly corresponds to a C function
function.

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 http://www.forth.org may be worth a look.


HTH


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[Albert van der Horst]

In article <m2j8ed$4pb$1...@dont-email.me>, rickman <gnu...@gmail.com> wrote:

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!

>
>Thanks :)

Groetjes Albert

>
>--
>
>Rick
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Albert van der Horst]

In article <m2jh87$69c$1...@dont-email.me>, rickman <gnu...@gmail.com> wrote:
>On 10/26/2014 2:57 PM, Andrew Gabriel wrote:
>> In article <m2jfg5$ulh$1...@dont-email.me>,
>> rickman <gnu...@gmail.com> writes:
>>> On 10/26/2014 1:09 PM, Gordon Henderson wrote:
>>>>
>>>>> 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.
>>>>
>>>> Other languages are avalable ... :-)
>>>
>>> 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.
>
>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?

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

[If you can find them,

Most of them are piles of
...

#ifdef __USE_GNU
...
#endif

#ifdef __USE_BSD
#include <ttydefaults.h>
#endif

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

<SNIP>
>--
>
>Rick

Groetjes Albert

[rickman]

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.

--

Rick

[rickman]

On 10/26/2014 3:34 PM, Martin Gregorie wrote:
> On Sun, 26 Oct 2014 18:06:42 +0000, mm0fmf wrote:
>
>> On 26/10/2014 16:44, rickman wrote:
>>> 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.
>>
>> 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.
>>
> 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:

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.

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

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

>> It's 2014 and soon will 2015. Must be time to let Forth rest in peace
>> now and move to a modern language.
>>
> Maybe so, but I wouldn't be surprised to find there's still a lot of it
> still running in radio-astronomy labs.

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

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

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.

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

Yes.

> 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
> 64 characters). The version I used kept these in a large, randomly
> accesses file along with the set of words[1] that defined the Forth
> runtime/command interpreter/compiler/standard library.

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.

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

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.

> [1] 'word' is a Forth term that roughly corresponds to a C function
> function.
>
> 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 http://www.forth.org may be worth a look.

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.

--

Rick

[Gordon Henderson]

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

[rickman]

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.

--

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> I'm still not following. How does the language the OS was written in
> have any impact on the interfaces the OS provides?

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.

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

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.

[rickman]

On 10/26/2014 4:24 PM, Paul Rubin wrote:
> rickman <gnu...@gmail.com> writes:
>> I'm still not following. How does the language the OS was written in
>> have any impact on the interfaces the OS provides?
>
> 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.
>
>> 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.
>
> 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.

I hear you. I don't need to implement a full fledged terminal program.
I can do something fairly simple really. It could use wraparound
rather than use scrolling for example. Also, my protocol is query,
answer, so I could easily display this on a split screen showing the
lines side by side which I am doing now, but using ANSI codes to display
in different colors. White space would work just as well and be simpler.

> 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 Pty is "complicated to program", I'd rather use sockets I think. The
reason I'm shying away is that the socket interface broke when I got a
new laptop with Win 8. I can't seem to figure out what is wrong and I'm
tired of looking. I just want to have more control of my code. The
real use of this program is in production test where they are running
Win 7 and older boxes. So that all still works. I could use the rPi in
the lab when using the test fixture for other purposes.

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

Thanks for your comments. I certainly have stuff to think about.

I've cross posted this to the comp.lang.forth forum and I'm a bit
surprised I haven't gotten any replies from the gforth people. Maybe I
just need to give it more time. It *is* Sunday after all. lol

Any idea where folks normally get help with gForth?

--

Rick

[rickman]

Manual? Manual!!??? There's an F'ing MANUAL???

The manual is mute on serial port usage. I have found some references,
but they mostly are Greek to me like,

http://www.forth.org/svfig/kk/TestSerial.f.txt

I'm also finding info saying I need to set group membership to allow
access to the serial port.

--

Rick

[Raymond Wiker]

Googling for "raspberry pi forth", I came across
https://github.com/organix/pijFORTHos . I have no idea if this is in a
useable state, but it looks interesting.

[rickman]

On 10/26/2014 5:12 PM, Raymond Wiker wrote:
>
> Googling for "raspberry pi forth", I came across
> https://github.com/organix/pijFORTHos . I have no idea if this is in a
> useable state, but it looks interesting.

Thanks for the link. Right now I'd like to pursue gForth because if I
get my code working with that, it is likely I can use the code with
minimal modifications under Windows gForth as well. Also, pijFORTHos is
actually a bare metal forth not running under Linux at all. I want to
keep this under an OS for now as there will be files written from the
program and networking will be used to move the data. Not to mention I
may want to add special capabilities to the rPi such as an oscilloscope.

--

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> I hear you. I don't need to implement a full fledged terminal
> program. I can do something fairly simple really. It could use
> wraparound rather than use scrolling for example.

It's not worth bothering. Just use a terminal.

> If Pty is "complicated to program", I'd rather use sockets I think.

Pty is probably simpler than sockets, it's just different and doesn't
come up as often. I.e. most internet programmers are already used to
sockets, while pty might require some head scratching.

Actually there's an even simpler approach now that I think of it. Just
launch "xterm somescript" where somescript is a script that you write,
and xterm will run the script instead of a shell. The script would just
telnet to the socket listener in your program. Telnet in "line mode"
will send a line at a time, doing stuff like erase processing, so your
program won't have to deal with that.

> The real use of this program is in production test where they
> are running Win 7 and older boxes. So that all still works. I could
> use the rPi in the lab when using the test fixture for other purposes.

I'm unclear where the rpi comes into the production system, if it does
at all.

[rickman]

On 10/26/2014 5:39 PM, Paul Rubin wrote:
> rickman <gnu...@gmail.com> writes:
>> I hear you. I don't need to implement a full fledged terminal
>> program. I can do something fairly simple really. It could use
>> wraparound rather than use scrolling for example.
>
> It's not worth bothering. Just use a terminal.

Not sure if you mean a terminal or a terminal emulator. I still have to
figure out how to talk to a terminal emulator.

>> If Pty is "complicated to program", I'd rather use sockets I think.
>
> Pty is probably simpler than sockets, it's just different and doesn't
> come up as often. I.e. most internet programmers are already used to
> sockets, while pty might require some head scratching.

I already have a sockets implementation working for Windows. I would
need to port that to Linux which may not be so fun.

> Actually there's an even simpler approach now that I think of it. Just
> launch "xterm somescript" where somescript is a script that you write,
> and xterm will run the script instead of a shell. The script would just
> telnet to the socket listener in your program. Telnet in "line mode"
> will send a line at a time, doing stuff like erase processing, so your
> program won't have to deal with that.

I don't follow. Why would the terminal emulator be sending anything? I
guess I wasn't clear. The terminal emulator is just being used to
display the message traffic from the serial port.

>> The real use of this program is in production test where they
>> are running Win 7 and older boxes. So that all still works. I could
>> use the rPi in the lab when using the test fixture for other purposes.
>
> I'm unclear where the rpi comes into the production system, if it does
> at all.

It doesn't. As I said I would use the rPi for the same program for
other purposes in the lab.

Maybe you can help me with the terminalogy of the sockets interface. I
thought my program was a socket server. You seem to call it a
"listener". Is that the same thing?

--

Rick

[Gordon Henderson]

In article <m2jnvm$ji$1...@dont-email.me>, rickman <gnu...@gmail.com> wrote:
>On 10/26/2014 4:24 PM, Gordon Henderson wrote:
>> In article <m2jfg5$ulh$1...@dont-email.me>, rickman <gnu...@gmail.com> wrote:
>>> On 10/26/2014 1:09 PM, Gordon Henderson wrote:
>>>>
>>>>> 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.
>>>>
>>>> Other languages are avalable ... :-)
>>>
>>> Meaning what? Is using OS functions somehow easier in other languages?
>>
>> 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.
>
>Manual? Manual!!??? There's an F'ing MANUAL???

This one?

https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/

>The manual is mute on serial port usage. I have found some references,
>but they mostly are Greek to me like,
>
>http://www.forth.org/svfig/kk/TestSerial.f.txt

OK - So it's some 20 years since I got paid to write some Forth..

That looks like a more or less complete implementation of a library to
access a generic serial port.

However it looks way overly complicated to me - using threads (for why?)

Stuff you might need to know:

The Pi's serial port is /dev/ttyAMA0

Hardware under Linux more or less works like a file - so open the file,
read and write to the file using a file handle or descriptor (often
refered to as 'fd' on other peoples code)

The down-side of just open/read/write is that it will usually block and
yo won't be able to set the baud rate. termios is the mechanism to fiddle
with that and things like partiy, etc.

>I'm also finding info saying I need to set group membership to allow
>access to the serial port.

If you're running Raspbian then you ought to be OK.

Type

id

if in the output it says (dialout) then you're fine.

You'll need to stop the kernel using the serial port - edit
/boot/cmdline.txt and also need to stop Raspbian using it too - edit
/etc/inittab. In both cases look for the /dev/ttyAMA0 information and
remove it. Note that /boot/cmdline.txt must be one unbroken line.

Hope that helps to get you going.

If your output is just to the screen without any formatting, etc. you can
simply run the program from an xterm (or whatever terminal is standard
with lxde)

gordon@cmpi0:$ gforth
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
: hw ." Hello world" cr ; ok
hw Hello world
ok


Gordon

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
>> It's not worth bothering. Just use a terminal.
> Not sure if you mean a terminal or a terminal emulator.

Terminal emulator.

> I still have to figure out how to talk to a terminal emulator.

Just have the emulator run a telnet script as described.

> I don't follow. Why would the terminal emulator be sending anything?
> I guess I wasn't clear. The terminal emulator is just being used to
> display the message traffic from the serial port.

Ok, in that case the terminal emulator is only receiving and not
sending, no big deal. The socket is bidirectional and you're only using
one direction, which is fine. Maybe at some point you might like to
type something on the terminal. You can always add the capability later.

> Maybe you can help me with the terminalogy of the sockets interface.
> I thought my program was a socket server. You seem to call it a
> "listener". Is that the same thing?

Yeah pretty much.

[rickman]

Ok, I have windows code to do this already and I'd like to get rid of
it. Even if I use the terminal emulator, I still need to figure out how
to open a socket from inside gForth. Just saying "run a telnet script"
doesn't tell me much.

--

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> Ok, I have windows code to do this already and I'd like to get rid of
> it. Even if I use the terminal emulator, I still need to figure out
> how to open a socket from inside gForth.

The linux and windows socket api's are pretty similar. I have no idea
what the gforth wrapper looks like.

There might be a hacky way to do this with shell redirection of the
stderr file descriptor. Basically you'd pipe stderr into netcat, and
launch an xterm with a netcat listener ("netcat -l") so that stuff
written to the stderr from your program would then appear in the xterm.

Hmm, linux also has "named pipes" (fifos) where you create a filename
representing the named pipe, write to it from your forth program and
read from it in your terminal window. Getting this to work smoothly can
take some messing around. Maybe this is the easiest approach. On your
application side you'd just open the fifo filename and write to it.
In the terminal you'd just "cat" the fifo.

https://en.wikipedia.org/wiki/Named_pipe#In_Unix

[rickman]

On 10/26/2014 6:05 PM, Gordon Henderson wrote:
> In article <m2jnvm$ji$1...@dont-email.me>, rickman <gnu...@gmail.com> wrote:
>> On 10/26/2014 4:24 PM, Gordon Henderson wrote:
>>> In article <m2jfg5$ulh$1...@dont-email.me>, rickman <gnu...@gmail.com> wrote:
>>>> On 10/26/2014 1:09 PM, Gordon Henderson wrote:
>>>>>
>>>>>> 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.
>>>>>
>>>>> Other languages are avalable ... :-)
>>>>
>>>> Meaning what? Is using OS functions somehow easier in other languages?
>>>
>>> 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.
>>
>> Manual? Manual!!??? There's an F'ing MANUAL???
>
> This one?
>
> https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/

Sorry, should have used a smiley.

>> The manual is mute on serial port usage. I have found some references,
>> but they mostly are Greek to me like,
>>
>> http://www.forth.org/svfig/kk/TestSerial.f.txt
>
> OK - So it's some 20 years since I got paid to write some Forth..
>
> That looks like a more or less complete implementation of a library to
> access a generic serial port.
>
> However it looks way overly complicated to me - using threads (for why?)

Yeah, I didn't get it either. Under Win32Forth it was just a couple of
windows commands to open and control the serial port. Actually I think
the open was just file I/O but more complicated because they do some
really goofy stuff with the file name when you get to double digit COM
port numbers. After that the I/O is just file I/O.

> Stuff you might need to know:
>
> The Pi's serial port is /dev/ttyAMA0
>
> Hardware under Linux more or less works like a file - so open the file,
> read and write to the file using a file handle or descriptor (often
> refered to as 'fd' on other peoples code)
>
> The down-side of just open/read/write is that it will usually block and
> yo won't be able to set the baud rate. termios is the mechanism to fiddle
> with that and things like partiy, etc.

The windows I/O is just read-file, but it returns a length which can be
zero. Comkey? asks for 1 byte so the char is saved and the routine
returns if it was found or not. When Comkey is called it calls Comkey?
to make sure a char is in the buffer than returns the char from the
buffer. Sounds like I can do the same thing. I just need to find the
file I/O calls. But the serial port needs to be set up. One reference
said to do that outside of the app.

>> I'm also finding info saying I need to set group membership to allow
>> access to the serial port.
>
> If you're running Raspbian then you ought to be OK.
>
> Type
>
> id
>
> if in the output it says (dialout) then you're fine.

Yep, it says dialout, so that part is covered.

> You'll need to stop the kernel using the serial port - edit
> /boot/cmdline.txt and also need to stop Raspbian using it too - edit
> /etc/inittab. In both cases look for the /dev/ttyAMA0 information and
> remove it. Note that /boot/cmdline.txt must be one unbroken line.
>
> Hope that helps to get you going.

I'll give that a try. I need to get used to a text editor first.

> If your output is just to the screen without any formatting, etc. you can
> simply run the program from an xterm (or whatever terminal is standard
> with lxde)
>
> gordon@cmpi0:$ gforth
> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
> : hw ." Hello world" cr ; ok
> hw Hello world
> ok

Certainly I do need console I/O, but I also need a second screen.

--

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
>> However it looks way overly complicated to me - using threads (for why?)
> Yeah, I didn't get it either.

Obvious reason for threads is for bidirectional i/o, and being able to
dump out a bufferload of text to the terminal without making your
program wait.

> The windows I/O is just read-file, but it returns a length which can
> be zero.

Yeah you can do that with Linux too, you set a flag for asynchronous
operation and then you can query whether the device is ready.

I'd say try the following:

1. Open terminal window
2. run "mkfifo /tmp/bob"
3. run "cat < /tmp/bob" (this will just sit and wait, so keep going)
4. Open another terminal window
5. In new window, run "cat > /tmp/bob" and start typing stuff

You should see the stuff you type in step 5 appear on the console from
step 3.

It should be obvious from this, replace step 5 with:

5a. Run a program that opens /tmp/bob and writes stuff to it.

This is probably the simplest way to deal with your unidirectional
output problem.

[rickman]

Thanks, that sounds useful. I assume steps 1, 2 and 3 can be combined
into a script which when run opens the window and runs the two commands?
Is there a way to have the first terminal window interpret ANSI
commands, or is that automatic?

--

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> Thanks, that sounds useful. I assume steps 1, 2 and 3 can be combined
> into a script which when run opens the window and runs the two
> commands?

Yes, or you can just do step 1 once with the fifo staying someplace
persistent. You can then launch the terminal from gforth like this:

s" xterm -e cat /tmp/bob &" system

See "Passing Commands to the Operating System" in the gforth manual
for the "system" command.

> Is there a way to have the first terminal window interpret ANSI
> commands, or is that automatic?

Automatic.

[A. Dumas]

On 26/10/2014 17:11, Gordon Henderson wrote:
> 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)

dist-upgrade doesn't mean something like "os system distribution
upgrade." You don't get more, or different, packages. According to the
man page for apt-get, it's a more intelligent version of upgrade:

> dist-upgrade
> dist-upgrade in addition to performing the function of upgrade,
> also intelligently handles changing dependencies with new versions
> of packages; apt-get has a "smart" conflict resolution system, and
> it will attempt to upgrade the most important packages at the
> expense of less important ones if necessary. The dist-upgrade
> command may therefore remove some packages.

Maybe the name means distinction in the sense of (mathematical set)
difference, although if so, diff-upgrade would have been clearer.

[rickman]

Awesome. Thanks a lot.

--

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
>> Automatic.
> Awesome. Thanks a lot.

Actually there are a ton of options to xterm to control the fonts,
colors, sizes, etc. You could spend a few hours reading the manual
page. There might be some alternate terminal programs on the rpi as
well, like maybe gnome-terminal? I don't use an rpi so I don't know
what's there.

[Dom]

The difference between upgrade and dist-upgrade is that upgrade will
only install newer versions of packages already installed on your system
if it can do so without removing any existing packages or installing
additional ones.

So if you had knife(1.0), fork(1.2) and spoon(1.2) installed, and then
knife(1.3) was released which depended on spork(1.3) which replaced
fork(1.2) and spoon(1.2), an upgrade would do nothing, but a
dist-upgrade would remove fork and spoon and install spork.

So in a way it is a distribution upgrade as you are changing which
packages are installed rather than just upgrading existing ones.

This situation is also a lot more common when moving to a new release
than during routine upgrades of the Stable system (Wheezy at the
moment). Testing (Jessie) is more likely to need dist-upgrade.

[Albert van der Horst]

The only thing you're saying is that those are c-based Forth's or
someone did the hard work for you. Neither detracts from the
fact that it is easier to do with c as a starting point.
(You know, I'm the author of an assembler based Forth.)

[Albert van der Horst]

In article <7x7fzmy...@ruckus.brouhaha.com>,

Paul Rubin <no.e...@nospam.invalid> wrote:
>rickman <gnu...@gmail.com> writes:
>> I'm still not following. How does the language the OS was written in
>> have any impact on the interfaces the OS provides?
>
>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.

That is half the story. The truth behind is that UNIX + C is the only
portable operating system in town. If you don't believe me, fill in
the blanks .... + Ada ...+Forth ...+Haskell ...+algol68

Then we need millions+ customers to gain a critical mass.

[Albert van der Horst]

Willem Ouwerkerk has his server for 8051 single board computers.
It has drop down menus, all based on not much more than a few ansi codes
and AT-XY.
I have worked on the MANIP thermal simulation for spacecraft. It had a
windows system that runs within a vt100, and portably at that.

If you're on some unix-like OS, remember infocom. You can look up
escape codes for things like color, scrolling and whatnot.
The character based windows on startup when installing linux in
same mode uses that. You can get pretty far with half a dozen
of those codes. And your program will work with a Hazeltine 1200
if ever one wants to hook that thing up. 1]

>
>--
>
>Rick

Groetjes Albert

1] Those were already pretty obscure in the 80's.

[Albert van der Horst]

In article <7xlho25...@ruckus.brouhaha.com>,

Numbered pipes and files aren't too hard
"
albert@cherry:~$ lina 17> aapje

80386 ciforth 5.1
"we gaan naar rome " 3 WRITE-FILE THROW
? ciforth ERROR # -9 : Bad file descriptor

"we gaan naar rome " 17 WRITE-FILE
OK
BYE

albert@cherry:~$ cat aapje
we gaan naar rome albert@cherry:~$more aapje

"

Groetjes Albert

[Albert van der Horst]

(I've some recent experience, trying to write a terminal server
for single board computers like the MPS430).

You didn't notice but returning with a count of zero is not smart
but stupid.
Suppose you have a 300 baud line and a 4 Ghz machine. Then you're effectively
polling and hanging up the machine. It is stupid not to wait at least
the time that is needed for a single character to arrive, 30 mS.
So we have to play with time outs of the order of one character
timing, which is milliseconds. Writing a serial line is full of those
real time issues.
Windows nt followed to an extent the VMS philosophy which is
1. set out a read, return immediately
2. If the read finishes *as configured* (this means x characters,
or a time out, or a ^D, or a ^J or and ASCII null, or a combination
of those) it sets and event flag.
3. You can have your program wait, on any combination of event flags,
so you can keep track of several simultaneous read and write operations.

This is generally considered superior to the Unix approach with the
select mechanism, but ...
(In the 80's I heard, Unix is good for development, VMS is good for
real time. )
MSDOS documentation, implementation and integration with the rest
of the OS is lacking in many respects. (Did I say MSDOS, I mean MS windows.)

There are no hard specifications, now how is one supposed to write a
driver for USB serial with those specs?

This also answers the question, why threads in Linux?
You really need them for time outs alone.

>
>
>>> I'm also finding info saying I need to set group membership to allow
>>> access to the serial port.

One must be aware of how groups work. Then you can forget them until
such time that you're warned you've not enough privileges.

>--
>
>Rick

[Gordon Henderson]

In article <544e08cc$0$6917$e4fe...@dreader36.news.xs4all.nl>,

Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:

>If you're on some unix-like OS, remember infocom. You can look up
>escape codes for things like color, scrolling and whatnot.
>The character based windows on startup when installing linux in
>same mode uses that. You can get pretty far with half a dozen
>of those codes. And your program will work with a Hazeltine 1200
>if ever one wants to hook that thing up. 1]

There's also the ncurses library - if there's a gforth wrapper for it. That
makes your terminal windows more or less implementation independant and
allows for multiple windows, pop-ups and so on.

I've used curses a lot from C, but not from forth.

Gordon

[Andrew Gabriel]

In article <7x38aag...@ruckus.brouhaha.com>,

xterm has a little known feature built-in to allow it to be used as
a secondary (or multiple) terminal window under control of an application,
without the need to run any command in it - the app simply reads and writes
to specific filedescriptors setup for the purpose. This is the -S (capital-
S for Slave Mode) option. A single process can open a number of xterms this
way, and directly control them without running additional apps in them.

Unfortunately, -S is woefully inadequately described on the manpage,
and its format very system-specific (again not covered on manpage).

(dtterm also supports -S, but gnome-terminal does not AFAIK.)

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

[Gordon Henderson]

In article <544e13b6$0$6883$e4fe...@dreader36.news.xs4all.nl>,

Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:

>(I've some recent experience, trying to write a terminal server
>for single board computers like the MPS430).
>
>You didn't notice but returning with a count of zero is not smart
>but stupid.
>Suppose you have a 300 baud line and a 4 Ghz machine. Then you're effectively
>polling and hanging up the machine. It is stupid not to wait at least
>the time that is needed for a single character to arrive, 30 mS.
>So we have to play with time outs of the order of one character
>timing, which is milliseconds. Writing a serial line is full of those
>real time issues.

Linux (and Unix in general) doesn't work like that. Regardless of the
language you're writing your program in, Linux maintains the serial
devices for you. You can write a block of data to a serial device and
your program will not stall unless you fill up the output buffer in the
Linux kernel.

There are system calls to let you force-flush the output buffer and
foce-empty the output buffer as well as letting you know how much is
in it.

So, depending on how your program is written, you never need to wory,
and you can always increase the buffer size if you need to.

Similarly for reading, the kernel reads the characters and stores them
in a buffer until your program is ready to read them - at which point,
you can either use a non-blocking read which won't stall if there are no
characters left, or use a system call to let you know how many characters
are ready to be read.

Of-course if you don't read the input quick enough and are not using
hardware or software handshaking (which the kernel does automatically
if configured to do so), then you lose data, but this is not different
to any other system.

>Windows nt followed to an extent the VMS philosophy which is
>1. set out a read, return immediately
>2. If the read finishes *as configured* (this means x characters,
>or a time out, or a ^D, or a ^J or and ASCII null, or a combination
>of those) it sets and event flag.
>3. You can have your program wait, on any combination of event flags,
>so you can keep track of several simultaneous read and write operations.
>
>This is generally considered superior to the Unix approach with the
>select mechanism, but ...
>(In the 80's I heard, Unix is good for development, VMS is good for
>real time. )
>MSDOS documentation, implementation and integration with the rest
>of the OS is lacking in many respects. (Did I say MSDOS, I mean MS windows.)
>
>There are no hard specifications, now how is one supposed to write a
>driver for USB serial with those specs?

Linux drives USB serial drives and presents an interface that's identical
to an on-board hardware serial device. You can not normally tell if you're
talking to a USB serial device or a hardware serial device unless you
know it's path - typically /dev/ttyS0 for on-board serial (or /dev/ttyAMA0
for the Pi), and /dev/ttyUSB0 or /dev/ttyACM0 for USB serial devices.

>This also answers the question, why threads in Linux?
>You really need them for time outs alone.

Well you don't. There are ways to do without threads, and without using
select() or poll() either. It's just a matter of knowing the system calls
to use - and for a newbie to Linux, that's a fairly steep learning curve,
and the termiios structure and ioctl() mechanism can appear somewhat
daunting at first.

Gordon

[Stephen Pelc]

On Sun, 26 Oct 2014 15:14:56 -0400, rickman <gnu...@gmail.com> wrote:

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

VFX Forth for ARM Linux has a serial port driver, a socket layer
and technical support. It works well on both the Raspberry Pi and
the Beaglebone Black.

Stephen

--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[Anton Ertl]

rickman <gnu...@gmail.com> writes:
>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.

Concerning the telnet client part: Gforth maps the Forth "user input
device" to the standard input/output, and it expects a terminal there
for the interactive mode (I think that's called a console application
in Windows).

So if you have a telnetd on your rPi, you can telnet there, start
Gforth from there, and then the Gforth output (TYPE, EMIT, etc.) will
be displayed on your telnet client, and your input to the telnet
client will be the input of Gforth (KEY, ACCEPT, QUIT input).

The more modern variant of this approach would be to use an ssh
connection rather than a telnet connection; i.e., sshd on the rPi, an
ssh client (ssh on Unix, putty on Windows) on the PC.

With this approach, you don't need to open a socket or anything, just
all the usual words to talk with the user input device.

However, if you want to have a separate channel for diplaying the
message traffic, one way to do that would be to start an xterm and
talk to it through a pipe. An example of how to do that can be found
in status.fs in the Gforth distribution (not sure if that's included
in the Debian package), which does exactly that. To make use of that,
you have to run an X server on the display end of the connection (so
that xterm has an X server to display on).

Other approaches are also possible, but these two are the ones that
should be easiest.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/

[Martin Gregorie]

On Mon, 27 Oct 2014 10:26:11 +0000, Gordon Henderson wrote:

> Well you don't. There are ways to do without threads, and without using
> select() or poll() either. It's just a matter of knowing the system
> calls to use - and for a newbie to Linux, that's a fairly steep learning
> curve, and the termiios structure and ioctl() mechanism can appear
> somewhat daunting at first.
>

Sure, but IME using poll() makes the whole issue of handling more than
one file/network connection.serial port within the same program without
using threads or interprocess communication rather simple once you get
your head around hoe poll() works.

Again, IME, a major issue is working out what C standard library calls to
use. If you know the name of the function, the manpages usually tell you
all you need to know about that function, and 'apropos' is good if you're
not entirely sure about its name (apropos search manpage title lines and
lists all the manpages with your search term in the title.

However, if you're doing more than trivial C programming on a Linux box,
get a copy of "Unix SVR4 System Programming" from O'Reilly (aka The Lion
Book). Its quite a chunk and, despite its name, is 100% relevant to
writing C on Linux. Its groups functions logically, uses clear
descriptions of what's going on and includes goor example code.

Last shot: If you're newish to C, but want to write it well, your
personal library should include
"The C Programming Language" by Kernighan and Richie (ed. 2 or later)
"The Practise of Programming" by Kernighan and Pike

The first is a very readable introduction to writing C, written by the
authors of the language while the second is applicable to almost any
block structured language (C, Java, Python...) and gives good advice
about variable and function names, program layout and how to write code
thats easy to maintain and debug. Its a good book to read when you've
learnt a programming language or two and before you tackle a significant
programming task.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[Gordon Henderson]

In article <m2lgi5$l6s$2...@dont-email.me>,

Not sure why you're telling me this - I've been programming in C on Unix
and like systems for nearly 35 years now and am quite happy stuck in my ways.


Gordon

[Martin Gregorie]

On Mon, 27 Oct 2014 14:12:25 +0000, Gordon Henderson wrote:

> Not sure why you're telling me this - I've been programming in C on Unix
> and like systems for nearly 35 years now and am quite happy stuck in my
> ways.
>

Apologies, Gordon - I obviously misplaced my post within the thread. It
was, of course, intended for Rickman, who seemed doubtful about writing
Linux programs and/or C. Hopefully it will also be useful for anybody
else in his position.

I would have found Kernighan&Pike very useful when I was in starting to
write significant programs (or even simpler ones that weren't throwaways!
) but at that point even K&R hadn't been written, let alone UNIX. As it
happens I'd already evolved a fairly similar style to that described in
K&P, but even so I found it a useful read simply because it is extremely
readable and offers a good description of how to write well-structured
programs.

[A. Dumas]

On 27/10/2014 08:11, Dom wrote:
> The difference between upgrade and dist-upgrade is that upgrade will
> only install newer versions of packages already installed on your system
> if it can do so without removing any existing packages or installing
> additional ones.
>
> So if you had knife(1.0), fork(1.2) and spoon(1.2) installed, and then
> knife(1.3) was released which depended on spork(1.3) which replaced
> fork(1.2) and spoon(1.2), an upgrade would do nothing, but a
> dist-upgrade would remove fork and spoon and install spork.
>
> So in a way it is a distribution upgrade as you are changing which
> packages are installed rather than just upgrading existing ones.
>
> This situation is also a lot more common when moving to a new release
> than during routine upgrades of the Stable system (Wheezy at the
> moment). Testing (Jessie) is more likely to need dist-upgrade.

Right! However, I'm fairly sure the new epiphany-browser wasn't (isn't)
included in a dist-upgrade. My update script does dist-upgrade and I had
run it a few times already between the release of Epiphany and manually
installing it. (However again, Gordon said "additional stuff to support
the new web browser" so that might indeed be covered:)

[Paul Rubin]

and...@cucumber.demon.co.uk (Andrew Gabriel) writes:
> xterm has a little known feature built-in to allow it to be used as
> a secondary (or multiple) terminal window under control of an application,
> without the need to run any command in it - the app simply reads and writes
> to specific filedescriptors setup for the purpose. This is the -S (capital-
> S for Slave Mode) option.

Yes I noticed that in the xterm man page, but does the app then have to
deal with the pty interface? I remember wanting to use that for
something once, and it looked kind of messy in the docs, and I ended up
not pursuing it. I guess if the xterm can just inherit a file
descriptor and not have to mess with pty devices, that can be simpler
than the named pipe approach.

[rickman]

I'm not sure what you mean by "hard work". If you mean the few
constants, yes, there is a file with them declared in Forth. Otherwise
is is just a windows system call with a data structure. All of that is
already a part of any Forth that runs under an OS. How else could they
get to the I/O? Serial ports just use a few different constants.

You make it sound like it takes enormous work to find those constants
and use them.

--

Rick

[rickman]

On 10/27/2014 4:48 AM, Albert van der Horst wrote:
> In article <7x7fzmy...@ruckus.brouhaha.com>,
> Paul Rubin <no.e...@nospam.invalid> wrote:
>> rickman <gnu...@gmail.com> writes:
>>> I'm still not following. How does the language the OS was written in
>>> have any impact on the interfaces the OS provides?
>>
>> 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.
>
> That is half the story. The truth behind is that UNIX + C is the only
> portable operating system in town. If you don't believe me, fill in
> the blanks .... + Ada ...+Forth ...+Haskell ...+algol68
>
> Then we need millions+ customers to gain a critical mass.

I don't get your point. There are a huge number of native Forth
implementations, so if I understand your analogy it would be just Forth
+ Forth. No?

--

Rick

[rickman]

On 10/27/2014 7:30 AM, Stephen Pelc wrote:
> On Sun, 26 Oct 2014 15:14:56 -0400, rickman <gnu...@gmail.com> wrote:
>
>> 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.
>
> VFX Forth for ARM Linux has a serial port driver, a socket layer
> and technical support. It works well on both the Raspberry Pi and
> the Beaglebone Black.

Great, how does that help me use gForth?

--

Rick

[rickman]

Obviously I am terrible at explaining things as I never seem to be able
to get people to understand what I am trying to do with this app. I
find it very simple, but I must be leaving out important info. Let me
try drawing an ASCII art picture...
Test Fixture Forth App Terminal Emulator
+--------+ +--------+ +---------+
| | RS232 | Forth | ??? | RS232 |
| UUT |<=====>| User |<=====>| Data |
| | | I/O | | Display |
+--------+ +--------+ +---------+

The middle box is the Forth app with its own console I/O. The left box
is a test fixture connected to the computer by RS-232. The user
controls the app through the console I/O and when actually production
testing boards test results are copied into the paste buffer by the
program to be pasted into a spread sheet.

The current iteration of the program uses a socket connection to display
the RS232 message data in a terminal emulator as a second window
separate from the console. This is useful as a debug tool but is not
strictly required for production testing.

Just to be clear, the rPi will not be used for production testing. If
possible I would like to have a single source file which will compile
correctly on both Linux and Windows systems, but that is not essential
and not even important at this stage. Right now I'd just like to get
the serial port working and find a way to display the traffic data
somewhere other than the console window. I think the pipes thing may
work just fine, possibly under Windows as well.

--

Rick

[Andrew Gabriel]

In article <7xsii9c...@ruckus.brouhaha.com>,

Yes, program creates a pty. Look at W.Richard Steven's excellent book,
"Advanced Programming in the Unix Environment", chapter 19.
(He shows ptys for Solaris and BSD, but unfortunately not Linux.
You can find ptyopen.c Linux source code for doing it on the web.)
You end up with two filedescriptors, one for the master side and one
for the slave side of the pty.

Then you simply fork/exec xterm, giving it the master side fd, and you
use the slave side fd to read and write to the xterm. The format of
the -S option (on Solaris at least) is -Sxx%d where %d is the master
side fd, and xterm ignores the first two characters (the "xx") for some
historic reason (I vaguely recall they must not be slashes, which cause
the field to be interpreted differently). The other undocumented feature
here is that xterm sends back an initial line of text which was not typed
in the xterm window - it is the X Window ID of the xterm window (which I
just skip past, as I never need my app to ask the window manager to
iconize or redisplay the xterm).

[rickman]

On 10/27/2014 5:43 AM, Albert van der Horst wrote:
> In article <m2k3hn$5lv$1...@dont-email.me>, rickman <gnu...@gmail.com> wrote:
>>
>> The windows I/O is just read-file, but it returns a length which can be
>> zero. Comkey? asks for 1 byte so the char is saved and the routine
>> returns if it was found or not. When Comkey is called it calls Comkey?
>> to make sure a char is in the buffer than returns the char from the
>> buffer. Sounds like I can do the same thing. I just need to find the
>> file I/O calls. But the serial port needs to be set up. One reference
>> said to do that outside of the app.
>
> (I've some recent experience, trying to write a terminal server
> for single board computers like the MPS430).

What is a terminal *server*?

I can't say I follow your reasoning. I don't see how bit rate has
anything to do with the issue. If a read is requested and there is no
data in the read buffer, the routine returns indicating it read no data.
If there is data in the buffer it returns the data and the lesser
count of data in the buffer and the amount requested. Actually, this is
the same as the no data case where it returns the data in the buffer
which is none and returns the size which is zero. In all cases it
returns immediately. If the program wishes to wait for data it just
sits in a loop checking for new data and hopefully wasting time by
calling a wait routine rather than tying up CPU with a spin loop.

Where exactly is the problem?

--

Rick

[rickman]

On 10/27/2014 11:34 AM, Martin Gregorie wrote:
> On Mon, 27 Oct 2014 14:12:25 +0000, Gordon Henderson wrote:
>
>> Not sure why you're telling me this - I've been programming in C on Unix
>> and like systems for nearly 35 years now and am quite happy stuck in my
>> ways.
>>
> Apologies, Gordon - I obviously misplaced my post within the thread. It
> was, of course, intended for Rickman, who seemed doubtful about writing
> Linux programs and/or C. Hopefully it will also be useful for anybody
> else in his position.

I'm not sure why you think I am "doubtful" about writing in C. I am..
er, was... fairly experienced in C, but I have not used it in a decade
or more and don't intend to use it if I don't have to... and I *don't*
have to. Don't get me wrong. There is not much bad about C. I just
like the interactivity of Forth. I find it much easier to get stuff
working in Forth than to use a debugger in C.

> I would have found Kernighan&Pike very useful when I was in starting to
> write significant programs (or even simpler ones that weren't throwaways!
> ) but at that point even K&R hadn't been written, let alone UNIX. As it
> happens I'd already evolved a fairly similar style to that described in
> K&P, but even so I found it a useful read simply because it is extremely
> readable and offers a good description of how to write well-structured
> programs.

My copy of K&R is sitting in my bookcase along with a couple of other C
books and a small collection of VHDL books. My two Forth books are
laying on my desk next to my work area...

--

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> I just like the interactivity of Forth. I find it much easier to get
> stuff working in Forth than to use a debugger in C.

Since you're talking about raspberry pi's, this seems like a good chance
to try Python.

[rickman]

Yes, that thought occurred to me last night, but I already have code in
Forth for my app. I will try Python another time.

Btw, is that why it is the Raspberry 'Pi' as in 'Py'thon?

--

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> Btw, is that why it is the Raspberry 'Pi' as in 'Py'thon?

I kinda doubt it ;-).

You should also look at the Beaglebone Black by the way.

[rickman]

Why?

--

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
>> You should also look at the Beaglebone Black by the way.
> Why?

Well it's a comparable board in the same space, but more technically
oriented, has some different capabilities, worth looking into if you're
into these things. You might like its realtime coprocessors, for
example.

[Elizabeth D. Rather]

On 10/27/14 11:51 AM, rickman wrote:
...

>
> Obviously I am terrible at explaining things as I never seem to be able
> to get people to understand what I am trying to do with this app. I
> find it very simple, but I must be leaving out important info. Let me
> try drawing an ASCII art picture...
> Test Fixture Forth App Terminal Emulator
> +--------+ +--------+ +---------+
> | | RS232 | Forth | ??? | RS232 |
> | UUT |<=====>| User |<=====>| Data |
> | | | I/O | | Display |
> +--------+ +--------+ +---------+
>
> The middle box is the Forth app with its own console I/O. The left box
> is a test fixture connected to the computer by RS-232. The user
> controls the app through the console I/O and when actually production
> testing boards test results are copied into the paste buffer by the
> program to be pasted into a spread sheet.

Baffled by your concern. Native Forths have been doing this since the
1970's, without OSs of any kind. Serial port drivers took (in the good
old days) about one block/sceen of code. Multiple tasks could manage
their own screens or ports.

IMO introducing OSs into the picture is complicating the process, not
simplifying it.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[rickman]

On 10/28/2014 2:31 AM, Elizabeth D. Rather wrote:
> On 10/27/14 11:51 AM, rickman wrote:

> ....

>>
>> Obviously I am terrible at explaining things as I never seem to be able
>> to get people to understand what I am trying to do with this app. I
>> find it very simple, but I must be leaving out important info. Let me
>> try drawing an ASCII art picture...
>> Test Fixture Forth App Terminal Emulator
>> +--------+ +--------+ +---------+
>> | | RS232 | Forth | ??? | RS232 |
>> | UUT |<=====>| User |<=====>| Data |
>> | | | I/O | | Display |
>> +--------+ +--------+ +---------+
>>
>> The middle box is the Forth app with its own console I/O. The left box
>> is a test fixture connected to the computer by RS-232. The user
>> controls the app through the console I/O and when actually production
>> testing boards test results are copied into the paste buffer by the
>> program to be pasted into a spread sheet.
>
> Baffled by your concern. Native Forths have been doing this since the
> 1970's, without OSs of any kind. Serial port drivers took (in the good
> old days) about one block/sceen of code. Multiple tasks could manage
> their own screens or ports.
>
> IMO introducing OSs into the picture is complicating the process, not
> simplifying it.

I'm baffled by your response. I'm not writing this from scratch. I
have a working program that runs under Windows using Win32Forth. I'm
just trying to port that to the rPi. What native Forth should I use
that would be more suitable than using the Raspian OS that comes with
the board? I believe I have seen a native Forth for the rPi, but I
don't see how that makes anything more simple.

Funny, one response in this thread says I am silly for thinking about
writing my own code for the data display in a separate window since the
OS provides so many other ways to do that. Now I am being told I am
silly for not wanting to write nearly all of the code myself for the
windows management as well as the serial port driver.... I think.

--

Rick

[rickman]

I'm only looking at the rPi because I was given one. Since it has most
of the capabilities of a PC I figure it would be nicer to use in the lab
than a PC, mostly because it is so much smaller. I also have been
considering rolling an add on board for the rPi but so far have not
figured out what it would be. So this is a learning experience.

The BBB is interesting, but support is through a Google group and the
market is *soooo* much smaller. The rPi really rolled over top of it
and all the other SBC Linux units out there. They've sold 3.8 million
so far. For 99% of the things I would do with a Linux SBC there is no
difference so I will use the one with better support.

--

Rick

[Elizabeth D. Rather]

Ok, if the board comes with all the code you need, why is there a long
thread about how to do serial I/O? I understand that you have a whole
application. It should be straightforward to write the underlying
TYPE/ACCEPT support, either natively (I don't know how permissive
Raspian is of folks doing their own I/O) or with OS calls. I do know
that whatever solution you find will almost certainly be simpler than
what you're doing under Windows.

[rickman]

I'm just not following what you are saying. I think when you say
"native" you mean not using the OS rather than not *having* an OS. I
have no interest in writing an interrupt driver for an OS when one
already exists. Why should I reinvent the wheel?

Or do I still not understand what you are suggesting?

You also mention OS calls which is exactly what I am asking about. I
find your comparison to Windows a bit silly. So far everything I have
been told is virtually the same as under Windows. As much as anything I
am asking about gForth really. gForth runs under Linux and Windows.
I'm hoping I can find code that works transparently under both.

My point in asking about this is that I am sure I'm not the first person
to use a serial port in gForth. The one code example found so far was
very complicated, much more so than what I need.

--

Rick

[Gordon Henderson]

In article <7xa94hy...@ruckus.brouhaha.com>,

Or..

Since you're talking about a Linux computer, this seems like a good
chance to try one of the 1000's of other languages avalable for it.

The Pi Foundation like Python and yes, the "Pi" in the name does refer to
Python, but it's just another Linux system at the end of the day. Python
is just one more language you can use with Linux. There are at least
three different Forths avalable for it. And Cobol, Ada, brainfuck and
who knows what else.. (even BASIC)

I'd suggest not picking a language because it's popular, but picking
one you know how to use - and it seems Forth in this case is just what
the OP wants.

Gordon

[Gordon Henderson]

In article <7xd29dy...@ruckus.brouhaha.com>,

Paul Rubin <no.e...@nospam.invalid> wrote:
>rickman <gnu...@gmail.com> writes:
>> Btw, is that why it is the Raspberry 'Pi' as in 'Py'thon?
>
>I kinda doubt it ;-).

It really is. The foundation love Python.

Gordon

[Elizabeth D. Rather]

It can be easier to write the driver (which, in my experience, takes
about an hour with no OS) than to spend days finding out how to do it
through an OS. Back in the day, we ignored DOS calls for that very
reason (DOS was much slower, anyway). I am not familiar with Linux or
gForth, but the very fact that there has been such discussion here I
find baffling.

> You also mention OS calls which is exactly what I am asking about. I
> find your comparison to Windows a bit silly. So far everything I have
> been told is virtually the same as under Windows. As much as anything I
> am asking about gForth really. gForth runs under Linux and Windows. I'm
> hoping I can find code that works transparently under both.

If it's easy and just the same as Windows, why the long discussion?

> My point in asking about this is that I am sure I'm not the first person
> to use a serial port in gForth. The one code example found so far was
> very complicated, much more so than what I need.

I fervently hope you find a simpler solution. Serial drivers should be
simple.

[rickman]

On 10/28/2014 4:11 AM, Gordon Henderson wrote:
> In article <7xa94hy...@ruckus.brouhaha.com>,
> Paul Rubin <no.e...@nospam.invalid> wrote:
>> rickman <gnu...@gmail.com> writes:
>>> I just like the interactivity of Forth. I find it much easier to get
>>> stuff working in Forth than to use a debugger in C.
>>
>> Since you're talking about raspberry pi's, this seems like a good chance
>> to try Python.
>
> Or..
>
> Since you're talking about a Linux computer, this seems like a good
> chance to try one of the 1000's of other languages avalable for it.
>
> The Pi Foundation like Python and yes, the "Pi" in the name does refer to
> Python, but it's just another Linux system at the end of the day. Python
> is just one more language you can use with Linux. There are at least
> three different Forths avalable for it. And Cobol, Ada, brainfuck and
> who knows what else.. (even BASIC)

What are the other two Forths? Not that I would likely use one, but I'm
curious. gForth runs on the PC as well and I am expecting to have one
program that I can run on both platforms.

> I'd suggest not picking a language because it's popular, but picking
> one you know how to use - and it seems Forth in this case is just what
> the OP wants.

Yeah. I like your approach. :)

--

Rick

[Gordon Henderson]

In article <m2nj9o$l56$2...@dont-email.me>, rickman <gnu...@gmail.com> wrote:

>What are the other two Forths? Not that I would likely use one, but I'm
>curious. gForth runs on the PC as well and I am expecting to have one
>program that I can run on both platforms.

yforth and the stand-alone one mentioned by someone else earlier. I'm sure
there are others too.

Gordon

[A. Dumas]

On 28/10/2014 09:14, rickman wrote:
> On 10/28/2014 4:11 AM, Gordon Henderson wrote:
>> There are at least
>> three different Forths avalable for it.
>

> What are the other two Forths? Not that I would likely use one, but I'm
> curious.

To see what is available in the standard software repositories:
"apt-cache search forth | grep -i forth" (include grep to weed out
things which are merely related).

[Stephen Pelc]

It doesn't, but it may be a cheaper solution overall when your
time is paid for.

Stephen

--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[Albert van der Horst]

To find one may be easy. To get everything working like it does in
Win32Forth or gForth is a gigantic task.

Here is an exercise:
you can see that pipe is in man page 2 for linux
That means that it must be possible to call it
<1> <2> <3> __NR_pipe XOS
where XOS is int80 : the generic system call.

Now find the actual number __NR_pipe such that you can actually call it from
Forth. Maybe you're very clever with this, but for me it takes time.

>
>--
>
>Rick

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Albert van der Horst]

An operatings system for me is a couple of facilities:
word processor, prefereably compatible with MS-WORD
pc-board design
Verilog implementation
able to show all formats of you tube films
shopping in all internet shops
....
do latex typesetting
prints on the usual printers you can buy

So colorforth doesn't fit the bill.

[Alan Adams]

In message <544fa701$0$6973$e4fe...@dreader36.news.xs4all.nl>

An operating system is none of those. It is the software layer that
sits between each of those and the hardware.

That list is of applications, which have to have been compiled for the
operating system.

Alan

> So colorforth doesn't fit the bill.

>>
>>--
>>
>>Rick


> Groetjes Albert


--

Alan Adams, from Northamptonshire
al...@adamshome.org.uk
http://www.nckc.org.uk/

[rickman]

I'm sorry, I can't follow what you are trying to say. What is your point?

--

Rick

[rickman]

On 10/28/2014 8:41 AM, Stephen Pelc wrote:
> On Mon, 27 Oct 2014 17:37:05 -0400, rickman <gnu...@gmail.com> wrote:
>
>> On 10/27/2014 7:30 AM, Stephen Pelc wrote:
>>> On Sun, 26 Oct 2014 15:14:56 -0400, rickman <gnu...@gmail.com> wrote:
>>>
>>>> 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.
>>>
>>> VFX Forth for ARM Linux has a serial port driver, a socket layer
>>> and technical support. It works well on both the Raspberry Pi and
>>> the Beaglebone Black.
>>
>> Great, how does that help me use gForth?
>
> It doesn't, but it may be a cheaper solution overall when your
> time is paid for.

Perhaps, but I don't have a good way of estimating that. To be honest,
I find the MPE web site to be confusing and hard to find info on your
products.

--

Rick

[mm0fmf]

On 27/10/2014 21:51, rickman wrote:
> Obviously I am terrible at explaining things as I never seem to be able

> to get people to understand what I am trying to do with this app

That's the first clearly expressed thing you have written.

[Ray]

You may find this site of interest. It includes section on using Forth with
the Gertboard add on.

<elinux.org/Forth>

RayH

[rickman]

There are several things wrong with that idea. The first is that I
*want* to have the OS so that I can use the many other tools available
under it. One of my issues with Linux is the lack of support from a
variety of vendors, but for the most part I can do anything under Linux
I can do under Windows. I bet you aren't typing your posts on a bare
metal Forth machine.

Secondly I disagree it is an hour job to write and debug a serial port
driver on the rPi hardware. I have looked at the hardware manual and I
expect it would take much longer just to find the info needed and
learning how the device works in enough detail to use interrupts with
the UART. This is not an MSP430 or an AVR.

One of the reasons I wish to work with the rPi is to put me in a better
position to build an add on card for the Pi. This card would very
likely include a very low power FPGA and a GA144. But I need to have
some level of confidence that I can get a fast interface to the Pi.
Right now the few parallel lines and an SPI won't cut it. The BBB looks
much better in that regard with a parallel memory mapped interface I am
told. But the BBB has much less of a support group. In reality I am
learning about Linux as the moment so it doesn't matter as much which
hardware I am on. I can change that later if I find it important.

> Back in the day, we ignored DOS calls for that very
> reason (DOS was much slower, anyway). I am not familiar with Linux or
> gForth, but the very fact that there has been such discussion here I
> find baffling.

Most of the discussion has actually been off topic in the sense that it
was not directly along the line of minimal effort to my end. I thought
it might be a good idea crossposting to both the Forth group and to the
rPi group. It seems many of the replies from the rPi group are about
the many different ways the window interface can be done. Many of the
replies from the Forth group seem to be suggesting a variety of things,
but few of them on target. I expected someone familiar with gForth
would point me to an example saying, Here is how so and so did it" as I
found when doing this under Win32Forth. The only example I found in
gForth was very complex clearly due to needs that are not at all like
mine. But I have most of the info I need and might be able to work out
the rest. Now I need to figure out how to edit code on the rPi and I
should be ready to proceed. I might work from my PC and control the rPi
remotely. Or I have been thinking of changing editors on the PC anyway.
Maybe this would be a good time to learn Emacs.

>> You also mention OS calls which is exactly what I am asking about. I
>> find your comparison to Windows a bit silly. So far everything I have
>> been told is virtually the same as under Windows. As much as anything I
>> am asking about gForth really. gForth runs under Linux and Windows. I'm
>> hoping I can find code that works transparently under both.
>
> If it's easy and just the same as Windows, why the long discussion?

I would ask you that question. If you aren't interested in helping, why
are you in this discussion making it longer?

>> My point in asking about this is that I am sure I'm not the first person
>> to use a serial port in gForth. The one code example found so far was
>> very complicated, much more so than what I need.
>
> I fervently hope you find a simpler solution. Serial drivers should be
> simple.

I think that is true, it is often the OS that is not so simple.

--

Rick

[Stephen Pelc]

On Tue, 28 Oct 2014 12:51:27 -0400, rickman <gnu...@gmail.com> wrote:

>Perhaps, but I don't have a good way of estimating that. To be honest,
>I find the MPE web site to be confusing and hard to find info on your
>products.

Well, we answer our emails - try the obvious one with the xxx removed,
or ring the US access number 901-313-4312 during UK office hours -
it's got voicemail, so we'll call back if we miss you.

[Richard Owlett]

[ *SNIP* ~1 month ]

On 10/26/2014 rickman wrote:
> ... Please remember I am not conversant with Linux. ...

On 10/26/2014 rickman (in a different post) also wrote:

> ... I have a program ... It was written in Forth using OS specific calls (Windows).
> ... Now I wish to port this program to the rPi. ...

I also gather that Rick has not used gforth before.

Rick, as a NONexpert in FORTH nor *nix may I suggest:

_The Debian Administrator's Handbook_ by Raphaėl Hertzog and
Roland Mas
( http://debian-handbook.info/ )
"Debian Reference" by Osamu Aoki
( https://www.debian.org/doc/manuals/debian-reference/ )

Assuming that current Linux and Windows versions of gforth are
functionally equivalent that you first port your Forth program to
the Windows version of gforth. That way you deal with only one
new thing at a time.

P.S. I predate the use of transistors in computers ;/

[rickman]

Clearly I need to learn more about using Linux. That is no small part
of the reason why I am using the rPi. But it seems every time I try
something new I feel like I hit a brick wall. I just installed Xemacs
on the pi and when I run it I feel like I need to go back to basics. It
is so different from any other editor I've ever seen that I am totally
stumped on getting started with it. Fortunately it has a lot of
materials. :)

I will try your command, thanks. Another learning experience.

--

Rick

[rickman]

So I am improving... lol

--

Rick

[rickman]

Oddly enough this page seems to mostly talk about extending the Atlast
kernal with C code. But it is something to look at.

--

Rick

[rickman]

On 10/28/2014 5:22 AM, A. Dumas wrote:

This command only turned up gForth and yForth. I'm happy with gForth so
far.

I brought my laptop to the workbench where the Pi is and it is pretty
clear that I need to do the remote login thing. Trying to use two
keyboards and two mice will likely drive me insane... or more insane.
It will also get around the lack of a pipe character with my Dell keyboard.

--

Rick

[rickman]

Your exercise is one sided. What would it have taken for me to find the
info with C? It would have been a large task since I know virtually
nothing about Linux in general. You think it is easy because you have
learned to do similar things and this is just applying the knowledge you
have acquired. I don't have that knowledge so the Forth example is not
much bigger than with C.

To be honest, this is not a useful conversation for me. I'm not really
sure what your purpose is in pursuing it.

--

Rick

[Mel Wilson]

On Tue, 28 Oct 2014 14:09:25 -0400, rickman wrote:
> [ ... ] Now I need to figure out how to edit code on the rPi and I

> should be ready to proceed. I might work from my PC and control the rPi
> remotely. Or I have been thinking of changing editors on the PC anyway.
> Maybe this would be a good time to learn Emacs.

ISTR the nano editor is not bad. I hope I'm right in remembering that
it's available on the Pi.

Mel.

[Ivan D. Reid]

On Tue, 28 Oct 2014 21:50:22 +0000 (UTC), Mel Wilson <mwi...@the-wire.com>
wrote in <m2p32s$d3p$1...@dont-email.me>:

Yes, I was thinking of recommending that; it's been available on every
Linux distro I've used lately, including Ubuntu on the Tegra TK1 "Jetson"
development kit. For simple text/code editing it doesn't have all the
baggage of emacs (or vi). Worth checking out if you don't *need* multi-
windows, multi-buffers, X windows, etc.

--
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".

[rickman]

On 10/28/2014 8:01 PM, Ivan D. Reid wrote:
> On Tue, 28 Oct 2014 21:50:22 +0000 (UTC), Mel Wilson <mwi...@the-wire.com>
> wrote in <m2p32s$d3p$1...@dont-email.me>:
>> On Tue, 28 Oct 2014 14:09:25 -0400, rickman wrote:
>>> [ ... ] Now I need to figure out how to edit code on the rPi and I
>>> should be ready to proceed. I might work from my PC and control the rPi
>>> remotely. Or I have been thinking of changing editors on the PC anyway.
>>> Maybe this would be a good time to learn Emacs.
>
>> ISTR the nano editor is not bad. I hope I'm right in remembering that
>> it's available on the Pi.
>
> Yes, I was thinking of recommending that; it's been available on every
> Linux distro I've used lately, including Ubuntu on the Tegra TK1 "Jetson"
> development kit. For simple text/code editing it doesn't have all the
> baggage of emacs (or vi). Worth checking out if you don't *need* multi-
> windows, multi-buffers, X windows, etc.

Yeah, I'm sure there is a lot in emacs I don't need, but I do work in
multiple languages including Verilog and VHDL and like the syntax
coloring. Also, I'd like to switch editors on the PC so I am using the
same one on all platforms. Nano might do this, but it is not clear from
searching for this info.

--

Rick

[Martin Gregorie]

On Tue, 28 Oct 2014 14:09:25 -0400, rickman wrote:

> Now I need to figure out how to edit code on the rPi and I
> should be ready to proceed.
>

As you are thinking of changing editors, it would be useful to know if
you prefer programming from the command line or using a GUI before
recommending editors.

I'll make just one observation here: its worth looking at Vi or its
improved Vim clone. You may hate it but its still useful to know because
it is capable of running from a really minimal keyboard and screen. It
can be used if the screen is so old or broken that it only has a glass
teletype level of screen painting ability and a keyboard without cursor
or function keys. If you manage the bork the RPi really badly, knowing vi
may help you recover because its often usable when the system is degraded
to the point where emacs and other editors can't be used.

> I might work from my PC and control the rPi remotely.
>

I think thats a good idea anyway. Connect the RPi to your LAN and run
PuTTY, a well regarded SSH implementation for Windows, on your PC and
you've immediately got command-line access to the RPi via an SSH session
as well as file transfers via the scp utility. This is known as running
the RPi in headless mode and means you don't need a screen/keyboard/mouse
for it.

If you want some GUI capability, use VNC: you run vncserver on the RPi
and a Windows version of vncviewer on the PC, or there's a Java applet
that lets your web browser act as the viewer. Either way, this lets you
drive the RPi from your PC's keyboard and mouse and see what its doing on
the PC screen.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[Paul Rubin]

Martin Gregorie <mar...@address-in-sig.invalid> writes:
> I think thats a good idea anyway. Connect the RPi to your LAN and run
> PuTTY, a well regarded SSH implementation for Windows, on your PC and
> you've immediately got command-line access to the RPi

Note you can still use the named pipe approach to multiple Forth windows
by just opening multiple putty windows as described above. Run gforth
in one of them and cat the named pipe to another.

[Ivan D. Reid]

On Tue, 28 Oct 2014 20:50:48 -0400, rickman <gnu...@gmail.com>
wrote in <m2pdlu$hgl$1...@dont-email.me>:

OK, I'm not sure if there's a "native" Windows version of nano.
You might not want to go down this route, but I use cygwin on Windows and
it does have nano. If you just use terminal screens it's not too hard;
going the full X windows route is a whole other steep learning curve. (If
you do go the whole hog with cygwinX, then (X)emacs becomes available on
Windows too -- but I'm pretty sure there's a more-native version
somewhere.)

[rickman]

On 10/28/2014 9:20 PM, Ivan D. Reid wrote:
> On Tue, 28 Oct 2014 20:50:48 -0400, rickman <gnu...@gmail.com>
> wrote in <m2pdlu$hgl$1...@dont-email.me>:
>> On 10/28/2014 8:01 PM, Ivan D. Reid wrote:
>
>>> Yes, I was thinking of recommending that; it's been available on every
>>> Linux distro I've used lately, including Ubuntu on the Tegra TK1 "Jetson"
>>> development kit. For simple text/code editing it doesn't have all the
>>> baggage of emacs (or vi). Worth checking out if you don't *need* multi-
>>> windows, multi-buffers, X windows, etc.
>
>> Yeah, I'm sure there is a lot in emacs I don't need, but I do work in
>> multiple languages including Verilog and VHDL and like the syntax
>> coloring. Also, I'd like to switch editors on the PC so I am using the
>> same one on all platforms. Nano might do this, but it is not clear from
>> searching for this info.
>
> OK, I'm not sure if there's a "native" Windows version of nano.
> You might not want to go down this route, but I use cygwin on Windows and
> it does have nano. If you just use terminal screens it's not too hard;
> going the full X windows route is a whole other steep learning curve. (If
> you do go the whole hog with cygwinX, then (X)emacs becomes available on
> Windows too -- but I'm pretty sure there's a more-native version
> somewhere.)

Thanks for the insight. I looked at nano and found that it was only
available for Windows under Cygwin. Xemacs is available as a Win32 app.
I have downloaded it but not tried to use it. I fired it up on the
rPi and can't use it at all. I'll have to take some time to read the
fine manual. :)

I'm taking the forth group off of the replies that only have to do with
the rPi and not Forth. I think they don't need to be bothered by this
thread for the most part which surprises me a bit. I figured I get some
input about the serial port stuff from the various gForth users there.

--

Rick