haley%lucid@Sun.COM (Mike Haley) (01/07/89)
Iam looking for a "C" interpreter that runs under UNIX. I sure would like to here from anyone who knows of such a package. Thanks -mike haley sun!haley
raeburn@athena.mit.edu (Ken Raeburn) (01/08/89)
In article <84207@sun.uucp> haley%lucid@Sun.COM (Mike Haley) writes: >Iam looking for a "C" interpreter that runs under UNIX. You could certainly do worse than Saber-C, produced by a company called (I think) Saber Software, in Cambridge, MA. I can only say a little bit about the people supporting it. I know one of them, Stephen Kaufer, from when he had an office here at Athena, and I've nothing negative to say about him. He always showed interest in any problems I ran into with the software. (Nice guy, too.) I've also dealt a little bit (quick demo in person, or email) with one or two other people from their staff; they've also been friendly and responsive. Saber runs both source and object code, with a reasonably large amount of sanity checking when interpreting source. (Uninitialized values, pointers out of bounds, accessing an object with a type different from that originally stored there, etc, etc.) There's also lots of load-time cross-checking of declarations and definitions. It also runs in an interactive mode, which interprets shell-like command lines and C source code, with subroutines available that implement all of the commands. (Earlier versions required you to use C statements for everything, i.e.: quit(); load("foo.c"); but version 2 has a more friendly shell-like interface as well.) When errors are flagged at runtime, the user can interrupt execution, run a few commands (examine or modify variables, call other routines) and resume execution or reset everything and run it over. The user-settable options include ANSI or pre-ANSI modes (I don't remember exactly what parameters change here, I always use ANSI); automatic reloading of changed source files (I think even including dependencies on header files); miscellaneous parameters about how to present information to the user; automatic suppression of certain warnings. The latest version we've got, at least (dunno about earlier ones), can handle programs forking; pulls up a new window on your display for the subprocess, etc. (Not sure what it does for terminals; I haven't used this feature much.) Lots of nice stuff. I think the only complaint I had about a recent version (after looking over the documentation) was that there was no way to turn off its interpretation of lint-style comments like /*ARGSUSED*/. At least, I think that was it. (Sorry, it was a while ago, and I haven't used it much lately.) Mmm... make that three complaints. #2: If you're debugging something large from source code, it gets to be slow and requires lots of memory. Sure, it's to be expected, but I can wish. :-) And #3: If your program is big enough, and your system runs out of memory (or you hit your per-process limit), or occasionally with some other types of errors, saber sometimes finds itself unable to recover. As I said, I haven't used it in a while, so I don't remember all the details, and besides, it's probably gotten better since then. I expect there'll be more and better stuff in future versions. (Steve was asking opinions one day along the lines of, "which of these N features would be most useful to see in the next version of saber?" They didn't do 'em all, so maybe in the next version. :) I don't know their street address or phone numbers, but I think Steve reads this newsgroup; he can probably provide you some more info. ~~ Disclaimer: I don't work for these folks, I just use there stuff. I also don't speak for my employers here, but I think they like the product too. :) ~~ ~~ Ken Raeburn / raeburn@athena.mit.edu ~~ systems programmer ~~ MIT Project Athena ~~
seanf@sco.COM (Sean Fagan) (01/09/89)
In article <8688@bloom-beacon.MIT.EDU> raeburn@athena.mit.edu (Ken Raeburn) writes: >Mmm... make that three complaints. #2: If you're debugging something >large from source code, it gets to be slow and requires lots of >memory. Sure, it's to be expected, but I can wish. :-) Somebody gave a talk about Saber-C at the Summer 88 UseNIX (unfortunately, it was all sales fluff. Disgusting). Anyway, the point of this is that somebody from AT&T wanted to know how well Saber-C would handle *really* large functions, say on the order of 3 million lines. The Saber-C Official Sales Fluff Man replied something about 3 million line functions, and getting what you deserved... -- Sean Eric Fagan | "Merry Christmas, drive carefully and have some great sex." seanf@sco.UUCP | -- Art Hoppe (408) 458-1422 | Any opinions expressed are my own, not my employers'.
dymm@h.cs.wvu.wvnet.edu (David Dymm) (01/10/89)
From article <84207@sun.uucp>, by haley%lucid@Sun.COM (Mike Haley): > Iam looking for a "C" interpreter that runs under UNIX. > I sure would like to here from anyone who knows of such > a package. Thanks > > -mike haley sun!haley Stepstone makes a C and C++ interpretor that runs under UNIX. The company is in Menlo Park, CA at 415-329-9816.
geoff@tom.harvard.edu (Geoff Clemm) (01/11/89)
In article <2033@scolex> seanf@scolex.UUCP (Sean Fagan) writes: >In article <8688@bloom-beacon.MIT.EDU> raeburn@athena.mit.edu (Ken Raeburn) writes: >>Mmm... make that three complaints. #2: If you're debugging something >>large from source code, it gets to be slow and requires lots of >>memory. Sure, it's to be expected, but I can wish. :-) This I agree with, BUT ... >Somebody gave a talk about Saber-C at the Summer 88 UseNIX (unfortunately, >it was all sales fluff. Disgusting). This is blatantly false. There were no technical details because most people attending didn't want to know how to write an interpreter -- they wanted to know what would be the advantages of using one, in particular, Sabre's. >Anyway, the point of this is that >somebody from AT&T wanted to know how well Saber-C would handle *really* >large functions, say on the order of 3 million lines. >The Saber-C Official Sales Fluff Man replied something about 3 million line >functions, and getting what you deserved... If this is in fact what the AT&T person asked, then the answer was appropriate - the idea of a 3 million line function is absurd. Hopefully (for AT&T's sake), the conversation is being misquoted, and the question was about 3 million line programs. In Sabre-C you are allowed to link in standard object code with the code you are interpreting -- the fairly reasonable assumption is that you have 50,000 lines of suspect code that you want to interpret, and the other 2.95 million runs as standard object code. I'm not sure what motivates this flaming, since my experience with the Sabre folks is that they are civilized, polite, and interested in satisfying their customers (I have no connection with the company). Geoff Clemm
rogerson@PEDEV.Columbia.NCR.COM (rogerson) (01/11/89)
Why do you need to have 3 Million lines of C source code in the interpeter? Programs are suppose to be developed in modulas. Only the modulas which are not working should be interpreted. All the other modulas can be completely compiled. They only source code you then need is the function definition. The interpreter code flag anything wrong before it gets to the modula, you then correct it and go on your merry way. If you, however, find that the problem is in one of the unworking modulas you can always put the source into the interpreter. Still, you would not need to have such a tremendous amount of source. This should in most cases make the modulas even more stable. Everyone always assumes that you must have EITHER a compiler or an interpreter. Why can't we have both. -----Dale Rogerson-----
cramer@athens.iex.com (Bill Cramer) (01/21/89)
I have some marketing info on my desk about a C interpreter product
called "Safe-C" from Catalytix Corporation. It looks real nice on paper
and runs on darn near any Unix environment (not just Sun and VAX, as does
the other interpreter, Saber-C already mentioned in previous postings).
They also have a pretty slick runtime analysis package. Their address is:
Catalytix Corporation
55 Wheeler St
Cambridge, MA 02138
(617)497-2160)
Please note that I have no hands on experience with this product; we are
only considering buying it. If anyone out there has some real exposure,
I'd appreciate a followup posting or email to me.
Bill Cramer
IEX Corporation
Plano, Texas
{uunet,killer,convex}!iex!cramer