[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 3 readline bugs: source positions, readline-options, endless loop on
Re: 3 readline bugs: source positions, readline-options, endless loop on error
Thu, 25 Jan 2001 13:06:59 +0100 (MET)
On Thu, 25 Jan 2001, Martin Grabmueller wrote:
> > Date: Thu, 25 Jan 2001 11:41:31 +0100 (MET)
> > From: Dirk Herrmann <address@hidden>
> > On Thu, 25 Jan 2001, Martin Grabmueller wrote:
> > > The next problem is that with readline, you don't get source positions
> > > in error messages. The reason is that the readline port created by
> > > `make-readline-port' (readline.scm) is not given a file name. The
> > > following patch fixes the problem for simple cases, but not when
> > > calling `set-readline-input-port!', which should also copy the
> > > filename; but I am not sure how to test this procedure.
> > >
> > > Maybe this problem is not worth fixing anyway, because the filename is
> > > always `standard input'.
> > I think the problem has to be solved differently: Why should the output
> > of source positions be dependent of the existence of a filename for an
> > input port? This does not make sense, for example for string ports.
> > Thus, I suggest to display source positions independent of whether the
> > port has an associated file name. If no file name was given, the error
> > message can use a default string like "<unnamed port>". Or, rather one
> > could think of storing the port with the source properties instead of a
> > filename.
> Your first suggestion is easy to implement and only requires hacking
> display_header in backtrace.c. I could provide a patch for that.
Yes, that would be nice.
> The second requires a bigger patch, at least a lot of functions in
> read.c would have to change to either pass the port along where
> currently the filename is passed, or to put the port into the source
> property hash instead of the filename. Also, srcprop.c would need to
> be modified, because the allowed source properties are kindof
> I think the effort for the second version is not justified, because we
> would not gain much more information from storing the port with the
> properties, as they have no name anyway. Also, the source properties
> would keep a reference to the port, which prevents it from getting
> closed (unless I have not properly understood the weak hash thingy).
Even if a port has no name, you would still gain the information about
what kind of port it is. If it is a string port, you currently don't get
any information about that fact, and a filename is also not printed :-(
And, keeping a reference to a port will not prevent it from getting
closed, but only from getting garbage collected. However, I am not sure
whether guile bothers to actually close the input ports...