[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. Garbewww.ebrag.deGPG 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] plan9 and the Unicode Consortium definitions
I am just wondering whether any API to access more complete set of character properties defined by Unicode.org is available in Plan9. So far I have seen only library functions like isalpharune(2) defined in runetype.c, but it does not cover all the character categories defined by the Unicode Consortium. Something might be expected in the Section 7 of manpages, might not it? BTW I've got some code I wrote earlier for Hugs and Glasgow Haskell Compiler, which is autogenerated from UnicodeData.txt (runetype.c seems to be manually hardcoded, or at least there is nothing in the mkfile that shows how it was generated). If there is any interest, I may send a link. My code is based on the same princilpes as I see in runetype.c: binary search over sorted lists of character ranges. Another question: is (historical) 16-bitness of runes a limitation of the C runtime library only, or is the kernel rune-size-aware, too? Because what Unicode.org defines is wider than 16 bits, as everybody knows. Unless there is any intentional divergence from the Unicode.org definitions. PS I looked at the sources mirror at 9grid.de, and manpages at the Bell Labs website. Outdated? -- Dimitry Golubovsky Anywhere on the Web
Re: [9fans] plan9 and the Unicode Consortium definitions
Good day. On Fri, 19 Aug 2005 10:51:07 -0400 Dimitry Golubovsky [EMAIL PROTECTED] wrote: PS I looked at the sources mirror at 9grid.de, and manpages at the Bell Labs website. Outdated? From this morning. Sincerely, Christoph
[9fans] plan9 and the Unicode Consortium definitions
Andrey, Andrey wrote: I am just wondering whether any API to access more complete set of character properties defined by Unicode.org is available in Plan9. you mean things like diacritics? I mean character categories defined in http://www.unicode.org/Public/4.1.0/ucd/UCD.html#General_Category_Values Abbr. Description Lu Letter, Uppercase Ll Letter, Lowercase Lt Letter, Titlecase Lm Letter, Modifier Lo Letter, Other Mn Mark, Nonspacing Mc Mark, Spacing Combining Me Mark, Enclosing Nd Number, Decimal Digit etc., total about 30 or so. isxxxrune distinguishes only among 5 categories. This would probably inlcude diacritics, but my question was more general (maybe even philosophical): there exists a recommended set of Unicode character properties, APIs, and interfaces (Unicode.org). Plan9 which probably influenced some aspects of Unicode to be implemented in other systems does not follow. Is there any historical /political /technical /other reason? Related man pages mention The Unicode Standard though in SEE ALSO section. What is more interesting to me (technically, as I asked in my first message) - is 16-bitness of runes hardcoded anywhere in the kernel, or only in libc? -- Dimitry Golubovsky Anywhere on the Web
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!
[9fans] acme core
i fat fingered some combination of b2 and something else and got this core: is this a linuxthreads vs. nptl problem? erik --- ; found 0 at 2 (h=1) myperproc 1: cannot find self ; ls -l /home/quanstro/src/elocate/core.31684 -rw--- 1 quanstro users 11911168 Aug 19 17:07 /home/quanstro/src/elocate/core.31684 ; stack /home/quanstro/src/elocate/core.31684 abort() called from myperproc+0x82 myperproc() /home/quanstro/plan9/src/libthread/Linux.c:368 called from _threadproc+0xb _threadproc() /home/quanstro/plan9/src/libthread/Linux.c:395 called from needstack+0x14 needstack(n=0x200) /home/quanstro/plan9/src/libthread/thread.c:380 called from chanalt+0x1a chanalt(a=0xb7995230) /home/quanstro/plan9/src/libthread/channel.c:253 called from _chanop+0x32 _chanop(c=0x810ff50, op=0x1, p=0xb7995310, canblock=0x1) /home/quanstro/plan9/src/libthread/channel.c:327 called from chansend+0x2a chansend(c=0x810ff50, v=0xb7995310) /home/quanstro/plan9/src/libthread/channel.c:333 called from _ioproc+0xf3 _ioproc(arg=0x810ff08) /home/quanstro/plan9/src/libdraw/x11-mouse.c:134 called from threadstart+0x18 threadstart(y=0xb7955008, x=0x0) /home/quanstro/plan9/src/libthread/thread.c:93 called from makecontext+0x44 ; core /home/quanstro/src/elocate/core.31684 stack /home/quanstro/src/elocate/core.31684 # Fri Aug 19 17:07:54 CDT 2005 # acme -f /home/quanstro/plan9/font/code2000/code2000.12.font
