Re: [9fans] 9base ports to unix
On 8/21/05, Russ Cox <[EMAIL PROTECTED]> 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
Re: [9fans] 9base ports to unix
> 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
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
On 8/19/05, Steve Simon <[EMAIL PROTECTED]> 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
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
[9fans] 9base ports to unix
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