From: Sam S. <sd...@gn...> - 2005-06-07 13:57:22
|
> * Bruno Haible <un...@hf...g> [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. |
From: Bruno H. <br...@cl...> - 2005-06-07 20:44:31
|
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 |
From: Sam S. <sd...@gn...> - 2005-06-21 20:44:11
|
> * Bruno Haible <oe...@py...t> [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. |
From: Bruno H. <br...@cl...> - 2005-06-22 21:14:25
|
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 |
From: Bruno H. <br...@cl...> - 2005-06-22 21:20:44
|
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 |
From: Sam S. <sd...@gn...> - 2005-06-22 22:36:47
|
> * Bruno Haible <oe...@py...t> [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. |