[9fans] bug/feature report (long)

[9fans] bug/feature report (long)

[andrey mirtchovski]

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

Re: [9fans] bug/feature report (long)

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 148 bytes --]

i suspect the example expects them to be as global as
screen and _screen, but does not make that clear.
(they would then be initialised to nil.)

[-- Attachment #2: Type: message/rfc822, Size: 1734 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] bug/feature report (long)
Date: Tue, 7 May 2002 16:09:41 -0600
Message-ID: <cdeab0e2c6a78f5bd21aaf03248ab137@acl.lanl.gov>

> A useful tip: always use the -w flag to 8c et al.  Take
> any warnings seriously -- they are often caused by
> programming errors.  In this case, you would be warned
> that ptr is used but not set.  And indeed it isn't.

i don't want to argue, and indeed you're right.  this is bad
programming.  the fact remains though, the 'create new rio window'
example in graphics(2) does not work if copied/pasted in a
threadmain-ed program.

Re: [9fans] bug/feature report (long)

[andrey mirtchovski]

> A useful tip: always use the -w flag to 8c et al.  Take
> any warnings seriously -- they are often caused by
> programming errors.  In this case, you would be warned
> that ptr is used but not set.  And indeed it isn't.

i don't want to argue, and indeed you're right.  this is bad
programming.  the fact remains though, the 'create new rio window'
example in graphics(2) does not work if copied/pasted in a
threadmain-ed program.

Re: [9fans] bug/feature report (long)

[David Gordon Hogan]

> void
> main()
> {
> 	int *ptr;
> 	print("%ux\n", ptr);
> }
> p9% diff norm.c thrd.c
> 6c6
> < main()
> ---
> > threadmain()
>
> i guess, threadmain does not initialize pointers to nil.

Local variable are not initialized in general.  In the case
of main(), it just happens to be nil (zero) because the
stack segment hasn't had a chance to get polluted yet.

A useful tip: always use the -w flag to 8c et al.  Take
any warnings seriously -- they are often caused by
programming errors.  In this case, you would be warned
that ptr is used but not set.  And indeed it isn't.