cvs commit: hugs98/src ffi.c

[Simon Marlow]

> > btw The storable instances are bogus - fixing now
>=20
> Ooops, they were in fact fine (I got confused over whether they should
> use byte offsets or element offsets).
>=20
> But while killing my commit of the 'fixed' code I got myself=20
> in this state:
>=20
> cvs server: [09:47:46] waiting for reid's lock in=20
> /home/cvs/root/hugs98/lib/extscvs server: [09:48:16] waiting=20
> for reid's lock in /home/cvs/root/hugs98/lib/extscvs server:=20
> [09:48:46] waiting for reid's lock in=20
> /home/cvs/root/hugs98/lib/extsKilled by signal 2.
>=20
> I have no idea how to clean this up.

I assume you've probably fixed this by now.  For future reference (and
anyone else who runs into this problem): stale locks tend to be left
around when CVS crashes, and have to be removed by hand by logging on to
cvs.haskelll.org with SSH, and removing the appropriate lock file from
/home/cvs/root/<wherever> which is usually called something beginning
with '.#cvs' IIRC.

Cheers,
	Simon