From: Christophe R. <cs...@ca...> - 2004-11-02 12:07:33
|
Hi, sbcl-0.8.16.26, just merged, builds with full 21-bit Unicode support by default; it is still possible to build a system which resembles historical versions more closely (only with fewer bugs :-) by removing :SB-UNICODE in customize-target-features.lisp. I have only tested this on x86/Linux; it is entirely possible that I have goofed in merging things (for the PPC) or just implementing them blind (for the other platforms); I warmly encourage testing of simple buildability earlier rather than later in the development cycle -- we still have 18 whole days to go before freezing this month's sbcl, so there is plenty of time to deal with problem reports as long as we get them early enough. There are some known problems. Firstly, as I mentioned on this list before (without anyone coming to offer a strong opinion, as I recall) the sb-md5 contrib fails its tests. The problem lies in the MD5SUM-SEQUENCE function operating on a string: there is an underlying assumption that the character sequence in memory has an identical octet layout as the same sequence of characters in a file; this assumption does not hold with :SB-UNICODE enabled. (And indeed it doesn't even hold in the old world for high-bit characters, which are typically encoded in utf-8 on disk but in latin1 in memory.) It is likely that there is third-party software (such as SB-SHA1, Blowfish and the like) which is similarly afflicted by this change. Secondly, there are performance implications in all these changes. Nothing should be too drastically pessimized, but if there is something which has degraded performance it would be good to know about it before we release something that's embarrassingly slow. The more data are provided, the more likely it is that a solution can be found: I hope everyone's aware of the profiling tools distributed with SBCL. Thirdly, the details of external-format support are probably not in their final form: it is unlikely that the simple keyword-as-external-format-designator implementation is rich enough to describe the multiple layers of translation in a general external format: I hope that people who use multiple encodings will come forward to discuss their needs. In addition, the implementation will most likely undergo some changes; there are clear opportunities for sharing code between SB-ALIEN and streams code for external formats, and there have been requests for functionality to convert between strings and numeric vectors as a function of external-format. (Finally, be advised: my own development time will shortly be severely curtailed, so to a large extent further development of this aspect of SBCL is down to Other People... I look forward to reading patches on the commits mailing list. :-) Cheers, Christophe |
From: Adam W. <li...@co...> - 2004-11-03 06:04:11
|
Hi Christophe Rhodes, > Hi, > > sbcl-0.8.16.2[7], just merged, builds with full 21-bit Unicode support > by default; it is still possible to build a system which resembles > historical versions more closely (only with fewer bugs :-) by removing > :SB-UNICODE in customize-target-features.lisp. This is very impressive Christophe. Congratulations! I suggest people build it using this command: ./make.sh 'sbcl --sysinit /dev/null --userinit /dev/null' Otherwise they may load .sbclrc which may cause compilation to eventually abort (e.g. if readtable case is set to :INVERT in .sbclrc). The new version of sbcl can be tested without installing it using this command: ./src/runtime/sbcl --core ./output/sbcl.core --sysinit /dev/null --userinit /dev/null It's great to see you've adopted strings of Unicode code points. This is far superior to 16-bit surrogates. Regards, Adam |
From: R. M. <rm...@mh...> - 2004-11-03 21:29:05
|
On Wed, 03 Nov 2004 19:04:02 +1300, Adam Warner wrote: > Hi Christophe Rhodes, > >> Hi, >> >> sbcl-0.8.16.2[7], just merged, builds with full 21-bit Unicode support >> by default; it is still possible to build a system which resembles >> historical versions more closely (only with fewer bugs :-) by removing >> :SB-UNICODE in customize-target-features.lisp. > > This is very impressive Christophe. Congratulations! > > I suggest people build it using this command: > > ./make.sh 'sbcl --sysinit /dev/null --userinit /dev/null' > > Otherwise they may load .sbclrc which may cause compilation to eventually > abort (e.g. if readtable case is set to :INVERT in .sbclrc). Did that on my Linux/PPC (Version CVS "0.8.16.29") but the build process segfaults :-( From what i can the segfault happens during the compilation of file "src/code/stream.lisp" Last log message: ; compiling varargs entry for #'(LAMBDA (&OPTIONAL # # ...) (DECLARE #)...): ; recognizing DEFUN FILL-POINTER-SOUT ; compiling top level form: ; compiling function FILL-POINTER: debugger invoked on a SIMPLE-ERROR in thread 9043: segmentation violation at #X258F3D8 I'd be happy to help but this is _Way_ beyond my level of skills. HTH Ralf Mattes |
From: Raymond W. <Ray...@fa...> - 2004-11-04 07:22:46
|
R. Mattes writes: > On Wed, 03 Nov 2004 19:04:02 +1300, Adam Warner wrote: > > > Hi Christophe Rhodes, > > > >> Hi, > >> > >> sbcl-0.8.16.2[7], just merged, builds with full 21-bit Unicode support > >> by default; it is still possible to build a system which resembles > >> historical versions more closely (only with fewer bugs :-) by removing > >> :SB-UNICODE in customize-target-features.lisp. > > > > This is very impressive Christophe. Congratulations! > > > > I suggest people build it using this command: > > > > ./make.sh 'sbcl --sysinit /dev/null --userinit /dev/null' > > > > Otherwise they may load .sbclrc which may cause compilation to eventually > > abort (e.g. if readtable case is set to :INVERT in .sbclrc). > > Did that on my Linux/PPC (Version CVS "0.8.16.29") but the build process > segfaults :-( Probably not very helpful, but: - 0.8.16.26 builds on PPC/Darwin wwith no problems. This is a great addition to SBCL! Now, if I could only arrange it so that I could use Lisp for job-related stuff... |
From: Christophe R. <cs...@ca...> - 2004-11-04 10:56:11
|
"R. Mattes" <rm...@mh...> writes: >> I suggest people build it using this command: >> >> ./make.sh 'sbcl --sysinit /dev/null --userinit /dev/null' > > Did that on my Linux/PPC (Version CVS "0.8.16.29") but the build process > segfaults :-( > >>From what i can the segfault happens during the compilation of file > "src/code/stream.lisp" > Last log message: > > ; compiling varargs entry for #'(LAMBDA (&OPTIONAL # # ...) (DECLARE #)...): > ; recognizing DEFUN FILL-POINTER-SOUT ; compiling top level form: > ; compiling function FILL-POINTER: > > debugger invoked on a SIMPLE-ERROR in thread 9043: > segmentation violation at #X258F3D8 Is this repeatable? This is the host compiler which is segfaulting, so it is possibly indicative of a bug in that compiler (or poor non-ECC RAM :-). If it is, try building from openmcl or clisp. Cheers, Christophe |
From: <rm...@mh...> - 2004-11-04 11:23:30
|
On Thu, Nov 04, 2004 at 10:55:46AM +0000, Christophe Rhodes wrote: > "R. Mattes" <rm...@mh...> writes: > > >> I suggest people build it using this command: > >> > >> ./make.sh 'sbcl --sysinit /dev/null --userinit /dev/null' > > > > Did that on my Linux/PPC (Version CVS "0.8.16.29") but the build process > > segfaults :-( > > > >>From what i can the segfault happens during the compilation of file > > "src/code/stream.lisp" > > Last log message: > > > > ; compiling varargs entry for #'(LAMBDA (&OPTIONAL # # ...) (DECLARE #)...): > > ; recognizing DEFUN FILL-POINTER-SOUT ; compiling top level form: > > ; compiling function FILL-POINTER: > > > > debugger invoked on a SIMPLE-ERROR in thread 9043: > > segmentation violation at #X258F3D8 > > Is this repeatable? Happend three times. > This is the host compiler which is segfaulting, > so it is possibly indicative of a bug in that compiler Argh ... > (or poor non-ECC RAM :-). pretty much not the case: this is my developer box which does a lot of compilation (even large C++ frameworks that tend to stress the box to its limits). ... but that was a good hint: i should've looked at the start of my build log: //building cross-compiler, and doing first genesis This is SBCL 0.8.13.77.character.37, an implementation of ANSI Common Lisp. ^^^^^^^^^^^^^^^^^^^^^ The make.sh script picked up the wrong version of sbcl. > If it is, try building from openmcl or clisp. I'll try do run a compile with my normal sbcl (0.8.14). Iff that fails i'll try openmcl. Is there anything i need to configure besides setting SBCL_XC_HOST? Thanks for your help RalfD |
From: R. M. <rm...@mh...> - 2004-11-04 14:42:00
|
On Thu, 04 Nov 2004 10:55:46 +0000, Christophe Rhodes wrote: > "R. Mattes" <rm...@mh...> writes: > >>> I suggest people build it using this command: >>> >>> ./make.sh 'sbcl --sysinit /dev/null --userinit /dev/null' >> >> Did that on my Linux/PPC (Version CVS "0.8.16.29") but the build process >> segfaults :-( >> >>>From what i can the segfault happens during the compilation of file >> "src/code/stream.lisp" >> Last log message: >> >> ; compiling varargs entry for #'(LAMBDA (&OPTIONAL # # ...) (DECLARE #)...): >> ; recognizing DEFUN FILL-POINTER-SOUT ; compiling top level form: >> ; compiling function FILL-POINTER: >> >> debugger invoked on a SIMPLE-ERROR in thread 9043: >> segmentation violation at #X258F3D8 > > Is this repeatable? This is the host compiler which is segfaulting, > so it is possibly indicative of a bug in that compiler (or poor > non-ECC RAM :-). If it is, try building from openmcl or clisp. Ok, i changed my build setup to use the "right" sbcl (0.8.14) instead of the 0.8.13-Character-Branch and everything seems to work fine. I'm currently trying to build the sources as a debian package to test it with the various third-party packages i use. Thank's a lot RalfD > Cheers, > > Christophe > > > ------------------------------------------------------- This SF.Net > email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE LinuxWorld > Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click |
From: Thomas F. B. <tfb@OCF.Berkeley.EDU> - 2004-11-03 20:07:27
|
langinfo.h and friends are missing on Mac OS X 10.2, so SBCL won't build here, with or without :sb-unicode. |
From: Christophe R. <cs...@ca...> - 2004-11-04 11:00:00
|
"Thomas F. Burdick" <tfb@OCF.Berkeley.EDU> writes: > langinfo.h and friends are missing on Mac OS X 10.2, so SBCL won't > build here, with or without :sb-unicode. Oh, my word, how broken is this OS? OK, well, all we actually use is a call to nl_langinfo(CODESET) to return strings of the form "UTF-8", "ISO-8859-1" and "ANSI_X3.4-1968" as appropriate: I'm sure this could be faked or reimplemented by looking at LANG and LC_CTYPE environment variables. Cheers, Christophe |