Re: [9fans] any success with current plan9port on sunos5.8?

Re: [9fans] any success with current plan9port on sunos5.8?

[Richard C Bilson]

> From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
> 
> Just curious: has anyone had any luck with the
> current plan9 ports package on sunos 5.8?
> (I read that Bengt has problems too, and that
>  for Russ it works (fine?) on 5.9, correct?)

Well, I had to comment out some stuff that doesn't work and rename a
few symbols, but in large part it works.  I believe Bengt already
described most of these problems.  I'm typing this in acme right now.

I do notice that among my diffs that at one point I played with the
stack size.  I don't know whether a larger stack is actually necessary,
but I do know that most of the SunOS problems I've had have come down
to one stack or another being too small.

Index: cmd/acme/dat.h
===================================================================
RCS file: /cvs/plan9/src/cmd/acme/dat.h,v
retrieving revision 1.7
diff -r1.7 dat.h
549c549
< #define	STACK	32768
---
> #define	STACK	65536
Index: libthread/main.c
===================================================================
RCS file: /cvs/plan9/src/libthread/main.c,v
retrieving revision 1.9
diff -r1.9 main.c
47c47
< 		mainstacksize = 32*1024;
---
> 		mainstacksize = 64*1024;

Re: [9fans] any success with current plan9port on sunos5.8?

[C H Forsyth]

---
> #define	STACK	65536
===================================================================
---
> 		mainstacksize = 64*1024;


what are they doing that uses that much??

Re: [9fans] any success with current plan9port on sunos5.8?

[William Josephson]

On Fri, Jun 11, 2004 at 03:02:04PM +0100, C H Forsyth wrote:
> ---
> > #define	STACK	65536
> ===================================================================
> ---
> > 		mainstacksize = 64*1024;
> 
> 
> what are they doing that uses that much??

Maybe they're as clever as the GNU folks
and use a ton of stack space to do qsort().

Re: [9fans] any success with current plan9port on sunos5.8?

[Russ Cox]

> Maybe they're as clever as the GNU folks
> and use a ton of stack space to do qsort().

Now, now.  The only reason the GNU folks 
use a lot of stack space for qsort() is the big
buffer that they read /proc/meminfo into.
The sort itself is very careful about how much
stack it uses.

Russ

Re: [9fans] any success with current plan9port on sunos5.8?

[Axel Belinfante]

> Well, I had to comment out some stuff that doesn't work and rename a
> few symbols, but in large part it works.  I believe Bengt already
> described most of these problems.  I'm typing this in acme right now.

Cool. Looked back at Bengt's message, and reread the (p9)yield fix,
which I remembered applying.
Then found that my libthread/fdwait.c starts (started, by now)
with a #define NONOPLAN9DEFINES such that my pollidle would call
sunos' yield() instead of libthreads (renamed via the #define) p9yield() :-(
(why I did add the NONOPLAN9DEFINES there I don't recall)

Suffices to say that after some recompilations acme now works,
and I'm pretty confident that after recompiling
(after removing all the debug prints I introduced)
the whole port will benefit from the increased stack sizes.

Thanks _a_lot_ for the replies to my initial post in this thread,
which gave me enough inspiration to put in enough perspiration...

Axel - feeling foolish, but happy it works now

Re: [9fans] any success with current plan9port on sunos5.8?

[Bengt Kleberg]

Richard C Bilson wrote:

> Well, I had to comment out some stuff that doesn't work and rename a
> few symbols, but in large part it works.  I believe Bengt already
> described most of these problems.  I'm typing this in acme right now.
> 

it has to be added that i only got things to compile. i can not get the 
graphical programs (sam, acme, 9term) to work. the window appears, but 
there is no content. a working acme is much better result than i 
managed. congratulations.


bengt

Re: [9fans] any success with current plan9port on sunos5.8?

[Axel Belinfante]

Bengt wrote:
> Richard C Bilson wrote:
> 
> > Well, I had to comment out some stuff that doesn't work and rename a
> > few symbols, but in large part it works.  I believe Bengt already
> > described most of these problems.  I'm typing this in acme right now.
> > 
> 
> it has to be added that i only got things to compile. i can not get the 
> graphical programs (sam, acme, 9term) to work. the window appears, but 
> there is no content. a working acme is much better result than i 
> managed. congratulations.

Just to make sure you do not have the same problem as I had:
check which *yield* symbols are present in your non-working binary,
do something like

	nm o.acme |grep yield

If you have both p9yield and yield you likely have the same problem.
in the same way, try (typing path from memory)

	nm $PLAN9/src/libthread/fdwait.o | grep yield

that is where my problem originated.
Fix it by recompiling fdwait.c such that the yield() call
in that file gets #define'ed to p9yield, so there is no
reference any more to the sunos system library yield routine.

My fix was:

; cvs diff fdwait.c
Index: fdwait.c
===================================================================
RCS file: /cvs/plan9/src/libthread/fdwait.c,v
retrieving revision 1.8
diff -r1.8 fdwait.c
1c1
< #define NOPLAN9DEFINES
---
> //#define NOPLAN9DEFINES

This is to make sure that the following workaround to
deal with the yield name clash has the right effect.

Index: thread.h
===================================================================
RCS file: /cvs/plan9/include/thread.h,v
retrieving revision 1.9
diff -r1.9 thread.h
124c124,128
< int	yield(void);
---
> int	p9yield(void);
> #ifndef NOPLAN9DEFINES
> #define       yield   p9yield
> #endif
> 

Looking at it now, I guess a different (better?!?) solution might be
to simply remove the #ifndef NOPLAN9DEFINES and #endif lines from
around above #define in thread.h .

Axel.

Re: [9fans] any success with current plan9port on sunos5.8?

[Bengt Kleberg]

Axel Belinfante wrote:
...deleted
> Just to make sure you do not have the same problem as I had:
> check which *yield* symbols are present in your non-working binary,

i have both p9yield and yield present.


...deleted
> Fix it by recompiling fdwait.c such that the yield() call
> in that file gets #define'ed to p9yield, so there is no
> reference any more to the sunos system library yield routine.

will do.


...deleted
>>int	p9yield(void);
>>#ifndef NOPLAN9DEFINES
>>#define       yield   p9yield
>>#endif
>>
> 
> 
> Looking at it now, I guess a different (better?!?) solution might be
> to simply remove the #ifndef NOPLAN9DEFINES and #endif lines from
> around above #define in thread.h .

imho the idea of NOPLAN9DEFINES is to make sure that only the original 
operating systems definitions are present. it would be very confusing to 
  get yield() replaced with p9yield() after having defined NOPLAN9DEFINES.

your first idea is better. however, i do not think it is perfect. 
instead, i wonder why fdwait.c had NOPLAN9DEFINE. if it was neccessary 
surely something else is now broken when it was removed. and if it was 
not neccessary, why was it there?


bengt

[9fans] plan9port 9term

[Bengt Kleberg]

i have a question about plan9port 9term. is it supposed to have a 
button-3 menu?
the old 9term (from matty farrow) does.


bengt

Re: [9fans] plan9port 9term

[Axel Belinfante]

> i have a question about plan9port 9term.
> is it supposed to have a button-3 menu?

it has not, (that is why?) it displays the rio button3 menu
(or the button3 menu from whatever window manager you are using), as:
(quoted from todo list in the $PLAN9/src/cmd/rio/README)

  - Should change 9term to redirect b3 clicks to rio so that rio
    can put up the usual b3 menu.

(at least, that is what it does for me, as far as I can tell
 (cvs diff) that code got added to the ports distribution)

> the old 9term (from matty farrow) does.

but that one has different entries.
This 9term is much closer to the plan 9 rio windows.


Somewhat related:
I also have code that tries to do some other items from
the todo list in the $PLAN9/src/cmd/rio/README:

  - Should change window focus on b2/b3 clicks and then
    pass along the click event to the now-focused window.

but I think I recall Russ wanted to wait a bit to see if he
really wants this, before including it in the distribution.


The 9wm on which rio is based already contains the code to do

   - Should work out a protocol between 9term and rio so that:
	* 9term can tell rio to blue its border during hold mode

using an X property (Atom? whatever it is called) put in the X server.
I have some not-so-beautiful code that does this as well.

Axel.

Re: [9fans] plan9port 9term

[boyd, rounin]

> > the old 9term (from matty farrow) does.

and what a horrible thing that was; two ioctls per char.

i added look and hacked it so it only called ioctl when
necessary.  trouble being that releasing it outa Digital
woulda revealed (albeit trivial) undocumented pty
features which may have not been in the company's
interests.

getting stuff out was a nightmare anyway.

Re: [9fans] plan9port 9term

[Bengt Kleberg]

Axel Belinfante wrote:
>>i have a question about plan9port 9term.
>>is it supposed to have a button-3 menu?
> 
> 
> it has not, (that is why?) it displays the rio button3 menu
> (or the button3 menu from whatever window manager you are using), as:
> (quoted from todo list in the $PLAN9/src/cmd/rio/README)
> 
>   - Should change 9term to redirect b3 clicks to rio so that rio
>     can put up the usual b3 menu.

i should  have looked around in more README files before asking.
but rio is not the first place where i expected to find information 
about 9term :-)


bengt