Re: [9fans] invisible prompt in win

[erik quanstrom]

 To me it looks more like a consequence of Plan 9's treatment of files as
 sequences of bytes/chars/runes rather then sequences of lines as is common
 in Unix. Basically, you can't scroll beyond the end of the file, and if the

unix and plan 9 agree: a file is an ordered sequence of bytes. unix
read/write/seek are measured in the same units as plan 9
pread/pwrite/seek: bytes.

but i think you may be talking about vi.  but even here,
the problem only happens on the first line.  i think it's just
a garden variety bug.  no philosophy need apply.

 Rio and sam show the same behaviour, by the way.

indicating exactly where to look.  (libframe.)

- erik

Re: [9fans] invisible prompt in win

[erik quanstrom]

 On Oct 5, 2008, at 9:52 AM, erik quanstrom wrote:
  indicating exactly where to look.  (libframe.)
 
 I don't think so, as libframe doesn't provide a scroll function. Maybe  
 (rio sam acme) use a common scroll function? I'll look into it.

i don't think the callback Frame.scroll would exist unless it's job
were to allow libframe to decide when to scroll.  if the application
made the decision by itself, there would be no need for this callback.

- erik

Re: [9fans] mounting stdin using 9pfuse

[sqweek]

On Sat, Oct 4, 2008 at 3:18 AM, Roman V. Shaposhnik [EMAIL PROTECTED] wrote:
 it appears that I'm missing something fundamental in how
 9pfuse (the one written by Russ) works when it is given
 - as an address.

 Seems to work here on linux after:
 #include error.h
 #include errno.h
+#include unistd.h

 void socket012(int fd)
 {
   int i;
-  for (i=0; i3; i++) {
+ for (i=0; i2; i++) {
close(i);
dup2(fd, i);

if (fork()) {
socket012(fd[0]);
-   execlp(9pfuse, 9pfuse, -, /tmp/fuse, (char*)0);
+   execlp(9pfuse, 9pfuse, -D, -, /tmp/fuse, (char*)0);
} else {
socket012(fd[1]);

 ls -l caused a failed assertion in ramfs, but it was going. Can't
justify why the diff works, but before adding -D and changing 3 - 2 I
didn't have any success. Would love to look into it further but in the
interest of not destroying my work schedule this week I'm going to get
some damn sleep. Good luck.
-sqweek

Re: [9fans] panic

[erik quanstrom]

 Sorry about that.  We're soaking a version of the kernel that includes
 a reference count in the Block struct.  It's so far used by the
 Ethernet drivers, IP stack and USB code, and usbohci.c escaped a
 little too early.
 
 I've just pushed out a newer allocb.c to sources that initializes the
 refence count at allocation.

the new version of port/allocb.c panics my terminal early in the boot
process.  unfortunately, i'm going to have to buy another serial card
to debug this, so i won't have any information for a while.  what i 
do know is the panic is ref -1 from freeb and the caller is readq.

- erik