Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #19527 > unrolled thread
| Started by | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| First post | 2013-02-07 22:51 +0100 |
| Last post | 2013-02-10 00:06 -0500 |
| Articles | 20 on this page of 144 — 25 participants |
Back to article view | Back to comp.lang.forth
3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-07 22:51 +0100
Re: 3D-graphics calculations using integers? "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-02-07 22:08 +0000
Re: 3D-graphics calculations using integers? AKE <assadebrahim2000@gmail.com> - 2013-02-07 14:32 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-07 23:40 +0100
Re: 3D-graphics calculations using integers? AKE <assadebrahim2000@gmail.com> - 2013-02-07 17:06 -0800
Re: 3D-graphics calculations using integers? AKE <assadebrahim2000@gmail.com> - 2013-02-07 17:07 -0800
Re: 3D-graphics calculations using integers? Pablo Hugo Reda <pabloreda@gmail.com> - 2013-02-07 14:36 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-07 23:46 +0100
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-07 16:38 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 10:22 +0100
Re: 3D-graphics calculations using integers? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-08 10:26 +0000
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-07 12:50 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 00:15 +0100
Re: 3D-graphics calculations using integers? kenney@cix.compulink.co.uk - 2013-02-08 14:51 -0600
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 22:02 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-07 18:21 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 00:30 +0100
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 00:39 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-07 18:51 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 12:28 +0100
Re: 3D-graphics calculations using integers? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-08 12:25 +0000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 22:04 +0100
Re: 3D-graphics calculations using integers? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-09 15:27 +0000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 16:36 +0100
Re: 3D-graphics calculations using integers? Mark Wills <forthfreak@gmail.com> - 2013-02-08 05:01 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 21:58 +0100
Re: 3D-graphics calculations using integers? Roberto Waltman <usenet@rwaltman.com> - 2013-02-08 10:08 -0500
Re: 3D-graphics calculations using integers? Roberto Waltman <usenet@rwaltman.com> - 2013-02-08 10:11 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 22:05 +0100
Re: 3D-graphics calculations using integers? Pablo Hugo Reda <pabloreda@gmail.com> - 2013-02-08 08:29 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 18:48 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-08 17:20 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 23:32 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-09 23:57 -0500
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-08 15:02 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 02:24 +0100
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-08 15:58 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 16:43 +0100
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-09 10:03 -1000
Re: 3D-graphics calculations using integers? "Ed" <invalid@nospam.com> - 2013-02-10 11:35 +1100
Re: 3D-graphics calculations using integers? humptydumpty <ouatubi@gmail.com> - 2013-02-08 23:48 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 16:37 +0100
OT: ANS Forth Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 17:27 +0100
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-09 10:06 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-09 12:26 -0800
Re: OT: ANS Forth Elizabeth D Rather <erather@forth.com> - 2013-02-09 14:38 -1000
Re: OT: ANS Forth "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-22 12:52 -0500
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-22 09:25 -1000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-10 08:15 -0600
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-10 23:34 -0800
Re: OT: ANS Forth Josh Grams <josh@qualdan.com> - 2013-02-11 22:14 +0000
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-11 13:34 -1000
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-11 11:52 +1100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-10 17:11 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-10 22:06 -1000
Re: OT: ANS Forth "Charles Childers" <crc@retroforth.org> - 2013-02-11 17:17 -0500
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-13 11:42 +1100
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-12 16:07 -1000
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-15 09:42 +1100
Re: OT: ANS Forth Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-15 00:16 +0100
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-17 16:05 +1100
Re: OT: ANS Forth Howerd <howerdo@yahoo.co.uk> - 2013-02-17 04:16 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-17 13:12 +0000
Re: OT: ANS Forth Howerd <howerdo@yahoo.co.uk> - 2013-02-17 09:15 -0800
Re: OT: ANS Forth Brad Eckert <hwfwguy@gmail.com> - 2013-02-19 09:35 -0800
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-19 19:25 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-19 15:35 -0600
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 00:37 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-20 23:07 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 01:38 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-21 08:50 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 15:44 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-24 03:41 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 20:00 -0800
Re: OT: ANS Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-24 13:49 +0000
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-24 15:04 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-24 14:52 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-24 23:51 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-24 16:23 -0800
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-21 03:55 -0600
Re: OT: ANS Forth "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-22 13:01 -0500
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-22 12:26 -0600
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-19 21:54 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-19 18:21 -0600
Re: OT: ANS Forth Brad Eckert <hwfwguy@gmail.com> - 2013-02-20 08:45 -0800
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-20 11:01 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-20 11:25 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 00:22 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-20 22:50 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 01:08 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-21 12:42 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-21 13:50 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 09:36 -0800
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 01:32 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:50 -0800
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 03:03 +0100
Re: OT: ANS Forth Brad Eckert <hwfwguy@gmail.com> - 2013-02-21 09:12 -0800
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:38 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-21 09:01 -1000
Re: OT: ANS Forth mhx@iae.nl (Marcel Hendrix) - 2013-02-22 00:05 +0200
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-21 13:24 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 09:33 -0800
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-21 13:04 -0600
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 01:41 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:31 -0800
Re: OT: ANS Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-02-23 09:15 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-23 04:33 -0600
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-23 13:49 +0000
Re: OT: ANS Forth Roberto Waltman <usenet@rwaltman.com> - 2013-02-23 13:35 -0500
Re: OT: ANS Forth Roberto Waltman <usenet@rwaltman.com> - 2013-02-23 13:46 -0500
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 15:26 -0800
Re: OT: ANS Forth Roberto Waltman <usenet@rwaltman.com> - 2013-02-24 09:41 -0500
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-21 09:09 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:37 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-23 13:57 +0000
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-23 08:47 -1000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 01:27 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:16 -0800
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-23 04:36 -0600
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-23 16:52 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 12:39 -0800
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 16:27 +0000
Re: OT: ANS Forth "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-23 18:08 -0500
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 02:20 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-24 20:16 -0800
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 16:04 +0100
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-25 17:12 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 20:44 +0100
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 16:45 +0100
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-24 02:09 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 04:03 +0100
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 17:58 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 20:57 +0100
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 16:43 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-02 18:14 +0100
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 13:56 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-24 03:45 -0600
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-13 04:12 -0600
Re: OT: ANS Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-13 12:24 +0000
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-11 14:41 +0000
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-11 19:44 +0000
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-11 21:14 +0000
Re: 3D-graphics calculations using integers? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-09 18:14 -0600
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-10 00:06 -0500
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | "Ed" <invalid@nospam.com> |
|---|---|
| Date | 2013-02-17 16:05 +1100 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <kfpoft$3j8$1@speranza.aioe.org> |
| In reply to | #19740 |
Zbiggy wrote: > In comp.lang.forth, Ed wrote: > > > If having the lowest number of users and vendors in its history and being > > reduced to securing votes from lurkers on a usenet group is surviving well, > > then Forth is indeed a most unusual language. > > I've got a feeling, it may change during following years. There are numerous > designs of new "home-computer" generations: > > - commercial: > > http://www.kickstarter.com/projects/2057605091/p112-single-board-computer-kit > http://www.xgamestation.com/ > http://propellerpowered.us/index.php?route=product/product&path=25_73&product_id=55 > > > - "homebrew": > > http://www.msarnoff.org/6809/ > https://sites.google.com/site/retroelec/ > http://sbc.rictor.org/ > http://www.rickard.gunee.com/projects/ > http://www.linusakesson.net/scene/craft/ > > As I see, presently they mostly program their designs in assembler, or C. > But soon most of these people will find, that Forth is better suited for > this... I think hobby Forth will be around for quite some time but interest will remain small. Forth's lack of acceptance isn't due to ignorance but its quirkyness. I hear comments like: "Yes, I've played with Forth and tried a few things. It was fun, however it's not for me." Forth is not what most folks expect of a high-level language. This is true even among Forth users.
[toc] | [prev] | [next] | [standalone]
| From | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| Date | 2013-02-17 04:16 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <3f94bc5e-70cd-4e20-8367-c5fae9078531@googlegroups.com> |
| In reply to | #19769 |
On Sunday, February 17, 2013 6:05:18 AM UTC+1, Ed wrote: > Zbiggy wrote: > > > In comp.lang.forth, Ed wrote: > > > > > > > If having the lowest number of users and vendors in its history and being > > > > reduced to securing votes from lurkers on a usenet group is surviving well, > > > > then Forth is indeed a most unusual language. > > > > > > I've got a feeling, it may change during following years. There are numerous > > > designs of new "home-computer" generations: > > > > > > - commercial: > > > > > > http://www.kickstarter.com/projects/2057605091/p112-single-board-computer-kit > > > http://www.xgamestation.com/ > > > http://propellerpowered.us/index.php?route=product/product&path=25_73&product_id=55 > > > > > > > > > - "homebrew": > > > > > > http://www.msarnoff.org/6809/ > > > https://sites.google.com/site/retroelec/ > > > http://sbc.rictor.org/ > > > http://www.rickard.gunee.com/projects/ > > > http://www.linusakesson.net/scene/craft/ > > > > > > As I see, presently they mostly program their designs in assembler, or C. > > > But soon most of these people will find, that Forth is better suited for > > > this... > > > > I think hobby Forth will be around for quite some time but interest will > > remain small. > > > > Forth's lack of acceptance isn't due to ignorance but its quirkyness. > > I hear comments like: "Yes, I've played with Forth and tried a few things. > > It was fun, however it's not for me." Forth is not what most folks expect > > of a high-level language. This is true even among Forth users. Hi Ed, > Forth's lack of acceptance isn't due to ignorance but its quirkyness. If by "quirkiness" you mean that Forth is not like other mainstream languages, I would agree, and this certainly puts people off using it. > Forth is not what most folks expect of a high-level language. I agree with this too. > I think hobby Forth will be around for quite some time but interest will > remain small. What is interesting about your post is that I agree with almost everything that you say, but I do not agree with two things that I infer from the way that you say them : 1. That Forth's lack of popularity is somehow a failure of Forth as a language 2. That Forth's lack of popularity is necessarily a bad thing > Forth's lack of acceptance isn't due to ignorance Agreed - some people like Forth, other people will never like Forth however much they know about it. > I think hobby Forth will be around for quite some time but interest will > remain small. I think that Forth will always be less popular than any language that is supported by billion dollar companies, taught in Computer Science classes and heavily advertised as the latest and best way to program. But maybe interest will pick up. Mainstream computer languages are getting more complicated, as attempts to "lock in" customers get more difficult, so it could be that its time for simplicity to make a comeback. I see a parallel with the music industry - however much MTV produces heavily marketed products aimed at particular demographics there will always be some people that just want to make music. Thank God for Mumford & Sons, for example ( http://www.youtube.com/watch?v=0MkpBqGPS7g ). Similarly there will always be a need for C#/.Net, or whatever the latest language is, because people want job security, and for that you need a mass market. Forth could never be adopted by Microsoft, for example, because it does not provide enough "lock in" to make it profitable. But for individual users such as myself, and hobby programmers, it makes a wonderfully powerful tool. Just my 2p worth... Best regards, Howerd
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-02-17 13:12 +0000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <5120d75a$0$26884$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #19770 |
In article <3f94bc5e-70cd-4e20-8367-c5fae9078531@googlegroups.com>, Howerd <howerdo@yahoo.co.uk> wrote: <SNIP> > >Similarly there will always be a need for C#/.Net, or whatever the >latest language is, because people want job security, and for that you >need a mass market. The inventor of C# had the same drive as CHuck Moore. Don't blame C# because it was adopted by Microsoft. > >Forth could never be adopted by Microsoft, for example, because it does >not provide enough "lock in" to make it profitable. They adopted C# to kill Java, for sure. >But for individual users such as myself, and hobby programmers, it makes >a wonderfully powerful tool. Same can be said from C# ... > >Just my 2p worth... > >Best regards, >Howerd 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]
| From | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| Date | 2013-02-17 09:15 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <febbe8e1-63e9-46c7-a8ff-a5ced30de1da@googlegroups.com> |
| In reply to | #19772 |
On Sunday, February 17, 2013 2:12:58 PM UTC+1, Albert van der Horst wrote: > In article <3f94bc5e-70cd-4e20-8367-c5faexxxxxxxx@googlegroups.com>, > > Howerd <howxxxx@yahoo.co.uk> wrote: > > <SNIP> > > > > > >Similarly there will always be a need for C#/.Net, or whatever the > > >latest language is, because people want job security, and for that you > > >need a mass market. > > > > The inventor of C# had the same drive as CHuck Moore. Don't blame C# > > because it was adopted by Microsoft. > > > > > > > >Forth could never be adopted by Microsoft, for example, because it does > > >not provide enough "lock in" to make it profitable. > > > > They adopted C# to kill Java, for sure. > > > > >But for individual users such as myself, and hobby programmers, it makes > > >a wonderfully powerful tool. > > > > Same can be said from C# ... > > > > > >Just my 2p worth... > > > > > >Best regards, > > >Howerd > > > > 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 Hi Albert, > Same can be said from C# ... Yes - there is even an open source C# compiler : http://www.mono-project.com/Main_Page Wonderful and powerful though this is, I could not find a .NET CLR for the MSP430 ;-) Maybe this will be included in a later update of Windows 8? Its horses for courses here :-) Best regards, Howerd
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2013-02-19 09:35 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <6010e112-93d6-4541-9ba8-2dc4020eec0c@googlegroups.com> |
| In reply to | #19769 |
On Saturday, February 16, 2013 10:05:18 PM UTC-7, Ed wrote: > > Forth's lack of acceptance isn't due to ignorance but its quirkyness. > I hear comments like: "Yes, I've played with Forth and tried a few things. > It was fun, however it's not for me." Forth is not what most folks expect > of a high-level language. This is true even among Forth users. They want Forth to work the way they were taught that programming languages should work. Nobody likes to un-learn stuff because overriding the ego is hard.
[toc] | [prev] | [next] | [standalone]
| From | Andy Valencia <user@vsta.org> |
|---|---|
| Date | 2013-02-19 19:25 +0000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <20130219191650.21147.66122@Nokia-N810-43-7> |
| In reply to | #19822 |
Brad Eckert <hwfwguy@gmail.com> writes: > They want Forth to work the way they were taught that programming languages > should work. Nobody likes to un-learn stuff because overriding the ego is > hard. This is true of any innovative language. Having done the exercise multiple times, I can say as a high level language Forth did not compare well at all to Python, Prolog, OCaml, Erlang. For low level/embedded, it always lagged behind C. I've written a *lot* of Forth, and I still believe C comes out way ahead. Its true strength is that it provides a simple language model which lends itself to implementation with a modest amount of effort. And that this small model often provides a sweet spot when facing the limitations of the 16-bit world. It also provides a nostalgic return to simplicity in a world of massively layered software. Andy Valencia Home page: http://www.vsta.org/andy/ To contact me: http://www.vsta.org/contact/andy.html
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-02-19 15:35 -0600 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <O4ednUuOcsG7bb7MnZ2dnUVZ_qGdnZ2d@supernews.com> |
| In reply to | #19827 |
Andy Valencia <user@vsta.org> wrote: > Brad Eckert <hwfwguy@gmail.com> writes: >> They want Forth to work the way they were taught that programming languages >> should work. Nobody likes to un-learn stuff because overriding the ego is >> hard. > > This is true of any innovative language. Having done the exercise > multiple times, I can say as a high level language Forth did not > compare well at all to Python, Prolog, OCaml, Erlang. For low > level/embedded, it always lagged behind C. I've written a *lot* of > Forth, and I still believe C comes out way ahead. Oh come on, this is bloody ridiculous. I can understand the argument about higher-level languages like Python, but C for embedded work? C is crude, it has very limited extensibiity, it has a mess of tools: compilers, linkers, makefiles, debuggers. And even then it doesn't have an interactive environment. The lack of extensibility means that whatever the language designer provides had better better be right, because you're not going to get anything better. And yes, I know there are IDEs that make up for some of this, but I've never seen anything that can approach the ease of development and interactivity of an embedded Forth system. And, as a GCC developer, I have more than a passing familiarity with C. > Its true strength is that it provides a simple language model which > lends itself to implementation with a modest amount of effort. And > that this small model often provides a sweet spot when facing the > limitations of the 16-bit world. It also provides a nostalgic > return to simplicity in a world of massively layered software. Well, yes it does. And this is a bad thing? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-21 00:37 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7xehgakqpc.fsf@ruckus.brouhaha.com> |
| In reply to | #19830 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > C for embedded work? C is crude, it has very limited extensibiity..., > there are IDEs that make up for some of this, but I've never seen > anything that can approach the ease of development and interactivity > of an embedded Forth system. I'd be interested to know what kinds of features a Forth environment needs to supply this ease of development. Are you talking about interacting with a resident Forth on the embedded target? Does it have its own way to edit and save and re-run source code (maybe with blocks/screens), instead of having to keep re-typing it at a serial port? If not, did you use some kind of cross-development system and reload source code from a remote host? Do those dev environments have a way to start and stop a multi-tasker so you can inspect task data from an interactive Forth shell? What little Forth hacking I've done has been in gforth, which has pretty good checks and diagnostics for all kinds of program errors. I get the impression that embedded Forths are much less helpful about that, making debugging all the more painful.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-02-20 23:07 -1000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <QuWdnTSVx80hfrjMnZ2dnUVZ_r2dnZ2d@supernews.com> |
| In reply to | #19862 |
On 2/20/13 10:37 PM, Paul Rubin wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> C for embedded work? C is crude, it has very limited extensibiity..., >> there are IDEs that make up for some of this, but I've never seen >> anything that can approach the ease of development and interactivity >> of an embedded Forth system. > > I'd be interested to know what kinds of features a Forth environment > needs to supply this ease of development. Are you talking about > interacting with a resident Forth on the embedded target? Does it have > its own way to edit and save and re-run source code (maybe with > blocks/screens), instead of having to keep re-typing it at a serial > port? If not, did you use some kind of cross-development system and > reload source code from a remote host? Do those dev environments have a > way to start and stop a multi-tasker so you can inspect task data from > an interactive Forth shell? > > What little Forth hacking I've done has been in gforth, which has pretty > good checks and diagnostics for all kinds of program errors. I get the > impression that embedded Forths are much less helpful about that, making > debugging all the more painful. SwiftX uses an umbilical link to the target. In olden times it was serial, but nowadays it's more commonly USB or other fast connections, sometimes JTAG. Compiling is done on the host, which generates a program image and downloads it to the target. The compiling is extremely fast (~1s or less, even for fairly large programs), and downloading is pretty quick, depending on the details of the interface - they vary a lot. Only the executable code & initialized data space is downloaded. The host retains the heads of all words, with links to their target image. So, testing is just like on a resident system: put arguments on the stack and type a word. The host passes its stack to the target, asks the target to execute the word, and gets its stack back. You can examine target memory, ports, etc. There is no perceptible time delay -- it feels just like working on your resident system. If you want to, you can type in a definition and it is automatically compiled (to target code), downloaded, and it's ready to test. If your target program has multiple tasks, the one supporting the umbilical link lets you observe the others, including user variables and global variables they're managing, etc. A resident Forth on the target is somewhat more trouble, but they usually do let you keep your source in a file on the host and download the whole thing. If the link is USB or another fast technology it's not so bad. If you're really curious about this, you should download a free trial version of SwiftX for a target you have or can get, and check it out. 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]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-21 01:38 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7xk3q26m87.fsf@ruckus.brouhaha.com> |
| In reply to | #19864 |
"Elizabeth D. Rather" <erather@forth.com> writes: > SwiftX uses an umbilical link to the target..... Compiling is done on > the host... Only the executable code & initialized data space is > downloaded.., testing is just like on a resident system: put > arguments on the stack and type a word. The host passes its stack to > the target, asks the target to execute the word, and gets its stack > back. You can examine target memory, ports, etc. There is no > perceptible time delay -- it feels just like working on your resident > system. Thanks, this sounds pretty neat, though relatively complex compared to a classic resident interpreter. > A resident Forth on the target is somewhat more trouble, but they > usually do let you keep your source in a file on the host and download > the whole thing. If the link is USB or another fast technology it's > not so bad. I guess that makes sense. Now I'm wondering about the possibility of having a complete IDE in a target microcontroller, with a block editor saving source code to program flash. There are quite a few midsized and larger microcontrollers that would be plausible targets for this. > If you're really curious about this, you should download a free trial > version of SwiftX for a target you have or can get, and check it out. I might try that sometime. I'm also interested in how it was done historically, in the old 16-bit systems.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-02-21 08:50 -1000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <N46dnYYkgMXq8bvMnZ2dnUVZ_uidnZ2d@supernews.com> |
| In reply to | #19866 |
On 2/20/13 11:38 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> SwiftX uses an umbilical link to the target..... Compiling is done on >> the host... Only the executable code & initialized data space is >> downloaded.., testing is just like on a resident system: put >> arguments on the stack and type a word. The host passes its stack to >> the target, asks the target to execute the word, and gets its stack >> back. You can examine target memory, ports, etc. There is no >> perceptible time delay -- it feels just like working on your resident >> system. > > Thanks, this sounds pretty neat, though relatively complex compared to a > classic resident interpreter. Yes, it is more complex, but it delivers target code that is far more compact and significantly faster, thanks to sophisticated optimizing compilers which can run on a PC host but are impractical in a limited-space target. This is the technology that works for professional, production applications. The concept started in the early 80's, addressing the smaller microcontrollers such as the 8051. It has evolved over the years so that, although rather complex on the inside, it is extremely simple to use. >> A resident Forth on the target is somewhat more trouble, but they >> usually do let you keep your source in a file on the host and download >> the whole thing. If the link is USB or another fast technology it's >> not so bad. > > I guess that makes sense. Now I'm wondering about the possibility of > having a complete IDE in a target microcontroller, with a block editor > saving source code to program flash. There are quite a few midsized and > larger microcontrollers that would be plausible targets for this. Sure, that can work. But harken back to the discussion we were just having about Forths that leave the compiler, etc., in place in a finished program. This is a very innocuous practice on a PC with Gb of memory, but the tradeoffs in an embedded system are quite different. >> If you're really curious about this, you should download a free trial >> version of SwiftX for a target you have or can get, and check it out. > > I might try that sometime. I'm also interested in how it was done > historically, in the old 16-bit systems. As I described above, although for professional projects this concept only survived for a few years (late 70's to mid-80's). 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]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-23 15:44 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7xk3pyd287.fsf@ruckus.brouhaha.com> |
| In reply to | #19883 |
"Elizabeth D. Rather" <erather@forth.com> writes: >> Now I'm wondering about the possibility of having a complete IDE in a >> target microcontroller... > ... This is a very innocuous practice on a PC with Gb of memory, but > the tradeoffs in an embedded system are quite different. Yeah, I'm thinking of microcontrollers with relatively plentiful program space. E.g. the Stellaris Launchpad (Cortex M4F procesor) has 256K of program flash and 32K of ram, quite a bit more program space than the classic 16-bit computers had, and would presumably work fine. The MSP430 Launchpad (16k flash, 512B ram) is probably too constrained. The KL05 Freedom board (ARM Cortex M0+, 32k flash, 4k ram) might be marginally enough. What I'm not sure is whether the flash erase commands on these chips are capable of erasing 1K pages as a block system would need. > As I described above, although for professional projects this concept > only survived for a few years (late 70's to mid-80's). That's a good point. I had been imagining those systems staying in use for a lot longer.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-02-24 03:41 +0000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <51298bd3$0$610$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #19970 |
In article <7xk3pyd287.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >"Elizabeth D. Rather" <erather@forth.com> writes: >>> Now I'm wondering about the possibility of having a complete IDE in a >>> target microcontroller... >> ... This is a very innocuous practice on a PC with Gb of memory, but >> the tradeoffs in an embedded system are quite different. > >Yeah, I'm thinking of microcontrollers with relatively plentiful program >space. E.g. the Stellaris Launchpad (Cortex M4F procesor) has 256K of >program flash and 32K of ram, quite a bit more program space than the >classic 16-bit computers had, and would presumably work fine. The MSP430 >Launchpad (16k flash, 512B ram) is probably too constrained. The KL05 >Freedom board (ARM Cortex M0+, 32k flash, 4k ram) might be marginally >enough. What I'm not sure is whether the flash erase commands on these >chips are capable of erasing 1K pages as a block system would need. For the Launchpad, it is probably best to map blocks onto an sd card. That can be used for other traditional uses like data aquisition. All of the flash is usable as program memory (unlike e.g. the Renesas chips). > >> As I described above, although for professional projects this concept >> only survived for a few years (late 70's to mid-80's). > >That's a good point. I had been imagining those systems staying in >use for a lot longer. 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]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-23 20:00 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7xbobapdie.fsf@ruckus.brouhaha.com> |
| In reply to | #19980 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes: > For the Launchpad, it is probably best to map blocks onto an sd card. None of the Launchpads support SD cards as far as I know. Maybe there is a way to communicate with an SD card through GPIO pins but that would be kind of extreme.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2013-02-24 13:49 +0000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <512a19f7.988062534@192.168.0.50> |
| In reply to | #19981 |
On Sat, 23 Feb 2013 20:00:25 -0800, Paul Rubin <no.email@nospam.invalid> wrote: >albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >> For the Launchpad, it is probably best to map blocks onto an sd card. > >None of the Launchpads support SD cards as far as I know. Maybe there >is a way to communicate with an SD card through GPIO pins but that >would be kind of extreme. Most SD cards still support SPI mode. Most microcontrollers have an SPI port. If you are desparate or cheap, you can easily write a bit-banged driver. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-02-24 15:04 +0000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <512a2bf3$0$26901$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #19987 |
In article <512a19f7.988062534@192.168.0.50>, Stephen Pelc <stephenXXX@INVALID.mpeforth.com> wrote: >On Sat, 23 Feb 2013 20:00:25 -0800, Paul Rubin ><no.email@nospam.invalid> wrote: > >>albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >>> For the Launchpad, it is probably best to map blocks onto an sd card. >> >>None of the Launchpads support SD cards as far as I know. Maybe there >>is a way to communicate with an SD card through GPIO pins but that >>would be kind of extreme. > >Most SD cards still support SPI mode. Most microcontrollers have an >SPI port. If you are desparate or cheap, you can easily write a >bit-banged driver. What would you think of a 5 euro card? We're cheap! Buy a 2 euro micro-sd card with a sd enclosure, and solder the enclosure to a header. Or just solder to the gold pads of a normal sd card. The bit banged driver has been written a long time ago for the 8051 Byteforth. > >Stephen 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]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-24 14:52 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7x8v6dfhoh.fsf@ruckus.brouhaha.com> |
| In reply to | #19989 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes: > Buy a 2 euro micro-sd card with a sd enclosure, and solder the > enclosure to a header. Adding this amount of external hardware somewhat defeats the point of those highly integrated SOC's. You might as well use a Raspberry Pi or something like that, with a more workstation-like development environment. In my case I've been thinking of building a certain embedded gadget that has to be quite small and low powered, but at the same time have a certain amount of user-level configurability. The typical approach would be to just have some closed UI functions that adjust the config parameters. A more flexible approach for technical users would be to have a communication port speaking some simple binary protocol, and a special purpose PC or phone application that configures the device using the protocol. It seems to me though that having a completely resident Forth in the device that the user can control from a generic terminal emulator would be cooler still, so I've been playing with the idea. This is all at the level of "in my nonexistent free time" though, i.e. pretty much a thought exercise and likely to stay that way.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-02-24 23:51 +0000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <512aa769$0$26874$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #19997 |
In article <7x8v6dfhoh.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >> Buy a 2 euro micro-sd card with a sd enclosure, and solder the >> enclosure to a header. > >Adding this amount of external hardware somewhat defeats the point of >those highly integrated SOC's. You might as well use a Raspberry Pi or >something like that, with a more workstation-like development >environment. You must be kidding. Whenever you do something with the Launcpad, you have to solder something to it. A DB9 connector (to play the tingle tangle) , a temperature sensor, an lcd display, relays, buttons. Why are you upset when I add an sd card? 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]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-24 16:23 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7x38wlkzqg.fsf@ruckus.brouhaha.com> |
| In reply to | #20000 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes: > You must be kidding. Whenever you do something with the Launcpad, you > have to solder something to it. A DB9 connector (to play the tingle tangle) > , a temperature sensor, an lcd display, relays, buttons. > Why are you upset when I add an sd card? Well usually it's just header pins, no soldering ;-). For the Launchpad itself I guess an external socketed SD is less of a big deal. If the idea is to use the Launchpad as a development tool for an eventual much smaller embedded circuit, then that circuit has to minimize the external parts.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-02-21 03:55 -0600 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <OJudnbK5U6mKcrjMnZ2dnUVZ_qKdnZ2d@supernews.com> |
| In reply to | #19862 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> C for embedded work? C is crude, it has very limited extensibiity..., >> there are IDEs that make up for some of this, but I've never seen >> anything that can approach the ease of development and interactivity >> of an embedded Forth system. > > I'd be interested to know what kinds of features a Forth environment > needs to supply this ease of development. Are you talking about > interacting with a resident Forth on the embedded target? I've used both resident Forths on embedded targets and chipFORTH/umbilical-style systems. On balance, the latter is preferable because the host machine is much more powerful. > Does it have its own way to edit and save and re-run source code > (maybe with blocks/screens), instead of having to keep re-typing it > at a serial port? Oh heavens, yes. I've never done anything like re-typing at a serial port. > If not, did you use some kind of cross-development system and reload > source code from a remote host? I've done that too. > Do those dev environments have a way to start and stop a multi- > tasker so you can inspect task data from an interactive Forth shell? It'd be trivial to add that, but I've never wanted it. As I was saying, if a system is really flexible and comprehensible you don't every debugging facility to be dreamt up by the system's author. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web