Re: [9fans] ports update

Re: [9fans] ports update

[Richard C Bilson]

> I'm running quite reliably under Linux/x86 for all day-to-day work,

Actually, I just blew away my existing copy and did a fresh check-out,
and now things seem to work on Linux.  Thanks, cvs.

I'll see if I can get purify to work on SunOS.

Re: [9fans] ports update

[Russ Cox]

Richard C Bilson wrote:

>>I'm running quite reliably under Linux/x86 for all day-to-day work,
>>    
>>
>
>Actually, I just blew away my existing copy and did a fresh check-out,
>and now things seem to work on Linux.  Thanks, cvs.
>
>I'll see if I can get purify to work on SunOS.
>  
>

I did just fix an important bug in the resize code
that could cause stray memory accesses after you've
resized the window.  And I rolled in Axel's new startup
code changes -- they handle the case where you're
sitting at a (say) 24-bit display but have your default
window depth set to 8-bit.

William Josephson suggests that the setlabel/gotolabel
implementation for SPARC may not be handling register
window overflow/underflow properly.  We have a different
implementation in tra (and of course I don't know the history
of either one) that might be worth trying, but I've done
my time fighting this stuff for the day.  ("SPARC" is "CRAPS"
backwards. -- rob)

Russ

Re: [9fans] ports update

[Axel Belinfante]

> I did just fix an important bug in the resize code
> that could cause stray memory accesses after you've
> resized the window. 

And many thanks for that!!

> And I rolled in Axel's new startup
> code changes -- they handle the case where you're
> sitting at a (say) 24-bit display but have your default
> window depth set to 8-bit.

Just to have it mentioned in public:

the code only uses the default window depth if all else fails --
if it succeeds at 24-bit it will happily ignore your default 8-bit.

(if this would be too surprising the code could be changed
 to only try the default, I guess)

Axel.

Re: [9fans] ports update

[boyd, rounin]

> Thanks, cvs.

oxymoron

Re: [9fans] ports update

[boyd, rounin]

rob did say, many years ago, that the SPARC FPU was a nightmare.

Re: [9fans] ports update

[boyd, rounin]

> Do you have the translator at hand anyway?

sam

Re: [9fans] ports update

[Scott Schwartz]

| I suspect it's a stack overflow problem, I just don't know
| where to look or how.  I'm not overflowing the stack on other
| systems, and I've got 32kB stacks in the program in question,
| which should be way more than enough.  On Linux I can use
| valgrind to check such things (well, sort of).

Sun's bcheck might work.  I'll see if I can give it a try.

Re: [9fans] ports update

[Russ Cox]

Fco.J.Ballesteros wrote:

>Do you mean that you use global search and replace both to
>translate anonymous struct/unions to named ones and
>also to translate array initialization syntax?
>  
>

Yes, but different search-and-replaces.

>Initialization syntax can be hard to do that way, unless I'm
>missing something obvious (eg. like it existing now in the std).
>  
>

It's easy to turn

int x[10] = {
[a]   1,
[b]   2,
[c]   3,
};

into

int x[10];

static void
initx(void)
{
    x[a]= 1;
    x[b]= 2;
    x[c]= 3;
};

and then call initx() from somewhere appropriate.

> Do you have the translator at hand anyway?


I'd have to dig it up and it doesn't entirely work.

Russ

Re: [9fans] ports update

[Sam]

> Strangely, they're quite sturdy when run over VNC, but
> not when I use my normal (Xfree86) X server.

It works like a champ here (gentoo linux, x86, xfree86).

I wish I could find the words to express how happy I am
using the ports.  The first time I used acme in linux
I was damn near misty-eyed.

(stands and claps)

Sam

Re: [9fans] ports update

[Russ Cox]

Richard C Bilson wrote:

>>From: Russ Cox <rsc@swtch.com>
>>
>>I suspect it's a stack overflow problem, I just don't know
>>where to look or how.  I'm not overflowing the stack on other
>>systems, and I've got 32kB stacks in the program in question,
>>which should be way more than enough.  On Linux I can use
>>valgrind to check such things (well, sort of).
>>    
>>
>
>For what it's worth, I haven't yet been able to get the ports working
>reliably under either Linux/x86 or SunOS.  Strangely, they're quite
>sturdy when run over VNC, but not when I use my normal (Xfree86) X
>server.
>  
>

I'm running quite reliably under Linux/x86 for all day-to-day work,
and I was using FreeBSD for a good while too.  There was an important
bug fix to libregexp a couple weeks ago, but since then they've been solid.

Russ

Re: [9fans] ports update

[Axel Belinfante]

> For what it's worth, I haven't yet been able to get the ports working
> reliably under either Linux/x86 or SunOS.  Strangely, they're quite
> sturdy when run over VNC, but not when I use my normal (Xfree86) X
> server.

If the problem is at start up time of window apps (X BadMatch error)
the answer may be in a fix (on a fix) I privately send to Russ.
If not...

on sunos, acme dies when I resize it (make it bigger).
I worked around by commenting out the free(i) in
 libdraw/alloc.c:/^freeimage
Now it no longer dies but still does not use the added size.

I recompiled all with that 'patch' and now at least
those apps I tried seem to work (acme, 9term).
Did not use them a lot, so far, though.

Axel.

Re: [9fans] ports update

[Richard C Bilson]

> From: Russ Cox <rsc@swtch.com>
> 
> I suspect it's a stack overflow problem, I just don't know
> where to look or how.  I'm not overflowing the stack on other
> systems, and I've got 32kB stacks in the program in question,
> which should be way more than enough.  On Linux I can use
> valgrind to check such things (well, sort of).

For what it's worth, I haven't yet been able to get the ports working
reliably under either Linux/x86 or SunOS.  Strangely, they're quite
sturdy when run over VNC, but not when I use my normal (Xfree86) X
server.

I was hoping I could say something more constructive but I can't.  If I
have some time, I'll see if I can send 'em through purify.

- Richard

Re: [9fans] ports update

[Fco.J.Ballesteros]

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

Do you mean that you use global search and replace both to
translate anonymous struct/unions to named ones and
also to translate array initialization syntax?

Initialization syntax can be hard to do that way, unless I'm
missing something obvious (eg. like it existing now in the std).

Do you have the translator at hand anyway?

thanks

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

From: Russ Cox <rsc@swtch.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ports update
Date: Fri, 26 Mar 2004 10:41:12 -0500
Message-ID: <40644F18.4060208@swtch.com>

Fco.J.Ballesteros wrote:

>Anyone has a translator from Ken C to the std?
>  
>

Yes, but it's hard to preserve comments and the like.
I typically use acme and global search and replace.
It's usually trivial.  (For a counterexample, though, see
libhtml.)

Russ

Re: [9fans] ports update

[Russ Cox]

Douglas A. Gwyn wrote:

> Russ Cox wrote:
>
>> The C is now more standard, so much so that it compiles
>> under SunOS with their compilers.  The resulting programs
>> don't stay running for very long, but I've grown to expect
>> that from SunOS.
>
>
> Solaris has been very stable in my experience.  Most likely you're 
> doing something like growing the stack without bound, or failing to 
> close fds in a server, or something of the sort involving differences 
> between the Plan 9 and Solaris program environments.


I suspect it's a stack overflow problem, I just don't know
where to look or how.  I'm not overflowing the stack on other
systems, and I've got 32kB stacks in the program in question,
which should be way more than enough.  On Linux I can use
valgrind to check such things (well, sort of).

Russ

Re: [9fans] ports update

[Russ Cox]

Fco.J.Ballesteros wrote:

>Anyone has a translator from Ken C to the std?
>  
>

Yes, but it's hard to preserve comments and the like.
I typically use acme and global search and replace.
It's usually trivial.  (For a counterexample, though, see
libhtml.)

Russ

Re: [9fans] ports update

[Fco.J.Ballesteros]

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

Anyone has a translator from Ken C to the std?

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

From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ports update
Date: Fri, 26 Mar 2004 09:54:30 GMT
Message-ID: <4uidnZbhYMHKVf7dRVn-tw@comcast.com>

Russ Cox wrote:
> The C is now more standard, so much so that it compiles
> under SunOS with their compilers.  The resulting programs
> don't stay running for very long, but I've grown to expect
> that from SunOS.

Solaris has been very stable in my experience.  Most likely you're doing 
something like growing the stack without bound, or failing to close fds 
in a server, or something of the sort involving differences between the 
Plan 9 and Solaris program environments.

Re: [9fans] ports update

[Douglas A. Gwyn]

Russ Cox wrote:
> The C is now more standard, so much so that it compiles
> under SunOS with their compilers.  The resulting programs
> don't stay running for very long, but I've grown to expect
> that from SunOS.

Solaris has been very stable in my experience.  Most likely you're doing 
something like growing the stack without bound, or failing to close fds 
in a server, or something of the sort involving differences between the 
Plan 9 and Solaris program environments.

[9fans] ports update

[Russ Cox]

As usual, http://swtch.com/plan9port.

Lots of bugs fixed.

The C is now more standard, so much so that it compiles
under SunOS with their compilers.  The resulting programs
don't stay running for very long, but I've grown to expect
that from SunOS.

Various small feature additions.  Not least, win uses
a real pty now, so that ^D and DEL are interpreted properly
during the session, and 9term behaves more like recent rio, with
filename completion and arrow movement.  9term works on
Mac OS X now too.

There is a link to a change log at the bottom of the page.

Thanks to all who reported bugs, fixes, enhancements, and
suggestions.

Enjoy.
Russ