gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Patch for configure.in


From: Gregory Wright
Subject: Re: [Gcl-devel] Patch for configure.in
Date: 21 Jun 2002 19:32:39 -0400

On Fri, 2002-06-21 at 19:11, Camm Maguire wrote:
> Greetings!  So nice to see a knowledgeable autoconfer interested in
> GCL! 
> 
> Gregory Wright <address@hidden> writes:
> 
> > On Wed, 2002-06-19 at 17:02, Camm Maguire wrote:
> > > Greetings!  First of all, thank you for working on getting ilisp
> > > working! 
> > > 
> > > Gregory Wright <address@hidden> writes:
> > > 
> > > > --=-PbhhzNvdDj+5BROuZtgX
> > > > Content-Type: text/plain
> > > > Content-Transfer-Encoding: 7bit
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > The attached patch adds the option to build without readline support.
> > > > Just say ./configure --without-readline. Building with readline support
> > > > remains the default, if it is available.
> > > > 
> > > 
> > > OK, I've committed a slight modification, as we seem to be using the
> > > enable/disable versions elsewhere.  You can ./configure --disable
> > > readline. 
> > >
> > 
> > I would suggest keeping the --with/--without, since (from the
> > autoconf-2.5 manual)
> > 
> >     Some packages require, or can optionally use, other software
> >     packages already installed. The user can give configure command
> >     line options to specify which such external software to use.
> >     The options have one of these forms:
> > 
> >             --with-package=[arg]
> >             --without-package
> > 
> 
> Thanks for spelling this out -- had always been a mytery to me.  I
> agree, we should keep this distinction.  Will try to get to it when I
> can. 

I can take care of this, since I already volunteered to buff
configure.{in,ac}.


> 
> > The right way to do this is not in the shell script wrapper, but in the
> > initialization code for the front end itself. We want to call isatty to
> > test whether the standard input is a terminal or not. isatty should be
> > supported on any platform gcl builds on. If it indicates a terminal,
> > initialize readline, otherwise leave it off.
> > 
> 
> Agreed!  On my todo list too.  If you have a suggested patch before I
> get to it, please post it.
> 

I'll try to cook up a patch based on the guile code. It's should be
simple.

The point of the exercise is to avoid trouble when reading from a pipe,
so we can make gcl play nicely with different front ends. {Xe,e}macs is
the usual front end, but perhaps eclipse could be a possibility in the
future.



> > This is the approach taken by guile, IIRC.
> > 
> > Unfortunately, testing whether the shell was invoked interactively (by
> > checking whether the variable $- contains 'i') doesn't work. For a
> > script, $- always indicates a non-interactive shell.
> > 
> 
> Is this a problem?  Can't we turn on readline in the
> non-interactive-but-tty case?  It seems like the only major place we
> want to turn it off is in a 'dumb' emacs terminal/shell.
> 
> > > 
> > > OK, Are you sure?
> > 
> > Well, I think I've found a way to configure ilisp to work around the
> > readline issue, at least for ilisp + xemacs. I'm still beating on it to
> > be certain. We should probably retain the option to build without
> > readline, as problems like this happen whenever interactive applications
> > with line editing read from other processes via sockets or pipes. And
> > I'm always leery of shell script wrappers because of portability issues.
> > 
> 
> OK, lets retain the option.  What's the latest on ilisp?  Sounds like
> you have something working.

Ilisp still needs a bit of work. It shuts gcl down cleanly now but can
still wedge in a tight select() loop. It's as if ilisp is expecting
output that has somehow gotten lost. Ilisp just polls eternally. Let you
know when it's ready to go.


> -- 

Gregory Wright
Chief Technical Officer
PacketStorm Communications, Inc.
20 Meridian Road
Eatontown, New Jersey 07724

1 732 544-2434 ext. 206
1 732 544-2437 [fax]
address@hidden





reply via email to

[Prev in Thread] Current Thread [Next in Thread]