clisp-devel

Re: clisp/src TODO,1.88,1.89

[Sam S. <sd...@gn...>]

> * Bruno Haible <un...@hf...> [2005-06-07 10:51:16 +0000]:
>
> +bind-eval.tst failure on Linux/amd64 [sam]

this one is yours.

> +use LockFile instead of LockFileEx [sam]
> +
> +comments for addr_to_string, string_to_addr [sam]
> +
> +comments for open_file_stream_handle, file_stream_truename [sam]

ok.

> +workaround for extra comma in _clisp.1 [sam]

forget about it.
it has been fixed in the XSL CVS.

> +regression: resolution of logical pathnames is broken, try
> +   (compile-file (logical-pathname "FOO.LISP")) [sam]

you mean this?

*** - LOGICAL-PATHNAME: argument "FOO.LISP" does not contain a host
      specification


-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://ffii.org/> <http://pmw.org.il/> <http://www.camera.org>
<http://www.dhimmi.com/> <http://www.openvotingconsortium.org/>
Lisp: it's here to save your butt.

Re: clisp/src TODO,1.88,1.89

[Bruno H. <br...@cl...>]

Sam wrote:
> > +bind-eval.tst failure on Linux/amd64 [sam]
>
> this one is yours.

No, this feature is your code. I looked at it and found that I don't understand
the code. So it's better if you fix it, since you understand it.

> > +workaround for extra comma in _clisp.1 [sam]
>
> forget about it.
> it has been fixed in the XSL CVS.

Will you upgrade your tools to this version, or is it too risky?

> > +regression: resolution of logical pathnames is broken, try
> > +   (compile-file (logical-pathname "FOO.LISP")) [sam]
>
> you mean this?
>
> *** - LOGICAL-PATHNAME: argument "FOO.LISP" does not contain a host
>       specification

Actually I meant this:

   (compile-file (logical-pathname "SYS:FOO.LISP"))

With clisp-2.33.2 I got

*** - OPEN: file #P"/foo.lisp" does not exist

which means that the translation from logical to physical pathname was
performed successfully. Now I get

*** - TRANSLATE-PATHNAME: replacement pieces ("foo" "lisp" :NEWEST) do not fit
      into #P"*"

which indicates an error during this translation.

Bruno

Re: clisp/src TODO,1.88,1.89

[Sam S. <sd...@gn...>]

> * Bruno Haible <oe...@py...> [2005-06-07 22:43:19 +0200]:
>
> Sam wrote:
>> > +bind-eval.tst failure on Linux/amd64 [sam]
>>
>> this one is yours.
>
> No, this feature is your code. I looked at it and found that I don't
> understand the code. So it's better if you fix it, since you
> understand it.

nope, I don't.

>> > +workaround for extra comma in _clisp.1 [sam]
>>
>> forget about it.
>> it has been fixed in the XSL CVS.
>
> Will you upgrade your tools to this version, or is it too risky?

I am tracking this issue.
if they will not get their act together before we release, it can be
fixed by hand for the release.

>> > +regression: resolution of logical pathnames is broken, try
>> > +   (compile-file (logical-pathname "FOO.LISP")) [sam]

fixed. all the release blockers are now yours.


PS. has the FRESH-LINE issue been settled?
    <http://article.gmane.org/gmane.lisp.clisp.devel:14259>

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.honestreporting.com> <http://www.dhimmi.com/>
<http://www.memri.org/> <http://www.palestinefacts.org/>
There are two ways to write error-free programs; only the third one works.

Re: clisp/src TODO,1.88,1.89

[Bruno H. <br...@cl...>]

Sam wrote:
> I am tracking this issue.
> if they will not get their act together before we release, it can be
> fixed by hand for the release.
>
> >> > +regression: resolution of logical pathnames is broken, try
> >> > +   (compile-file (logical-pathname "FOO.LISP")) [sam]
>
> fixed. all the release blockers are now yours.

Thanks. You're exemplary!

Bruno

Re: FRESH-LINE and #\Tab

[Bruno H. <br...@cl...>]

Sam wrote:
> PS. has the FRESH-LINE issue been settled?
>     <http://article.gmane.org/gmane.lisp.clisp.devel:14259>

Although in general the line position after outputting a tab is undefined,
I can admit that in all cases it will be > 0, and that FRESH-LINE should
notice this.

The fix will be to complement the stream's strm_wr_ch_lpos field with a
strm_wr_ch_lpos_positive field that is 1 if the line-position is known
to be > 0 and 0 otherwise. That's for built-in streams. For Gray streams,
test whether (STREAM-LINE-COLUMN stream) is > 0. It will be a bit of a
slow-down. Oh well. And since it's a change that touches a dozen of C
functions, it must be delayed after 2.34.

Bruno

Re: FRESH-LINE and #\Tab

[Sam S. <sd...@gn...>]

> * Bruno Haible <oe...@py...> [2005-06-22 23:18:49 +0200]:
>
> Sam wrote:
>> PS. has the FRESH-LINE issue been settled?
>>     <http://article.gmane.org/gmane.lisp.clisp.devel:14259>
>
> Although in general the line position after outputting a tab is
> undefined, I can admit that in all cases it will be > 0, and that
> FRESH-LINE should notice this.
>
> The fix will be to complement the stream's strm_wr_ch_lpos field with
> a strm_wr_ch_lpos_positive field that is 1 if the line-position is
> known to be > 0 and 0 otherwise. That's for built-in streams. For Gray
> streams, test whether (STREAM-LINE-COLUMN stream) is > 0. It will be a
> bit of a slow-down. Oh well. And since it's a change that touches a
> dozen of C functions, it must be delayed after 2.34.

this sounds too complex.
what happens now to strm_wr_ch_lpos when #\TAB is output?
why not just increment it by 1? (or by 5 - #\#, #\\, #\T, #\A, #\B :-)

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://pmw.org.il/> <http://www.camera.org>
<http://www.iris.org.il> <http://ffii.org/> <http://www.memri.org/>
Never succeed from the first try - if you do, nobody will think it was hard.