Groups > comp.lang.forth > #46543 > unrolled thread

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

Started by	JUERGEN <epldfpga@aol.com>
First post	2016-04-06 00:14 -0700
Last post	2016-08-12 11:11 -0400
Articles	20 on this page of 107 — 24 participants

Back to article view | Back to comp.lang.forth

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →

#46789

From	"Elizabeth D. Rather" <erather@forth.com>
Date	2016-04-26 08:39 -1000
Message-ID	<ZqOdnTrRjrhxKILKnZ2dnUU7-aXNnZ2d@supernews.com>
In reply to	#46778

On 4/26/16 1:32 AM, Anton Ertl wrote:
> "Elizabeth D. Rather" <erather@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.

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

[toc] | [prev] | [next] | [standalone]

#46791

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-04-26 19:20 +0000
Message-ID	<2016Apr26.212011@mips.complang.tuwien.ac.at>
In reply to	#46789

"Elizabeth D. Rather" <erather@forth.com> writes:
>On 4/26/16 1:32 AM, Anton Ertl wrote:
>> "Elizabeth D. Rather" <erather@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/

[toc] | [prev] | [next] | [standalone]

#46793

From	"Elizabeth D. Rather" <erather@forth.com>
Date	2016-04-26 13:09 -1000
Message-ID	<m-Cdnf2hP_GQaILKnZ2dnUU7-LvNnZ2d@supernews.com>
In reply to	#46791

On 4/26/16 9:20 AM, Anton Ertl wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> On 4/26/16 1:32 AM, Anton Ertl wrote:
>>> "Elizabeth D. Rather" <erather@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.

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

[toc] | [prev] | [next] | [standalone]

#46807

From	Albert van der Horst <albert@cherry.spenarnc.xs4all.nl>
Date	2016-04-27 17:55 +0000
Message-ID	<slrnni22pr.9a2.albert@cherry.spenarnc.xs4all.nl>
In reply to	#46791

On 2016-04-26, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>>On 4/26/16 1:32 AM, Anton Ertl wrote:
>>> "Elizabeth D. Rather" <erather@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


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

[toc] | [prev] | [next] | [standalone]

#46799

From	hughaguilar96@gmail.com
Date	2016-04-27 01:54 -0700
Message-ID	<f849ae0c-f8ec-4dfa-b78a-dddcb11dafd7@googlegroups.com>
In reply to	#46764

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

[toc] | [prev] | [next] | [standalone]

#46772

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2016-04-26 02:47 -0500
Message-ID	<2rSdnc6QpZ-WgILKnZ2dnUU78amdnZ2d@supernews.com>
In reply to	#46763

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@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.

[toc] | [prev] | [next] | [standalone]

#46773

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-04-26 01:12 -0700
Message-ID	<87bn4wkcvh.fsf@nightsong.com>
In reply to	#46772

Andrew Haley <andrew29@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.

[toc] | [prev] | [next] | [standalone]

#46774

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2016-04-26 04:04 -0500
Message-ID	<eIadnaMtAOaHsoLKnZ2dnUU78afNnZ2d@supernews.com>
In reply to	#46773

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@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.

[toc] | [prev] | [next] | [standalone]

#46775

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-04-26 02:53 -0700
Message-ID	<877ffkk875.fsf@nightsong.com>
In reply to	#46774

Andrew Haley <andrew29@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.

[toc] | [prev] | [next] | [standalone]

#46782

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2016-04-26 08:23 -0500
Message-ID	<MOednZGyXcxz9oLKnZ2dnUU78eXNnZ2d@supernews.com>
In reply to	#46775

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@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.

[toc] | [prev] | [next] | [standalone]

#46821

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-04-27 17:49 -0700
Message-ID	<87oa8uh80w.fsf@nightsong.com>
In reply to	#46782

Andrew Haley <andrew29@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.

[toc] | [prev] | [next] | [standalone]

#46825

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2016-04-28 03:47 -0500
Message-ID	<XfWdnR18-IGIU7zKnZ2dnUU7-fXNnZ2d@supernews.com>
In reply to	#46821

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@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.

[toc] | [prev] | [next] | [standalone]

#46826

From	Albert van der Horst <albert@cherry.spenarnc.xs4all.nl>
Date	2016-04-28 11:50 +0000
Message-ID	<slrnni41pi.dgp.albert@cherry.spenarnc.xs4all.nl>
In reply to	#46821

On 2016-04-28, Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@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
>


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

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

[toc] | [prev] | [next] | [standalone]

#46835

From	hughaguilar96@gmail.com
Date	2016-04-29 00:11 -0700
Message-ID	<180ff207-b151-40ea-88e3-6d555961ceb0@googlegroups.com>
In reply to	#46774

On Tuesday, April 26, 2016 at 2:04:29 AM UTC-7, Andrew Haley wrote:
> Paul Rubin <no.email@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.

[toc] | [prev] | [next] | [standalone]

#46777

From	Albert van der Horst <albert@cherry.spenarnc.xs4all.nl>
Date	2016-04-26 11:26 +0000
Message-ID	<slrnnhunjb.108.albert@cherry.spenarnc.xs4all.nl>
In reply to	#46772

On 2016-04-26, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> Paul Rubin <no.email@nospam.invalid> wrote:
>> Andrew Haley <andrew29@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

[toc] | [prev] | [next] | [standalone]

#46783

From	foxaudioresearch@gmail.com
Date	2016-04-26 07:04 -0700
Message-ID	<2ddcbd71-ddc0-4d01-85b6-01f06c27c741@googlegroups.com>
In reply to	#46777

On Tuesday, April 26, 2016 at 7:26:18 AM UTC-4, Albert van der Horst wrote:
> On 2016-04-26, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> > Paul Rubin <no.email@nospam.invalid> wrote:
> >> Andrew Haley <andrew29@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

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

[toc] | [prev] | [next] | [standalone]

#46784

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2016-04-26 09:29 -0500
Message-ID	<g4idndL7TIj85oLKnZ2dnUU78bGdnZ2d@supernews.com>
In reply to	#46783

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

[toc] | [prev] | [next] | [standalone]

#46788

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-04-26 10:47 -0700
Message-ID	<87y480i7nf.fsf@nightsong.com>
In reply to	#46783

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

[toc] | [prev] | [next] | [standalone]

#46700

From	visualforth@rocketmail.com
Date	2016-04-20 16:04 -0700
Message-ID	<b0f07504-721c-4783-9d0a-24ed9c6bea75@googlegroups.com>
In reply to	#46679

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.

[toc] | [prev] | [next] | [standalone]

#46690

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-04-19 10:47 -0700
Message-ID	<87oa95mqx7.fsf@nightsong.com>
In reply to	#46677

JUERGEN <epldfpga@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

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →

csiph-web

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

Contents

#46789

#46791

#46793

#46807

#46799

#46772

#46773

#46774

#46775

#46782

#46821

#46825

#46826

#46835

#46777

#46783

#46784

#46788

#46700

#46690