------- start of forwarded message (RFC 934 encapsulation) -------
Received: from bloom-beacon.MIT.EDU by martigny.ai.mit.edu with ESMTP
(1.40.112.8/16.2) id AA040521446; Sat, 20 Dec 1997 07:37:26 -0500
Return-Path: <scsh-request@martigny.ai.mit.edu>
Received: (from news@localhost) by bloom-beacon.MIT.EDU (8.7.6/25-eef) id
HAA29426 for scsh-news@martigny.ai.mit.edu; Sat, 20 Dec 1997 07:37:11 -0500
(EST)
Received: from USENET by bloom-beacon with netnews
for scsh-news@martigny.ai.mit.edu (scsh-news@martigny.ai.mit.edu);
contact usenet@bloom-beacon if you have questions.
Message-Id: <01bd0d41$98b6e400$0f02000a@gjchome.nis.newscorp.com>
Organization: Delphi Internet Services <http://www.delphi.com/>
From: "George J. Carrette" <gjc@delphi.com>
To: scsh-news@martigny.ai.mit.edu
Subject: How does scsh compare to using SIOD with "#!/usr/local/bin/siod"
scripts?
Date: 20 Dec 1997 12:25:50 GMT
This newsgroup evidently had enough interest to get created, but it
sure doesn't have much activity if you filter out the crossposted articles,
the FAQ and the spammers.
Perhaps some discussion could happen on the more general topic of
people's experiences using Scheme for "shell script" programming in general
and not just focused on a single particular implementation.
For example in SIOD there was some emphasis on minimizing startup overhead,
and as such it has proved to be practical for cgi script programming, and
general
unix command programming, where users aren't even aware what language is
being used. For example in http://people.delphi.com/gjc/siod.html
you will find an http client, and http proxy server, ftp and smtp client
software,
a directory-tree snapshot and comparision utility, some "tar"
functionality,
as examples and practical utilities. Others have implemented a "majordomo"
compatible mailing list processor.
I would never consider replacing my unix "shell" with SIOD, because
replacing
your shell with anything not POSIX "ksh" compatible causes serious problems
with commonly distributed makefiles and other software.
Also the "replacing your shell" paradigm doesn't port very well to
other non-unix environments. But the "#!" paradigm does, in fact, port.
The distribution http://people.delphi.com/gjc/siod.html
has a "csiod" command, which is a kind of "linker/binder"
for scheme source files which produces native executables.
On Unix of course this does nothing except copy the data
into a file starting with "#!/usr/local/bin/siod" and with execute mode
bits set.
On Windows (95/NT) and on VMS it instead copies an executable bootstrap
program followed by the data.
Old timers will recall the package from Yale University which was so good
at bootstrapping shared TOPS-20 executables using MIT's PDP-10 MACLISP.
The use of this technique was instrumental in the success of Sussman's
and Ableson's first Scheme-based subject work which was required of
every MIT undergraduate in electrical engineering, circa 1981.
Without this technique the Scheme system would have run just as horribly
as the CLU system running on the same machine. In fact, probably worse.
It is also possible that the use of the interactive scheme-syntax
rubout-handler
caused all the maclisp programs to stay "realtime active" with respect to
the
scheduler, forcing those using CLU to be treated as more background
oriented
tasks.
I digress into these old war stories only to illustrate the subtle nature
of
what makes a good application programming language from a system
point of view.
What is the current state of the art? I'm afraid considerably less than it
was 15 years ago.
We need to relearn techniques involving memory-mapped position-independant
(that would make things easier) shared data structures.
Steam-clean off the accumulated dust and hardened-fat from spending so many
years living with BSD-Unix style limitations.
------- end -------
>From bdc@martigny.ai.mit.edu Sat Dec 20 13:00:39 1997
Received: from berne.ai.mit.edu by martigny.ai.mit.edu with SMTP
(1.40.112.8/16.2) id AA170820839; Sat, 20 Dec 1997 13:00:39 -0500
Resent-Date: Sat, 20 Dec 1997 13:00:39 -0500
Resent-From: Brian D. Carlstrom <bdc@martigny.ai.mit.edu>
Resent-To: scsh-list@martigny.ai.mit.edu
Return-Path: <scsh-request@martigny.ai.mit.edu>
Message-Id: <01bd0d41$98b6e400$0f02000a@gjchome.nis.newscorp.com>
Organization: Delphi Internet Services <http://www.delphi.com/>
From: "George J. Carrette" <gjc@delphi.com>
To: scsh-news@martigny.ai.mit.edu
Subject: How does scsh compare to using SIOD with "#!/usr/local/bin/siod"
scripts?
Date: 20 Dec 1997 12:25:50 GMT
This newsgroup evidently had enough interest to get created, but it
sure doesn't have much activity if you filter out the crossposted articles,
the FAQ and the spammers.
Perhaps some discussion could happen on the more general topic of
people's experiences using Scheme for "shell script" programming in general
and not just focused on a single particular implementation.
For example in SIOD there was some emphasis on minimizing startup overhead,
and as such it has proved to be practical for cgi script programming, and
general
unix command programming, where users aren't even aware what language is
being used. For example in http://people.delphi.com/gjc/siod.html
you will find an http client, and http proxy server, ftp and smtp client
software,
a directory-tree snapshot and comparision utility, some "tar"
functionality,
as examples and practical utilities. Others have implemented a "majordomo"
compatible mailing list processor.
I would never consider replacing my unix "shell" with SIOD, because
replacing
your shell with anything not POSIX "ksh" compatible causes serious problems
with commonly distributed makefiles and other software.
Also the "replacing your shell" paradigm doesn't port very well to
other non-unix environments. But the "#!" paradigm does, in fact, port.
The distribution http://people.delphi.com/gjc/siod.html
has a "csiod" command, which is a kind of "linker/binder"
for scheme source files which produces native executables.
On Unix of course this does nothing except copy the data
into a file starting with "#!/usr/local/bin/siod" and with execute mode
bits set.
On Windows (95/NT) and on VMS it instead copies an executable bootstrap
program followed by the data.
Old timers will recall the package from Yale University which was so good
at bootstrapping shared TOPS-20 executables using MIT's PDP-10 MACLISP.
The use of this technique was instrumental in the success of Sussman's
and Ableson's first Scheme-based subject work which was required of
every MIT undergraduate in electrical engineering, circa 1981.
Without this technique the Scheme system would have run just as horribly
as the CLU system running on the same machine. In fact, probably worse.
It is also possible that the use of the interactive scheme-syntax
rubout-handler
caused all the maclisp programs to stay "realtime active" with respect to
the
scheduler, forcing those using CLU to be treated as more background
oriented
tasks.
I digress into these old war stories only to illustrate the subtle nature
of
what makes a good application programming language from a system
point of view.
What is the current state of the art? I'm afraid considerably less than it
was 15 years ago.
We need to relearn techniques involving memory-mapped position-independant
(that would make things easier) shared data structures.
Steam-clean off the accumulated dust and hardened-fat from spending so many
years living with BSD-Unix style limitations.
|