[9fans] 9base ports to unix

[9fans] 9base ports to unix

[Anselm R. Garbe]

Hi there,

just wanted to let you know, that I ported following base tools of plan9 to Unix
in a single package, based on Russ' plan9ports:

basename, cal, cat, cleanname, cmp, date, dc, diff, echo, eqn, factor, fmt,
fortune, freq, fsize, grep, idiff, join, ls, mkdir, p, rc, readcons,
rm, sed, seq,
sleep, sort, split, strings, sum, tail, tee, test, time, touch, tr, uniq, wc, xd

All binaries are statically linked (also with the host-OS libraries)
by default. I included libregexp, libbio, libutf and libfmt into lib9
to simplify the build process (the libs are still in separate
directories though, just a question of linking).
All tools don't need mk to be build, because I wrote Makefiles to get
rid of the mk dependency (which would make the package bigger). The
whole package is a tarball with 260kb and can be downloaded here:

http://wmi.modprobe.de/snaps/9base-20050819.tar.gz

(Note, bash-3.0 has about 2,3mb(!!!))

I did so, because for writing rc scripts, which is my favorite
scripting language already, it sucked to be dependent on dynamically
linked bloat binaries from GNU. I measured that a simple sleep call to
the default sleep program of Debian consumes about 2MB memory. Since
sleep might be rarely used, the problem of GNU test still occurs,
which needs the same amount. With times(1) I measured running
equivalent scripts (nearly doing the same) written in bash and rc,
bash using the GNU tools, rc using these 9base tools, and conclude
that rc is about 50 times(!) faster. My suspicion is, that this might
be related to dynamic linking and the overhead on process forks, but
also due to the unnecessary bloat contained in a shell, which has
2,3MB compressed source code.

Before the base port I created a 9rc package, which I already
announced in an earlier stage and which is available separately for
those who are only interested in the original rc (without libregexp
and libbio inclusion to lib9). This package can be downloaded here
(130kb):

http://wmi.modprobe.de/snaps/9rc-20050814.tar.gz

Regards,
--
  Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361

Re: [9fans] 9base ports to unix

[Steve Simon]

Hi,

> I did so, because for writing rc scripts, which is my favorite
> scripting language already, it sucked to be dependent on dynamically
> linked bloat binaries from GNU. I measured that a simple sleep call to

Not wishing to troll, but genuine interest - why do you prefer a port
of plan9's rc to a staticially linked version of Byrons rc rewrite?

For me there is nothing to chose unless you have a lot of scripts from
a plan9 system that tickle the changes Byron made. I find the differences
between Plan9 and Linux sed more of a pain.

-Steve

Re: [9fans] 9base ports to unix

[Anselm R. Garbe]

On 8/19/05, Steve Simon <steve@quintile.net> wrote:
> Not wishing to troll, but genuine interest - why do you prefer a port
> of plan9's rc to a staticially linked version of Byrons rc rewrite?

Because Byron's rc is not conform to Tom Duff's paper and does very
nasty things, the worst is the totally broken if-else syntax, a
sample:

if(foo) {
}
else {
}

is invalid syntax, only

if(foo) {
} else {
}

is valid syntax (why no if not?), if the else branch is supplied in
Byron's rc reimplementation. Beside of that, Byron's rc introduced
many features like readline() support, history support, clunky
builtins etc., which I removed from the source code (beside other
cleanups, like auto*hell removal, you can find my forked/cleaned up
version, which also implements export here:
http://wmi.modprobe.de/snaps/rci-20050809.tar.bz2 (it is based on
rc-1.7.1)).
Also, Byron's shell implements rc-inconform things like `foo as
abbreviation for `{foo} unless foo is a token which does not contain
whitespaces, or the broken flatten operator $^foo instead of the
correct $"foo. The latter annoyences I fixed in rci, but I wasn't able
to fix the if-else handling, because the broken syntax uses some
common grammar tricks also seen in other interpreters which reflect
into the syntax tree walking, - I didn't wanted to replace the tree
walking code in rc(i), thus I lived with the broken if-else syntax.

> For me there is nothing to chose unless you have a lot of scripts from
> a plan9 system that tickle the changes Byron made. I find the differences
> between Plan9 and Linux sed more of a pain.

I think Bryan did a big mistake when designing his rc
standard-incompliant, because that has been the same issue with
sh-style shells already. I could agree that rfork is complicated, and
I could also accept some extensions, but the base language should be
equal in a shell which states to be rc, but which isn't rc in fact,
only some approximation.

Regards,
-- 
  Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361

Re: [9fans] 9base ports to unix

[Scott Schwartz]

I like Byron's version a lot.  The best feature: you don't have to
backslash lines inside a parenthesized list!

Re: [9fans] 9base ports to unix

[Russ Cox]

> I did so, because for writing rc scripts, which is my favorite
> scripting language already, it sucked to be dependent on dynamically
> linked bloat binaries from GNU. I measured that a simple sleep call to
> the default sleep program of Debian consumes about 2MB memory. Since
> sleep might be rarely used, the problem of GNU test still occurs,

I suspect you are confusing VM footprint with memory footprint.
In the case of /bin/sleep, presumably all the shared libraries 
were already in memory and being used by (shared with, if you wil)
other programs.

Russ

Re: [9fans] 9base ports to unix

[Anselm R. Garbe]

On 8/21/05, Russ Cox <russcox@gmail.com> wrote:
> > I did so, because for writing rc scripts, which is my favorite
> > scripting language already, it sucked to be dependent on dynamically
> > linked bloat binaries from GNU. I measured that a simple sleep call to
> > the default sleep program of Debian consumes about 2MB memory. Since
> > sleep might be rarely used, the problem of GNU test still occurs,
> 
> I suspect you are confusing VM footprint with memory footprint.
> In the case of /bin/sleep, presumably all the shared libraries
> were already in memory and being used by (shared with, if you wil)
> other programs.

Yea I know that the execution segments of shared objects are shared
among processes. Anyway, a statically linked sleep uses around 640K VM
(25% of the shared one) in the case of Debian and starts up without
the noticable (50 times) overhead of building the depndency tree for
shared objects (even if it might be cached in some way). I see no
point for dynamic linkage in small programs (well, with firefox, KDE
or Gnome insanity there is no other way, if one determines 20 or 30
dependent shared libs of a single binary and if one has to expect that
all data segments are leaked memory, then at least the exec segments
can be shared to hide amok memory usage to the user...;).

Regards,
-- 
  Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361