BBC MicroBit has arrived - which Forth in Python is recommended for now?

[JUERGEN]

A MicroBit has arrived on my desk, but no Forth yet available. Until a real Forth is running, and as Python is a supported language - is there a Forth out there in Python I could load and run? Speed is not the issue for now nor is completeness. I mainly want to control the IOs, and the 25 LEDs are just enough to display ok, or a 4 Bit INPUT value, a 4 bit OUTPUT value - and 3 levels of Stack ...
Any help appreciated. http://microbit-micropython.readthedocs.org/en/latest/.
Picture and video you can find at https://www.facebook.com/groups/PROGRAMMINGFORTH/?fref=ts. Has anybody re-written JonesForth in Python?

[hughag...@gmail.com]

John Passaniti's claim to fame was that he wrote a Forth-like interpreter in Perl --- maybe you could try that --- makes as much sense as Forth in Python.

[Martin Nicholas]

It's a 32-bit ARM Cortex Processor (Cortex M0):
http://www.bbc.co.uk/mediacentre/mediapacks/microbit/specs
so a FORTH for this shouldn't be too elusive.

--
Regards,

Martin Nicholas.

E-mail: reply-...@mgn.org.uk

[JUERGEN]

There might be a misunderstanding: There will be Forths running on the MicroBit - BUT this means that the original software has to be replaced or at least partially. The idea here was to use the existing Python Programming Environment to have a small Forth running as an Application - leaving everything else as is.

[hughag...@gmail.com]

On Wednesday, April 6, 2016 at 12:14:43 AM UTC-7, JUERGEN wrote:

> A MicroBit has arrived on my desk, but no Forth yet available.

Well, I read up on that BBC MicroBit computer. I think that it is pretty cool that every junior-high-school student in England is given a computer for free. Nothing like that is done in America --- in America the focus is primarily on the government providing money to senior citizens (Social Security, Medicare, etc.), and also to anybody who claims to be a victim (welfare, section-8 housing, etc.) --- but very little is done for young people.

BTW: How did you manage to get one on your desk? My understanding is that they aren't sold to the public, but are only given to the school kids.

[Julian Fondren]

On Wednesday, April 6, 2016 at 4:32:26 AM UTC-5, JUERGEN wrote:
>
> There might be a misunderstanding: There will be Forths
> running on the MicroBit - BUT this means that the original
> software has to be replaced or at least partially. The idea
> here was to use the existing Python Programming Environment
> to have a small Forth running as an Application - leaving
> everything else as is.
>

There's no well-known Forth-in-Python, so I think you won't be
able to get very far with your idea. Looking around the web I
see what you've probably found already:

https://github.com/jtauber/forth/blob/master/forth.py

http://openbookproject.net/py4fun/forth/forth.py

https://mail.python.org/pipermail/edu-sig/2000-October/000744.html

These are hopelessly incomplete. Can't even call them toys.


Well, this looks a little bit better:

https://github.com/jdinuncio/pyforth/blob/master/pyforth/forthvm.py

Adding . and WORDS :

@word_('.')
def dot(forth):
print forth._pop()

@word_()
def words(forth):
for name in forth.dct: print name,

Interactively:

$ python f.py
words
and forth_interpret >= >> <> over is_immediate /mod create ! or
end & + * - , / . lit init exit swap branch dup rot- ; : = < >
<< @ <= 0branch >r immediate exec_ key word_from_name not [ ]
interpret ^ ` bye word r> drop words | depth pick rdrop emit ~

1 2 + .
3


-- Julian

[JUERGEN]

In my spare time I work as STEM Ambassador in educational projects - which came as part of the MSP430 MicroBox scouts project last year. You cannot buy them yet, and I do not own it, they are on loan only for project preparation - so I am a Loaner - not an Owner. ... and having a good relationship with the people who have access helped as well.

[Albert van der Horst]

hughag...@gmail.com writes:

>On Wednesday, April 6, 2016 at 12:14:43 AM UTC-7, JUERGEN wrote:

>> A MicroBit has arrived on my desk, but no Forth yet available.=20

>Well, I read up on that BBC MicroBit computer. I think that it is pretty co=
>ol that every junior-high-school student in England is given a computer for=
> free. Nothing like that is done in America --- in America the focus is pri=
>marily on the government providing money to senior citizens (Social Securit=
>y, Medicare, etc.), and also to anybody who claims to be a victim (welfare,=

> section-8 housing, etc.) --- but very little is done for young people.

>BTW: How did you manage to get one on your desk? My understanding is that t=

>hey aren't sold to the public, but are only given to the school kids.

I see the website. -- great ... blabla .. magnificent .. Lots about hardware.
Nothing about software, which is the heart of the machine.

I see a conspiracy to get kids away from free open source software.

The best way for a kid to get involved, is to lay hands on a second hand
computer and install linux on it, or play with a discarded ("too
old") cell phone with android.

It is probably cheaper then the Microbit, too.

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

[JUERGEN]

You can Not-Like it, but I rather live with the facts: 1 000 000 will be delivered free of charge in the UK to children. This is a basis for Forth. I rather go with the flow.
I do agree with the compilation via Internet is not a good idea and had issues already - but an on-board Forth Application will be free, independant of the internet and interactive.

[JUERGEN]

Thank you very much for all the links - brilliant. We now will probably have to enter the Python world, as there will be probably more options - or tell them what is missing for a Starter Forth so they can add it - more extension with the next update ...

[Mark Wills]

There's no point. Python is *insanely* easy, and all the libraries
for handling the hardware will already be there. Might as well just
use them and enjoy yourself.

[Raimond Dragomir]

Is the python resident (micropython) or is it cross-compiling?

[Julian Fondren]

On Wednesday, April 6, 2016 at 8:10:31 AM UTC-5, Mark Wills wrote:
> There's no point.

Forth is the point. If you'd rather use it, personally, then
why not share why you would with other people?

> Python is *insanely* easy,

Python's easiness is a meme. Guido worked on teaching
languages. He did some research on teaching languages (case
insensitive is better; integer / is bad -- a lot of advice that
Python itself ignores). He had ideals of Python being a
teaching language. So Python's become a teaching language,
because people bought into the meme and produced the materials
and put it before kids. Good for them. And since Python isn't
without redeeming qualities, OK for the kids. It's better than
BASIC. And COBOL. And RPG. And Fortran. And esoteric
minimal languages. And languages that don't have
implementations or documentation anymore. OK, I think that's
close to an exhaustive list of languages Python isn't grossly
inferior to. For teaching purposes it's also better than any
language where compilation takes much time, or that can't be
interactive.

Guido is a terrible language designer, and Python has continued
to stray from his original goals. It didn't even have +=
because he thought additional operators were confusing. Now it
has += and similar. Now it also has list comprehensions, and
decorators (@word_() is an example in my previous post) and
generators and all kinds of crap. It's a language of broken
concepts because Guido didn't like or didn't understand or
couldn't implement them (lambdas, lexical variables) and new
flashy concepts that don't fit with the language, don't add any
capabilities to the language, and are harder to work with than
their counterparts in very similar languages (list
comprehensions, generators, decorators).

The pain of the 2/3 version split in the community is purely
due to stupid and ugly decisions and then Guido not being able
to escape them without breaking them. With other languages the
stupid decisions hang around forever but just get ignored, and
your old code still works.

If you want a teaching language that's not Forth, it should be
JavaScript. Its warts are too ignoreable, its core language is
too clean (it's not "X is an '''acceptable lisp''' lol"; it's
"Brendan Eich wanted Scheme but couldn't sell Scheme's
syntax"), object literals are too good (just look from them to
Python's objects, fast, and try to keep your gorge down), and
the browser is too prominent for you to use anything else.


-- Julian

[JUERGEN]

I do disagree - either via the PC or the Mobile or a cheap display and a keyboard. I want to have Forth on the MicroBit - if this is not for you - fine.

[JUERGEN]

I forget about Python for now- why learn another one? And I had a go and gave up. A little typo and you find out after compilation - so a NO for me - and there has to be an agreed target so opinions make sense. Mine is to have Forth available on the MicroBit - Mecrisp - VFX , but alternatively the Python based Forth as Application is an interesting play alternative - probably not for 98% of the people here - but they are not the target anyway - I was asking for help.

[Raimond Dragomir]

> > There's no point. Python is *insanely* easy, and all the libraries
> > for handling the hardware will already be there. Might as well just
> > use them and enjoy yourself.
>

I don't know where it comes this idea from - the python is easy.
It's a high level language that hides A LOT of complexity.
Given that fact, some complex things are easy. But do we want
to teach kids that some hard things are easy? This is just a lie
in their face.
I would teach kids simple things that are simple things. Forth
is good at that. This way the kids will get a grasp of what things
are easy and what not.

Also, their site is tiresome after 5mins (to me). Too much advertising.
They probably want to bind million of kids to their site. Ugly.
Forth will be much independent.

[Raimond Dragomir]

Is the hardware open? Do we know the schematic, the parts etc?
How can the cpu be programmed?
Is there a BLE stack that should be compiled with an application or is it
a library or something?
Many questions to be answered...

[JUERGEN]

On Wednesday, April 6, 2016 at 11:48:41 AM UTC+1, Albert van der Horst wrote:

Software is at the entry point https://www.microbit.co.uk/ SOFTWARE and different languages, and soory to be a bit sarcastic - you are probably completely right, and we all have our Forth Computers on our desk running Forth instructions rather than machine code and this running on a 2048 core Greenarray chip - we wish. Learning starts at 0 in electronics - forget about Linux for beginners - or was this the first thing your children learnt? Please share your positive experience.

[JUERGEN]

Completly agreed - a few lines of interactive Forth and the LED is on - more complex stuff comes later. In many cases complexity is hidden nowadays - so you do not really understand what is happening.
For this reason we started MicroBox : 1 chip, 1 resistor, 1 connector to the USBtoTTL, 1 PCB - and you start programming in Forth - add some LEDs and switches and start controlling them. Just needs an 8 Bit Port on the MSP430G2553. I want the same entry pacckage for the MicroBit.

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> is there a Forth out there in Python I could load and run? Speed is
> not the issue for now nor is completeness. I mainly want to control
> the IOs, and the 25 LEDs are just enough to display ok, or a 4 Bit
> INPUT value, a 4 bit OUTPUT value - and 3 levels of Stack ...

This doesn't sound so easy unless you're willing to hack a little bit of
Python code. You can find "Forth in Python" with a web search (Julian
did that), but:

1) the Microbit uses a very small (but nice) alternative Python
implementation called MicroPython while most existing Python programs
use the full size Python (CPython). MicroPython is a mostly-compatible
version of the language but it's missing a lot of the libraries CPython
comes with, and that might make it hard to get Forth working.

2) You want to control the Microbit hardware from Forth, and any Forth
in Python intended for PC's isn't likely to have those Microbit-specific
commands. So you'll have to add them.

3) The Microbit has so little memory that it's surprising they got even
MicroPython to run on it at all. MicroPython originally was released
for a chip with around 192kb of ram. The Microbit might only be able to
run quite small Python programs, not a full featured Forth interpreter.

Why not take the opportunity to play with Python a little? Then you'll
have a better understanding of how the two approaches compare.

The quickest way to get Forth running on the Microbit might be using
one of the many small Forths based on C, since I think the Microbit
setup has a C compiler.

[rickman]

Mecrisp is easy (relatively speaking) to port to any ARM.

--

Rick

[JUERGEN]

It seems the idea was good - but the hardware is against it

[visua...@rocketmail.com]

Why using Python to create Forth?

The MicroBIT covers Touch Develop, Python and JavaScript, so why not Forth?

The whole thing looks like a closed community, but there is an installation section which needs git and yotta, so I guess that Forth will be installable, to: http://microbit-micropython.readthedocs.org/en/latest/devguide/installation.html

By the way, there is a Block Editor available:
https://www.microbit.co.uk/getting-started/block-editor
Courtesy of Microsoft.
Just kidding.

[hughag...@gmail.com]

On Wednesday, April 6, 2016 at 8:13:03 AM UTC-7, Raimond Dragomir wrote:
> > > There's no point. Python is *insanely* easy, and all the libraries
> > > for handling the hardware will already be there. Might as well just
> > > use them and enjoy yourself.
> >
> I don't know where it comes this idea from - the python is easy.
> It's a high level language that hides A LOT of complexity.
> Given that fact, some complex things are easy. But do we want
> to teach kids that some hard things are easy? This is just a lie
> in their face.
> I would teach kids simple things that are simple things. Forth
> is good at that. This way the kids will get a grasp of what things
> are easy and what not.

A lot of Python programming involves people who know very little about programming writing scripts around code-libraries that are written in C (presumably by somebody who does know how to program). This is my understanding of Python anyway --- I don't program in Python.

What do "we" want to teach kids? Well, it is the parent's responsibility to decide what they want their kids to learn. As a practical matter, there are jobs available in Python but not in Forth, and most parents want their kids to be employable.

Personally, I enjoy programming that solves problems. The problems don't have to be practical either. For example, I have LowDraw.4th in the novice package. Calculating the probabilities of Low-Draw poker is not very practical (nobody plays the game anymore, not even in Gardenia CA). I enjoyed writing the program though. The program does a recursive-descent traversal over every possible Low-Draw hand --- realistically, Python would be too slow even given today's powerful computers --- this isn't what Python is all about.

[rickman]

The Microbit has a standard ARM MCU and a number of standard peripherals
which will have some sort of library code available to drive them.
There is no reason to think a special library or development system is
needed to program this board. Any compiler for any language that
supports the MCU will work on the Microbit.

--

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> The Microbit has a standard ARM MCU and a number of standard
> peripherals which will have some sort of library code available to
> drive them. There is no reason to think a special library or
> development system is needed to program this board. Any compiler for
> any language that supports the MCU will work on the Microbit.

There are some GPIO pins that control the LEDs (there's a 5x5 LED
array), but if you want to do stuff like display scrolling text messages
on them, you need Microbit-specific libraries or else you have to write
a lot of code yourself. The MicroBit's Python implementation has some
convenient library functions for that and if you wanted to port an
existing Python Forth to the MicroBit Python, you'd want to do some
hacking to expose those functions to the Forth user.

[Mark Wills]

I'm all for a Forth on the MicroBit - why not? I just meant there's
no point in getting a Forth-in-python running just to control the
I/Os and LEDs as you mentioned in your first post. Might as well just
just use Python for that and have some fun!

But getting a Forth on it? Sure, why not. Then we can have some
proper fun ;-)

[Albert van der Horst]

Mark Wills <markwi...@gmail.com> writes:

>On Wednesday, 6 April 2016 15:55:32 UTC+1, JUERGEN wrote:
>> On Wednesday, April 6, 2016 at 2:10:31 PM UTC+1, Mark Wills wrote:
>> > On Wednesday, 6 April 2016 10:32:26 UTC+1, JUERGEN wrote:

>> > > On Wednesday, April 6, 2016 at 10:13:42 AM UTC+1, Martin Nicholas wro=

>te:
>> > > > On Wed, 6 Apr 2016 00:14:41 -0700 (PDT)
>> > > > JUERGEN <epld...@aol.com> wrote:

>> > > >=20
>> > > > > A MicroBit has arrived on my desk, but no Forth yet available. Un=
>til
>> > > > > a real Forth is running, and as Python is a supported language - =
>is
>> > > > > there a Forth out there in Python I could load and run? Speed is =
>not
>> > > > > the issue for now nor is completeness. I mainly want to control t=
>he
>> > > > > IOs, and the 25 LEDs are just enough to display ok, or a 4 Bit IN=

>PUT
>> > > > > value, a 4 bit OUTPUT value - and 3 levels of Stack ... Any help

>> > > > > appreciated. http://microbit-micropython.readthedocs.org/en/lates=

>t/.
>> > > > > Picture and video you can find at

>> > > > > https://www.facebook.com/groups/PROGRAMMINGFORTH/?fref=3Dts. Has

>> > > > > anybody re-written JonesForth in Python?

>> > > >=20

>> > > > It's a 32-bit ARM Cortex Processor (Cortex M0):
>> > > > http://www.bbc.co.uk/mediacentre/mediapacks/microbit/specs
>> > > > so a FORTH for this shouldn't be too elusive.

>> > > >=20
>> > > > --=20
>> > > > Regards,
>> > > >=20
>> > > > Martin Nicholas.
>> > > >=20
>> > > > E-mail: reply-...@mgn.org.uk
>> > >=20
>> > > There might be a misunderstanding: There will be Forths running on th=
>e MicroBit - BUT this means that the original software has to be replaced =
>or at least partially. The idea here was to use the existing Python Program=
>ming Environment to have a small Forth running as an Application - leaving =
>everything else as is.
>> >=20

>> > There's no point. Python is *insanely* easy, and all the libraries
>> > for handling the hardware will already be there. Might as well just
>> > use them and enjoy yourself.

>>=20
>> I do disagree - either via the PC or the Mobile or a cheap display and a =
>keyboard. I want to have Forth on the MicroBit - if this is not for you - f=

>ine.

>I'm all for a Forth on the MicroBit - why not? I just meant there's
>no point in getting a Forth-in-python running just to control the
>I/Os and LEDs as you mentioned in your first post. Might as well just
>just use Python for that and have some fun!

>But getting a Forth on it? Sure, why not. Then we can have some
>proper fun ;-)

The first thing to know is whether the Forth -compiler must be
an ELF format or (MS) .com format. The other possibility is that the whole
Microbit is in fact one single turnkey program, with a built in
interpreter for Python.
It took me more than 5 minutes to not find that information on the
Microbit website, which warrants the conclusion that it is a
programmer-hostile environment.

An environment like ARM-android accepts ELF files. There is a gforth
ELF-arm, and shortly there will be ciforth-ELF-arm. (The last hurdle
was compiling turnkeys to executable files.)

[JUERGEN]

Others have found it difficult as well to find information.
What we all have to realize is the fact that this website is mostly for children;
but as this is a interesting product - there will be more as soon as people get their hands on it. Just remember, this is not a product sold on the open market yet. I am just lucky to have access - and know Forth a bit and would like to have Forth run on this hardware.

[Gerard Sontag]

Le jeudi 7 avril 2016 11:30:00 UTC+2, Albert van der Horst a écrit :
> .........

> It took me more than 5 minutes to not find that information on the
> Microbit website, which warrants the conclusion that it is a
> programmer-hostile environment.

>........

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

Hello,
Not sure what you really mean but...
You can use the mbed environment to program it: https://developer.mbed.org/platforms/Microbit/
Keil uvision lite (with 32k limit). Yes it's free of charge not free software
Gcc, and surely a lot of other tools
As soon as you can get a .bin file you can flash it using the drag & drop facility offered by the CMIS-DAP thru the Freescale KL26Z

Gérard

[rickman]

On 4/7/2016 5:29 AM, Albert van der Horst wrote:
>
> Groetjes Albert

Lol, shows how truly observant I am. I'm not very good with names, but
I do recognize Albert van der Horst. However, I never noticed that your
messages were signed Groetjes Albert. When I read that I thought it was
the name of someone else... I just googled groetjes and found its
meaning... lol

I may be slow, but I get there eventually. So be patient with me. :)

--

Rick

[rickman]

On 4/7/2016 6:27 AM, JUERGEN wrote:
>
> Others have found it difficult as well to find information.
> What we all have to realize is the fact that this website is mostly for children;
> but as this is a interesting product - there will be more as soon as people get their hands on it. Just remember, this is not a product sold on the open market yet. I am just lucky to have access - and know Forth a bit and would like to have Forth run on this hardware.

Another issue is that when the Microbit *is* brought to market no one
knows what price it will have. If they charge $25 for it, I think it
will *not* be well received.

It looks to me like it will be some significant time before they are
available to the public anyway... unless someone produces a clone board.

--

Rick

[hughag...@gmail.com]

On Thursday, April 7, 2016 at 1:27:25 AM UTC-7, Mark Wills wrote:
> I'm all for a Forth on the MicroBit - why not? I just meant there's
> no point in getting a Forth-in-python running just to control the
> I/Os and LEDs as you mentioned in your first post. Might as well just
> just use Python for that and have some fun!
>
> But getting a Forth on it? Sure, why not. Then we can have some
> proper fun ;-)

It would be pointless to write a Forth interpreter in Python, which is why I compared Juergen's idea to Passaniti's Forth in Perl, as Passaniti was the Prince of Pointless. Obviously, Forth should be written in assembly-language!

At Testra I asked why they never made an experimenters' board for the MiniForth/RACE and I was told: "Hobbyists require too much support, and they don't have any money."

This MicroBit is intended to be given away for free to junior-high-school kids. They provided Python rather than Forth because they wanted to minimize the amount of support that they needed to provide. Python is actually a terrible choice for a micro-controller --- Python was designed to be a scripting language on desktop-computers --- it is only provided on the MicroBit to be a safe environment.

It would be pretty humorous though if everybody who got the free board ignored Python and used Forth instead --- if they do this, then they won't get any support --- but they might learn something!

Education is theoretically supposed to be about figuring things out for yourself, although in practice the teachers will do everything in their power to prevent this from happening --- the parents won't be enthusiastic about this either, as they will point out that there are jobs available in Python but not in Forth --- but kids traditionally ignore their teachers and parents and just do whatever seems to be the most fun, which in this case would be Forth.

[JUERGEN]

There are lot of programmers in Python now
- just saying Forth is best has unfortunately not worked until now.
- So a way would be to give them a Forth implementation in the language they know , where they can look at the source code they can understand to run on the MicroBit; or another device if the code is available.
- and native Forth versions will follow when ready.
But then they would have to start from scratch again. Would they ?

This is NOT a closed community - it is made for school children and the target is 1 million of them - not a product you can buy now. so a nice and large target community for Forth.
I assume within 6 months MicroBits will appear on eBay.

[Mark Wills]

Forth isn't the best, unfortunately. I'm a great a fan of Forth, but
its hey-day is long behind it.

It's a good language to learn in order to learn about the hardware
that your code is running on, but there's not even a standard, simple
way to open a serial port in Forth, and the serial port has been
obsolete for, what ten, maybe fifteen years?

[Andrew Haley]

Mark Wills <markwi...@gmail.com> wrote:
>
> It's a good language to learn in order to learn about the hardware
> that your code is running on, but there's not even a standard,
> simple way to open a serial port in Forth, and the serial port has
> been obsolete for, what ten, maybe fifteen years?

In what language is there a standard way to open a serial port?

Andrew.

[Ron Aaron]

There is in 8th: sio:open

You don't even need to know the name of the port. You could just do
this to open the first port:

sio:enum a:shift sio:open

(assuming that there is at least one port)

[Raimond Dragomir]

Working in embedded systems for 20 years, still using uarts all over
the place. I have very few designs that don't need at least one...

[Andrew Haley]

OK, I shoulda asked in what standardized language is there a standard
way to open a serial port? :-)

Andrew.

[Ron Aaron]

On 19/04/2016 13:15, Andrew Haley wrote:

> OK, I shoulda asked in what standardized language is there a standard
> way to open a serial port? :-)

Ah, well that's a different question :)

[rickman]

I thought you could use the same commands as opening a file? Isn't that
the way it works in C? Or are you saying that the different names used
under different OS makes it not standard?

--

Rick

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> There are lot of programmers in Python now
> - just saying Forth is best has unfortunately not worked until now.
> - So a way would be to give them a Forth implementation in the
> language they know , where they can look at the source code they can
> understand to run on the MicroBit; or another device if the code is
> available.

There's a Forth in Javascript if that's of any interest:

http://home.diphi.com/users/jeffr/forth/jsforth.html

[Andrew Haley]

No, that's not the way it works in C. It's the way it works in UNIX,
for sure, but in C we don't know that the serial port is accessed as a
file and we certainly don't know how to do simple things like setting
the baud rate. If the serial port is a file then Forth can open it as
a file just like any other programming language.

Andrew.

[minf...@arcor.de]

>
> No, that's not the way it works in C. It's the way it works in UNIX,
> for sure, but in C we don't know that the serial port is accessed as a
> file and we certainly don't know how to do simple things like setting
> the baud rate. If the serial port is a file then Forth can open it as
> a file just like any other programming language.
>
> Andrew.

Correct. However many C compilers offer a _nonstandard_ library
conio.h with _inp/_outp functions to read/write ports.

[Bernd Paysan]

Am Wed, 20 Apr 2016 04:35:08 -0700 schrieb minforth:
> Correct. However many C compilers offer a _nonstandard_ library conio.h
> with _inp/_outp functions to read/write ports.

Oh, _inp/_outp is very DOS-related...

Most Forth systems that have access to serial ports have ways to access
the serial port in a pretty simple way; usually, you can open it by name,
and set the baud rate; the rest is usually set reasonable (8N1).

If I look at how much effort it is to set a serial port in Unix, it is
way more complicated: Not only is it setting the baud rate, but you also
need to set the serial tty into a "raw" mode, where it doesn't send
signals, doesn't convert characters into other characters and so on;
things you may need if the serial port is a terminal attached to an old
Unix computer, but completely unrelated to using a serial port to an
embedded device, where the PC is the terminal.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[visua...@rocketmail.com]

On Monday, April 18, 2016 at 4:21:02 PM UTC-4, Mark Wills wrote:
>
> It's a good language to learn in order to learn about the hardware
> that your code is running on, but there's not even a standard, simple
> way to open a serial port in Forth, and the serial port has been
> obsolete for, what ten, maybe fifteen years?

Using a standard Forth like 4e4th, you don't need to open the serial port.
It is opened automatically with power up, because it is needed to communicate with the Forth system on chip. The serial port never will be obsolete, because it is the easiest way to communicate. It only needs three connections: RX, TX, and GND. Doesn't matter if you use USB, RS232, or any other serial connection.

If you need more than one communication connection, it is always hardware dependent and depending on the vendor support. With redirecting emit and key other communication connections are easy to use. No special commands needed.

Cheers,
Dirk.

[minf...@arcor.de]

Am Mittwoch, 20. April 2016 23:14:51 UTC+2 schrieb Bernd Paysan:
> Am Wed, 20 Apr 2016 04:35:08 -0700 schrieb minforth:
> > Correct. However many C compilers offer a _nonstandard_ library conio.h
> > with _inp/_outp functions to read/write ports.
>
> Oh, _inp/_outp is very DOS-related...
>
> Most Forth systems that have access to serial ports have ways to access
> the serial port in a pretty simple way; usually, you can open it by name,
> and set the baud rate; the rest is usually set reasonable (8N1).
>
> If I look at how much effort it is to set a serial port in Unix, it is
> way more complicated: Not only is it setting the baud rate, but you also
> need to set the serial tty into a "raw" mode, where it doesn't send
> signals, doesn't convert characters into other characters and so on;
> things you may need if the serial port is a terminal attached to an old
> Unix computer, but completely unrelated to using a serial port to an
> embedded device, where the PC is the terminal.
>

Yes, you're right. And in microcontrollers, memory mapped I/O is very common. So there just is no golden way to circumvent the bare metal.

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
> Am Wed, 20 Apr 2016 04:35:08 -0700 schrieb minforth:
>> Correct. However many C compilers offer a _nonstandard_ library conio.h
>> with _inp/_outp functions to read/write ports.
>
> Oh, _inp/_outp is very DOS-related...
>
> Most Forth systems that have access to serial ports have ways to
> access the serial port in a pretty simple way; usually, you can open
> it by name, and set the baud rate; the rest is usually set
> reasonable (8N1).

That's right. The early Forth way to do it (from Chuck Moore's Forth,
Inc. days on) was to have a task per serial port. That task's TYPE
and EXPECT (and also STRAIGHT, for raw I/O) use its serial port. You
don't need non- blocking I/O or anything like that because the task
can handle it asynchronously, and the task can be tiny. If you need
to send a message to something connected to that serial port, ask the
task to do it. The idea of "opening" a serial port didn't really
arise.

It was a completely different way to think about communications ports
than what I was used to, and it took me some time to get the hang of
it. But after a while I came to love the approach: it is a powerful
and radically simple way to write applications which use multiple
communications ports. Today the idea of structuring an application so
that it has a lot of asynchronous processes communicating through
mailboxes or queues is quite commonplace, but it was a revelation to
me.

Andrew.

[JUERGEN]

I think I can close the loop here now. Matthias was a lot faster than I had expected and finished a Mecrisp Forth for the MicroBit; all is where you normally find Mecrisp - switch on your PC running Linux throw the hex into the microBit folder, start your terminal at 115200 and Paul and I saw yesterday the OK and Words. Enough to check. Thanks Matthias. https://sourceforge.net/projects/mecrisp/ Released /Target literature package for Microbit.tar.gz

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>That's right. The early Forth way to do it (from Chuck Moore's Forth,
>Inc. days on) was to have a task per serial port. That task's TYPE
>and EXPECT (and also STRAIGHT, for raw I/O) use its serial port. You
>don't need non- blocking I/O or anything like that because the task
>can handle it asynchronously, and the task can be tiny.

How does full duplex work with that? Do you have one task for reading
from the port and one task for writing to it? That would be two tasks
per port, then.

Certainly an interesting design, and it reminds me of the current
practice in the Linux kernel to have kernel threads in similar cases
where one would otherwise have to introduce asynchronous (non-blocking
etc.) interfaces.

So how did one communicate with these tasks? Was this really simpler
than an asynchronous interface? I can imagine that it's more
powerful, though; e.g., the task can buffer input if needed, or not,
if not.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> How does full duplex work with that? Do you have one task for reading
> from the port and one task for writing to it? That would be two tasks

> per port, then.... Certainly an interesting design

I never programmed multitasking Forth but two threads (or processes) per
port is a very typical way to do these things in other systems.

> So how did one communicate with these tasks? Was this really simpler
> than an asynchronous interface?

With mailboxes. There's an article by Brad Rodriguez about it and the
interface is similar to how it's done in Go, Python, Erlang, etc.
Whether it's simpler than async is yet another of those dreary
opinionated topics with proponents on both sides. I myself find it
simpler. Most Python users prefer async so I'm in the minority (Python
supports both styles). In Go, Erlang, and Haskell, multiple lightweight
processes/threads/"goroutines" are the norm.

Python users may be thread-averse because Python uses OS threads which
are fairly expensive. Java also usually uses OS threads and for a long
time had no way to do async at all, but (true to form for Java) people
didn't care how expensive it was until they had to.

[Elizabeth D. Rather]

On 4/24/16 5:45 AM, Anton Ertl wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> That's right. The early Forth way to do it (from Chuck Moore's Forth,
>> Inc. days on) was to have a task per serial port. That task's TYPE
>> and EXPECT (and also STRAIGHT, for raw I/O) use its serial port. You
>> don't need non- blocking I/O or anything like that because the task
>> can handle it asynchronously, and the task can be tiny.
>
> How does full duplex work with that? Do you have one task for reading
> from the port and one task for writing to it? That would be two tasks
> per port, then.

No. The serial port is the task's "terminal". A task has a current input
device and a current output device, and the serial port normally
fulfills both functions.

> Certainly an interesting design, and it reminds me of the current
> practice in the Linux kernel to have kernel threads in similar cases
> where one would otherwise have to introduce asynchronous (non-blocking
> etc.) interfaces.
>
> So how did one communicate with these tasks? Was this really simpler
> than an asynchronous interface? I can imagine that it's more
> powerful, though; e.g., the task can buffer input if needed, or not,
> if not.

There are various ways. The intended design was that each task had a
semi-autonomous job description, analogous to an employee in a business.
There were variables and other data structures in shared memory that
could be used for inter-task communication. Also, one task can assign
another a function by a mechanism that equated to pushing the address of
a definition onto its return stack. There was also a mechanism, usually
used for printer tasks, wherein a human user could type PRINT followed
by one or more commands in the input stream and the input stream
following the word PRINT was moved to the printer's input stream and it
would interpret it.

Much of this, including design guidelines, is discussed in the
multitasker sections of Forth Application Techniques and other books.

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

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:
>On 4/24/16 5:45 AM, Anton Ertl wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>> That's right. The early Forth way to do it (from Chuck Moore's Forth,
>>> Inc. days on) was to have a task per serial port. That task's TYPE
>>> and EXPECT (and also STRAIGHT, for raw I/O) use its serial port. You
>>> don't need non- blocking I/O or anything like that because the task
>>> can handle it asynchronously, and the task can be tiny.
>>
>> How does full duplex work with that? Do you have one task for reading
>> from the port and one task for writing to it? That would be two tasks
>> per port, then.
>
>No. The serial port is the task's "terminal". A task has a current input
>device and a current output device, and the serial port normally
>fulfills both functions.

But then I don't see how "you don't need non-blocking I/O" works.

E.g., the task EMITs to the serial port and that blocks because the
other side is not ready; meanwhile, input is coming on the serial
port. After the hardware buffers are full, data will be lost.

Or, the task KEYs from the serial port and waits for input; meanwhile,
some other task C wants to tell the serial-port task to send
something, and then something more. But the serial-port task is
blocked and not reacting to the message, so at some point it's mailbox
is full, and C has to decide whether it wants to overwrite the stuff
in the mail box, or block itself.

Anyway, certainly not a full duplex connection.

[Elizabeth D. Rather]

The design of a task is an integral aspect of the application. A task
isn't just the owner of a port, it has a larger responsibility than
that. A simple case (the original model) is a task supporting a human
user who types on the keyboard and sees stuff on the screen. A data
acquisition task is acquiring data on the port and storing it somewhere,
possibly performing operations (validation, scaling, etc.) along the
way. A port would not normally be shared; in the case of a printer, it
would block while generating and printing a document at the request of
another task, but in most applications it is not necessary or
appropriate to treat a port as a resource in that sense.

[Andrew Haley]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>That's right. The early Forth way to do it (from Chuck Moore's Forth,
>>Inc. days on) was to have a task per serial port. That task's TYPE
>>and EXPECT (and also STRAIGHT, for raw I/O) use its serial port. You
>>don't need non- blocking I/O or anything like that because the task
>>can handle it asynchronously, and the task can be tiny.
>
> How does full duplex work with that? Do you have one task for reading
> from the port and one task for writing to it? That would be two tasks
> per port, then.

I have never seen separate tasks for send and receive. But you're
quite right, it doesn't work with full duplex. If you want that, you
have to do something different. (This is a case of the more general
rule which is not to over-generalize solutions: just do the simple
thing that you need.) Having said that, there is a race between
sending a packet and starting the recieve, so it is sometimes
necessary to have a version of TYPE which takes the address of a
receive buffer as well as a transmit buffer so that nothing gets lost.

> Certainly an interesting design, and it reminds me of the current
> practice in the Linux kernel to have kernel threads in similar cases
> where one would otherwise have to introduce asynchronous
> (non-blocking etc.) interfaces.

I think that's essentially the same idea.

> So how did one communicate with these tasks? Was this really
> simpler than an asynchronous interface? I can imagine that it's
> more powerful, though; e.g., the task can buffer input if needed, or
> not, if not.

The task handles the entire communications protocol and might even do
database updates as well. The way to communicate with these tasks is
entirely application-dependent. At its very simplest you'd write:

: poll taskname activate do-some-stuff ;

Andrew.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> I have never seen separate tasks for send and receive. But you're
> quite right, it doesn't work with full duplex.

Interesting, wonder why they did it that way, given how lightweight
Forth tasks are.

> If you want that, you have to do something different. (This is a case
> of the more general rule which is not to over-generalize solutions:
> just do the simple thing that you need.)

I think it's simpler to use two tasks than use extra logic to keep track
of which way the port is going, swap directions, etc. I've always done
it with two (not in Forth yet though) and it's quite natural.

[Elizabeth D. Rather]

It really depends on how you think about what a "task" is. If you think
of a task as a "person" with a set of responsibilities (e.g., accepting
data from a device, processing it, and recording it) then you look at
how that port is being used. I can't think offhand of a case in which a
full-duplex port literally has concurrent streams of data flowing in and
out. Examples that come to mind are a port that may be doing continuous
output until an input signals that it should stop, or one that is
receiving data and sends a signal to stop when it has enough. Both these
examples make logical sense as the responsibility of a single task that
knows what it's doing. The actual reception or transmission of
individual events would be done in interrupt code. To actually set up
two tasks, even though these tasks are pretty lightweight, adds the
necessity for them to communicate in ways that complicate the process
considerably.

[Paul Rubin]

"Elizabeth D. Rather" <era...@forth.com> writes:

> It really depends on how you think about what a "task" is. If you
> think of a task as a "person" with a set of responsibilities (e.g.,
> accepting data from a device, processing it, and recording it) then
> you look at how that port is being used.

One person accepting data, one sending data, and one recording it,
maybe.

> I can't think offhand of a case in which a full-duplex port literally
> has concurrent streams of data flowing in and out.

That's the *definition* of a full-duplex port! ;-)

> Examples that come to mind are a port that may be doing continuous
> output until an input signals that it should stop, or one that is
> receiving data and sends a signal to stop when it has enough.

Think of a phone conversation where both people can talk at the same
time, or a rendezvous where two people each hand a suitcase full of
data to the other (simultaneous file transfers in both directions).

> To actually set up two tasks, even though these tasks are pretty
> lightweight, adds the necessity for them to communicate in ways that
> complicate the process considerably.

Shrug, I think it's more complicated to figure out how to juggle the
necessary stuff in one task. Doing it with 2 tasks is simple and
general and I've done it that way tons of times. I hear all kinds of
dire stories about locking and synchronization errors but none of that
has ever happened to me. The main simplifying principles are 1)
communicate between tasks only through mailboxes (never through shared
memory) and 2) any piece of mutable data should be owned by exactly one
task and only accessed (whether reading or writing) by that task. If
any other task something done with the data it can query the owning task
through a mailbox.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> I have never seen separate tasks for send and receive. But you're
>> quite right, it doesn't work with full duplex.
>
> Interesting, wonder why they did it that way, given how lightweight
> Forth tasks are.

Eh? There wouldn't be any point.

>> If you want that, you have to do something different. (This is a case
>> of the more general rule which is not to over-generalize solutions:
>> just do the simple thing that you need.)
>
> I think it's simpler to use two tasks than use extra logic to keep track
> of which way the port is going, swap directions, etc.

The task is either sending or receiving. I am unaware of any extra
logic.

> I've always done it with two (not in Forth yet though) and it's
> quite natural.

I don't understand this comment. In data acquisition and control,
it's perfectly normal to use half-duplex communication.

Andrew.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>> it doesn't work with full duplex.
>> Interesting, wonder why they did it that way

> Eh? There wouldn't be any point.

The point is that it doesn't work with full duplex. I wonder why they
chose a method with that limitation.

> I don't understand this comment. In data acquisition and control,
> it's perfectly normal to use half-duplex communication.

Maybe there's flow control, or typeahead, or whatever. Maybe if I know
the application only uses half-duplex, I can implement some hacky thing
that relies on that fact. But if I'm supplying a library facility it
wouldn't occur to me to limit it like that.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>>> it doesn't work with full duplex.
>>> Interesting, wonder why they did it that way
>> Eh? There wouldn't be any point.
>
> The point is that it doesn't work with full duplex. I wonder why they
> chose a method with that limitation.

Because it's the simple case. Because it's how data acquisition and
control protocols work. Because it's how multi-drop hardware works.

>> I don't understand this comment. In data acquisition and control,
>> it's perfectly normal to use half-duplex communication.
>
> Maybe there's flow control, or typeahead, or whatever.

No: what happens is that I/O is polled. The scanning teask sends a
request and waits for a reply. There's no need for typeahead or flow
control.

> Maybe if I know the application only uses half-duplex, I can
> implement some hacky thing that relies on that fact. But if I'm
> supplying a library facility it wouldn't occur to me to limit it
> like that.

I'm sure it wouldn't, because you don't really think in the Forth way.
Don't speculate!

Andrew.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> I'm sure it wouldn't, because you don't really think in the Forth way.
> Don't speculate!

The Forth way seems to be to speculate that full duplex is not needed.
I'd rather write something that works all the time, than write something
that only works if a speculative presumption happens to come true.

I wrote an application fairly recently that talked to a dozen or so
devices. I can't remember for sure how many were "really" full duplex
since I didn't care. I merely wrote a straightforward wrapper that
launched a pair of threads for each device and it handled everything
fine. It was almost the first thing I wrote in the program, before I
studied much what the individual devices were doing. That set down the
API that the later code would use.

Why would I worry my beautiful mind trying to analyze whether
bidirectional i/o would happen sometime later in the program
development? That would be premature optimization.

[Albert van der Horst]

On 2016-04-26, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
> Paul Rubin <no.e...@nospam.invalid> wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>> I have never seen separate tasks for send and receive. But you're
>>> quite right, it doesn't work with full duplex.
>>
>> Interesting, wonder why they did it that way, given how lightweight
>> Forth tasks are.
>
> Eh? There wouldn't be any point.
>
>>> If you want that, you have to do something different. (This is a case
>>> of the more general rule which is not to over-generalize solutions:
>>> just do the simple thing that you need.)
>>
>> I think it's simpler to use two tasks than use extra logic to keep track
>> of which way the port is going, swap directions, etc.
>
> The task is either sending or receiving. I am unaware of any extra
> logic.

Take my communication program with a Forth on the MSP430.
It send ``1 1 +'' then waits for OK. Then it can send the next
command. Seems half duplex.

It is not that simple. WORDS has facilities to interrupt it with
a KEY. Now you've your extra logic.
Under the hood an USB connection is full-duplex. Under that hood it
uses only one bit, that is switched between input and output,
so it must be half duplex.

>
>> I've always done it with two (not in Forth yet though) and it's
>> quite natural.
>
> I don't understand this comment. In data acquisition and control,
> it's perfectly normal to use half-duplex communication.

>
> Andrew.

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

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:

>I can't think offhand of a case in which a
>full-duplex port literally has concurrent streams of data flowing in and
>out.

The other end is a user terminal, and is busy typing out the answer to
the user's last request, while the user is already typing in the next
request (typeahead).

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> I'm sure it wouldn't, because you don't really think in the Forth way.
>> Don't speculate!
>
> The Forth way seems to be to speculate that full duplex is not needed.

You know for certain that it's not needed yet because you have a set
of already-complete applications that have not needed it. Of course
it might be needed in the future, but I remember what Forth Inc. said
to me a long time ago in a galaxy far, far away:

"We can not promise you that in every case a feature in our systems
will be exactly what you need, but we can promise you that we've
thought about it."

> I'd rather write something that works all the time, than write
> something that only works if a speculative presumption happens to
> come true.

It's not really a presumption at all: it's the result of writing
applications. Forth systems (the industrial and professional kind)
weren't just written and then thrown over the wall: they are the
result of many years of using them to write applications and feeding
back the result into the product.

> Why would I worry my beautiful mind trying to analyze whether
> bidirectional i/o would happen sometime later in the program
> development? That would be premature optimization.

Because you don't get clean and simple programs by piling in features
speculatively.

Are you really telling me that it's actually easier to create and use
multiple threads per device just in case they might be needed than to
say to yourself "I'll just do it half duplex for now. If that turns
out to be inadequate I'll do something more complex"? If you answer
"yes", I will say "I don't believe you." :-)

Andrew.

[foxaudio...@gmail.com]

I guess I am getting pretty old, but my understanding of the "Forth way" was to understand what was really needed and write to that requirement. (ie don't add un-needed features)

In my use of serial communication I tended to prioritize receiving since it was outside of my direct control in most applications. Many times it was coming from another machine that did not respect flow control in a timely manner. So call me crazy, but I wrote an ISR with a queue to be sure I caught all the input.

Transmitting was fully under my control so I was less concerned about that and made my routines react to flow control from the other end appropriately.

The Forth Multi-tasker handled running the serial I/O process as a single task, but was assisted on the receive side by the ISR.

Is that now considered wrong? Or is it just to hard to create ISRs in a modern OS?

BF

[Andrew Haley]

foxaudio...@gmail.com wrote:
>
> I guess I am getting pretty old, but my understanding of the "Forth
> way" was to understand what was really needed and write to that
> requirement. (ie don't add un-needed features)
>
> In my use of serial communication I tended to prioritize receiving
> since it was outside of my direct control in most applications. Many
> times it was coming from another machine that did not respect flow
> control in a timely manner. So call me crazy, but I wrote an ISR
> with a queue to be sure I caught all the input.

That's an intersting one. I did that a few times, but eventually gave
up because I found at the start of a request I'd always be flushing
the queue to get rid of any left-over input. Once I realized that, it
was much simpler to get rid of the queue and receive straight into the
buffer.

Andrew.

[Paul Rubin]

foxaudio...@gmail.com writes:
> The Forth Multi-tasker handled running the serial I/O process as a
> single task, but was assisted on the receive side by the ISR.
> Is that now considered wrong? Or is it just to hard to create ISRs in
> a modern OS?

Usually the OS handles ISRs itself and for old fashioned serial, there
would be a receive ISR getting stuff from the uart. In Unix/Linux, the
OS then hands off the data to your program through a file-like
interface. There is a facility for writing ISR-like code ("signal
handlers") at the user level, but they're not true ISRs connected to
hardware interrupts, and the overhead of calling one is non-trivial.
You wouldn't use them for high frequency events.

[Elizabeth D. Rather]

On 4/26/16 1:32 AM, Anton Ertl wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
>> I can't think offhand of a case in which a
>> full-duplex port literally has concurrent streams of data flowing in and
>> out.
>
> The other end is a user terminal, and is busy typing out the answer to
> the user's last request, while the user is already typing in the next
> request (typeahead).

How do you want your terminal to work? That's a design issue. You can
make the output interruptible or not. Most of the time, you'd want any
input to go in the TIB and wait, but a report that may be long may
include provision for being interrupted at each line.

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:
>On 4/26/16 1:32 AM, Anton Ertl wrote:
>> "Elizabeth D. Rather" <era...@forth.com> writes:
>>> I can't think offhand of a case in which a
>>> full-duplex port literally has concurrent streams of data flowing in and
>>> out.
>>
>> The other end is a user terminal, and is busy typing out the answer to
>> the user's last request, while the user is already typing in the next
>> request (typeahead).
>
>How do you want your terminal to work? That's a design issue. You can
>make the output interruptible or not. Most of the time, you'd want any
>input to go in the TIB and wait, but a report that may be long may
>include provision for being interrupted at each line.

In Unix I can interrupt with Ctrl-C, or stop the output with Ctrl-S
(and continue with Ctrl-Q), and all the non-control characters are
saved as typeahead (well, that's the usual behaviour, and it's
configurable in various ways), all without the application having to
deal with any of that.

Of course, these days, the output is so fast that I use a 5000-line
scroll-back-buffer to make use of that; other people pipe the output
into more/less to deal with that problem. But with a terminal on a
serial line, the speed would be less of a problem.

- 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 2016: http://www.euroforth.org/ef16/

[Elizabeth D. Rather]

On 4/26/16 9:20 AM, Anton Ertl wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
>> On 4/26/16 1:32 AM, Anton Ertl wrote:
>>> "Elizabeth D. Rather" <era...@forth.com> writes:
>>>> I can't think offhand of a case in which a
>>>> full-duplex port literally has concurrent streams of data flowing in and
>>>> out.
>>>
>>> The other end is a user terminal, and is busy typing out the answer to
>>> the user's last request, while the user is already typing in the next
>>> request (typeahead).
>>
>> How do you want your terminal to work? That's a design issue. You can
>> make the output interruptible or not. Most of the time, you'd want any
>> input to go in the TIB and wait, but a report that may be long may
>> include provision for being interrupted at each line.
>
> In Unix I can interrupt with Ctrl-C, or stop the output with Ctrl-S
> (and continue with Ctrl-Q), and all the non-control characters are
> saved as typeahead (well, that's the usual behaviour, and it's
> configurable in various ways), all without the application having to
> deal with any of that.

Yes, our standard keyboard drivers are much the same. Ctrl-C, etc., are
handled at the interrupt level. Applications may have additional needs.

> Of course, these days, the output is so fast that I use a 5000-line
> scroll-back-buffer to make use of that; other people pipe the output
> into more/less to deal with that problem. But with a terminal on a
> serial line, the speed would be less of a problem.

Right.

[hughag...@gmail.com]

On Monday, April 25, 2016 at 5:07:26 PM UTC-7, Elizabeth D. Rather wrote:
> I can't think offhand of a case in which a
> full-duplex port literally has concurrent streams of data flowing in and
> out.

I would expect any first-year programmer to be familiar with the concept of asynchronous data-flow --- Elizabeth Rather can be ignored; she is not a programmer at all.

This is the same person who has repeatedly spoken out against general-purpose software. She said: "...in Forth it's so easy to build data structures that are exactly right for the particular application at hand that worrying about what pre-built structures you have and how to use them is just not worth the bother." In this quote, if you substitute the words "I/O drivers" for "data structures" then you have her current argument.

Realistically, a driver for a full-duplex port should be implemented to be full-duplex --- it is premature optimization to implement it as half-duplex because the current application program only needs a half-duplex port --- if you implement it as full-duplex then it will be general-purpose code that can be used in any program in the future (including the current application program that you may discover later on actually does need full-duplex).

The big problem with Elizabeth Rather is not her ignorance, but rather her desire to ban everything that she doesn't understand. For example, D/ was not put in the ANS-Forth standard because E.R. couldn't think offhand of a case in which it was needed (besides that, nobody at Forth Inc. could figure out how to write a division function if they weren't provided with a hardware division instruction of the needed size).

[Albert van der Horst]

On 2016-04-26, Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
>>On 4/26/16 1:32 AM, Anton Ertl wrote:
>>> "Elizabeth D. Rather" <era...@forth.com> writes:
>>>> I can't think offhand of a case in which a
>>>> full-duplex port literally has concurrent streams of data flowing in and
>>>> out.
>>>
>>> The other end is a user terminal, and is busy typing out the answer to
>>> the user's last request, while the user is already typing in the next
>>> request (typeahead).
>>
>>How do you want your terminal to work? That's a design issue. You can
>>make the output interruptible or not. Most of the time, you'd want any
>>input to go in the TIB and wait, but a report that may be long may
>>include provision for being interrupted at each line.
>
> In Unix I can interrupt with Ctrl-C, or stop the output with Ctrl-S
> (and continue with Ctrl-Q), and all the non-control characters are
> saved as typeahead (well, that's the usual behaviour, and it's
> configurable in various ways), all without the application having to
> deal with any of that.
>
> Of course, these days, the output is so fast that I use a 5000-line
> scroll-back-buffer to make use of that; other people pipe the output
> into more/less to deal with that problem. But with a terminal on a
> serial line, the speed would be less of a problem.

Or just show what is most important. I've changed my Forth to
a WORDS that shows most recent words last. It is 90% as good
as Marcel Hendrix solution that requires an amount of code that
equals my whole Forth. ;-)
In rare case I scroll back. I use a 10,000 line buffer I think,
but most of the time it is not enough anyway. So there are a lot
of Gigabyte test files in my euler directory.

>
> - anton

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> You know for certain that it's not needed yet because you have a set
> of already-complete applications that have not needed it.

Of course full duplex was (sometimes) needed even in the early days of
Forth. People paid good money for full-duplex terminals and modems for
the precise reason that they wanted to use both directions at once.

> "We can not promise you that in every case a feature in our systems
> will be exactly what you need, but we can promise you that we've
> thought about it."

I guess I still don't understand what was really saved by limiting it to
half duplex. The application I mentioned earlier that I coded to handle
full duplex: I don't know if it even used the full duplex. Being able
to handle full duplex from the beginning meant one less thing I had to
think about while writing the rest of the application.

> Are you really telling me that it's actually easier to create and use
> multiple threads per device just in case they might be needed than to
> say to yourself "I'll just do it half duplex for now. If that turns
> out to be inadequate I'll do something more complex"? If you answer
> "yes", I will say "I don't believe you." :-)

It never occurred to me to do it half-duplex-only so I can only
speculate on whether it would have been simpler. I can say that I had a
general API where you'd say "open a new channel" and it would launch two
threads, set up named mailboxes, etc. The two threads were very simple,
something like:

def transmit(mailbox, port):
while True:
read data (blocking) from mailbox
write data (blocking) to port

def receive(mailbox, port):
while True:
read data (blocking) from port
write data (generally non-blocking) to mailbox

That's sort of like factoring in Forth, I would have thought. Separate
out the two functions instead of trying to combine them into one more
complicated thing.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> You know for certain that it's not needed yet because you have a set
>> of already-complete applications that have not needed it.
>
> Of course full duplex was (sometimes) needed even in the early days of
> Forth. People paid good money for full-duplex terminals and modems for
> the precise reason that they wanted to use both directions at once.

Perhaps, but I didn't say that nobody in the wrold had used
full-duplex: I said that most of the applications Forth was used for
hadn't needed it.

>> Are you really telling me that it's actually easier to create and use
>> multiple threads per device just in case they might be needed than to
>> say to yourself "I'll just do it half duplex for now. If that turns
>> out to be inadequate I'll do something more complex"? If you answer
>> "yes", I will say "I don't believe you." :-)
>
> It never occurred to me to do it half-duplex-only so I can only
> speculate on whether it would have been simpler. I can say that I
> had a general API where you'd say "open a new channel" and it would
> launch two threads, set up named mailboxes, etc. The two threads
> were very simple, something like:
>
> def transmit(mailbox, port):
> while True:
> read data (blocking) from mailbox
> write data (blocking) to port
>
> def receive(mailbox, port):
> while True:
> read data (blocking) from port
> write data (generally non-blocking) to mailbox
>
> That's sort of like factoring in Forth, I would have thought.
> Separate out the two functions instead of trying to combine them
> into one more complicated thing.

Okay, but that's not quite the factoring I'm talking about. These
threads correspond to what would be done the interrupt handlers on the
Forth system, and don't really do anything except (on the receive
side) queue data. The Forth systems I'm talking about receive data
straight into the buffers provided by the application, with no extra
queueing.

(And this is how it was possible to run a dozen interactive users on
an IBM PC/XT.)

There is also a fair bit of complexity hidden in these tasks of yours.
For example, I guess the "write data (generally non-blocking) to
mailbox" involves some sort of elastic FIFO.

Perhaps a bit more explanation would help. TYPE doesn't need to do
anything other than set up an address and a count for the interrupt
routine and start the transmission, usually by writing the first byte
to the device, and stop the task. EXPECT is similar, but it just
needs to enable the receive interrupt. Full-duplex operation isn't
much different; of course two tasks could be used if needed, splitting
the UART for end and receive. It's just that neither Elizabeth nor I
can ever remember that happening!

Andrew.

[Albert van der Horst]

How does that work in the case of a communication program like so
(noforth on an MSP430 Launchpad)?
"
send line (with interpreted or toe be compiled code)
receive response (ACK or NACK)

Don't send a line unless the response is there.
Now throw in the wrench. If the user types a key (to the communication
program) a situation dependant action is taken.
While uploading a file, the uploading stops.
While receiving output from WORDS (that has a KEY? built in) it is sent
directly to the sbc, with different meanings attached to different keys.

"

> That's sort of like factoring in Forth, I would have thought. Separate
> out the two functions instead of trying to combine them into one more
> complicated thing.

Input and output streams are interrelated. The are also real time.
E.g. a message may end with ETX, but also with a time out. Then you
must find a way to communicate the error situation.

(I dont ask rethoric questions here. I've seen your messages and I
know that I may learn something here. For now on Unix I uses select that
wait on both a serial line and the standard in. VMS had of course the
event flags.)

Groetjes Albert

[hughag...@gmail.com]

On Tuesday, April 26, 2016 at 2:04:29 AM UTC-7, Andrew Haley wrote:
> Paul Rubin <no.e...@nospam.invalid> wrote:

> > Maybe if I know the application only uses half-duplex, I can
> > implement some hacky thing that relies on that fact. But if I'm
> > supplying a library facility it wouldn't occur to me to limit it
> > like that.
>
> I'm sure it wouldn't, because you don't really think in the Forth way.
> Don't speculate!

ANS-Forth is a cult --- this is why we have Andrew Haley's emphasis on the "Forth Way." Andrew Haley is supporting Elizabeth Rather by arguing against full-duplex asynchronous communication, despite the fact that the UART has been in use since the 1970s and is generally considered to be one of the big breakthroughs of computer science --- no matter how stupid Elizabeth Rather's pronouncements are, the cult members will argue in favor of those pronouncements using twisted logic and blatant lies.

Elizabeth Rather says: "I can't think offhand of a case in which a

full-duplex port literally has concurrent streams of data flowing in and

out." She is opposed to general-purpose code and instead wants hacky code that relies on the fact that a particular application only needs half-duplex code --- but this code which won't work on other applications that need full-duplex, so it is not general-purpose.

Why is general-purpose code considered to be in contradiction to the "Forth Way"? I've seen a handful of quotes from Charles Moore indicating that he is opposed to general-purpose code. I don't think this proves that he is opposed to general-purpose code though; this reminds me of how people find a handful of quotes in the Bible that support their agenda, and they ignore the huge number of quotes that are in contradiction to their agenda. If Charles Moore really was opposed to general-purpose code he would be on comp.lang.forth denouncing general-purpose code, and he would also be on comp.lang.forth agreeing with Elizabeth Rather than I'm not a Forth programmer --- but he isn't.

Most likely, what happened is that sometime in the 1970s Charles Moore made a comment to Elizabeth Rather such as: "I don't have time to write a general-purpose code-library because I told the customer that I would have the program ready on Monday, so I'm just going to hack together some code over the weekend." This little bit of wisdom stuck in Elizabeth Rather's mind forever, and so she spent the rest of her life denouncing general-purpose code-libraries in favor of hacky application-specific code that can't be reused.

Another problem here is that Elizabeth Rather just doesn't understand how general-purpose code is possible. This is what she said about my general-purpose data-structures in my novice package:
--------------------------------------------------------------------------
Does "*every* application" you write use exactly the same kind of data arranged in the same way? If so, having written it once you can reuse it often. If not, you either have to rearrange your data to make it work or modify your "general-purpose" structure.
--------------------------------------------------------------------------
That's stupid! But ANS-Forth is a cult, so all the cult members totally support Elizabeth Rather on this.

I would like to meet Charles Moore someday, just to ask him if he is really opposed to general-purpose code-libraries, and if he agrees with Elizabeth Rather that I'm not a Forth programmer. I suspect that he doesn't support ANS-Forth and he is okay with me writing code in Forth --- but you never know --- maybe he totally supports ANS-Forth and he damns me to Hell for having written MFX for the MiniForth.

[kiy]

On Wednesday, April 6, 2016 at 4:14:43 PM UTC+9, JUERGEN wrote:
> A MicroBit has arrived on my desk, but no Forth yet available. Until a real Forth is running, and as Python is a supported language - is there a Forth out there in Python I could load and run? Speed is not the issue for now nor is completeness. I mainly want to control the IOs, and the 25 LEDs are just enough to display ok, or a 4 Bit INPUT value, a 4 bit OUTPUT value - and 3 levels of Stack ...
> Any help appreciated. http://microbit-micropython.readthedocs.org/en/latest/.
> Picture and video you can find at https://www.facebook.com/groups/PROGRAMMINGFORTH/?fref=ts. Has anybody re-written JonesForth in Python?

parable is in (micro)python.
http://www.forthworks.com/parable/

[Bernd Paysan]

Am Sun, 15 May 2016 17:20:32 -0700 schrieb kiy:

> On Wednesday, April 6, 2016 at 4:14:43 PM UTC+9, JUERGEN wrote:
>> A MicroBit has arrived on my desk, but no Forth yet available.

Mecrisp Stellaris 2.2 supports MicroBit (target nrf51822).

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[JUERGEN]

At the moment Linux only I was told by Matthias and we tried it out - we have now to wait for a MicroBit Forth Windows implementation, as the target audience here is mostly Windows PCs. I had hoped to demonstrate it at the Maker Fair we go to this Saturday in Bristol http://www.ukesf.org/news/ukesf-joins-digimakers-microbox-project-kit/ Now it will be building up to 50 Forth MicroBoxes running from a serial Interface - which can interface to the standard MicroBit running their languages over the Internet ...

[JUERGEN]

I posted the links 21 April

[visua...@rocketmail.com]

This is really strange! Forth targets are using a serial line and need a terminal emulator which could run on Linux or Windows.
What's the problem?

[Jan Coombs]

Not sure, following Bernd's direction finds a .hex and a .bin
file for MicroBit in the distribution. When we installed the NXP
ARM Mecrisp target we just used the NXP Windows(r) programming
tool, but a free alternative on linux, to upload the image.

I think that the MicroBit tool set has image uploader. Linux
would be needed to rebuild Mecrisp, but that is not usually the
first job when testing a new tool. Perhaps it is all just a
communications problem?

Jan Coombs

[endlessboo...@gmail.com]

On Wednesday, April 6, 2016 at 3:14:43 AM UTC-4, JUERGEN wrote:
> A MicroBit has arrived on my desk, but no Forth yet available. Until a real Forth is running, and as Python is a supported language - is there a Forth out there in Python I could load and run? Speed is not the issue for now nor is completeness. I mainly want to control the IOs, and the 25 LEDs are just enough to display ok, or a 4 Bit INPUT value, a 4 bit OUTPUT value - and 3 levels of Stack ...
> Any help appreciated. http://microbit-micropython.readthedocs.org/en/latest/.
> Picture and video you can find at https://www.facebook.com/groups/PROGRAMMINGFORTH/?fref=ts. Has anybody re-written JonesForth in Python?

avoid python its just a play to get you near java cancer

[lawren...@gmail.com]

On Monday, April 25, 2016 at 6:23:31 AM UTC+12, Paul Rubin wrote:
> Python users may be thread-averse because Python uses OS threads which
> are fairly expensive.

Threading on modern OSes like Linux is quite cheap.

You’re not talking about Windows, are you?

Python users avoid threads because the GIL prevents them from taking full advantage of multiple CPUs.

In general, use of threading in any language can be fraught because their default “share everything” approach can lead to many hard-to-find bugs.

[lawren...@gmail.com]

On Thursday, April 7, 2016 at 2:38:21 AM UTC+12, Julian Fondren wrote:
> Python's easiness is a meme.

Do you mean “myth”?

> Guido is a terrible language designer, and Python has continued
> to stray from his original goals. It didn't even have +=
> because he thought additional operators were confusing. Now it
> has += and similar. Now it also has list comprehensions, and
> decorators (@word_() is an example in my previous post) and
> generators and all kinds of crap.

I don’t understand what you mean by “crap”. What are you comparing it with? Looking at Java, for example, the core Python language is maybe one-fifth the size, and manages to include useful concepts like operator overloading, which Java couldn’t manage. Python does introspection with 4 built-in functions, while Java needs several classes and dozens of methods to achieve the same.

The strength of Python is evident in how add-on libraries make use of features of the core language to do their stuff.

[hughag...@gmail.com]

I don't program in Python, but I've heard a lot of good things about it --- I wouldn't call it "crap" --- Python is something I should learn, as it is the most popular scripting-language in the world (it has largely supplanted Perl, which used to hold this title).

This thread started out by asking: "which Forth in Python is recommended?" I still consider writing Forth in Python to be an idiotic idea --- I felt the same way about John Passaniti's claim to fame, which was writing a Forth-like interpreter in Perl --- this is not what scripting languages are for!

[JUERGEN]

Whichever language you prefer you can pre-order you own MicroBit now. http://www.pcadvisor.co.uk/new-product/pc-components/what-is-bbc-microbit-year7-3619250/. MicroPython included ...

[Julian Fondren]

On Wednesday, June 15, 2016 at 11:34:34 PM UTC-5, lawren...@gmail.com wrote:
> On Thursday, April 7, 2016 at 2:38:21 AM UTC+12, Julian Fondren wrote:
> > Python's easiness is a meme.
>
> Do you mean “myth”?
>

No. Memes can drive people fulfill them. Python's abundance of learning
material grants it a measure of easiness, and it only has all this learning
material because it's "easy".

> > Guido is a terrible language designer, and Python has continued
> > to stray from his original goals. It didn't even have +=
> > because he thought additional operators were confusing. Now it
> > has += and similar. Now it also has list comprehensions, and
> > decorators (@word_() is an example in my previous post) and
> > generators and all kinds of crap.
>
> I don’t understand what you mean by “crap”.

I mean "et cetera". Do you understand what's been listed already?

> What are you comparing it with? Looking at Java,

Jesus Christ! Why not compare it to Brainfuck? Comparing a language to Java
is like comparing a random boat to a boat that comes with its own exclusive-use
ocean. Just grasping Java's incompatible ecosystem is more effort than
learning the language. Are you using make? you fool! You need ant, maven.
Are you using <any editor anyone would naturally use>? you fool! You need
Eclipse, IntelliJ.

Mainly, I've compared Python with earlier versions of itself. Today it would
be reasonable to compare it with Perl or PHP. And as awful as PHP is, I'd take
it over *Python*, just to avoid the version fissure that drives people to
pretend that Python doesn't have any convenient I/O functions.

> The strength of Python is evident in how add-on libraries make use of features of the core language to do their stuff.

This is like saying "that man's strength is evident in how he uses muscles to
move himself around". Oh really? How... unique.


-- Julian

[JUERGEN]

On Wednesday, April 6, 2016 at 8:14:43 AM UTC+1, JUERGEN wrote:
> A MicroBit has arrived on my desk, but no Forth yet available. Until a real Forth is running, and as Python is a supported language - is there a Forth out there in Python I could load and run? Speed is not the issue for now nor is completeness. I mainly want to control the IOs, and the 25 LEDs are just enough to display ok, or a 4 Bit INPUT value, a 4 bit OUTPUT value - and 3 levels of Stack ...
> Any help appreciated. http://microbit-micropython.readthedocs.org/en/latest/.
> Picture and video you can find at https://www.facebook.com/groups/PROGRAMMINGFORTH/?fref=ts. Has anybody re-written JonesForth in Python?

2 ARMs and a MicroBit https://www.techwillsaveus.com/shop/microbit-bundle/?utm_source=Technology+Will+Save+Us+Newsletter&utm_campaign=f559a7a865-Micro%3Abit+mb+lovers&utm_medium=email&utm_term=0_a0c875b17f-f559a7a865-346130093
£15 to £25 depending on Kit contents - has anybody bought one yet and is running Mecrisp Forth?

[rickman]

I'm seeing much higher prices in the US, $50 and $75 for the "BBC
micro:bit Activity Kit" and the "BBC micro:bit" respectively. Any idea
why the difference? Exactly which products are you seeing?

--

Rick C

[Cecil Bayona]

I wonder myself as it is a bit high priced, for less than $11 you can
get a ST Nucleo module with a F4 CPU, lots of RAM and FLASH memory that
has several Forth compilers available for it and can even use Visual
Studio development software if one so desires. There are a lot of
inexpensive small embedded computer devices, but it's hard to compete
with these ST Nucleo and Discover series of boards, they offer low cost
and very high performance, a tough act to beat.
--
Cecil - k5nwa

[JUERGEN]

look at the shipping page: https://www.techwillsaveus.com/home/shipping/

[JUERGEN]

different target market - children not you - none of the ones you mentioned comes with so much easy to understand information for free and for children with no programming background could start with them. And there are actually applications, workshops, training on school ...
Where is the same for Nucleo, can you supply the link please.

[rickman]

That only shows the shipping costs. I don't see the products you seem
to be seeing.

The UK Pound is currently around $1.30 while not too long ago it was
more like $1.50. But even at $1.50 the £25 price you mention would only
be $37.50.

What products do you see for £15 to £25? Can you just tell me the names
so I can see if they are the same ones I see?

--

Rick C

[rickman]

I would also point out that the Microbit isn't just a board, it includes
other hardware for various "experiments".

Contains: BBC micro:bit, USB cable, battery holder and 20x components.

--

Rick C

[JUERGEN]

£25 for the kit at https://www.techwillsaveus.com/shop/microbit-bundle/?utm_source=Technology+Will+Save+Us+Newsletter&utm_campaign=f559a7a865-Micro%3Abit+mb+lovers&utm_medium=email&utm_term=0_a0c875b17f-f559a7a865-346130093
The ultimate pack contains

BBC micro:bit
20× electronic components to build projects and activities
USB cable to connect it to your laptop
Battery holder to make it mobile
No other tools required

and
£15 at https://www.techwillsaveus.com/shop/microbit/ just the MicroBit; the USB cable you probably have and use it on your mobile. I actually used 5 countersunk screws and wires to connect it to a solderless breadboard

Shipping at https://www.techwillsaveus.com/home/shipping/
US
US shipping
FREE Standard Delivery on all orders over $50
US Standard Delivery – 3 to 7 days – $5.00
Did this help and you can see it now - 3 Microbits or kits and shipment is free

[rickman]

Yes, something is wrong with their web site I suspect. The prices for
the units you provide links to are $50 US and $75 US with the Microbit
board being the $75 item. I expect they are giving US vs. UK pricing
based on my IP address.

I think $50 for the kit is not a bad price. $75 for the board is pretty
high. If the mistake they made was switching the prices, the £15 board
would be $50 and the £25 kit would be $75. This is still pretty high
with a 3:1 exchange rate which is more than twice the going rate.
Something has gone awry with their currency conversion and/or web site
creation.

--

Rick C

[JUERGEN]

Well, there are the proven old methods if you really want one: call or email
https://www.facebook.com/techwillsaveus/app/100265896690345/
and the relevant data from there:
Founded on January 1, 2012
Short Description:
We create DIY gadget kits that encourage everyone to make, play code and invent with technology.
Mission:
Technology Will Save Us is one of the UK's most exciting design-led, technology start-ups focused on learning. We are on a m... See More
Phone: 020 3004 8843
Email: in...@techwillsaveus.com
Website: http://www.techwillsaveus.com
I do not think there is anything more I can do for you

[rickman]

I'm not all that excited by this device to be honest. It's interesting,
but it's not being marketed to me. I'm not in education.

--

Rick C