From: Daniel B. <da...@te...> - 2001-09-26 00:26:45
|
In SBCL 0.6.13, compiled calls to make-string appear to ignore an :initial-element #\Space argument * (defun s () (make-string 10 :initial-element #\Space)) S * (s) " " * (compile 's) S NIL NIL * (s) "" <- ten ASCII NULs I don't have a more recent version, I'm ashamed to say (I have too many SBCL trees anyway ...). Can anyone try this in recent CVS? It seems to work for most other initial elements (tried #\S, #\Tab, #\Newline); I almost wonder if the implementation is using #\Space for some kind of special marker, but I've looked at it and it doesn't seem to be. CMUCL works fine in this case, and has exactly the same code for MAKE-STRING; I'd be inclined to start by suspecting the argument-parsing code -dan -- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources |
From: William H. N. <wil...@ai...> - 2001-09-26 01:51:17
|
On Wed, Sep 26, 2001 at 01:25:55AM +0100, Daniel Barlow wrote: > > In SBCL 0.6.13, compiled calls to make-string appear to ignore an > :initial-element #\Space argument > > * (defun s () (make-string 10 :initial-element #\Space)) > S > * (s) > " " > * (compile 's) > S > NIL > NIL > * (s) > "" <- ten ASCII NULs > > I don't have a more recent version, I'm ashamed to say (I have too > many SBCL trees anyway ...). Can anyone try this in recent CVS? I just tried this in my checked out copy, what should become 0.pre7.37.flaky5.21, and the bug is there, except it's slightly different there because there are no interpreted functions any more, so you can skip the COMPILE step. It's now bug #126. -- William Harold Newman <wil...@ai...> "Sometimes if you have a cappuccino and then try again it will work OK." -- Dr. Brian Reid, 1992, quoted by mjr "Sometimes one cappucino isn't enough." -- mjr = Marcus J. "will do TCP/IP for food" Ranum <mj...@hu...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Nathan F. <fr...@ro...> - 2001-09-26 05:09:38
|
William Harold Newman wrote: > On Wed, Sep 26, 2001 at 01:25:55AM +0100, Daniel Barlow wrote: > >>In SBCL 0.6.13, compiled calls to make-string appear to ignore an >>:initial-element #\Space argument > > I just tried this in my checked out copy, what should become > 0.pre7.37.flaky5.21, and the bug is there, except it's slightly > different there because there are no interpreted functions any more, > so you can skip the COMPILE step. I tried it in what appears (according to the startup message) to be 0.pre7.37 (checked out from Sourceforge CVS a couple days ago) and Dan's example works properly -- i.e. the interpreted version and the compiled version behave the same, returning " ". -Nathan |
From: Alexey D. <ade...@co...> - 2001-09-26 08:45:40
|
FIX : change the value of DEFAULT-INIT-CHAR to #\Null (in src/code/early-extensions.lisp) or replace `#.default-init-char' to `#\Null' in `(defparameter *array-info* ...)' in src/compiler/array-tran.lisp. Explanation : (see src/compiler/array-tran.lisp, (deftransform make-array)) to make a simple vector inlined version of MAKE-ARRAY calls ALLOCATE-VECTOR, which automagically fills the memory with some default value (0s). If this value can not be read as INITIAL-ELEMENT (expected values with various types are in *ARRAY-INFO*), MAKE-ARRAY additionaly calls FILL. In the considered case ALLOCATE-VECTOR gives an array of #\NULL-s, but MAKE-ARRAY thinks, that it is filled with #\Space-s and does not call FILL. 0.pre7.37 does not seem to optimize calls to MAKE-ARRAY, therefore, it does full initialization. Regards, Alexey Dejneka |
From: William H. N. <wil...@ai...> - 2001-09-26 15:41:14
|
On Wed, Sep 26, 2001 at 12:50:27PM +0400, Alexey Dejneka wrote: > FIX : change the value of DEFAULT-INIT-CHAR to #\Null (in > src/code/early-extensions.lisp) or replace `#.default-init-char' to > `#\Null' in `(defparameter *array-info* ...)' in > src/compiler/array-tran.lisp. > > Explanation : (see src/compiler/array-tran.lisp, (deftransform > make-array)) to make a simple vector inlined version of MAKE-ARRAY > calls ALLOCATE-VECTOR, which automagically fills the memory with some > default value (0s). If this value can not be read as INITIAL-ELEMENT > (expected values with various types are in *ARRAY-INFO*), MAKE-ARRAY > additionaly calls FILL. In the considered case ALLOCATE-VECTOR gives > an array of #\NULL-s, but MAKE-ARRAY thinks, that it is filled with > #\Space-s and does not call FILL. > > 0.pre7.37 does not seem to optimize calls to MAKE-ARRAY, therefore, it > does full initialization. Thank you. The original CMU CL code used #\NULL as the initial value for strings. I prefer to use #\SPACE as the high level default initial element for strings, since it seems surprising for the default of an ANSI operation MAKE-STRING not to be an ANSI BASE-CHAR, and in converting from #\NULL to #\SPACE I introduced the bug when I misunderstood some of the behavior that you explained. I experimented with a little while waiting for compilation on some simple tests of something else, and I think I understand how to fix it and still keep the #\SPACE default, but it looks like a bit more than a one-line change, so I think I'll wait until I get back from of this already-gone-on-far-too-long flaky5_branch thing. -- William Harold Newman <wil...@ai...> pending patches from sbcl-devel: Ingvar Mattson any-8-bit-character-set patch 2001-09-05 (web link) MNA patch for fd-stream.lisp 2001-09-10 Alexey Dejneka "Bug in EXPAND-DEFGENERIC" patch 2001-09-10 Alexey Dejneka "strange behavior of DIRECTORY" bug report 2001-09-21, patch 2001-09-22 Swap FunctionPointer and InstancePointer type codes for PPC convenience (dan 2001-09-22). bug 126 fix Alexey Dejneka 2001-09-26 (now /usr/stuff/bug126.diff) already in flaky5_branch code: MNA 'reworked defclass patch' 2001-09-05 pending easy-to-fix bugs: (NBUTLAST NIL 0), reported anonymously in SourceForge bugs system PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |