Re: [9fans] the `Look' command in Acme

2012-05-18 Thread Peter A. Cejchan
 select text in the first window

  2-1 chord on Look in the second window's tag line


how about running a command from another window, w/o copying to the tagline?
++pac


Re: [9fans] the `Look' command in Acme

2012-05-18 Thread Yaroslav
2012/5/18 Peter A. Cejchan tyap...@gmail.com:
 select text in the first window

  2-1 chord on Look in the second window's tag line


 how about running a command from another window, w/o copying to the tagline?

This is it: you don't copy to the tagline but just pass last selection
as an argument.



Re: [9fans] I will buy laptop pre-installed with plan9!!!

2012-05-18 Thread Ethan Grammatikidis
On Thu, 17 May 2012 13:36:52 -0400
erik quanstrom quans...@labs.coraid.com wrote:

 abaco was confused about how relative urls work.
 i've attached the file i'm using (which has some
 extra differences), and here's the diff

Thanks! I'll push that to 9front if it works with their webfs.



Re: [9fans] I will buy laptop pre-installed with plan9!!!

2012-05-18 Thread Ethan Grammatikidis
On Thu, 17 May 2012 18:20:41 -0400
erik quanstrom quans...@quanstro.net wrote:

 On Thu May 17 17:44:51 EDT 2012, 9f...@hamnavoe.com wrote:
   Besides that, my Elysian field has namespaces.
  
  +1
 
 better than angry french motorists.

I can handle angry French motorists better than I can handle how Linux
these days.



Re: [9fans] I will buy laptop pre-installed with plan9!!!

2012-05-18 Thread Burton Samograd
 abaco was confused about how relative urls work.
 i've attached the file i'm using (which has some extra differences),
 and here's the diff

 Thanks! I'll push that to 9front if it works with their webfs.

I applied the patch to my 9front abaco source and it worked as advertised
(as in clicking on Google search result links now work).

--
Burton Samograd


This e-mail, including accompanying communications and attachments, is strictly 
confidential and only for the intended recipient. Any retention, use or 
disclosure not expressly authorised by Markit is prohibited. This email is 
subject to all waivers and other terms at the following link: 
http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page? for 
contact information on our offices worldwide.



Re: [9fans] +t and bind (Was Re: Thinkpad T61 Installation Experience)

2012-05-18 Thread Ethan Grammatikidis
On Thu, 17 May 2012 12:43:15 -0700
David Romano un...@cpan.org wrote:

 I suppose that's the double-edged sword with having the dynamic capabilities
 of bind(1).

In practice it's not much of a problem. /lib/namespace takes care of
the globally-persistant binds such as bind /$cputype/bin /bin and even
things like bind -c #e /env. $home/lib/profile takes care of per-user
binds including /tmp. These are the binds from my lib/profile which is
mostly a standard 9front one:

bind -b $home/bin/rc /bin
bind -b $home/bin/$cputype /bin
mount -qC /srv/cwfs /n/other other
bind -qc /n/other/usr/$user/tmp $home/tmp
bind -c $home/tmp /tmp
if(! syscall create /tmp/xxx 1 0666 [2]/dev/null)
ramfs   # in case we're running off a cd

Note the first 2 which are conventional Plan 9, you would expect those
to be there on any Plan 9 box. The two binds for tmp are no different.
(Yes, $home/tmp is normally bound to /tmp.)



Re: [9fans] I will buy laptop pre-installed with plan9!!!

2012-05-18 Thread erik quanstrom
On Fri May 18 12:30:56 EDT 2012, cinap_len...@gmx.de wrote:
 tested, commited. theres a little thing thats different with
 9front webfs. if the server doesnt return a Content-Type
 response header, the contenttype attribute file will not
 appear in the connection directory. (this is true for all
 response headers).

the web is not plan 9 compliant.

- erik



Re: [9fans] I will buy laptop pre-installed with plan9!!!

2012-05-18 Thread Christoph Lohmann
Greetings.

On Fri, 18 May 2012 21:24:02 +0200 erik quanstrom quans...@labs.coraid.com 
wrote:
 On Fri May 18 12:30:56 EDT 2012, cinap_len...@gmx.de wrote:

 the web is not plan 9 compliant.

That's really offtopic.


Sincerely,

Christoph Lohmann




[9fans] The creepy WORM. (was: Re: Thinkpad T61 Installation Experience)

2012-05-18 Thread Nemo
Because I noticed Ken's worm fs was being discussed in this thread, I thought
I might just drop here the man page for a new alternate file server that we 
wrote
for nix.

It's not yet ready for use (I'm using it, but it's still under testing, and the 
version
in the main nix tree is now out of date, btw; will send the new one soon).

But I thought it might be of interest to 9fans, if only to get comments.


 CREEPY(4)   CREEPY(4)

 NAME
  9pix, fmt, rip, arch - creepy file server and WORM archive

 SYNOPSIS
  creepy/9pix [ -DFLAGS ] [ -ra ] [ -A addr ] [ -S srv ] disk

  creepy/fmt [ -DFLAGS ] [ -wy ] disk

  creepy/rip [ -DFLAGS ] [ -a ] [ -c n ] [ -A addr ] [ -S srv
  ] disk

  creepy/arch [ -DFLAGS ] [ dir ]

 DESCRIPTION
  Creepy is a prototype file server for Nix. It maintains a
  mutable file tree with unix semantics, kept in main memory,
  served through 9P, see intro(5), and through IX.

  Creepy/9pix is the main file server program. It serves a
  file tree through 9P and IX.  The tree kept in memory is
  mutable. But frozen versions of the tree are written to
  disk, both upon request and also on a periodic basis, to
  survive power outages and other problems, and to be able to
  operate on trees that do not fit on main memory.  The
  tree(s) stored on disk are frozen and cannot be changed once
  written.

  By default the program listens for 9P in the standard TCP
  port and posts a connection that can be mounted at
  /srv/9pix.  Flags -A and -S may be used to specify an alter-
  nate network address and/or srv(3) file to post. Using these
  flags makes the program not to listen and not to post to
  srv(3) unless a flag indicates so.  Flag -r makes the pro-
  gram operate in read-only mode, and flag -a starts the pro-
  gram without requiring authentication to mount the file
  tree.

  The disk is organized as a log of blocks. When a new version
  of the tree must be written to disk, all blocks that changed
  are given disk addresses and are appended to the log. Once
  written, they are frozen.  If new changes are made to the
  tree, blocks are melted and forget their previous addresses:
  each time they are written again, they are assigned new
  ones.

  When the disk gets full, all reachable blocks are marked and
  all other blocks are considered available for growing the
  log (this is a description of semantics, not of the imple-
  mentation). Thus, the log is circular but jumps to the next
  available block each time it grows.  If, after the mark pro-
  cess, the disk is still full, the file system becomes read
  only but for removing files.

  Before using a disk it must be formatted using creepy/fmt.
  This initializes blocks used to store marks for the mark and
  sweep process and also initializes a super block and an
  empty root directory. Flag -y forces the format even if the
  disk seems to contain a fossil (4) or creepy (4) partition.
  Flag -w is used to format the partition for a WORM
  (described later) and not for a main file tree.

  Creepy/rip is the same file server program, but operates in
  WORM mode. In this case, no mark and sweep for free blocks
  will ever happen. Blocks are consumed from the disk until it
  becomes full.  The file tree served is always read-only.

  Operating the WORM to in administrative mode to add more
  trees or new versions of the archived trees does not require
  any protocol: it can be done using the standard file inter-
  face used to operate on any other tree, by mounting and
  changing it.

  An alternate mount specifier, wormwr, can be used to mount
  the tree in read-write mode, to update the archive.  Updat-
  ing the archive is performed by creating new trees with the
  conventional /treename/year/mmdd paths on the WORM. But note
  that such paths are not enforced by the program at all.
  Before updating a tree in the archive, for a new day, a con-
  trol request described later can be used to link the direc-
  tory for the previous version of the archive to the new one.
  After that, changes made to files would in effect copy on
  write all blocks affected, and refer to old ones when they
  did not change.

  Creepy/arch is a program started by creepy/9pix to archive
  snapshots of the tree into a directory provided by
  creepy/rip (or by any other file server).  The program is
  not expected to be run by users, and 

Re: [9fans] The creepy WORM. (was: Re: Thinkpad T61 Installation Experience)

2012-05-18 Thread Bakul Shah
On Fri, 18 May 2012 23:13:54 +0200 Nemo n...@lsub.org  wrote:
   Creepy is a prototype file server for Nix. It maintains a
   mutable file tree with unix semantics, kept in main memory,
   served through 9P, see intro(5), and through IX.

Creepy? It has become a creepy word now!

   Creepy/9pix is the main file server program. It serves a
   file tree through 9P and IX.  The tree kept in memory is
   mutable. But frozen versions of the tree are written to
   disk, both upon request and also on a periodic basis, to
   survive power outages and other problems, and to be able to
   operate on trees that do not fit on main memory.  The
   tree(s) stored on disk are frozen and cannot be changed once
   written.

Just curious.
If the tree doesn't fit in memory, how do you decide who to
kick out? LRU? Sounds much like a cache fs. What does it buy
you over existing cache filesystems? Speaking more generally,
not just in the plan9 context.
 

   The disk is organized as a log of blocks. When a new version
   of the tree must be written to disk, all blocks that changed
   are given disk addresses and are appended to the log. Once
   written, they are frozen.  If new changes are made to the
   tree, blocks are melted and forget their previous addresses:
   each time they are written again, they are assigned new
   ones.

I don't understand use of the words frozen  melted here.  How
is this different from how things work now? Something worse
than what venti or zfs do, which is to leave the old blocks
alone and allocate new space for new blocks.

   When the disk gets full, all reachable blocks are marked and
   all other blocks are considered available for growing the
   log (this is a description of semantics, not of the imple-
   mentation). Thus, the log is circular but jumps to the next
   available block each time it grows.  If, after the mark pro-
   cess, the disk is still full, the file system becomes read
   only but for removing files.

Why does circularity matter? It would make more sense to allocate
new blocks for a given file near its existing blocks regardless of
writing order.

Why not just use venti or some existing FS underneath than
come up with a new disk format?

Sounds like a fun project but it would be nice to see the
rationale for it.

Thanks!



[9fans] 9front: Support for encrypted partitions (in development, needs documentation)

2012-05-18 Thread Burton Samograd
The features list of 9front has the subject line.  How in development
is it, and could anybody give a documentation/HOWTO on getting it
working (if it does)?

--
Burton Samograd



Re: [9fans] 9front: Support for encrypted partitions (in development, needs documentation)

2012-05-18 Thread John Floren
9front has a mailing list, that's probably the best place to ask these
kind of things.

On Fri, May 18, 2012 at 8:50 PM, Burton Samograd
burton.samog...@gmail.com wrote:
 The features list of 9front has the subject line.  How in development
 is it, and could anybody give a documentation/HOWTO on getting it
 working (if it does)?

 --
 Burton Samograd




[9fans] Showing an image on an o/live window

2012-05-18 Thread kokamoto
Hi nemo,

You are doing server side work now, I got.

I wondered for a time how to show octopus.img on my
terminal's olive window.   Now, I got it.

The octopus.img is Plan9 format image originally sitts in
the /usr/octopus/port/live.   
I copied this to /lib/o/octopus.img, alos to $home
After olive comes up, I issued the following series of commands 
on a olive directory panel.
(1) !mkdir /mnt/ui/appl/image:logo
(2) !cp /usr/okamoto/octopus.img /mnt/ui/appl/image:logo/data
(3) !echo copyto /main/row:stats  /mnt/ui/appl/image:logo/ctl

Yes, the octopus image was shown on the top row, the second colomun,
right of New panel.   It's ok, however, why we need the third line?

Another one(not serious to me):
After copying octopus.img to /lib/o, the octopus image is shown
quickly in the center of olive window only just begining moment.
Is this your expected behaviour?

Sorry, you are now working on a server side, this is client side matter.

Kenji




Re: [9fans] Showing an image on an o/live window

2012-05-18 Thread kokamoto
forgot one more thing.

I did the command 
;page octopus.img
on the directory panel of /usr/okamoto on the terminal.

I got the octopus image on my PC (octopus server) side,
but not the terminal side.
My ubuntu has plan9port, and 'page' command can be
seen.

It' not easy to me to understand this behaviour...

Kenji