ADRIAN@vax.oxford.ac.uk (08/04/90)
TDS3 (D700E) Transcendent Development System ============================================ I think that I was a little carried away in my objections to aspects of iserver. I concede that *strictly* the iserver does not *quite* violate the occam/csp communication sematics. And I was wrong in stating that the source of the full TDS editor is provided with the ordinary binary release. What you do get is the source of an "EDUTIL utility bundle". By the way, you may have to do a little research to discover the support for the Toolset, which is not advertised. A couple of comments in reply to Neil Youngman: =============================================== >>It's pretty easy, just define procedures instead of nesting folds 10 deep. I actually find that a lot less helpful than folding, but you do need to make folds easy to use: a keyboard template, and a decent hard copy facility (see below). >> The way a lot of people I know use folds makes hard copy unreadable. Also Sure, I totally agree about unreadable *hard copy* without additional tools. That's why one of my very first EXEs when I first had a TDS or OPS or whatever it was called in those days was a proper FOLDED LISTER. I have an EXE which primarily produces hardcopy for PostScript, but also for various dot matrix printers, a colour inkjet and so on. The PostScript version places "boxes" around open folds, with the fold headers in "inverse video". But all versions provide some way to keep track of indentation, even across page boundaries. At a terminal, folded source and SCs are excellent. For hard copy, I usually use my PostScript program to produce readable source. If people would like an example, I could post a listing to the net: a PostScript program is of course plain ASCII. I might even be persuaded to give copies of the EXE away! >> they tend to duplicate code instead of encapsulating it in PROCs. Well, any tool can be misused. I must admit that I have seen many examples of *dreadful* folded programs. Unfortunately, some of the public domain occam sources are terrible examples of programming style and folding. The first issue of TDS did not have #USE libraries. That did sometimes result in duplicated folds. But TDS2 and TDS3 have very good facilities which mean that even those cases can be eliminated. >>>... Iserver >Excuse me while I puke :-) Yes, we all agree, don't we? But it *must* be good - it's written in C!! (?) >I haven't tried the toolset, but I regard the TDS editor as preetty cumbersome. >If I'm not on my regular m/c I keep getting control instead of ALT and so on. >It has taken me about a year to learn all the key combinations I should know >and I still get them wrong occasionally. I frequently find that I try to use Well, I make a keyboard template. And I would be lost and irritated if I had to remember (or even call up the help page for) all those funny key combinations. If you don't use a template, I am not at all surprised that you find the TDS unfriendly! I suspect that I would put my fist through the screen pretty quickly in those circumstances!!! In case you are wondering, I use colour coding to identify control or ALT or SHIFT combinations. Again, in beta test, including a template with the TDS was considered: that was rejected because of the variety of different keyboards. But there is something in the manual. By the time I volunteered to provide a set of PostScript files for all the common keyboards, it was too late. The product release was frozen. (But I guess that I could put that on the net as well if it is a useful use of bandwidth...) >compiler utilities when I have the file handler loaded and so on ad nauseam. Yes, I make this mistake as well now and again. Any suggestions about improving this on the next release? Should there be another status line somewhere displaying current utility/exe names? Don't forget that it is to be portable across hosts, so you can't assume any fancy window facilities. But I am impressed that the key allocations are such that such an error is never catastrophic! >Can I now get the function keys to match my word processor (Word ImPerfect) to >remove one source of problems. Yes!! This is one of the many new features that I did not mention. You can customize the mapping of function keys in any way that you choose. There is a simple ASCII file TDS3.ITM which defines the mapping of the host keyboard and screen onto the TDS3 functions. >>My experience is that those who persevere come to be very enthusiatic. And >Not me Give it a fair try. Use a template. Use a decent hardcopy lister. Anyone would detest it without these little embellishments. Find an enthusiast and pick up a few "tricks of the trade"! But Ok, maybe it's not for you? I am of course over reacting to those who complain without giving it a serious trial: you are obviously not one of those. >Is the folding environment essential? Why? Well, I simply can't follow occam text without folding. In fact, it seems that we *agree absolutely* on this. *Plain occam text* on paper is very difficult. For a program of any complexity, I loose trace of the indentation. It appears that your solution is lots of #INCLUDES, and separate listings for each module. That is the sort of thing I used do with sequential languages. But now I use folding for all my programming (C, PostScript, BCPL, Pascal,..). On the screen, there is no problem, provided you use folding properly. And I have written this EXE (advertisement above!) that completely solves the problem on paper. The problem that I have with lots of separate module listings is keeping them in order, dropping them on the floor, referring to several at once. Folding is *so much* easier, cleaner and elegant! >Can't avoid it and have learn't to love the good bits and ignore the bad bits? It's not perfect! But what about suggesting how to enhance/eliminate the bad bits? Have you been passing you comments back so that the next release can be improved to match your needs? Inmos is very receptive to suggestions, so long as they are practical, and achievable with available resources. Adrian Lawrence ---------------------------------------------------------------------------- ADRIAN @ UK.AC.OXFORD.VAX Microprocessor Unit, Oxford University, 13,Banbury Road, Oxford, Oxon. OX2 6NN. UK. ---------------------------------------------------------------------------- EARN/Bitnet: ADRIAN%UK.AC.OXFORD.VAX@AC.UK {EARN node UKACRL} ARPA: ADRIAN%VAX.OXFORD.AC.UK ACSnet: adrian@vax.oxford.ac.uk@au.oz.munnari [ean.ac.uk%nummari.cs.mu] -----------------------------------------------------------------------------