ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/29/90)
Category 1, Topic 18 Message 1 Sat Jul 28, 1990 R.BERKEY [Robert] at 00:00 PDT Frank Sergeant writes 900726: >Dennis, thanks for the pF info. I'd like to hear even more about it >from any polyFORTH enthusiasts. I've used polyFORTH and have something of a love/hate attitude toward it. It's been described as the personal programming tool of Charles Moore circa 1978, and he notes that he has made a point of throwing out things that aren't really needed. Yet without knowing the history of things that have been removed, it's not necessarily obvious what's not there, and that there are tools that can be easy to replace when needed. An example involves the type of tasks that can be built. The documentation describes, and the system comes with tools to build, (1) background tasks without terminal I/O, and (2) multi-programmer tasks with terminal I/O and private dictionaries. But with an understanding of the structure, it is relatively easy to build tasks with terminal I/O yet without private dictionaries. Quiet hooks like this, I suspect, are the result of experience. Whether of not this is design, polyFORTH deserves credit for keeping the programmer's potential open. "Don't limit your thinking to the way Forth comes", applies to polyFORTH: Don't limit your thinking to the way polyFORTH comes. I found multi-tasking systems difficult to debug. But perhaps had I seen this as part of the problem of the bug(s) I was fixing, I'd have spent some more time building appropriate debugging tools. Anyone who has ever added record and file locking to a database program in a preemptive multitasking environment might agree that such a programming task can be cumbersome. Read record, read/write record, read file, read/write file...make sure to lock the index file before locking the data file or expect "deadly embrace" from another routine doing it in the opposite order... I still find the block and buffer structure of polyFORTH combined with it's round-robin multi-tasking environment to be somewhat amazing. With the right programming touch, it's simply not necessary to do record and file locking. I've heard database designers agonize over the enormous task of permitting large files to span disk devices. With polyFORTH that capability comes with the design, and therefore already bug free, speed optimized, etc. And round-robin scheduling is a key. Is building multi-tasking difficult? I assumed so until I saw that it can be done in three blocks of code, and with a fast task switcher. Preemptive operating systems may get so involved with scheduling (I've heard) that they can spend half of their processor time just in scheduling. At another level I've found pF unpolished and user hostile. Unconventional names is one aspect--words that look like ones you are used to but that actually do something different. An original designer knows all of the right buttons to push to make something happen. pF might have changed since 1982, but at that time adding a user variable had four scattered and undocumented places that needed to be modified. And the designer also knows pitfalls to avoid. For a simple example, there is an 8086 assembler segment move instruction which uses DEST SOURCE syntax while with the rest of the move instructions the syntax is SOURCE DEST. I can still feel pain from having fallen into various programmer traps in pF. If pF is still like the 1982 versions there may be a long learning curve in store for new users. Yet pF is authentic Forth, which in my opinion is more than can be said about many of the "Forth" systems available today. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
dwp@willett.UUCP (Doug Philips) (07/29/90)
In <1407.UUL1.3#5129@willett.UUCP>, R.BERKEY [Robert] writes: > I've used polyFORTH and have something of a love/hate attitude toward it. > It's been described as the personal programming tool of Charles Moore circa > 1978, and he notes that he has made a point of throwing out things that aren't > really needed. Yet without knowing the history of things that have been > removed, it's not necessarily obvious what's not there, and that there are > tools that can be easy to replace when needed. > . . . > If pF is still like the 1982 versions there may be a long learning curve in > store for new users. From your comments that I quoted (and I didn't intentionally elide anything that I thought would change your meaning) it sounds as if your real contention with pF is that it is poorly documented???? Or is it well documented but some how intrinsicly opaque? > Yet pF is authentic Forth, which in my opinion is more > than can be said about many of the "Forth" systems available today. Are you just rephrasing "New is Good, but Old is Better?" I'm curious to know *why* you have formed that opinion. (From what you said about the capabilities of pF, it doesn't sound like a minimalists system (but I may be wrong).) -Doug --- Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/16/91)
Category 7, Topic 7 Message 6 Sun Jun 16, 1991 D.RUFFER [Dennis] at 01:20 EDT Re: lm03_cif@troi.cc.rochester.edu (Larry Moss) > I'm not incredibly pleased with PolyFORTH or the people on the > phone. Well, as Jack said, you are going to hear about it soon. I work for Forth, Inc. and somewhere around here I let it slip that I work on their polyFORTH systems. I am _very_ concerned that you seem to have gotten the brush off by our hotline personnel and I _will_ talk to him on Monday ;). However, in his defense, I might ask when you called? If it was last week, well he was teaching a bunch of people in an introductory class and that gives him little time to answer phones. No excuse, I know, but you might try again this week. Yes, we do make money teaching Forth, and I highly recommend the course. On the other hand, installation questions should not require a support contract. Did you just buy the system? In which case you do have support for I think 30 days (or something like that). If it is an old system, that someone else has already gotten installation support for, then I must ask how many new users we should help for the sale of one system. Sorry if that question seems somehow to be the wrong attitude, but support and development costs are the kinds of details I have to deal with. Now, about pF/FB320, let me first say that I had nothing whatsoever to do with it and I haven't even used it myself. So my answers probably won't mean much, but I'll give it an attempt anyways. ;) > No low program RAM I've never seen this message on any other pF so I assume it is FB320 specific. I'll have to figure that one out from the system itself, and have someone get back to you with an answer. I'll also have them give you some suggestions about your particular setup. > Error spawning shell This sounds like a problem shelling to DOS. There are two things that typically cause this. First may be that you don't have enough RAM left to spawn another copy of COMMAND.COM _and_ PF.COM. Do you have any _large_ TSR's loaded? The second has to do with the location of COMMAND.COM. If it is not in your root directory, the pF can't find it. I am ashamed to say that we have never "fixed" that particular problem, but the work around is very easy. Just copy your COMMAND.COM to the root directory of the drive that you are running pF from. Please let me know what caused it, since we are perpetuating whatever problem you are having into _all_ our products and I need to squash it rsn. On the towers code, I will refrain from telling you _how_ to code it (:let me know if you want to see my version:). Rather, I'm looking for things that would cause the problems you mention. > : COPY ( X Y Z -- X Y Z X Y Z ) >R 2DUP R@ -ROT R> ; Hmm, you might check that R@ is doing what you think it does. That is a pretty recent addition to pF and your system might not have it. It may not be giving you an error because there is an R@ defined in the system, but it may not be doing what you expect. On the system I have on my computer right now (pF8086/MSD) R@ is defined in the electives on the same block (29) as RECURSE is, so you might want to check that both are doing the right thing. Although, I can't think of anything we may have had with RECURSE as its name. Your comment about both the towers and your number input routines not working make me suspect that this might be the case. If so, then the following will fix you right up: CODE R@ ( - n) FORTH ' I USE > : BACK 8 EMIT ; While this _will_ work in /DOS or /BIOS display modes, from the sounds of things you are using /NATIVE where 8 is just another character. A better definition that will work in everything except /DOS (where it can't position the cursor) is: : BACK L# @ C# @ 1- TAB ; > \ FIX ASCII SO IT WORKS INSIDE OF : DEFINITIONS If your system has ASCII, then it also should have [ASCII]. Just like ' and ['], in polyFORTH you need one for both the compiling and interpreting modes. pF has always been down on "STATE smart" words, and your version of ASCII is one of "them". In case you don't have it, here is the "dumb" way to do it: : [ASCII] ASCII [COMPILE] LITERAL ; IMMEDIATE > If I ever manage to get this to run I'll need to learn how to use > the target compiler next. Hmm, and you think you are having problems now. <grin> Again, I can't recommend the Forth, Inc. programming courses enough for those who want to come up to speed as quickly as possible. The target compiler is covered in the Advanced course quite thoroughly, and unless you have a pF guru handy, you are most certainly going to need some help. I'll try to answer questions as you figure out how to ask them, but the target compiler is certainly _not_ one of those things you just pick up and use. It took me years before I had a really good handle on how it works. Even now (after 10+ years) it can still bite me from time to time. However, you need to know how if your are going to make the FB320 jump through hoops like it should, so fire away and I'll try to help. > The examples in teh manual for that don't seemto work either. From the Reference Manual or from the CPU Supplement? Where the Reference Manual is generic to all pF's, the CPU Supplement is specific to the FB320. Although I've seen worse things than examples not working in our versions, I know how annoying that can be to our customers. Usually it is only a configuration problem, but I will have to look into that one also. BTW, are you going to the Rochester Forth Conference? I will be there Thursday night. If you are there, look for where Sergei is going to be doing the GEnie RTC from. I will be the one running around trying to get it set up in time. Maybe we can find some time to talk about what you are doing. Later! {B-{)> DaR ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/18/91)
Category 7, Topic 7
Message 7 Sun Jun 16, 1991
F.SERGEANT [Frank] at 23:19 CDT
Larry Moss had some comments and questions about polyForth on a TI DSP
chip.
Larry, I was very interested to read your discussion of pF and your
troubles & questions about it. It is on my list to port Pygmy Forth to the
Analog Devices ADSP2101 and ADSP2105 chips. The first customer to send me
three thousand dollars will get my almost undivided attention and effort on
that project, unlimited telephone support, and probably a _custom_ manual!
Otherwise, I'll get to it as I feel like it. You may have already thought of
it and tried it, but if not, here is a tip: When you try to get Towers of
Hanoi running on the DSP Forth, take it a tiny step at a time, to see where
things break down. First, can you connect to the DSP chip, using the PC as
the terminal, type a carriage return and get an OK reply from the DSP Forth?
Next step is to see if you can display the stack. If there is no .S word,
then I recommend the following for a Q&D stack display
: .S ROT DUP . ROT DUP . ROT DUP . ; It only displays the top
3 items, but that's usually enough for your debugging work, and it should
work on _any_ Forth. Then, put three recognizable numbers on the stack (I
would use 99 98 99) and try out the .S to see if it works. Always leave
those three numbers on the stack to identify the top of the stack. Then
start entering and testing each little piece of the T of H code. The point
is to exercise each word, checking the stack before and after, to verify that
the word works the way you expect. This way you can fix the word or fix your
understanding of it. This advice is not directed specifically at you; I
have felt from others' postings that a number of people fail to use this key
power of Forth, ie to walk with certainty by testing, stand-a-lone, each
"subroutine." This still doesn't answer your installation questions or
questions about error messages, but maybe it will help. I'll look forward to
further reports.
-- Frank
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp