home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.linux
- Path: sparky!uunet!utcsri!newsflash.concordia.ca!garrot.DMI.USherb.CA!uxa.ecn.bgu.edu!mp.cs.niu.edu!linac!uwm.edu!caen!destroyer!gumby!yale!yale.edu!ira.uka.de!math.fu-berlin.de!mailgzrz.TU-Berlin.DE!cs.tu-berlin.de!alaspin!schli
- From: schli@cs.tu-berlin.de (Wolfram Schlickenrieder)
- Subject: Re: Tcl to replacement most of /bin & /usr/bin (was: Tcl on Linux machines.)
- In-Reply-To: jjensen@convex.com's message of Tue, 17 Nov 1992 19:27:36 GMT
- Message-ID: <SCHLI.92Nov17215553@alaspin.cs.tu-berlin.de>
- Followup-To: comp.os.linux
- Sender: news@cs.tu-berlin.de
- Organization: Technical University of Berlin, Germany
- References: <1992Nov13.022712.16069@twg.com> <1992Nov17.192736.4260@news.eng.convex.com>
- Date: Tue, 17 Nov 1992 20:56:08 GMT
- Lines: 34
-
-
- jjensen@convex.com (James Jensen) writes:
-
- > "David Herron" <david@twg.com> writes:
- > -
- > - - ***SMALLER*** disk space requirements. (and smaller memory
- > requirement)
- > -
- > - - More easily customizable environment, with customizations
- > (sometimes)
- > - just behind the front end of the tools.
- > -
- > - - Have the inner functionality of the tools made available in some
- > sort of
- > - script/program environment for building new tools. Particularly for
- > - writing little X based interfaces ...
- > -
- >
- > A more elegent and easier solution would be
- > to modify gcc to produce code for an interpreter.
- > The interpreter would be part of a shared library.
- > This would save the disk space. If gcc produced the
- > same internal code as Tcl or perl then your second two
- > goals would be met, I think.
-
- Yeah, why not write a small Linux-interpreter to interpret the
- source?!? :~}
-
- Honestly: The optimization criterion number one was speed,
- at least if you ask me and everyone I know... My question is:
- Are the "binaries" produced by Tcl as fast as the "real"
- binaries?
-
- ...Wolfram
-