From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200403221630.i2MGUf511738@zamenhof.cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme, rio workalike available in plan 9 ports
In-reply-to: Your message of "Sat, 20 Mar 2004 23:51:47 -0500."
             <405D1F63.5010002@swtch.com> 
References: <405D1F63.5010002@swtch.com> 
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 22 Mar 2004 17:30:41 +0100
Topicbox-Message-UUID: 3cb3103e-eacd-11e9-9e20-41e7f4b1d025

> Acme is now included in the ports tree, and has been
> for a few weeks.  Rob tracked down a bad stack overflow
> in libregexp, and since then it's been quite stable.

Tried building all (esp. acme) on SunOS 5.8.
Build works best with gcc.
Anybody else trying the stuff on SunOS 5.8?

Got a number of warnings, and some 'fatal' problems:
no futimesat for lib9/dirfwstat.c (could not find futimes at all)
no TIOCGWINSZ for cmd/mc.c (needs <sys/termios.h>


Unfortuntely I'm still running 8-bit depth.
Running acme on 8-bit depth only works after commenting out
in libdraw/x11-init.c the XMatchVisualInfo tests for 16, 15, 24 bits.

After that, acme runs on 8-bit.

However, resizing causes segfault.
I see what happens but don't see how to fix it.
in the getwindow (or before?) (Image) row.tag.fr.b gets freed,
I guess, because after the mallocz in getimage0
(from getwindow from acme.c) its is zeroed (id field incremented),
with resulting segfault when row.tag.fr.b->display is accessed in frinit.

Commenting out in libdraw/alloc.c in freeimage:	free(i);
makes that it no longer segfaults, but then when I resize
to make the window larger, the additional space is not used by
the text already in the window, that resizes in the old size.

When I Delcol and the Newcol the rightmost column the stuff
in the new column does use the whole availabe size.

If more info is needed to track this down, I'm happy to help.

Axel.