Re: [9fans] The Case for Bind
It's been years since I've used Plan 9, and I very-much miss bind and union mount. For me, the big benefit of them is that you can hard-code well-known names for certain files or directories, and yet you can override those paths as needed, without having to set a bunch of environment variables and worry about whether the program you're dealing with checks the environment variables. Real-world example: I maintain a commercial program that uses embedded Python and is run on customer servers over-which I have little or no control. I don't want my program to use the system Python libraries, if there are any. But in order to work in many different situations, including for testing while uninstalled, Python does a whole bunch of hunting around the system to find its libraries. This hunt is affected by the PYTHONHOME and PYTHONPATH environment variables, as well as code in site.py, and C initialization code with some hard-coded paths. To work around this, I set a flag that advises Python to ignore the environment, I overwrite the hard-coded paths (in spite of warnings in the Python docs) before initializing Python, and I supply my own replacement site.py. I think this isolates my program from the system Python, but it's complicated and there's probably some corner case I've missed. If the OS had bind and union mounts, then Python could always look for its libraries in /lib/python. Need a different library? bind ./lib /lib/python. There would be no need for PYTHONHOME or PYTHONPATH or sys.path or the searches in site.py and the C initialization code. I would simply bind my own library into the well-known location, and I would never have to worry about some bug in Python accidentally loading the system library. Off the top of my head, bind and union mount can eliminate the need for all of these common environment variables: PATH, MANPATH, LD_LIBRARY_PATH, PKGCONFIG, PYTHONPATH (as well as GOPATH, etc), TMPDIR, PAGER, EDITOR, and surely others. Namespace manipulation is not just an alternative to environment variables in cases like these; it's better because it eliminates code. Every program that wants to support one of these environment variables must contain code to do so. With namespace manipulation, they don't need any code, they just open() or exec() a well-known path. Namespace manipulation works to reconfigure any path name for any program, without the program's author having to provide a configuration hook of any kind. Micah
Re: [9fans] Acme Edit to remove lines
You can also take advantage of x's default behavior of splitting the selection into lines and use g to select which you want: Edit x g/^X/d
Re: [9fans] Acme and Git
In plan9port, this script will re-load any clean window that differs from
an existing file with the same name:
```
#!/usr/local/plan9/bin/rc
cleanIDs = `{9p read acme/index | awk '$4 == 0 && $5 == 0 { print $1 }'}
for (id in $cleanIDs) {
nm = `{9p read acme/$id/tag | sed 's/ .*//'}
if (test -f $nm && ! cmp -s $nm <{9p read acme/$id/body}) {
echo get | 9p write acme/$id/ctl
}
}
```
If you make it deal gracefully with acme not running, you could probably
have git call it automatically whenever you check out a different revision.
Caveats: this does nothing for directory windows, doesn't help with files
that exist in one branch and not another, won't touch a dirty window, and
has been tested very little.
By the way, Russ's Watch is here:
https://github.com/rsc/rsc/tree/master/cmd/Watch
Micah
On Wed, Feb 15, 2017 at 12:32 PM, Paul Lalonde
wrote:
> Do you have a pointer to Russ's Watch? I quick dig shows I have poor
> Google-fu.
> Paul
>
> On Wed, Feb 15, 2017 at 12:23 PM Bakul Shah wrote:
>
>> May be use Russ'es Watch command?
>>
>> > On Feb 15, 2017, at 5:05 AM, Paul Lalonde
>> wrote:
>> >
>> > I know I'm not the only acme user who uses Git extensively :-)
>> > Is there some way to tell if a file is changed on disk that is open in
>> an editor window? I frequently change branches and I often find myself
>> editing stale versions. I notice when comes time to Put, but that's a bit
>> late.
>> >
>> > Any tips to share?
>> >
>> > Paul
>>
>>
>>
Re: [9fans] Dragan
I'm curious. What is it? Google tells me nothing, unless you're talking about playing basketball with a Croatian or football with a Serbian. On Thu, Feb 4, 2016 at 8:27 PM, Prof Brucee wrote: > Anyone played with a Dragan? >
Re: [9fans] acme/sam language question
What if you specify the address twice like this: /A/+#0;/B/-#0g/CC/ s/CC/DD/g /A/+#0;/B/-#0p That doesn't work if A and B occur more than once in the file or if DD matches A or B. But otherwise, it seems to work for me. Micah On Nov 6, 2013, at 10:47 AM, Rudolf Sykora wrote: > On 31 October 2013 20:24, Rudolf Sykora wrote: >> On 31 October 2013 16:49, Friedrich Psiorz wrote: >>> It works for me, but I found another inconsistency. >>> >>> I tried it on p9p and 9vx, both in acme and sam. >> >> /A/+#0;/B/-#0 >> g/CC/ s/CC/DD/g >> p >> >> Well. If I use these commands one by one inside p9p acme >> (and probably sam, too), I truly get what I want (and what >> you say). The problem appears when I want to run it from >> a script like this: >> >> sam -d <[2] /dev/null >> /A/+#0;/B/-#0 >> g/CC/ s/CC/DD/g >> p >> EOF >> >> then you get, since the g is on a seperate line, an extra >> output from the line before g. And if you try to join g with >> the match like >> >> sam -d <[2] /dev/null >> /A/+#0;/B/-#0 g/CC/ s/CC/DD/g >> p >> EOF >> >> then you get no output if CC is not between A and B >> (although when it is there, you get what I want). >> In neither case I am fully satisfied. :) >> >> Thanks >> Ruda > > So far I still do not know how to do it properly... > But it seems nobody here proposes anything... > > Thanks for any clue > Ruda >
Re: [9fans] cocoa devdraw
> I'm seeing missing recipes. Lion and XCode 4.2 I get nearly identical output on Snow Leopard with XCode 4.0.2 (see below). BUT if I manually copy o.devdraw from $PLAN9/src/cmd/devdraw to $PLAN9/bin/devdraw, nearly everything seems to work. The best part (for me) is that now my acme and 9term windows work with Divvy! Huzzah! One downside: Dragging with the middle button down no longer seems to work right when I have MagicPrefs enabled. It works fine without MagicPrefs, but I can't middle drag with my Magic Mouse in Google SketchUp without MagicPrefs. Oh well, I can turn it on and off as needed. Thanks to everybody who's worked on this, Micah (./INSTALL output below) * Resetting /usr/local/plan9/config * Compiler version: gcc version 4.2.1 (Apple Inc. build 5666) (dot 3) * Running on Darwin: checking architecture... x86-64 found. * Building everything (be patient)... >>> cd /usr/local/plan9/src/cmd/fontsrv; mk all 9c main.c mk: no recipe to make 'osx-cocoa.o' >>> cd /usr/local/plan9/src/cmd/snarfer; mk all 9l -o o.snarfer osx-cocoa-snarfer.o ld: warning: directory not found for option '-L/usr/X11R6/lib64' * Installing everything in /usr/local/plan9/bin... >>> cd /usr/local/plan9/src/cmd/devdraw; mk install 9c -DOSX_VERSION=100608 macargv.c macargv.c:12: warning: passing argument 3 of 'AEInstallEventHandler' from incompatible pointer type macargv.c:13: warning: implicit declaration of function 'RunApplicationEventLoop' macargv.c:24: warning: implicit declaration of function 'FSpMakeFSRef' macargv.c:30: warning: implicit declaration of function 'FSMakeFSSpec' macargv.c:30: error: 'FSSpec' has no member named 'vRefNum' macargv.c:30: error: 'FSSpec' has no member named 'parID' macargv.c:45: error: 'FSSpec' has no member named 'name' macargv.c:49: error: 'FSSpec' has no member named 'name' macargv.c:83: error: 'typeFSS' undeclared mk: 9c -DOSX_VERSION=100608 macargv.c : exit status=exit(1) >>> mk: no recipe to make 'osx-cocoa.o' >>> cd /usr/local/plan9/src/cmd/snarfer; mk install 9l -o o.snarfer osx-cocoa-snarfer.o ld: warning: directory not found for option '-L/usr/X11R6/lib64' * Cleaning up... * Renaming hard-coded /usr/local/plan9 paths... * Building web manual... * Done. * Add these to your profile environment. PLAN9=/usr/local/plan9 export PLAN9 PATH=$PATH:$PLAN9/bin export PATH
Re: [9fans] acme(4) and addr=dot
> Addr is reset to 0,0 once opened. So, you need to perform these > operations in order: open addr; write ctl; then read addr. Thanks, all. Micah
[9fans] acme(4) and addr=dot
I think this may apply to all versions of acme, but I'm running into
it on p9p. First, acme(4) claims that a read on a window's addr file
returns the current address as a pair of character offsets m and n, in
'#m,#n' format or just '#m' if m and n are equal. It looks like it
really returns m and n as two space-padded integer values.
But that's just a documentation bug. What's really bothering me is
that I can't seem to get the value of dot. I've tried this:
% echo -n 'addr=dot' | 9p write acme/70/ctl
% 9p read acme/70/addr
0 0 %
Window 70's dot is somewhere on line 16. Thinking maybe the ctl file
had to stay open, I tried this:
% {echo 'addr=dot'; 9p read acme/70/addr >[1=2]} | 9p write acme/70/ctl
0 0 %
No help. Am I doing something wrong?
Micah
[9fans] Acme niceties
One thing I like about acme is it doesn't present me with little annoyances I must learn to work around. Instead I find little niceties like this: I was editing an over sized tag in a way that would cause it to shrink, leaving my mouse pointer outside. But acme nicely warped the pointer so it remained in the tag and my typing wasn't redirected unexpectedly. It's a small thing, but it made me happy, and I wanted to say thanks to whomever is responsible. I'm in the mood to appreciate small things today. Micah
Re: [9fans] p9p acme: incredibly slow typing in tag line for file.
>> Is this with a remote >> X or some other high latency connection to the >> underlying graphics? > > Right on my laptop. But ubuntu 9.04 is known to have "X issues" and I > did not know if this was another one. Has anybody figured this one out? I just updated to Ubuntu 9.04 and I'm seeing exactly the behavior Ron describes. Typing in a file tag (not a column tag) takes a noticeable amount of time per character -- varying between maybe 200ms and 1000ms by my guess. Sometimes I get the same delay in win and directory window tags, sometimes not. In any case, typing in the window body is fast. Also, resizing the acme window takes far too long -- maybe a couple of seconds. I think the time is linear in the number of files I have open in acme. Somebody asked whether writing to acme/n/tag was slow as well -- it doesn't look like it. Acme's still usable, since most of my text entry is in window bodies, but it sure is a pain. Thanks for any help anybody has to offer, Micah
Re: [9fans] Google finally announces their lightweight OS
> Why would it take a book? DMR made the point succinctly in his > critique of Knuth's literate program, showing how a few command-line > utilities do the work of the Don's elaborately constructed tries. Do you have a URL for this? Micah
Re: [9fans] impact of dynamic libraries on the speed of fork()
> I wrote a really simple program, forktest.c. Chris beat me to the punch, but I'm posting anyway because I went a different direction. I wrote some rc scripts that make static and dynamic libraries of various sizes and programs that use those libraries (trivially). For each number of functions 1, 10, 100, 1000, 1, 10 I timed static and dynamic execution of a program that conditionally calls that many functions in 1 or 10 libraries. The scripts are attached, run mklibs, then mkprogs, then runtests. Below are the results of a single run on my laptop (fixed with font looks better). I can't spend any more time on this, but it was a fun morning goof-off. Static (functions libraries binary-size user system elapsed) 1 1 556898 0.24 0.50 0.78 10 1 557324 0.28 0.44 0.82 10 10 557913 0.32 0.42 0.81 100 1 561737 0.24 0.50 0.84 100 10 562196 0.28 0.46 0.79 1000 1 609496 0.29 0.47 0.83 1000 10 606381 0.26 0.48 0.84 1 1 1105475 0.30 0.44 0.87 1 10 1083834 0.28 0.47 0.82 10 1 6245494 0.27 0.48 0.88 10 10 6043871 0.28 0.48 0.81 Dynamic (functions libraries binary-size user system elapsed) 1 1 6489 0.49 0.86 1.39 10 1 7322 0.52 0.86 1.45 10 10 7464 0.83 1.14 2.03 100 116366 0.59 0.78 1.42 100 1016177 1.14 1.11 2.35 1000 1 108268 0.55 0.87 1.47 1000 10 104496 0.88 1.12 2.07 1 1 1077758 0.81 0.98 1.89 1 10 1037387 1.12 1.36 2.63 10 1 10915272 2.79 2.50 6.31 10 10 10517862 3.13 3.68 7.13 I think dynamic 100-10 is a fluke, I also think it's interesting that the dynamic binaries are bigger above 1 function calls. Don't know why, don't have time to figure it out. Micah mklibs Description: Binary data mkprog Description: Binary data mkprogs Description: Binary data runtests Description: Binary data
Re: [9fans] Some arithmetic [was: Re: Sources Gone?]
>> > http://www.google.com/search?q="09+f9"; >> >> is that a legal url? > > P.S. Or am I missing some kind of a joke here? ;-) Intentional or not, it's a very good joke. Micah
Re: [9fans] Do we have a catalog of 9P servers?
>> That isn't happening. All we have is one TCP connection and one small >> program exporting file service. > > I see. But then, is it the "small program exporting file service" that does > the multiplexing? I mean, if two machines import a gateway's /net and both > run HTTP servers binding to and listening on *:80 what takes care of which > packet belongs to which HTTP server? The Plan 9 kernel doesn't do load balancing like that. (Why should it?) To do it in Plan 9, you'd write a small program that listened on a particular address and multiplexed connections to a list of other addresses. It wouldn't be hard -- aux/trampoline is halfway there. I think you're still thinking of importing /net in terms of NAT. It can be used to solve some of the same problems, but it isn't the same at all. Exportfs (the small program above) doesn't know that it's exporting a network stack or any kind of "special" files because the files in /net aren't special. The network stack doesn't know it's being used by a different computer -- it just sees exportfs reading and writing its files. The HTTP server doesn't know it's using somebody else's network stack, it's just reading and writing files in /net that it expects to work a certain way. The only component that knows there's a network stack being forwarded from one machine to another is the person at the controls. This is nothing like NAT. No packets are rewritten, and no code exists solely to support one computer using another's network stack. So FTP and other protocols that frustrate NAT work without special treatment. The same principal obviates the need for port forwarding. (In Plan 9 networks, that is.) Micah
Re: [9fans] Do we have a catalog of 9P servers?
> Very well said. This posting summarizes what's been going on: Thank you. > 2. Generality costs. Not always, and I think you may be overestimating the costs here. Your later posts talk about making a complete copy of the TCP stack. That isn't happening. All we have is one TCP connection and one small program exporting file service. Micah
Re: [9fans] Do we have a catalog of 9P servers?
>> I think Eris is saying that this makes Plan >> 9's resource requirements grow with the number of hosts behind the >> gateway -- not just with the number of connections through it like >> Linux. > > I don't quite follow. If by resources you mean process related resources > than I would agree. My very first comment didn't have anything to do > with process related resources. I did mean the extra processes, and I assumed that was what Eris was referring to. > And for the TCP related resources I > maintain that the amount of overhead in Plan9's case is definitely > comparable to a Linux's case. Right. Micah
Re: [9fans] Do we have a catalog of 9P servers?
>> I'm unclear as to what "amount of state" iptables needs to keep > > After you do something like: ># iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE > the Linux kernel module called nf_conntrack starts allocating > data structures to do its job. I'll leave it up to you to see how much > memory gets wasted on each connection. Here's a hint, > though: /proc/net/nf_conntrack I don't think Plan 9 is keeping any less state, is it? As far as the gateway is concerned, all of the connections from machines importing its /net are the same as connections from local programs. The TCP/IP stack has to keep track of those, but Plan 9 doesn't need separate connection tracking code for that because it's handled like any other connection. Plan 9 does need one extra connection per client and a process (or two?) to do the export. I think Eris is saying that this makes Plan 9's resource requirements grow with the number of hosts behind the gateway -- not just with the number of connections through it like Linux. You're right, Eris, but I think you're missing the point: importing /net gives you all the features you'd want from NAT (and some it doesn't give you) without a single line of code specifically written to make it happen. It isn't an example of how you can handle the most clients with the least hardware. It's an example of how a good design can give you features without having to code each one individually. Micah
Re: [9fans] mount followed by srvfs needs a sleep?
> local mount /srv/penelopa $home/shared/penelopa > #sleep 1 # --- see the text bellow; this pertains to my main > question > local srvfs CALC $home/shared/penelopa/home/ruda/CPA-CALC # > local mount /srv/CALC $home/shared/CALC I haven't actually tried this, so I probably shouldn't be writing it, but How about this: local 'rc -c ''mount blah blah && srvfs blah blah && mount blah blah''' > login&password. Only then I execute my 'local mount ...' command. If I > executed this right away (without mount & unmount) I would end in a > situation when the plumber shell needs to talk to me. But this shell writes > to the /dev/kprint... > What is the better way? I think this is the problem auth/fgui is supposed to solve. See factotum(4). > (and, actually, is this kind of authentication any safe?) In what way? Have you read /sys/doc/auth.ps? Micah
Re: [9fans] Local variables and rc functions
> Both fixes are in plan9port. Thanks, Russ. Micah
[9fans] Local variables and rc functions
Is this a bug?
% fn foo { echo $bar }
% bar=baz foo
%
I would expect to see baz instead of a blank line.
Micah
Re: [9fans] hot or not
> http://www.ugu.com/sui/ugu/show?I=ugu.hotnot&HN=1113&RT=10 Shouldn't that be RT=9? Or does your Plan 9 go to 10? Micah
Re: [9fans] acme/sam linewrapping off
> Another, even more compelling example is, when you want to look at some > scientific data from some experiment. There it is quite common to have rows > of data, each row having say 20 real numbers, each row meaning one 'step' of > the experiment. With acme or sam, with/without your solution, you have no > simple way of looking at it. Using Vim, it's an easy task, you can turn the > wrapping off... I tend to think editing tabular data is a task for a different program. 20 real numbers of a similar length are probably fine in Vim. But throw in a couple of fields where the length varies and keeping track of columns across lines gets to be a real task, wrapping or no. I'd like to see an acme-like environment for editing tables. (I know, "Quit talking; start coding.") Micah
