9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Chris Locke <chris@cjl1.demon.co.uk>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Mash
Date: Mon, 17 Jul 2000 09:12:42 +0000	[thread overview]
Message-ID: <963777053.17893.0.nnrp-01.c2de4822@news.demon.co.uk> (raw)
In-Reply-To: <200007161750.NAA09238@cse.psu.edu>

If you are interested in Mash you should check out
the new Inferno shell.

There's a short paper on it here...
http://www.vitanuova.com/papers/sh.html
and a man page here...
http://www.vitanuova.com/man/1/sh.html
oh, and here is the mash man page...
http://www.vitanuova.com/man/1/mash.html

Mash was a great improvement on the original Inferno
shell but suffered some problems itself.
It is made fatter by the specific pattern/dependency list
syntax built into the parser.  I struggled to find a use for
this outside of the make 'plug-in'.
Most users aren't running make in the shell all the time, so
we have a bunch of code (and remember that Inferno was originally
intended for small devices) built in to the shell that, under
normal usage, serves no purpose.

There was also a problem with sharing 'contexts'.
For example, when using the graphical Mash shell (wm/mash)
you can use the tk 'plug-in' to create buttons that act as
command shortcuts - when clicked they spit out a command as if
it had been typed.  However, they don't work if you run
a sub-shell (e.g. mash) in the wm/mash window.  The 'commands'
are buffered up until the sub-shell exits.

Another problem was that the dependency syntax wasn't the same
as mk or make.  On several projects I looked at setting up
mash-make files.  I tend to develop for Inferno on Plan9 using
Acme and the host limbo compiler because it is faster at compiling
than the Inferno (.dis) based limbo compiler.  Consequently I found
that to use mash-make I was having to maintain two different
'mkfile's.  This was too much bother so I stuck with mk on Plan9
and the minor inconvenience of having to make sure my Plan9/Inferno
namespaces overlapped.

It would have made for a very interesting paper for USENIX,
it would have been one of the few interesting things there.
The proceedings were incredibly dull this year
(apart from Rob's "getting dot dot right", which was a delight).

Chris Locke.

P.S. to BruceE, I didn't mean to be harsh on Mash, it really is a
nice piece of work, any chance of posting up your paper?


  reply	other threads:[~2000-07-17  9:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-16 17:50 brucee
2000-07-17  9:12 ` Chris Locke [this message]
2000-07-18  6:27   ` Lucio De Re
2000-07-16 22:20 brucee
2000-07-17  0:57 pip
2000-07-16 21:49 ` Boyd Roberts
2000-07-17  2:01 pip
2000-07-16 22:21 ` Boyd Roberts
2000-07-18  7:42 forsyth
2000-07-18  8:18 ` Lucio De Re
2000-07-18  8:24   ` Lucio De Re
2000-11-02 13:20 [9fans] mash rob pike
2000-11-02 15:54 ` Rick Hohensee
2000-11-03  9:27   ` Leo Caves
2000-11-03 17:25 rog

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=963777053.17893.0.nnrp-01.c2de4822@news.demon.co.uk \
    --to=chris@cjl1.demon.co.uk \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).