From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3deb3ec44245355ffc77cf8a7b8f67f2@acl.lanl.gov>
To: 9fans@cse.psu.edu
From: andrey mirtchovski <andrey@lanl.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] bug/feature report (long)
Date: Tue,  7 May 2002 15:51:21 -0600
Topicbox-Message-UUID: 8c6413e2-eaca-11e9-9e20-41e7f4b1d025

hi,

i was forced to spend several days without an internet connection,
which meant that i had to find something else to do instead of hitting
the refresh button on slashdot or a similar site at the rate of 60
clicks/minute.

here's what i found, some comments, suggestions and other generally
boring stuff:

the example in control(2) is no longer working -- the 'show' control
message now expects the name of the control the message is directed
to.  this fix worked for me:


<              chanprint(cs->ctl, "top rect %R\nshow", r1);
<              chanprint(cs->ctl, "bot rect %R\nshow", r2);
--
>              chanprint(cs->ctl, "top rect %R\ntop show", r1);
>              chanprint(cs->ctl, "bot rect %R\nbot show", r2);


the window creation example in graphics(2) is no longer working.
mount() now expects a second file descriptor (for an authenticated
connection, the man page says).  the following worked for me:

<               if(mount(fd, "/tmp", MREPL, "new -dx 300-dy 200") < 0)
--
>               if(mount(fd, -1, "/tmp", MREPL, "new -dx 300-dy 200") < 0)


with respect to that same example, i have found something that i'm not
sure how to explain: if compiled in a threaded environment
(threadmain()) the abovementioned code from graphics(2) crashes.
after digging a bit i found that gengetwindow() thinks that Image
*screen2; is pointing to a real screen and tries to free it.
unsuccesfully, because it was never malloc-ed...  i boiled it down to
the following example:

(i think the best way to illustrate is with a paste from the console):


p9% cat norm.c
#include <u.h>
#include <libc.h>
#include <thread.h>

void
main()
{
	int *ptr;
	print("%ux\n", ptr);
}

p9% diff norm.c thrd.c
6c6
< main()
---
> threadmain()
p9% 8c norm.c thrd.c; 8l -o norm norm.8; 8l -o thrd thrd.8
norm.c:
thrd.c:
p9% norm
0
p9% thrd
fefefefe
p9%

i guess, threadmain does not initialize pointers to nil.

i tried to find a reasonable justification for this, but am still not
sure whether it's a bug or a feature...


i also did two changes in the control library:  the first one is
fairly simple -- when the text written in an 'entry' control is longer
than the control width, scroll the text to the left so that the
user can see what they're typing.  this prohibits positioning the
cursor and editing earlier (no longer visible) text unless some
characters are deleted.  in unix-world this is solved by using the
cursor keys to move back and forth, in p9 the mouse is the only
thing usable for this.  it's not a big problem in my view.  please
note that i made this change because that's how i would like the
control to behave, it is by no means the right way or anything like
it.  here is the diff:

p9% diff entry.c.old entry.c
99a100
> 	int offset;
110a112,116
> 	if(e->ntext * e->font->font->width > Dx(r))
> 		offset = e->ntext - (Dx(r)/e->font->font->width);
> 	else
> 		offset = 0;
>
112c118
< 		ZP, e->font->font, nil, e->text, e->ntext,
---
> 		ZP, e->font->font, nil, e->text+offset, e->ntext,
p9%

the second change is a bit more controversial and i will not send a
patch for it, unless people think it's a good idea:  i modified the
'text' control to have some sort of a limit for the amount of lines
that could be entered.  naturally such thing should be configurable
through control messages, but in my case i simply hardcoded it to
 1500 lines.  if a new line is added to the control
the oldest line added is removed.  i also made the control wrap
extensive lines into two or more ones to allow for everything added to
the control to be visible.  adding scroll up/down control messages is
trivial and probably should be accomplished simply by selecting which
line to be displayed in the text window, so i left it out.

it's doesn't sound much when written down, but most of the feel of
'text' is now totally different.  most of the weekend was spent
debugging this change :)

i guess naturally a better solution would be to have something like
the rio window -- allowing for scroll, mouse select and copy (but not
paste?).  would something like this be a good idea?  wind.c in rio's
code doesn't look too menacing.

that's about it, i think i can find answers to my lesser questions
without boring the list :)

andrey