[9fans] first questions from a lurker
Hello All. I've been a lurker on 9fans for many years. Today I finally did an install - +9atom.iso.bz2 into a virtual box VM. The VM is NAT'ed to a corporate network and I can ping by IP address with no problem. First questions. 0. How to see my IP address? Cat a file in /net/... somewhere? 1. How to change the hostname - just edit /rc/bin/termrc and choose whatever I want to echo into /dev/sysname? Will that get reflected back out to the corporate net via DHCP? 2. How to use DHCP to get to the corporate DNS servers? (This worked pretty much OOTB on the labs dist, but I think that 9atom will be the better match for the work we want to do.) Right now all hostname lookups (via ping) fail. Unrelated: 3. I would like to generate a PDF (or even .PS file) of Volume 1 of the manual. What's in the dist has dates from over 10 years ago. I tried running 'mk print.out' in the manual directory (as glenda) but got an error. (Erik - can you do that automatically as part of your build process? :-) So. How can I produce such a file suitable for duplex printing? (Bonus points if the intro(N) page of each section comes out first. :-) Please go easy on the Plan 9 newbie who has to unlearn 30+ years of Unix habits. Thanks! Arnold
Re: [9fans] first questions from a lurker
And of course, I forgot another question: 4. How to do the moral equivalent of shutdown -h now? Thanks, Arnold - arn...@skeeve.com wrote: > Hello All. > > I've been a lurker on 9fans for many years. Today I finally did an > install - +9atom.iso.bz2 into a virtual box VM. The VM is NAT'ed > to a corporate network and I can ping by IP address with no problem. > > First questions. > > 0. How to see my IP address? Cat a file in /net/... somewhere? > > 1. How to change the hostname - just edit /rc/bin/termrc and choose >whatever I want to echo into /dev/sysname? Will that get reflected >back out to the corporate net via DHCP? > > 2. How to use DHCP to get to the corporate DNS servers? (This worked >pretty much OOTB on the labs dist, but I think that 9atom will be >the better match for the work we want to do.) Right now all >hostname lookups (via ping) fail. > > Unrelated: > > 3. I would like to generate a PDF (or even .PS file) of Volume 1 of the > manual. What's in the dist has dates from over 10 years ago. I tried > running 'mk print.out' in the manual directory (as glenda) but got > an error. (Erik - can you do that automatically as part of your build > process? :-) So. How can I produce such a file suitable for duplex > printing? (Bonus points if the intro(N) page of each section comes > out first. :-) > > Please go easy on the Plan 9 newbie who has to unlearn 30+ years > of Unix habits. > > Thanks! > > Arnold
Re: [9fans] first questions from a lurker
Pardon my not replying individually - thanks all of you for the answers! I'm looking forward to climbing this learning curve. :-) Arnold
[9fans] 9atom ISO images?
Hi. What is the status of the 9atom ISO images? I have a laptop that I think is too old to boot from USB that perhaps I can put Plan 9 on... Thanks, Arnold
Re: [9fans] [GSOC] fast kernel compile
> also, quite a bit that is unaccountably still in other kernels ("because
> Unix did it exactly that way in the 1970s on a PDP-11")
I think that "unaccountably" is a bit harsh. There is A L O T of old
Unix software that still just compiles and works out of the box on
Linux, Solaris, *BSD. There is a lot of value to that, when what you
care about is getting your work done (KTBR - Keep The Business Running).
I well understand that this community is less concerned about that,
but this community should also be open minded enough to understand
those kinds of concerns.
Arnold
Re: [9fans] [GSOC] fast kernel compile
Charles Forsyth wrote: > On 6 May 2014 09:38, wrote: > > > I think that "unaccountably" is a bit harsh. > > > I was talking about kernels and kernel mechanisms. Fair enough then. Thanks, Arnold
Re: [9fans] unicode 7.0.0 support
erik quanstrom wrote: > too bad there's no "carrie fisher with bazooka". :-) They had to leave something for the upcoming 8.0 standard. :-) (Blues Brothers - what a wonderful movie. I saw it again a few months ago for the first time in (ahem) decades. To quote Terry Pratchett: "We're on a mission from Glod." :-) Arnold
Re: [9fans] troff documentation link broken
Carsten Kunze wrote: > The whole paragraph does not make sense if .ul is used. Why defining .us > and not using it. This is a typo. troff doesn't underline by itself. > One way is to write a custom macro (as .us) or use ms macro's .UL. > .ul only underlines in nroff. Please remember that the document applies to both nroff and troff. For nroff (terminals, printers), .ul does underlining. For typesetters (includes laser printers) troff .ul does italics. The .us macro shows how to get real underlining on a typesetter device. Evolution plays a part here. The original formatter was nroff for printers and teletypes. Troff came along later, at which point .ul was already in use in people's documents and/or macro packages. HTH, Arnold
Re: [9fans] Announcing The Virtual Plan 9 Server Cookbook
Hi. This looks wonderful. Is it available in a PDF or more paper oriented format, for us old fogeys? Thanks, Arnold "David L. Craig" wrote: > This is the publication I wished I had had several > months ago, so I decided to write it. With hundreds > of screen shots and a few choice scripts (the main one > based on maht's make_cpuauth contribution to Plan 9), > it walks a UNIX sysadmin of modest experience through > installing Debian Sid onto an x86_64 box capable of > full-virtualization and then installing a virtual Bell > Labs Plan 9 computer therein and transforming it from > a stand-alone non-networked terminal configuration > into an Internet-capable cpu/auth server. > > This alpha version has all the information needed to > do this--only the Overview section remains to be > written. I would like to get other folks' evaluations > of the work so it can be improved. It is released > under Creative Commons Attribution/Share-Alike and GPL2. > > I really hope it is helpful to a lot of people as time > goes by. > > http://dlc.casita.net/~dlc/vp9cb/index.html > -- > > May the LORD God bless you exceedingly abundantly! > > Dave_Craig__ > "So the universe is not quite as you thought it was. > You'd better rearrange your beliefs, then. > Because you certainly can't rearrange the universe." > __--from_Nightfall_by_Asimov/Silverberg_
Re: [9fans] silly question
"Steve Simon" wrote: > I want to process some dated logfiles in awk. > > gawk has date, strftime and mktime but Brian's does not. > > plan9 has date(1) but there is no tm2sec(1), unless it > is called somthing I didn't expect. > > Anyone found somting I could not in the plan9 distribution? > > -Steve I'd be happy to know the results of attempting a gawk port via APE. :-) Thanks, Arnold
Re: [9fans] silly question
> > I'd be happy to know the results of attempting a gawk port via APE. :-) > > There is one > > http://ports2plan9.googlecode.com/files/gawk-4.0.0b.pkg.tbz > > or > /n/sources/contrib/staal1978/pkg/gawk-4.0.0b.pkg.tbz 4.0.0 is around 3 years old. Current version is 4.1.1. Although this one would do for Steve who wanted time functions. Thanks, Arnold
Re: [9fans] silly question
"Steve Simon" wrote: > > I'd be happy to know the results of attempting a gawk port via APE. :-) > > Not sure Al, Peter, or Brian would forgive me :-) > Though if memory serves it has been done already. > > -Steve Brian is a good friend of mine. He (at least) wouldn't mind. :-) Arnold
Re: [9fans] glendix
kokam...@hera.eonet.ne.jp wrote: > > http://www.glendix.org/ > > Please show me short summary of differences > between p9p and this. > The major aim seems to be the same to me, > that is, to avoid to write <<>>. > > Kenji > Glendix isn't maintained; I looked at the git and the last check-in was over 5 years ago. It's aim is to run Plan 9 binaries, which means putting P9 system calls into the Linux kernel. p9p is a port of the P9 utilities to *nix; userland only. HTH, Arnold
[9fans] [Off topic] Raspberry Pi 2 gets the evil OS
>From the "Be Still My Beating Heart" department: http://dev.windows.com/en-us/featured/raspberrypi2support
[9fans] whence kenc for linux?
Hi. Where's the right place to find kenc for Linux? Thanks, Arnold
Re: [9fans] ken cc for linux
Hi All. Thanks for the clarifications about ken's compiler. I don't know that I'll bother going to the go dist right now. > Gawk has been compiled with APE, I was mearly suggesting it might > be helpful to Aharon if this was repeated to confirm the continued > portability of the gawk code. I appreciate and accept your offer. To get the current code: git clone http://git.savannah.gnu.org/r/gawk.git cd gawk git checkout gawk-4.1-stable ./bootstrap.sh && ./configure && make && make check If you can't get to git from APE, then on Linux do the above and add make dist to create tarballs. The bootstrap.sh file merely sets timestamps. No autotools required! :-) Steve, feel free to continue the discussion with me off list, but please change the subject line so that your mail won't get squirrelled off into the 9fans mailbox by accident. Thanks! Arnold
[9fans] using git
Changed the subject line. Jeff Sickel wrote: > Alas, having git on Plan 9 may not be all that useful for me as git is > the first revision control tool I’ve used where the commands and overall > structure begs for a GUI to make sense of it all. I guess that’s what all > the web interfaces and forks are for… I beg to differ. I've been using it for 4+ years now. I can't stand the git GUI (at least the one on windows). There is definitely some learning curve and mindset change, but day-to-day use involves only a handful of commands. The O'Reilly book on Git is a reasonable way to learn it. I haven't used hg or bzr, but compared to svn and cvs, git is light years ahead. This is also true of some of the commercial variants such as Perforce and TFS. I know some real git fanatics. I'm not one, but I am a "fan". :-) I'll be happy to continue a discussion with you offline, if you wish. Thanks, Arnold
Re: [9fans] using git
Charles Forsyth wrote: > On 19 March 2015 at 16:09, wrote: > > > There is definitely some > > learning curve and mindset change > > Just what I want from a little servant that's supposed to help me manage > some file changes. Git is intended for something completely different than RCS. I really, REALLY, don't want to start a flame war, although this being 9fans, it's probably not possible. More's the pity. And again, I AM NOT trying to proselytize. But, if you are curious as to what value I personally found in git for gawk development, I will be happy to discuss it in personal email. If you don't care, then fine. I do still maintain that if you go to the trouble to learn git, daily use reduces to around 6 commands, no GUI required, or desirable. And I agree, an fs layer over git would be a wonderful Plan 9-style thing to have. That's all I really have to say about it. I'll go crawl back under my rock now. Arnold
Re: [9fans] using git
Hi All. Giacomo Tesio pretty much expressed the flow. For me, the cheap branching and excellent merging are extremely important, esp. as compared with earlier systems like subversion. The distribution development is also a huge boon; I have several contributors with write access to the main git repo; when one of them has a change that's been reviewed and is ready to go, or a bug fix, they can just commit it to the main repo and then I can get it. Like many people (I suspect), my experience was RCS -> CVS - Subversion -> Git I haven't tried the other systems, and I'm sure they all have their strengthes and that there are things I could learn from them. Git has the advantage of currently being the most popular, and also of being quite fast. A gitfs for Plan 9 sounds wonderful and there appear to be options for getting there, but it may be enough for most people to just use Linux as a bridge. Thanks, Arnold
Re: [9fans] Ports tree for Plan 9
lu...@proxima.alt.za: > It may be worth twisting Aaron's arm, he may well have a test suite > for GAWK that can be used here? The gawk test suite is part of the dist. See test/Makefile.am for the list of tests that are general and those that are gawk specific. I've tried to keep the separation clean. Kurt H Maier wrote: > Current status: the only failures are bizarre corner cases, but > presumably they're in the testsuite for a reason? Yes - people will do anything they can. Experience has taught me that even bizarre corner cases need to be handled. > Native awk is slower than APE awk, and Paul mentioned he thinks it's > because of the malloc implementation. BWK has said that malloc affects the performance of his awk; I think it's in his README file. > [1] http://code.9front.org/awk I can't get to this with a browser. How does one get the source? Is it intended to run on *nix also? It'd be nice to have since it's always fun to compare multiple implementations when trying to figure out a corner case. Besides BWK's awk, there is mawk, BusyBox awk, and the MKS awk as found in the various OpenSolaris derivatives. Thanks, Arnold
Re: [9fans] Ports tree for Plan 9
Kurt H Maier wrote: > I mangled some webshit earlier today on that server (bad timing I guess). > Correct link to the hg repo is https://code.9front.org/hg/awk This appears to be based on Brian Kernighan's awk from sometime in 1999 and not written from scratch. There have been many fixes to BWK's code since then. If you're going to start over, it should be done from his current code, available from his Princeton home page. Arnold
Re: [9fans] Ports tree for Plan 9
> Have the MKS sources ever been released? I don't believe so. I think they were the basis for z/OS, which is a POSIX environment on top of IBM's MVS. The MKS awk made its way out into the world via Solaris, which for some reason chose that code base, instead of a more recent version of BWK's awk, for their POSIX awk. Quite some time ago I ported it to Linux; it took an hour or so. It'd take more work to make it generally portable, which I never bothered to do. Arnold
Re: [9fans] Gawk in 9front-ports
Hi.
Jens Staal wrote:
> There was a recent discussion about that it would be nice to have gawk on
> Plan9.
>
> The latest upstream version of gawk can now be built via 9front-ports. I
> think/hope I built/ported it correctly, but it would be nice with
> critique/feedback/testing.
Majorly cool! The first thing to check is that 'make check' passes.
Some tests depend on locales; those are OK if they fail, assuming you
don't have locale data for them. Others are only run if gawk was built
with the MPFR library, so those should be OK too if they're not run. If
there are failures in other tests, they should be investigated.
I assume you built from the released tarball? Version 4.1.3?
> I noticed in the Arch linux package that gawk comes with a couple of
> dynamic libraries and a header. Are those also interesting to include in
> the Plan9 package (then as static libraries ofcourse)?
Supplyinig them as static libraries would serve no purpose. Those
dynamic libraries are extensions (or plug-ins, if you will). Gawk
loads them vial dlopen() if requested to via an @load directive in
the source or the via the -l command line option.
I hope that dlopen works on Plan 9; if so it's necessary to build
the libraries in whatever way will work to support dlopen.
The extension facility is something we (the gawk developers) put a
lot of work into for the 4.1 release. I can supply pointers to doc
for anyone who is interested. Here's a simple example:
$ gawk -lreaddir '{ print }' .
2814749767529876/./d
281474977052502/../d
2814749767530561/.bashrc/f
281474976885114/.bash_history/f
14355223812503808/.bash_profile/f
1407374884183439/.bzr.log/f
281474976885116/.ex-sgml-rc/f
281474976885117/.exrc/f
...
The readdir extension returns directory entries as records in an
easily-parsed format: '/' is the field separator and the fields are
the inode, the name, and an optional single-letter file type indicator.
The doc has more examples.
I hope this helps. Please feel to contact me off-list if you need
more info / help.
Thanks!
Arnold
Re: [9fans] Gawk in 9front-ports
Hugo Rivera wrote: > Why do you want gawk on plan9? I appreciate knowing about portability issues. :-) > I use awk a lot (on plan9 and elsewhere) and I wonder what reasons do > you have to use gawk over plan9's awk. Many features and extensions over standard awk. Different people will assign different levels of value to said features and extensions. A partial list: - The previously discussed dynamic plug-in facility - And awk-level debugger - A statement count profiler (and a pretty printer) - True arrays of arrays - Many more built-in functions and variables. In retrospect, some of these are just bloat and I'd have been better off without them. Arnold
Re: [9fans] Gawk in 9front-ports
Hi Hugo. I'm not sure who you're addressing. Jens did the port. I maintain gawk. Removing bloat unfortunately isn't going to happen in the mainline code base since there are backward compatibility issues. However, I'm happy to incorporate portability changes to make porting to Plan 9 easier, if they're reasonable. HTH, Arnold Hugo Rivera wrote: > Let me understand. Are you going to modify the current gawk version > according to your needs (perhaps removing some of the bloat you > mention)? or are you going to port gawk as it is? > > 2015-07-08 2:22 GMT-04:00 : > > Hugo Rivera wrote: > > > >> Why do you want gawk on plan9? > > > > I appreciate knowing about portability issues. :-) > > > >> I use awk a lot (on plan9 and elsewhere) and I wonder what reasons do > >> you have to use gawk over plan9's awk. > > > > Many features and extensions over standard awk. Different people will > > assign different levels of value to said features and extensions. > > A partial list: > > > > - The previously discussed dynamic plug-in facility > > - And awk-level debugger > > - A statement count profiler (and a pretty printer) > > - True arrays of arrays > > - Many more built-in functions and variables. In retrospect, some of these > > are just bloat and I'd have been better off without them. > > > > Arnold > > > > > > -- > Hugo
[9fans] Intel NUCs and Plan 9?
Does anyone have experience using Intel NUCs with Plan 9? I'm looking at http://www.amazon.com/Intel-Next-Unit-Computing-NUC5i3RYK/dp/B00S1ISFOQ/ref=sr_1_9?s=pc&ie=UTF8&qid=1436443454&sr=1-9&keywords=intel+nuc which is a Broadwell Core i3. Other recommendations for low-cost, small form factor boxes to run Plan 9 would be welcome, preferably with links (:-). Thanks, Arnold
Re: [9fans] Intel NUCs and Plan 9?
Raspberry pi isn't what I want. I want to be able to compile / do serious development and being able to run Linux would also help. I'm not comfortable moving outside of Intel architecture and I want the horsepower I can get out of a Haswell or Broadwell. Thanks, Arnold Shingo Onobori wrote: > Is the Raspberry Pi2 bad choice? > > http://www.plan9.bell-labs.com/wiki/plan9/download/ > > On 2015/07/09 21:18, arn...@skeeve.com wrote: > > Does anyone have experience using Intel NUCs with Plan 9? I'm looking > > at > > http://www.amazon.com/Intel-Next-Unit-Computing-NUC5i3RYK/dp/B00S1ISFOQ/ref=sr_1_9?s=pc&ie=UTF8&qid=1436443454&sr=1-9&keywords=intel+nuc > > which is a Broadwell Core i3. > > > > Other recommendations for low-cost, small form factor boxes to run > > Plan 9 would be welcome, preferably with links (:-). > > > > Thanks, > > > > Arnold > > >
[9fans] origins of configure
So, the history is more than this. Larry Wall's Configure (capital C) for rn and Perl was the first step at a shell script to examine system features and generate a config.h. It was inspirational for autoconf, but autoconf doesn't use any of its code, as far as I know. Autoconf was designed to solve real portability problems. In the late 80s and early 90s there was a huge variety of Unix systems and it was really hard to know what was available and what wasn't based on simple ifdefs. The variations were bigger than Erik makes out. Today, the scale of the problem is reduced, since we have POSIX and also fewer systems out there. Much of the bloat in the Autotools is from legacy. But there are still very real portability issues, especially among some of the fringe *BSD systems. MirBSD in particular is one of the worst, but that's another rant. If one were to start over today, one could likely arrive at a simpler system, but portability problems remain, and they are real. Arnold erik quanstrom wrote: > confirmed. it's existence is due to early gnu programs fighting with > small variations in unix and compilers. byron's rc used a small script > to the same effect. but for the most part, this all could be avoided > with careful planning and not using esoteric functions. > > gcc also had its own configuration step. the header rewriting is a vestage > of this system. > > - erik > > > On Jul 9, 2015 05:31, Jeff Sickel wrote: > > > > > > > On Jul 9, 2015, at 5:19 AM, Steve Simon wrote: > > > > > > FWIW: fgb did a stirling script called config which sets up some > > > environment and runs configure under ape. It doesn't always work but > > > often gets close > > > to generating a config.h as linux intended. > > > > Configure predates Linux. That, or my memory of using it to bang my head > > against the perl wall in the 1980s damaged the register. > > > > -jas > > > > … at least you’re not using Xenix > > > > > > > From 9fans-boun...@9fans.net Thu Jul 9 07:52:09 2015 > X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on > frenzy.freefriends.org > X-Spam-Level: > X-Spam-Status: No, score=0.0 required=5.0 tests=TIME_LIMIT_EXCEEDED > autolearn=unavailable version=3.3.1 > X-Envelope-From: 9fans-boun...@9fans.net > Return-Path: <9fans-boun...@9fans.net> > X-Virus-Scanned: by MailRoute > Date: Thu, 09 Jul 2015 06:50:06 -0700 > X-Android-Message-ID: <8f71c132-1b4d-4d0c-a741-d0738945f...@email.android.com> > From: erik quanstrom > To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> > Content-Type: text/plain; charset=utf-8 > Subject: Re: [9fans] Gawk in 9front-ports > X-BeenThere: 9fans@9fans.net > X-Mailman-Version: 2.1.13 > Precedence: list > Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> > List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> > List-Unsubscribe: <http://mail.9fans.net/options/9fans>, > <mailto:9fans-requ...@9fans.net?subject=unsubscribe> > List-Archive: <http://mail.9fans.net/private/9fans> > List-Post: <mailto:9fans@9fans.net> > List-Help: <mailto:9fans-requ...@9fans.net?subject=help> > List-Subscribe: <http://mail.9fans.net/listinfo/9fans>, > <mailto:9fans-requ...@9fans.net?subject=subscribe> > Sender: 9fans-boun...@9fans.net > Errors-To: 9fans-boun...@9fans.net > X-MIME-Autoconverted: from base64 to 8bit by freefriends.org id t69Dq5Ri006148 > Status: R > > confirmed. it's existence is due to early gnu programs fighting with small > variations in unix and compilers. byron's rc used a small script to the same > effect. but for the most part, this all could be avoided with careful > planning and not using esoteric functions. > > gcc also had its own configuration step. the header rewriting is a vestage > of this system. > > - erik > > > On Jul 9, 2015 05:31, Jeff Sickel wrote: > > > > > > > On Jul 9, 2015, at 5:19 AM, Steve Simon wrote: > > > > > > FWIW: fgb did a stirling script called config which sets up some > > > environment and runs configure under ape. It doesn't always work but > > > often gets close > > > to generating a config.h as linux intended. > > > > Configure predates Linux. That, or my memory of using it to bang my head > > against the perl wall in the 1980s damaged the register. > > > > -jas > > > > … at least you’re not using Xenix > > > > > > >
Re: [9fans] origins of configure
I don't intend to engage in yet another 9fans flame war. I do not argue with your analysis or proposal. However, it's based on considerable hindsight and experience that wasn't available when autotools started. Additionally, systems in that time period were changing continually. So it was not always true that what any given system provides is known in advance. The autotools (and especially gnulib) are bloated. A better design is possible. But it's unfair to say that at the time they could have done a lot better; I don't think that's true. "Hindsight is always 20/20". That's all I'll say on the topic. Arnold tlaro...@polynum.com wrote: > On Thu, Jul 09, 2015 at 09:24:57AM -0600, arn...@skeeve.com wrote: > > So, the history is more than this. > > > > Larry Wall's Configure (capital C) for rn and Perl was the first step > > at a shell script to examine system features and generate a config.h. > > Using a shell script to generate commands to compile on diverging Unices > was, by the date, already used in G.R.A.S.S. from C.E.R.L. and this > predates Perl and so on. I guess it is not the only example. > > >[...] > > Autoconf was designed to solve real portability problems. > > There are two problems with the autotools stuff: > > 1) Features are fixed for OSes, but the configuring is done other and > other again for every program. What a system offers shall be known; and > what the developers require shall be known too. Autotools was designed > in a world where neither the OS nor the developers exactly know what > they use; > > 2) Cross-compilation was not in mind, with some features tested by > compiling and running programs. The result is that the majority of > software built with autotools needs to be compiled natively (even > installed on an equal system since the layout is searched on the > building node); > > 3) To try to understand what's going on with several steps and huge > configs is out of reach. > > Rule: when it takes less time to build a solution from scratch than to > try to understand how to _use_ an existing solution (not to mention > understand), this solution has to be safely stored in /dev/null. > > Note: I have put my money where my mouth is : I have built such a > solution: the one publicly used with kerTeX---but it is a side > effect, it was not meant to be released. And it solves the 1) and > 2) and solves too the space problem: when an object is not any > longer necessary, it can be automatically removed, limiting the > space needed to compile to the bare minimum. > > -- > Thierry Laronde > http://www.kergis.com/ > http://www.arts-po.fr/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Replacement for find
Is there a C level equivalent of the BSD fts(3) suite of routines? Or even the System V ftw / GLIBC nftw suite? I suspect that having this would save some wheel-reinvention in these kinds of programs. Thanks, Arnold erik quanstrom wrote: > On Wed Sep 30 01:12:36 PDT 2015, charles.fors...@gmail.com wrote: > > > On 30 September 2015 at 09:01, Wolfgang Helbig wrote: > > > > > But I consider it ugly, to ask for the disk usage if you just want to > > > recursively list all files. > > > > > > > It probably is not ideal, even when the circumlocution is hidden in a > > script. > > Perhaps find's syntax and conventions could be improved, though? > > 9atom has a relative of andrey's find. it takes very few options. > the -d and -D options are not easily duplicated with du.
Re: [9fans] off topic - a good Git reference
Jeff Sickel wrote: > And then if you want all the fancy tools & wrappers groups seem to like > these days: Git is best used from the command line. All the tools just get in the way. The libgit work is probably the way to go for Plan 9. Arnold
Re: [9fans] Compiling ken-cc on Linux
> I know nothing about compilers, but actually gcc and clang dimension and > complexity is astonishing. > I've always thought that this is due to their desire to compile many > different language optimized for many different OS and architectures on > many different OS and architecture. That is a very large part of the reason. People also have used GCC (and I guess clang/llvm) as research vehicles, and such bits and pieces get included even if not stricly necessary. Also note that C++ is a hugely complicated langauge, and getting all the standards stuff right for it (and even for C) takes a lot of work. But you summed it up: * Multiple languages (front ends) * Multiple architectures (code generators / backends) * Optimized - a huge part of GCC is different kinds of optimizers > Alternative compilers, like tcc, only build C on very few architectures / > os with almost no optimization: they are much smaller, but still not > standard compliant. > > How can it be? In the case of TCC, there is no real guiding hand. People do what they feel like, or as they need it. Also, the original code base leaves a lot to be desired from a software design / engineering standpoint. (Function names consisting of a single letter!) TCC compiles really fast, and it's (finally) good enough that I can use it for my personal development / testing, but I would not use it to build a production binary, the code quality is much poorer. On Linux you can't use it for debugging either - it doesn't generate the debug info you need. :-( For that, GCC and clang are the way to go. I agree with the general sentiments - GLIBC and GCC are both bloated. But for the day-to-day work that *I* do, they're livable. My two cents, Arnold
Re: [9fans] Musings on Interfaces
Steve was borrowing: https://en.wikipedia.org/wiki/ALGOL : C. A. R. Hoare remarked: "Here is a language so far ahead of its time that it was not only an improvement on its predecessors but also on nearly all its successors." (This one is also mostly true. :-) Arnold Brantley Coile wrote: > Steve Bourne said it about 7th Edition. I just asked him. He also said it > turned out to be mostly true. > > > On Sep 1, 2016, at 12:36 PM, Adriano Verardo wrote: > > > > Brantley Coile wrote: > >> > >> I’m very grateful to still be using these tools. It’s a very personal > >> thing but for someone who first used 6th Edition Unix, ed and the old > >> shell, and used all the versions of Unix that followed, these tools, both > >> acme and sam, rio and 8 1/2, are an improvement to all that proceeded them > >> and followed them. > > Cool. > > Who said "Unix v7 (or 6 ?) is the major improvement of all subsequent > > releases" ? > > (or something similar, sorry for my poor spoken english) > >> Brantley Coile > >> > >> > >> > > > > > >
[9fans] x86 alternative to rPi
FYI folks. http://betanews.com/2016/09/22/solidrun-x86-braswell-microsom-linux-windows-10-raspberry-pi/ Arnold
[9fans] Yet Another small form factor Intel platform
https://newsroom.intel.com/news/intel-unveils-intel-compute-card-credit-card-sized-compute-platform/
[9fans] RPI faq in words of one syllable?
Hi. Is there a document somewhere that describes how to bring up an RPI with Plan 9, that assumes the reader knows absolutely nothing? E.g., where to buy it, what case and power supply to buy, what accessories if any. Where to download the image and what kind of SD card to put it on. How to boot Plan 9 and set it up as a standalone system. Etc. Thanks! Arnold
Re: [9fans] RPI faq in words of one syllable?
Lyndon Nerenberg wrote: > I wrote up a crib sheet covering exactly this a couple of months ago, but > it was on a VPS server whose filesystem I thoroughly trashed and is now > pushing up the daisies. I will dig around and see if I stashed a copy on > another machine. If not, I can re-create it easily enough, but not for a > week or two due to insanity at $WORK. > > --lyndon Hi. There is certainly no hurry. I would greatly appreciate it if you can find your notes or reproduce them; I suspect that I'm not the only one. MUCH thanks! Arnold
Re: [9fans] updating awk ...
Thanks for the info. I may pull the iso to take a look. In any case, for those using BWK's awk, it's worth pulling in the latest set of changes, they're not huge. Thanks, Arnold hiro <23h...@gmail.com> wrote: > spew is a 9front user who wanted to improve awk. > > there is no separate hg location, branch, etc., awk is in the default > branch of 9front. > > i don't know if he wasted a thought on unix while he was doing that, > better ask him: he's on #cat-v on freenode regularly. > > the 9front distribution .iso contains the complete hg repo with all > the history, so if you can run our awk, you also have the source and > the history. > his efforts started with the regexp library that used to require ape! > the first related commits i found are: > > changeset: 5271:9bf761f83f7e > branch: spew > user:ben@rana > date:Wed Apr 27 07:52:41 2016 -0500 > summary: remove ape regexp library, add utility for awk native port > > changeset: 5269:cad63b966180 > branch: spew > parent: 5266:682b1efdef40 > user:ben@rana > date:Tue Apr 26 22:23:44 2016 -0500 > summary: New libregexp and APE ported to native > > replying to list in case others want to understand, too.
Re: [9fans] Plan 9 C compiler for RISC-V by Richard Miller
Richard Miller <9f...@hamnavoe.com> wrote: > That's for Plan 9 use. I should also configure a version to run on > posix-type systems and put that on github. Is there a standalone version of the Plan 9 C compiler for *nix for x86 / x86_64? I'm looking for something easy to bring up and install to use an an additional compiler for testing a Free Software project. Thanks, Arnold
Re: [9fans] sources down
"David du Colombier" <0in...@gmail.com> wrote: > > i have wondered if it would be possible to apply the historic plan9 > > kernel diffs and regenerate these ancient kernels. > > The diff files are ed scripts generated with "diff -e", so it should be > possible to regenerate the original files with a bit of scripting. > > -- > David du Colombier How does that work if lines were deleted? Thanks, Arnold
Re: [9fans] sources down
> On Sun, Dec 30, 2018 at 11:58:20PM -0700, arn...@skeeve.com wrote: > > > > How does that work if lines were deleted? Kurt H Maier wrote: > [ example session, deleted ] Let me restate the question. When one has only the "new" file and the ed script that created it from the "old" one, and said script says "delete lines N through M", how does one recover the lines that were deleted? (With context or unified diffs, the deleted text is there.) Thanks, Arnold
Re: [9fans] sources down
"David du Colombier" <0in...@gmail.com> wrote: > > Let me restate the question. When one has only the "new" file and > > the ed script that created it from the "old" one, and said script > > says "delete lines N through M", how does one recover the lines > > that were deleted? (With context or unified diffs, the deleted text > > is there.) > > I don't think you can "reverse" the ed scripts produced with "diff -e", > unlike unified diff files. > > However, in 9hist, the files are always reconstructed forward, > starting from the complete original file. OK, then it makes sense then. Much thanks! Arnold
Re: [9fans] Rc port.
Federico Benavento wrote: > Hola, > > I just uploaded a standalone unix (only tested on macOS/Linux) port with > edit, history and completion support to GitHub. > I have been using it as my primary shell for months on macOS and it???s seems > to be working pretty well. > > https://github.com/benavento/rc > > Have fun. > ???- > Federico G. Benavento > benave...@gmail.com On Ubuntu 18.04, doing make, I get errors on several files. See attached. Thanks, Arnold ERRS Description: Binary data
[9fans] strange propogation paths in 9fans mail?
Hi. Is this happening for anyone else? Relatively recently, it's happened that I see the replies before the originals, with delays in between of *days*. This has happened in the past with 9fans, but not recently, and now it's started again... Thanks, Arnold
Re: [9fans] printing from Plan 9
Modern HP printers are very easy to handle. They sit on the network and Linux can find them automatically. HP provides excellent LInux support for their printers. CUPS isn't fun but it's not rocket science; once you get it going it's generally set and forget. My 2 cents, Arnold Charles Forsyth wrote: > the downside is that you'd need to deal with CUPS! > > On Sat, Sep 14, 2019 at 12:42 PM Richard Miller <9f...@hamnavoe.com> wrote: > > > > You may be better off > > > sacrificing one of your old RPI boards to Linux and using that as your > > > common printer interface to the large set of supported printer devices > > > > Sounds practical. Years ago I used a Mac for a CUPS server, until a > > MacOS opgrade suddenly made it stop working with lp(1), and I was too > > lazy to debug it. Maybe time to try again with raspbian. > > > > > >
Re: [9fans] plan9port on osx
"Ethan Gardener" wrote: > > i cannot find a plan9port maillist, so i am asking here. > > it's called plan9port-dev and it's on google groups: > > https://groups.google.com/forum/#!forum/plan9port-dev Clicking on the link tells me I don't have access to the group. I reported something directly to Russ a few days ago, but didn't hear back... Thanks, Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Teef4e32e6f6c10de-M6921d1a2c1823562acebfbf0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9legacy usb kb/mouse?
Richard Miller <9f...@hamnavoe.com> wrote: > > I happen to have a chance to test this on another machine, which > > has ps/2 interface on board. Dell's has no ps/2 interface. > > > > The machine having ps/2 interface DOES boot with usb kb/mouse > > without ps/2 kb/mouse attached. > > Some motherboards (I don't know about Dell) have a special setting > to enable different mouse protocols at boot time. Look for > something like "usb legacy support". I have also seen this affect USB keyboards (on Linux). Enabling it helped. HTH, Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T99364400713696a7-M7f41ae1d1679e75e51a61f6a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] looking for an old program
o...@eigenstate.org wrote: > > Is there a current URL from which I can snarf this program? > > Still seems to be up on 9p.io contrib: > > % ls /n/9pio/contrib/fernan/schem.tgz > /n/9pio/contrib/fernan/schem.tgz > > Mirrored for convenience here: > > https://orib.dev/tmp/schem.tgz Thanks Ori and Aksr who answered. I've pulled down a copy. Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T77d844ca40469192-M3de9cf34ac858fb71780e0f4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] APL
j...@corpus-callosum.com wrote: > Lyndon, > > Let us know if you find that source as it unfortunately doesn't appear to be > on netlib.org. > > P.S. Yes I know there are a million other APLs out there, as > well as J and the assorted follow-ons. It's the V7 code I'm > specifically interested in. Maybe it's tucked away in the > bitsaver archives ... Have you checked the TUHS archives? V7 source is there, it should be all of it... Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M36e9482b0f5cf587ed422a89 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] APL
tlaro...@polynum.com wrote: > On Mon, Feb 22, 2021 at 09:44:54PM +, Charles Forsyth wrote: > > I'm fairly sure Thompson wrote it on sabbatical in Berkeley. I think he > > also wrote the first version of a Pascal compiler. > > Pascal isn't a difficult language but I remember that compiler having an > > unusual style. I think others reworked it significantly later, > > so if it's there at all it's worth looking at the earliest possible one. > > > > The Pascal compiler rings a bell... It would be fun indeed to derived a > version from it so that, finally, TeX and al. could be "natively" > compiled instead of converting the (pseudo) Pascal to C (this is web2c > purpose or, as I have named it, pp2rc---Pseudo Pascal to Raw C). There was an interpreter for P-code and (I think later) a compiler for the Vax. You'd have to port it to current architectures, and compiling TeX would probably make TeX run more slowly than the C version. The Berkeley Pascals were some of the compilers used for "Software Tools in Pascal". Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M29f8ec6d6c8474c6d36e66e1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] APL
This is getting off topic ... > > There was an interpreter for P-code and (I think later) a compiler > > for the Vax. You'd have to port it to current architectures, and > > compiling TeX would probably make TeX run more slowly than the C version. > > > > The Berkeley Pascals were some of the compilers used for "Software Tools > > in Pascal". > > The Pascal version would probably be a bit slower. And it would be more > an alternative to verify the code than a primary way, since in fact > D.E.K. has not written the program in some Pascal but in Algol, a high > level abstract description, the wizardry being in the data structures. It's Pascal, but in literate form with WEB. I've read "Tex: The Program". :-) > And, indeed, only the control flows are being translated from pseudo > Pascal to C, the core---the data structures---being handled by ad-hoc > code. Could be, I'm not familiar with how web2c works. > And for the architectures, like other compilers, the aim would be to > convert to some intermediate language (perhaps assembly) and to borrow > the back-ends. I think the Pascal compiler used the PCC back end, but I no longer remember for sure. If so, you might could hook it up to the revived PCC project. Although it sounds like a fun project, there are probably better uses for your time. :-) Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-Mc80e8615b718f628a8468339 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Can compile Plan9 C compiler for windows10?
Is there a usable, standalone, 32- or 64-bit version of kenc that works on Linux? By "usable" I mean "able to compile and run regular Linux code". For example, oh, say, compiling and testing GNU Awk. :-) (Besides GCC and clang, I test gawk with tinycc and the revived PCC compilers. I have often wanted to add kenc into the mix, but haven't found a usable, standalone version thereof.) Thanks, Arnold ron minnich wrote: > Nxm built kencen toolchain on Linux. > > https://github.com/rminnich/NxM > > We could build all of plan9 on Linux. You might be able to start there and > produce .Exe's. > > Not tested for quite some time now. Derived from nix. > > > > On Sun, Mar 28, 2021, 6:17 AM wrote: > > > uh inferno's 8c compiles .exe file? > > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > > <https://9fans.topicbox.com/groups/9fans> + participants > > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > > <https://9fans.topicbox.com/groups/9fans/T4d77cc95ab4ed70c-M3f3b47b1f09745ffc88175bf> > > -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4d77cc95ab4ed70c-M736b5a79b2e3c21b143022da Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Can compile Plan9 C compiler for windows10?
Hi Russ. Thanks for this. You are probably right, but it's always good to test against as many compilers as possible. Out of curiousity, why is linking against the system libraries so hard? I assume a port of kenc to Linux would have a driver program that would just invoke the system ld(1). I'd think that getting the ABI and generation of ELF (or of standard Linux assembly language) correct would be the hard part. What am I missing? Thanks, Arnold Russ Cox wrote: > Hi Arnold, > > The hard part is not so much the compiling but the linking against > system libraries. Honestly once you have both gcc and clang happy (with > no warnings), I doubt very much that using the Plan 9 C compilers will > bring much additional benefit for finding bugs (except bugs in the > compiler!). > > Best, > Russ -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4d77cc95ab4ed70c-M317489e2b055f003ccfb0dca Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Can compile Plan9 C compiler for windows10?
OK - wasn't kenc ported to Linux for bootstrapping the early Go compilers? Is that version general, or not worth my trying to use? Thanks, Arnold Charles Forsyth wrote: > > > > I doubt very much that using the Plan 9 C compilers will bring much > > additional benefit for finding bugs (except bugs in the compiler!). > > > The cross-file type-checking does sometimes pick up unpleasantness caused > by type mismatches. > It was originally added to allow dynamically-loaded object modules to be > checked against the loading specification. > It has found a few problems elsewhere, including one in Python where one .c > file included a .h with a certain #define > in scope that another .c file didn't define by accident, causing the two .c > files to have completely different memory layouts > for a structure. > > > > Out of curiousity, why is linking against the system libraries so > > hard? I assume a port of kenc to Linux would have a driver program > > that would just invoke the system ld(1). I'd think that getting > > the ABI and generation of ELF (or of standard Linux assembly language) > > correct would be the hard part. > > What am I missing? > > > It works very differently from what you expect > http://9p.io/sys/doc/compiler.html <http://9p.io/sys/doc/compiler.html>: > > The compiler is a single program that produces an object file. Combined in > the compiler are the traditional roles of preprocessor, lexical analyzer, > parser, code generator, local optimizer, and first half of the assembler. > The object files are binary forms of assembly language, similar to what > might be passed between the first and second passes of an assembler. > > Object files and libraries are combined by a loader program to produce the > executable binary. The loader combines the roles of second half of the > assembler, global optimizer, and loader. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4d77cc95ab4ed70c-M6a254c61dea5a9cdc6797bc2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Can compile Plan9 C compiler for windows10?
Russ Cox wrote: > Standard C has moved on, and the Plan 9 C compilers have not kept up. > They're still fine for Plan 9 C code, but given the choice > I wouldn't throw anything else at them. That's pretty definitive. Thanks. Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4d77cc95ab4ed70c-Md4a535788cff08faf580ac1c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation
"Anonymous AWK fan via 9fans" <9fans@9fans.net> wrote: > As I interpret it, we'd need Nokia to re-release Plan 9 under a Lucent > Public License version 1.03 which would be the MIT license for > contributions to be relicensed (if I'm interpreting it correctly the > GPL release of Plan 9 couldn't apply to contributions either.) I Am Not A Lawyer, and I don't doubt that the P9 foundation can get good lawyers. But, once _ownership_ of the copyright was transferred to the P9F, they can do what they want with it, including publishing under the MIT license. There should not be a need to involve Nokia any further. My two cents. And apologies - I don't mean to start a long discussion about licensing. I'd rather let P9F worry about it (and throw a few $$ at them to help). I suggest we all do the same. :-) Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-Meba469dccfec41bd213492f7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation
Nobody is disgruntled (that we know about). The code under discussion in Richard Miller's contributed bcm kernel. Arnold Jeremy Jackins wrote: > Seems to me that there is always going to be some non-zero risk of lawsuits > when making a change like this, but clearly the foundation was comfortable > with the risk. So what's the point of this discussion? Who are these > disgruntled contributors you are speaking on behalf of? > > On Wed, 31 Mar 2021 at 09:34, wrote: > > > > It’s all the code that everyone is using. > > > The issue is that there is some code in Plan 9 not written at > > > Bell Labs which doesn't explicitly specify any license. > > > > What actual code are you reffering to? > > -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M7863c119ec5b85c26c4d2af1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] troff refer and bib
Maurizio Boriani wrote: > Hi, > is there somewhere in plan9 code base (9front, plan9port etc...) the > source code of refer and/or bib? I found many references to 'em but > didn't found the code or programs. The Research Unix versions can be found in the TUHS archives (see tuhs.org). I suspect that the Heirloom Troff versions could also be made to work. HTH, Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2e70e97724f65028-M46ff38b6dae4038e6646cb33 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (not quite SOLVED)
Richard Miller <9f...@hamnavoe.com> wrote: > > But is it not possible that the FPGA tools don't > > have the same issues with mmap that e.g. Go does? > > 1. Some of the fpga tools are closed-source so I can't check with > confidence that they will never try to use mmap. Um, nm(1) on the binary to see what it calls? Just a thought... :-) Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-Mbfab54f8bfadab46ceee71b5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] v9fs vs mmap (not quite SOLVED)
Richard Miller <9f...@hamnavoe.com> wrote: > >> 1. Some of the fpga tools are closed-source so I can't check with > >> confidence that they will never try to use mmap. > > > > Um, nm(1) on the binary to see what it calls? > > If you were distributing closed-source proprietary tools, would you leave > the symbol tables intact to assist reverse engineering? Of course not. But even stripped binaries have some symbols in them, especially for functions that are in the shared libc library on Linux. If the binaries are totally statically linked and stripped, then yes, you're out of luck. Try it. If I'm wrong, then I'm wrong. It won't be the first time. :-) Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-M149789ec7553d42e1fba4eff Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] void*
adr wrote: > On Sun, 15 May 2022, adr wrote: > > > What I mean is if we are going to follow C99 in the use of void*, > > we should allow arithmetic on them. > > Let me be clear, I know that C99 requires the pointer to be a > complete object type to do arithmetic, and I like that, is consistent. > But then I don't see the point to use void* as a generic pointer. It allows you pass pointers of any type without requiring casts: struct foo s[5] = ... memmove(s, & s[1], 4 * sizeof(struct foo)); // shift down 1 The compiler won't complain because any pointer type can be passed to a void* parameter. Otherwise you'd need to cast: memmove((uchar*) s, (uchar*) & s[1], 4 * sizeof(struct foo)); void* has been standard practice (even on Plan 9) for 30+ years. It's not worth changing it now. :-) HTH, Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-Md96cca95ce4773408cff1b24 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] kencc for 64 bit intel linux?
Hi All. A little off topic, apologies. Is there a version of kencc somewhere that can be easily built and installed on Linux and used as a plain C compiler? I'd prefer for x86_64 but I'll take one that only compiles 32 bit. Thanks, Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td066fba28f267517-M41952243844f7e0567de40e3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] kencc for 64 bit intel linux?
Thanks, I will check it out. Richard Miller <9f...@hamnavoe.com> wrote: > > Is there a version of kencc somewhere that can be easily built > > and installed on Linux and used as a plain C compiler? > > > > I'd prefer for x86_64 but I'll take one that only compiles 32 bit. > > https://github.com/inferno-os/inferno-os/tree/master/utils/6c > > There are also various forks on github which keep the compilers and > building utilities and throw away the rest of inferno. > > But it's reasonably easy just to do a standard inferno install, stopping > at the stage where the cross-compiler has been built. > -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td066fba28f267517-M3eeb88e8841e21204065bcae Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] programs from UNI*x
I'd love to know if gawk can be made to work on Plan 9. Latest release is at https://ftp.gnu.org/gnu/gawk/ Or you can clone the git repo. Thanks, Arnold Conor Williams wrote: > hello there 9fans.ers > > anyone need any UniX programs transferred (port.ed) to Plan9 > > will give u a good price 1cent an hour iff i can get it going... > > textual programs mostly... > > Kind Regards > will51 (conor.williams@ yada yada c. reply address) > ps: I am currently catching up on some good dickens novels and would > love some diversionary tactics my the fans of de plan9 oses -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e60a159b1280462-M3763c0bf086e5a3895030bfa Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] programs from UNI*x
Jacob Moody wrote: > On 6/28/23 10:09, arn...@skeeve.com wrote: > > I'd love to know if gawk can be made to work on Plan 9. > > Latest release is at https://ftp.gnu.org/gnu/gawk/ > > > > Or you can clone the git repo. > > > > Thanks, > > > > Arnold > > whats the issue with the awk we already have? There's no issue. I maintain gawk, so I'm curious if it'll run on Plan 9. That's all. Thanks, Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e60a159b1280462-M3218747b29b65ff7bf4df0ed Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] programs from UNI*x
Conor Williams wrote: > well Arnold?, 1. is the LINE pre processor directive supported by p9 > and also i2s _*that*_ function declared properly (&+3 is that definitely > the source that compiled > properly on SM. Windows et. Al?) I completely don't understand this. No need to continue on gawk. Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e60a159b1280462-M371df951b9d60e2a2c870234 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] troll paper
Charles Forsyth wrote: > > And, if I hear about it being > > “declarative” as a virtue, I point to the 81,000+ lines (and > > growing) of YAML, that I defy any one human to comprehend. > > > You might find help in culang.org DNS can't seem to find that for me Thanks, Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M6b93f78a60388d81a74a2467 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] troll paper
Taj Khattra wrote: > > > You might find help in culang.org > > > > DNS can't seem to find that for me > > https://cuelang.org/ Much thanks! Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Mb09361bab5b0b487622723cb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] List of companies that use Plan 9.
"B. Atticus Grobe" wrote: > As for companies that use 9, Coraid (Brantley Coile) was invested in 9 for > their network storage systems, although it's possible their newer products > don't utilize it. They still do. See his posts on LinkedIn. Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M978e977ab934f741265275d1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Where can I find active Plan 9 communities for support and collaboration?
"David L. Craig" wrote: > FWIW, I put together "The Virtual Plan 9 Cookbook" > (http://dlcusa.net/vp9cb-9pio) > years ago to address this newbie need. But there was no way to point it out > at > the "official" website. You've probably never heard of it. It might > have helped. It's ~ 10 years old. Is it still relevant? Or do you plan to update it? Thanks, Arnold -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9804faa2e50a80d8-Mcd1c3f432933c6476cb5b9f6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)
Does Go use things that are bison-specific? If not, maybe Berkeley Yacc (there are various versions around) would be easier to port. Arnold
Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)
If it's bison -y -d then maybe even Plan 9 Yacc would work. The bison dist has a manual, probably even with an index, in which you can look up suspicious constructs and decide if they can be safely tossed or not. Thanks, Arnold
Re: [9fans] Fortran growing in absolute number of users
Me: > > An interesting tidbit I came across: > > > > http://software.intel.com/en-us/blogs/2011/09/24/fortran-is-more-popular-than-ever-intel-makes-it-fast/ Erik: > by interesting, one assumes your mean, makes you want to > give up computing as you now realize it's an exercize in > regressing at moore's law speeds. > > - erik I thought it was an interesting tidbit that HPC people are going back to Fortran from C++. Ron, care to comment? Erik, maybe dig out the V7 ratfor and bring it into the 21st century for Plan 9? (:-) Arnold
Re: [9fans] awk reading?
I have to toot my own horn a bit: http://www.gnu.org/software/gawk/manual/ The manual is careful to distinguish standard awk from gnu awk features. If someone is up to porting gawk 4.0 to Plan 9, I'd be interested to help! Thanks, Arnold
Re: [9fans] awk reading?
> Mr. Robbins' book is a gold mine--and here I must say thanks, sir > for both the outstanding documentation and the indispensable code! Thanks. I've worked at it, hard, for many years. :-) I also recommend TAPL. It's a great book. Arnold
Re: [9fans] du vs. ls: duplication or not?
Hi. > What I meant was the size of the file is already given via ls(1). So > a recursive output that make sense and fit a manipulation via join(1) > (to combine a srv/qid) and sort and uniq etc. could do the trick. Not quite. On Unix (don't remember 'bout Plan 9 but I assume it's the same) files can have holes. All you have to do is lseek pass the end of the file and then write something. Bingo - size (or better, length of the byte stream) no longer has a direct relationship to the number of disk blocks occupied. On Unix systems, du looks in the stat structure at the count of blocks occupied (st_blocks IIRC) and does the computation from that. Similaly, many Unix du implementations will track hard links based on device+inode to only count a file's blocks once. > Since ls(1) gives the size of the file; since du(1) can not really or at > least not always in an arbitrary context tells the "real" occupation of > disk size, is not ls(1) enough? For the two above reasons, I think not. Again, at least on Unix. :-) (I suppose ls could print device+inode, and sort+join on that to remove duplicates, but the holes problems is still there. Hmmm. I bet ls can print the number of blocks instead of or in addition to the size. So maybe I'm wrong after all. :-) Arnold
Re: [9fans] Config File parsing
O'Reilly's "lex & yacc" is somewhat more user-friendly a reference than the dragon book, although the latter certainly has its value. :-) Arnold
Re: [9fans] nix at lsub
Hi. > To make it explicit, the plan I have is to > throw away o/live and o/mero and write something native for > macos, linux, and perhaps ios such that the UI widgets are abstract > and handled in a similar way they are handled in o/live. > > Only that they'd be native widgets with the look of the native system > (that's not to say you can't implement an editable text-pannel with > the mouse language we all love). Qt already provides this (and much more). It means working in C++ (which is either a bug or a feature, depending upon how you look at it). I have used Qt and find it well designed and pleasant to use, but many 9fans might find such a thougt to be heretical. > Also, as Forsyth points out, the set of widgets has to be rethought, e.g., > there should be a web widget. I think Qt even has that. > Then it's a matter of using those files from inferno, and remote systems. > > But, as I said, I don't have a single line of code yet for all of this. It sounds like interesting work! Good luck! Arnold
Re: [9fans] nix at lsub
> Is it exported as files? > > I thought I knew Qt, but, if it provides a file interface, I missed that. No - but I would suggest building on Qt, to let it handle all the interface to the native graphics, and you provide the file service / translation over it. I think that would be challenging and interesting, and also save you an *enormous* amount of work in having to write the same set of GUI interfaces three times (X11, windows, Mac OS). In other words, the GUI part is already a laregly solved problem; build upon it instead of reinventing it. Just an idea. :-) Arnold
Re: [9fans] nix at lsub
> > having to write the same set of GUI interfaces > > three times (X11, windows, Mac OS). > > I'd like to put in a good word for Plan 9, in case it gets forgotten. > And, yes, Qt does not support Plan 9, I guess we'll need to find some > compromise, if at all possible. > > ++L Good point. Unfortunately, until Plan 9 grows a C++ compiler, Qt isn't an option for it. If/when that does happen, it would be a worthwhile thing to have there (In My Humble Opinion, of course :-). Arnold
[9fans] how up to date are the PDF doc files on plan9.bell-labs.com?
Hi. Do the postscript / PDF files available from http://plan9.bell-labs.com reflect the current state of the system? I'm curious about both the reference manual and the various files from /sys/doc. Thanks! Arnold
Re: [9fans] how up to date are the PDF doc files on plan9.bell-labs.com?
Thanks Erik. Is it hard to produce a tar ball of .ps or .pdf files from current troff input? Thanks, Arnold
Re: [9fans] formatting the manual from plan9 ports?
Thanks to everyone for the advice. > On Tue May 29 23:48:31 EDT 2012, cinap_len...@gmx.de wrote: > > short hardcoded paths are an advantage. this is not linux. this > > is plan9. there are rules. the kernel already provides a way for > > indirection that works for *everything*. mount/bind and private > > namespaces. > > while this is all true, and i agree with you, the problem at hand it > to get things formatted on linux. Right. The problem is that Linux already has a /sys directory. Who knows what would break if I mount over that. Thanks, Arnold
[9fans] apparently nice summary of small linux pcs
http://raymii.org/cms/p_Small_Linux_PCs_overview Arnold
Re: [9fans] rc vs sh
Lucio De Re wrote: > All Bashes are equal, Even this isn't true. Bash is at 4.2 and people still report "issues" with 3.x. (Same with gawk; gawk is at 4.0.1, people still send it bug reports about 3.1.3, which is 10 years old!) I am not familiar with the use of Bash in Go; I suspect that they stick to stuff that will work across Baash versions though. Arnold
Re: [9fans] stripping down the kernel for an small embedded systems?
Thanks Charles and Erik for both your answers. I have pointed my colleague to the online archive. Arnold
[9fans] a cute small Intel cube
Hi All. This might make an interesting 9box: http://www.engadget.com/2012/09/13/intels-core-i3-nuc-mini-boards-set-to-hit-mket-in-october-po/ Arnold
Re: [9fans] a cute small Intel cube
Calvin Morrison wrote: > > http://www.engadget.com/2012/09/14/intels-core-i3-nuc-mini-system-bares-it-all-for-idf-hands-on-v/ > > but why not stick an i5 or i7 in there? heat dissipation in the small > form factor? Price is undoubtely a factor too.
Re: [9fans] off-topic: why linux lost the desktop
erik quanstrom wrote: > > The question is rather: What killed the Plan 9 desktop? > > poor special effects? > > - erik The Plan 9 desktop was never aimed at the consumer market, which is what Miguel was bemoaning for Linux. Plan 9 was never even aimed the broader Unix / software developer market; it was designed mainly to please the developers (which is fine, they did great things, but let's be honest here). The broader point is that the Unix / Linux / Open Source "communities" seem to be plagued with a never-ending desire to reinvent the same wheels over again instead of moving forward. This may be part of what Rob had in mind in his 2000 paper about systems reearch being dead. And it may just be part of the human condition. :-( Arnold
Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
> > > gcc etc. are used to deliver a lot of code that is used in > > > real word. And without a standard there would've been lot > > > less interoperability and far more bugs. This remains true. It is possible and not that difficult to write code that can be successfully and correctly compiled by multiple compilers (like, oh, i dunno, maybe, GNU awk :-). > > Most interoperability delivered by gcc comes from the fact that gcc is > > widespread, not that the standard is effective. If it was we wouldn't need > > to port gcc to everything. > > even clang got forced into bug-for-bug compatability mode. Also the Intel compiler, ICC. Like many things, standards seem to obey a bell curve. The problem is that we're on the descending side on so many of them... (Dare I say it? "POSIX". Freel free to run screaming in horror. :-) Having lived through the Unix wars of the late 80s and early 90s, I think that overall standards are a good thing. It just seems that more recently the comittees keep adding stuff in order to justify their continued existence, instead of solving real problems. Arnold
Re: [9fans] sleep(2) historical question
> Seems best to get rid of the fixed 100Hz clock and allow as > fine a timer resolution (& accuracy) as a particular CPU + > kernel combination can do. So what this argues for is a query interface - hello mr. kernel, what can you and your hardware do? In whatever units make sense. Then userspace can do the calculation it needs and ask for the sleep time that it will know the kernel can really supply. Erik's problem boils down to "the kernel knows what it can do and is quite capable but i can't get it at from user space". So (a) make the information availble and (b) let user space figure it out. Classic separation of mechanism from policy. At least, that what it looks like to me. :-) Arnold
Re: [9fans] ape/errno.h
Hi. Jeff Sickel wrote: > >> It should be EISCONN, not because "other systems" have this, but because > >> it is in Sus v3. > > Other systems were my only reference as I just didn't want to buy the > spec at this stage. If anyone has a link to a freely available spec > then that would be a good reference point for APE in the future. http://pubs.opengroup.org/onlinepubs/009604599/basedefs/errno.h.html This is from the 2004 standard (the first one google found) but the 2008 version should be findable from opengrouop.org somewhere. It won't be too much different (we hope! :-). HTH, Arnold
Re: [9fans] ape/errno.h
Hi. Jeff Sickel wrote: > > http://pubs.opengroup.org/onlinepubs/009604599/basedefs/errno.h.html > > > > This is from the 2004 standard (the first one google found) but the > > 2008 version should be findable from opengrouop.org somewhere. It won't > > be too much different (we hope! :-). > > If the OpenGroup's so open why do I need an account to view/download > the Single UNIX Specification? Or any of their specs for that matter... > > https://www2.opengroup.org/ogsys/catalog/t101 > > Guess I'll dig through some other accounts to keep the IEEE lawyers happy. If you're happy with HTML: http://pubs.opengroup.org/onlinepubs/9699919799/ (Google for "POSIX 2008 base definitions"). HTH, Arnold
[9fans] off topic: lego runs linux
http://www.youtube.com/watch?v=qAQ3g-iW-Ow
Re: [9fans] Ancient History: "Electronic Mail Without Aliases"
> http://ftp.math.utah.edu/pub///mirrors/minnie.tuhs.org/Documentation/Papers/Email_No_Aliases/ I'll take the credit for this. :-) I asked on the TUHS list, was pointed to Mike Lesk, asked him for the paper, and he graciously supplied it. A few people on that list (also on 9fans) supplied pointers to PDF they were able to generate. It was an interesting read. It is absolutely amazing how much was accomplished with so little (a hypothetical dedicated mail machine that would only need 5 meg of disk... :-). If one phrase sums up the Unix and Plan 9 philosophies, it would have to be: Small Is Beautiful Arnold
[9fans] doing a native awk port (was Re: Bug in print(2) g verb)
Changing the subject here... "Paul A. Patience" wrote: > > for the native port of awk I am completing > (started by boyd). I was under the impression that awk was a native port, but I could be wrong. In any case, I recommend that you start with BWK's latest, which is availble on github: git clone git://github.com/onetrueawk/awk And also talk to Erik who did some work on bringing the Plan 9 awk into sync with BWK's a little while back. HTH, Arnold P.S. The git repo includes his test suite in the file awktest.a; it should probably be unarchived in a separate directory from the source.
Re: [9fans] Acme button 1 working like button 3
> On Wed Apr 10 09:30:33 EDT 2013, mirtchov...@gmail.com wrote: > > Russ and his wife had a baby, I think he's busy changing diapers > > (there was an announcement on golang-dev that he'll be away for a > > month). erik quanstrom wrote: > a baby is proof that no matter how obsessive a coder you are, > you can get even less sleep and not code a wink. > > - erik And be in an even more elevated state of happiness. Arnold
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
Aram Hăvărneanu wrote: > Alternatively, one can implement rc(1) or awk(1) in Go, rather than > implementing all the base tools. Speaking from experience, there are a fair number of dark corners to handle if you are going to implement awk. Contact me off list for pointers to documentation and test suites. Is there even a yacc equivalent from Go? That might be a reasonable project - add Go support to Berkely Yacc, Plan 9 Yacc, or Bison. Or larger in scale, to implement Yacc itself in Go. Arnold
Re: [9fans] test(1) -older bug?
Richard Miller <9f...@hamnavoe.com> wrote: > And the consequences of not freeing a few bytes of memory, in a command > which will exit a few microseconds later, would be ... ? The Code Correctness Police come and collect you and force you to program on Windows... :-) Arnold
[9fans] is lsub web server up?
Hi. I tried to get the 9pix paper but am getting connection refused sorts of errors from http://lsub.org. Thanks, Arnold
