From: Sam S. <sd...@gn...> - 2008-09-18 08:50:50
|
Sorry about such a long pretest process. Let us hope that it bodes well for the quality of the release. Please stress-test clisp cvs head on your favorite platform. Specifically, build clisp in a fresh check out and do "make all check mod-check". Thanks. |
From: Reini U. <ru...@x-...> - 2008-09-20 10:02:19
|
2008/9/18 Sam Steingold <sd...@gn...>: > Sorry about such a long pretest process. > Let us hope that it bodes well for the quality of the release. > Please stress-test clisp cvs head on your favorite platform. > Specifically, build clisp in a fresh check out and do "make all check mod-check". > Thanks. I was very busy lately and had no time for the former pre-tests, sorry. Fresh cvs up and fresh build on cygwin (cvs up -PACd) I'm still on a business trip for one month with lousy WLAN connections and slow single-core laptop. base: finished 4 files: 0 errors out of 542 tests 1 i18n/test.tst: 0 errors out of 10 tests 2 syscalls/test.tst: 0 errors out of 189 tests 3 regexp/test.tst: 0 errors out of 308 tests 4 readline/test.tst: 0 errors out of 35 tests mod-check: finished 8 files: 2 errors out of 615 tests 1 rawsock/test.tst: 0 errors out of 77 tests 2 bindings/win32/test.tst: 0 errors out of 26 tests 3 berkeley-db/test.tst: 0 errors out of 75 tests 4 pcre/test.tst: 0 errors out of 314 tests 5 postgresql/test.tst: 1 error out of 4 tests 6 zlib/test.tst: 0 errors out of 4 tests 7 libsvm/test.tst: 0 errors out of 49 tests 8 gdbm/test.tst: 1 error out of 66 tests postgresql because it was not running, and gdbm for the same old reason. XLIB and gtk2 are causing problems again in my installation, but it worked before so I guess it's my laptop setup. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Raymond T. <raymond.toy@Ericsson.com> - 2008-09-22 19:58:47
|
Sam Steingold wrote: > Sorry about such a long pretest process. > Let us hope that it bodes well for the quality of the release. > Please stress-test clisp cvs head on your favorite platform. > Specifically, build clisp in a fresh check out and do "make all check mod-check". Fresh install of clisp cvs head on Solaris 8. make check produces the same socket-connect error as before (unsurprisingly) and no other errors. I ran make mod-check for the first time. It reports: finished 3 files: 11 errors out of 487 tests 1 i18n/test.tst: 0 errors out of 10 tests 2 syscalls/test.tst: 4 errors out of 170 tests 3 regexp/test.tst: 7 errors out of 307 tests I assume these should all pass, but I don't know. I'm attaching the erg files for these tests. Ray |
From: Sam S. <sd...@gn...> - 2008-09-23 02:13:35
|
> * Raymond Toy <enlzbaq.gbl@Revpffba.pbz> [2008-09-22 14:44:41 -0400]: > > > > Form: (LOOP :FOR N :UPFROM 3 :FOR LG = (HANDLER-CASE (LGAMMA N) (FLOATING-POINT-OVERFLOW NIL 'FLOATING-POINT-OVERFLOW)) :FOR L! = (HANDLER-CASE (LOG (FLOAT (! (1- N)) LG)) (FLOATING-POINT-OVERFLOW NIL 'FLOATING-POINT-OVERFLOW)) :UNLESS (AND (FLOATP LG) (FLOATP L!) (= 1 (FLOAT (/ L! LG) 0.0))) :RETURN (LIST N LG L!)) > CORRECT: (172 711.71472580229d0 FLOATING-POINT-OVERFLOW) > CLISP : (172 711.7147258022899d0 FLOATING-POINT-OVERFLOW) > Differ at position 1: 711.71472580229d0 vs 711.7147258022899d0 > CORRECT: (711.71472580229d0 FLOATING-POINT-OVERFLOW) > CLISP : (711.7147258022899d0 FLOATING-POINT-OVERFLOW) so you libc's lgamma is more precise than that of glibc. interesting. > > Form: (LOOP :FOR N :UPFROM 3 :FOR TG = (TGAMMA N) :UNLESS (= 1 (/ (! (1- N)) TG)) :RETURN N) > CORRECT: 5 > CLISP : 4 oops. tgamma is less precise. oh well, I guess I can tweak the tests to ignore the difference... or maybe you have a better idea? > Form: (STRING= (SHOW (GETENV "USER")) (SHOW (FILE-OWNER *TMP1*))) > CORRECT: T > CLISP : NIL > OUT: > "NIL > \"eusrtoy\" > " please do: $ set | grep eusrtoy > > Form: (LET ((INODE (SHOW (FILE-STAT-INO (FILE-STAT *TMP1*))))) (WITH-OPEN-STREAM (S (RUN-PROGRAM "tail" :ARGUMENTS (LIST "-f" (NAMESTRING *TMP1*) (FORMAT NIL "--pid=~D" (PROCESS-ID))) :OUTPUT :STREAM)) (SLEEP 1) (WITH-OPEN-FILE (NEW *TMP1* :DIRECTION :OUTPUT :IF-EXISTS :RENAME-AND-DELETE) (= INODE (SHOW (FILE-STAT-INO (FILE-STAT NEW))))))) > CORRECT: NIL > CLISP : T > OUT: > "5031013 > 5031013 > " arghm. aha! I know. this is not linux, so "tail --pid" does not work. right? does this help? --- test.tst.~1.82.~ 2008-09-17 22:43:36.000000000 -0400 +++ test.tst 2008-09-22 22:08:40.000000000 -0400 @@ -410,15 +410,18 @@ T (multiple-value-list (os:sync)) () (let ((inode (show (posix:file-stat-ino (posix:file-stat *tmp1*))))) - (with-open-stream (s (ext:run-program - "tail" :arguments (list "-f" (namestring *tmp1*) - (format nil "--pid=~D" - (os:process-id))) - :output :stream)) - (sleep 1) ; let tail open file + (multiple-value-bind (run args) (cmd-args) + (push "abort" args) (push "-on-error" args) + (show (cons run args) :pretty t) + (with-open-stream (s (ext:run-program run :arguments args + :input :stream :output :stream)) + (flush-clisp s) + (proc-send s (format nil "(setq s (open ~S))" (namestring *tmp1*))) + (unwind-protect (with-open-file (new *tmp1* :direction :output :if-exists :rename-and-delete) - (= inode (show (posix:file-stat-ino (posix:file-stat new))))))) + (= inode (show (posix:file-stat-ino (posix:file-stat new))))) + (proc-send s "(close s)(ext:quit)"))))) NIL (let ((file "foo.bar") (dates '(3141592653 3279321753))) > Form: (RE-TEST "[ -~]*" "abc") > CORRECT: ("abc") > CLISP : ("") > Differ at position 0: "abc" vs "" > CORRECT: ("abc") > CLISP : ("") > > > Form: (RE-TEST "[ -~ -~]*" "abc") > CORRECT: ("abc") > CLISP : ("") > Differ at position 0: "abc" vs "" > CORRECT: ("abc") > CLISP : ("") > > > Form: (RE-TEST "[ -~ -~ -~]*" "abc") > CORRECT: ("abc") > CLISP : ("") > Differ at position 0: "abc" vs "" > CORRECT: ("abc") > CLISP : ("") > > > Form: (RE-TEST "[ -~ -~ -~ -~]*" "abc") > CORRECT: ("abc") > CLISP : ("") > Differ at position 0: "abc" vs "" > CORRECT: ("abc") > CLISP : ("") > > > Form: (RE-TEST "[ -~ -~ -~ -~ -~]*" "abc") > CORRECT: ("abc") > CLISP : ("") > Differ at position 0: "abc" vs "" > CORRECT: ("abc") > CLISP : ("") > > > Form: (RE-TEST "[ -~ -~ -~ -~ -~ -~]*" "abc") > CORRECT: ("abc") > CLISP : ("") > Differ at position 0: "abc" vs "" > CORRECT: ("abc") > CLISP : ("") > > > Form: (RE-TEST "[ -~ -~ -~ -~ -~ -~ -~]*" "abc") > CORRECT: ("abc") > CLISP : ("") > Differ at position 0: "abc" vs "" > CORRECT: ("abc") > CLISP : ("") > > I don't know what these regexps mean, but I suspect that this is because the solaris regex implementation differs from the glibc one. I hope there is a regex compile flag which would make the tests pass - could you please investigate? alternatively, you can pass --with-included-regex to the top-level configure (or just edit Makefile and add it to MODULE_CONFIGURE_FLAGS and rm -rf regexp && make base base-mod-check) -- Sam Steingold (http://sds.podval.org/) on Fedora release 9 (Sulphur) http://dhimmi.com http://memri.org http://ffii.org http://jihadwatch.org http://iris.org.il http://pmw.org.il http://honestreporting.com I'm out of my mind, but feel free to leave a message... |
From: Raymond T. <ray...@er...> - 2008-09-23 13:24:09
|
Sam Steingold wrote: >> * Raymond Toy <enlzbaq.gbl@Revpffba.pbz> [2008-09-22 14:44:41 -0400]: >> >> >> >> Form: (LOOP :FOR N :UPFROM 3 :FOR LG = (HANDLER-CASE (LGAMMA N) (FLOATING-POINT-OVERFLOW NIL 'FLOATING-POINT-OVERFLOW)) :FOR L! = (HANDLER-CASE (LOG (FLOAT (! (1- N)) LG)) (FLOATING-POINT-OVERFLOW NIL 'FLOATING-POINT-OVERFLOW)) :UNLESS (AND (FLOATP LG) (FLOATP L!) (= 1 (FLOAT (/ L! LG) 0.0))) :RETURN (LIST N LG L!)) >> CORRECT: (172 711.71472580229d0 FLOATING-POINT-OVERFLOW) >> CLISP : (172 711.7147258022899d0 FLOATING-POINT-OVERFLOW) >> Differ at position 1: 711.71472580229d0 vs 711.7147258022899d0 >> CORRECT: (711.71472580229d0 FLOATING-POINT-OVERFLOW) >> CLISP : (711.7147258022899d0 FLOATING-POINT-OVERFLOW) > > so you libc's lgamma is more precise than that of glibc. > interesting. I wouldn't say it's more precise. It looks like it's only off by one bit. Maxima says the answer should be 711.714725802290006953521780627031219622767703 > >> Form: (LOOP :FOR N :UPFROM 3 :FOR TG = (TGAMMA N) :UNLESS (= 1 (/ (! (1- N)) TG)) :RETURN N) >> CORRECT: 5 >> CLISP : 4 > > oops. tgamma is less precise. > oh well, I guess I can tweak the tests to ignore the difference... > > or maybe you have a better idea? I think that getting these special functions down to the last bit is difficult. The tgamma test case has at least 3 rounding errors: One from lgamma itself, one from (exp lg), and one for (/ (! (1- N)) tg). > >> Form: (STRING= (SHOW (GETENV "USER")) (SHOW (FILE-OWNER *TMP1*))) >> CORRECT: T >> CLISP : NIL >> OUT: >> "NIL >> \"eusrtoy\" >> " > > please do: > $ set | grep eusrtoy What are you looking for? I have lots of envvars containing my uid. But USER=eusrtoy. > >> Form: (LET ((INODE (SHOW (FILE-STAT-INO (FILE-STAT *TMP1*))))) (WITH-OPEN-STREAM (S (RUN-PROGRAM "tail" :ARGUMENTS (LIST "-f" (NAMESTRING *TMP1*) (FORMAT NIL "--pid=~D" (PROCESS-ID))) :OUTPUT :STREAM)) (SLEEP 1) (WITH-OPEN-FILE (NEW *TMP1* :DIRECTION :OUTPUT :IF-EXISTS :RENAME-AND-DELETE) (= INODE (SHOW (FILE-STAT-INO (FILE-STAT NEW))))))) >> CORRECT: NIL >> CLISP : T >> OUT: >> "5031013 >> 5031013 >> " > > arghm. > aha! I know. > this is not linux, so "tail --pid" does not work. > right? > > does this help? [snip] Almost. Change the (setq s (open ~S)) to (defvar s (open ~S)). I get a note about an undefined variable, unless I defvar it. This test passes then. > >> Form: (RE-TEST "[ -~]*" "abc") >> CORRECT: ("abc") >> CLISP : ("") >> Differ at position 0: "abc" vs "" >> CORRECT: ("abc") >> CLISP : ("") > > I don't know what these regexps mean, but I suspect that this is because > the solaris regex implementation differs from the glibc one. I think the first is testing for a string containing characters between space and ~. > I hope there is a regex compile flag which would make the tests pass - > could you please investigate? > alternatively, you can pass --with-included-regex to the top-level Without --with-included-regex, does clisp use the system regex library? If so, there are no flags. regex only support ed-style regexes. > configure (or just edit Makefile and add it to MODULE_CONFIGURE_FLAGS > and rm -rf regexp && make base base-mod-check) > Maybe the default on solaris should be to use the included regex. But I didn't compile in the ffcall feature. Does that mean it won't work? Ray |
From: Sam S. <sd...@gn...> - 2008-09-23 14:02:33
|
Raymond Toy wrote: > Sam Steingold wrote: >>> * Raymond Toy <enlzbaq.gbl@Revpffba.pbz> [2008-09-22 14:44:41 -0400]: >>> Form: (STRING= (SHOW (GETENV "USER")) (SHOW (FILE-OWNER *TMP1*))) >>> CORRECT: T >>> CLISP : NIL >>> OUT: >>> "NIL >>> \"eusrtoy\" >>> " >> please do: >> $ set | grep eusrtoy > > What are you looking for? I have lots of envvars containing my uid. > But USER=eusrtoy. so why does (GETENV "USER") return NIL in the above test? >>> Form: (LET ((INODE (SHOW (FILE-STAT-INO (FILE-STAT *TMP1*))))) (WITH-OPEN-STREAM (S (RUN-PROGRAM "tail" :ARGUMENTS (LIST "-f" (NAMESTRING *TMP1*) (FORMAT NIL "--pid=~D" (PROCESS-ID))) :OUTPUT :STREAM)) (SLEEP 1) (WITH-OPEN-FILE (NEW *TMP1* :DIRECTION :OUTPUT :IF-EXISTS :RENAME-AND-DELETE) (= INODE (SHOW (FILE-STAT-INO (FILE-STAT NEW))))))) >>> CORRECT: NIL >>> CLISP : T >>> OUT: >>> "5031013 >>> 5031013 >>> " >> arghm. >> aha! I know. >> this is not linux, so "tail --pid" does not work. >> right? >> >> does this help? > > [snip] > > Almost. Change the (setq s (open ~S)) to (defvar s (open ~S)). I get a > note about an undefined variable, unless I defvar it. This test passes > then. are you saying that you get an error without defvar?! setq works fine for you in the stream lock test. >>> Form: (RE-TEST "[ -~]*" "abc") >>> CORRECT: ("abc") >>> CLISP : ("") >>> Differ at position 0: "abc" vs "" >>> CORRECT: ("abc") >>> CLISP : ("") >> I don't know what these regexps mean, but I suspect that this is because >> the solaris regex implementation differs from the glibc one. > > I think the first is testing for a string containing characters between > space and ~. how about the others?! >> I hope there is a regex compile flag which would make the tests pass - >> could you please investigate? >> alternatively, you can pass --with-included-regex to the top-level > > Without --with-included-regex, does clisp use the system regex library? yes, if the clisp/src/glm4/regex.m4 test passes. > If so, there are no flags. regex only support ed-style regexes. there is no re_set_syntax? >> configure (or just edit Makefile and add it to MODULE_CONFIGURE_FLAGS >> and rm -rf regexp && make base base-mod-check) > > Maybe the default on solaris should be to use the included regex. But I please submit a patch to glm4/regex.m4 to the gnulib mailing list. > didn't compile in the ffcall feature. Does that mean it won't work? regexp does not use ffi since 2003-08-07 |
From: Raymond T. <ray...@er...> - 2008-09-23 15:02:16
|
Sam Steingold wrote: > Raymond Toy wrote: >> Sam Steingold wrote: >>>> * Raymond Toy <enlzbaq.gbl@Revpffba.pbz> [2008-09-22 14:44:41 -0400]: >>>> Form: (STRING= (SHOW (GETENV "USER")) (SHOW (FILE-OWNER *TMP1*))) >>>> CORRECT: T >>>> CLISP : NIL >>>> OUT: >>>> "NIL >>>> \"eusrtoy\" >>>> " >>> please do: >>> $ set | grep eusrtoy >> >> What are you looking for? I have lots of envvars containing my uid. >> But USER=eusrtoy. > > so why does (GETENV "USER") return NIL in the above test? > >>>> Form: (LET ((INODE (SHOW (FILE-STAT-INO (FILE-STAT *TMP1*))))) >>>> (WITH-OPEN-STREAM (S (RUN-PROGRAM "tail" :ARGUMENTS (LIST "-f" >>>> (NAMESTRING *TMP1*) (FORMAT NIL "--pid=~D" (PROCESS-ID))) :OUTPUT >>>> :STREAM)) (SLEEP 1) (WITH-OPEN-FILE (NEW *TMP1* :DIRECTION :OUTPUT >>>> :IF-EXISTS :RENAME-AND-DELETE) (= INODE (SHOW (FILE-STAT-INO >>>> (FILE-STAT NEW))))))) >>>> CORRECT: NIL >>>> CLISP : T >>>> OUT: >>>> "5031013 >>>> 5031013 >>>> " >>> arghm. >>> aha! I know. >>> this is not linux, so "tail --pid" does not work. >>> right? >>> >>> does this help? >> >> [snip] >> >> Almost. Change the (setq s (open ~S)) to (defvar s (open ~S)). I get a >> note about an undefined variable, unless I defvar it. This test passes >> then. > > are you saying that you get an error without defvar?! > setq works fine for you in the stream lock test. > >>>> Form: (RE-TEST "[ -~]*" "abc") >>>> CORRECT: ("abc") >>>> CLISP : ("") >>>> Differ at position 0: "abc" vs "" >>>> CORRECT: ("abc") >>>> CLISP : ("") >>> I don't know what these regexps mean, but I suspect that this is because >>> the solaris regex implementation differs from the glibc one. >> >> I think the first is testing for a string containing characters between >> space and ~. > > how about the others?! More of the same, I think. Basically as if I said [a-za-za-z] which is probably the same as [a-z]. > >>> I hope there is a regex compile flag which would make the tests pass - >>> could you please investigate? >>> alternatively, you can pass --with-included-regex to the top-level >> >> Without --with-included-regex, does clisp use the system regex library? > > yes, if the clisp/src/glm4/regex.m4 test passes. > >> If so, there are no flags. regex only support ed-style regexes. > > there is no re_set_syntax? Nope. And I see the man page for regex(3) differs from what regex.h defines. regex.h defines regcomp which allows some flags to set the syntax. As best as I can tell, clisp is using regexec/regcomp. Some simple tests (in C) with regcomp/regexec shows that it works. Perhaps, clisp isn't calling regcomp/regexec quite right? Where is this defined? Ray |
From: Sam S. <sd...@gn...> - 2008-09-23 15:12:33
|
Raymond Toy wrote: > >>>> I hope there is a regex compile flag which would make the tests pass - >>>> could you please investigate? >>>> alternatively, you can pass --with-included-regex to the top-level >>> Without --with-included-regex, does clisp use the system regex library? >> yes, if the clisp/src/glm4/regex.m4 test passes. >> >>> If so, there are no flags. regex only support ed-style regexes. >> there is no re_set_syntax? > > Nope. And I see the man page for regex(3) differs from what regex.h > defines. regex.h defines regcomp which allows some flags to set the > syntax. As best as I can tell, clisp is using regexec/regcomp. > > Some simple tests (in C) with regcomp/regexec shows that it works. > Perhaps, clisp isn't calling regcomp/regexec quite right? Where is this > defined? clisp/modules/regexp/regexi.c REGEXP::REGEXP-COMPILE calls regcomp REGEXP::REGEXP-EXEC calls regexec you can debug them the usual way PS. please do "cvs up" and confirm that the syscalls tests pass |
From: Raymond T. <ray...@er...> - 2008-09-23 20:18:03
|
Sam Steingold wrote: > Raymond Toy wrote: >> >>>>> I hope there is a regex compile flag which would make the tests pass - >>>>> could you please investigate? >>>>> alternatively, you can pass --with-included-regex to the top-level >>>> Without --with-included-regex, does clisp use the system regex library? >>> yes, if the clisp/src/glm4/regex.m4 test passes. >>> >>>> If so, there are no flags. regex only support ed-style regexes. >>> there is no re_set_syntax? >> >> Nope. And I see the man page for regex(3) differs from what regex.h >> defines. regex.h defines regcomp which allows some flags to set the >> syntax. As best as I can tell, clisp is using regexec/regcomp. >> >> Some simple tests (in C) with regcomp/regexec shows that it works. >> Perhaps, clisp isn't calling regcomp/regexec quite right? Where is this >> defined? > > clisp/modules/regexp/regexi.c > > REGEXP::REGEXP-COMPILE calls regcomp > REGEXP::REGEXP-EXEC calls regexec > This behaves in a funny way. (regexp:regexp-compile "[a-{]*") produces an error: *** - REGEXP:REGEXP-COMPILE ("[a-{]*"): "Invalid range end" AFAICT, [a-{] should be a valid range, and a simple C program works. Same thing if the pattern is "[a-~]*". (clisp errors, C program ok.) Could this be related to the GL0(misc_encoding) used before the call to regexec and regcomp? Also, the implementation doesn't quite match the documentation. The impnotes says imply that there is a :boolean keyword for regexp-exec, but function signature doesn't mention it. Ray |
From: Sam S. <sd...@gn...> - 2008-09-23 20:48:06
|
Raymond Toy wrote: > Sam Steingold wrote: >> Raymond Toy wrote: >>>>>> I hope there is a regex compile flag which would make the tests pass - >>>>>> could you please investigate? >>>>>> alternatively, you can pass --with-included-regex to the top-level >>>>> Without --with-included-regex, does clisp use the system regex library? >>>> yes, if the clisp/src/glm4/regex.m4 test passes. >>>> >>>>> If so, there are no flags. regex only support ed-style regexes. >>>> there is no re_set_syntax? >>> Nope. And I see the man page for regex(3) differs from what regex.h >>> defines. regex.h defines regcomp which allows some flags to set the >>> syntax. As best as I can tell, clisp is using regexec/regcomp. >>> >>> Some simple tests (in C) with regcomp/regexec shows that it works. >>> Perhaps, clisp isn't calling regcomp/regexec quite right? Where is this >>> defined? >> clisp/modules/regexp/regexi.c >> >> REGEXP::REGEXP-COMPILE calls regcomp >> REGEXP::REGEXP-EXEC calls regexec >> > > This behaves in a funny way. > > (regexp:regexp-compile "[a-{]*") > > produces an error: > > *** - REGEXP:REGEXP-COMPILE ("[a-{]*"): "Invalid range end" > wfm: [9]> (regexp:regexp-exec p "}" ) #S(REGEXP:MATCH :START 0 :END 0) [10]> (regexp:regexp-compile "[a-{]") #<FOREIGN-POINTER #x000000001E210B90> [11]> (setq p *) #<FOREIGN-POINTER #x000000001E210B90> [12]> (regexp:regexp-exec p "z" :boolean t) T [13]> (regexp:regexp-exec p "}" :boolean t) [14]> > AFAICT, [a-{] should be a valid range, and a simple C program works. > Same thing if the pattern is "[a-~]*". (clisp errors, C program ok.) are you sure that regexec and regcompile receive the exact same arguments from the C program and from clisp? please try gdb. > Could this be related to the GL0(misc_encoding) used before the call to > regexec and regcomp? what is GL0(misc_encoding) for you? (this is the same as *misc-encoding* and should be 1:1) > Also, the implementation doesn't quite match the documentation. > > The impnotes says imply that there is a :boolean keyword for > regexp-exec, but function signature doesn't mention it. WFM: (describe #'regexp:regexp-exec) #<ADD-ON-SYSTEM-FUNCTION REGEXP:REGEXP-EXEC> is a built-in system function. Argument list: (#:ARG0 #:ARG1 &KEY :BOOLEAN :START :END :NOTBOL :NOTEOL) For more information, evaluate (DISASSEMBLE #'REGEXP:REGEXP-EXEC). |
From: Raymond T. <ray...@er...> - 2008-09-23 21:18:55
|
Sam Steingold wrote: > Raymond Toy wrote: > > wfm: > > [9]> (regexp:regexp-exec p "}" ) > #S(REGEXP:MATCH :START 0 :END 0) Because the pattern is [a-{]*, which means 0 or more matches, regexp-exec will always succeed. > [10]> (regexp:regexp-compile "[a-{]") > #<FOREIGN-POINTER #x000000001E210B90> Definitely fails for me. > are you sure that regexec and regcompile receive the exact same > arguments from the C program and from clisp? > please try gdb. I don't exactly know how to do that. lisp.run -M lispinit.mem doesn't have the regexp package. How do I get that? > >> Could this be related to the GL0(misc_encoding) used before the call to >> regexec and regcomp? > > what is GL0(misc_encoding) for you? > (this is the same as *misc-encoding* and should be 1:1) *misc-encoding* is #<ENCODING CHARSET:ISO-8859-1 :UNIX> > >> Also, the implementation doesn't quite match the documentation. >> >> The impnotes says imply that there is a :boolean keyword for >> regexp-exec, but function signature doesn't mention it. > > WFM: > > (describe #'regexp:regexp-exec) I said the impnotes don't match. Ray |
From: Sam S. <sd...@gn...> - 2008-09-23 22:35:04
|
Raymond Toy wrote: > Sam Steingold wrote: >> [10]> (regexp:regexp-compile "[a-{]") >> #<FOREIGN-POINTER #x000000001E210B90> > > Definitely fails for me. :-( >> are you sure that regexec and regcompile receive the exact same >> arguments from the C program and from clisp? >> please try gdb. > > I don't exactly know how to do that. lisp.run -M lispinit.mem doesn't > have the regexp package. How do I get that? $ gdb lisp.run (gdb) base (gdb) br C_subr_regexp_regexp_compile (gdb) br C_subr_regexp_regexp_exec (gdb) run http://clisp.cons.org/impnotes/faq.html#faq-debug http://clisp.cons.org/impnotes/faq.html#faq-fine >>> Could this be related to the GL0(misc_encoding) used before the call to >>> regexec and regcomp? >> what is GL0(misc_encoding) for you? >> (this is the same as *misc-encoding* and should be 1:1) > > *misc-encoding* is > > #<ENCODING CHARSET:ISO-8859-1 :UNIX> good - this is 1:1 byte for char. > I said the impnotes don't match. ah - thanks. fixed. |
From: Raymond T. <ray...@er...> - 2008-09-23 22:05:30
|
Sam Steingold wrote: > Raymond Toy wrote: >> Sam Steingold wrote: >>> [10]> (regexp:regexp-compile "[a-{]") >>> #<FOREIGN-POINTER #x000000001E210B90> >> >> Definitely fails for me. > > :-( > >>> are you sure that regexec and regcompile receive the exact same >>> arguments from the C program and from clisp? >>> please try gdb. >> >> I don't exactly know how to do that. lisp.run -M lispinit.mem doesn't >> have the regexp package. How do I get that? > > $ gdb lisp.run > (gdb) base > (gdb) br C_subr_regexp_regexp_compile > (gdb) br C_subr_regexp_regexp_exec > (gdb) run > > http://clisp.cons.org/impnotes/faq.html#faq-debug > http://clisp.cons.org/impnotes/faq.html#faq-fine > Thanks for the hints. I do get a few errors from gdb on startup related to the gdbinit. But I can continue and do something useful. So, I see that clisp is actually using GNU regex to emulate regcomp and friends for regexi.c. Ok. And I see that at line 2634 of regcomp.c, the test for wcscoll > 0 must be true so REG_ERANGE is returned. But gdb says cmp_buf is: $23 = {97, 0, 0, 0, 123, 0} so I don't see how cmp_buf is greater than cmp_buf+4. Maybe wcscoll is broken on Solaris? Ray |
From: Sam S. <sd...@gn...> - 2008-09-24 00:39:35
|
> * Raymond Toy <enlzbaq.gbl@revpffba.pbz> [2008-09-23 18:05:22 -0400]: > > > So, I see that clisp is actually using GNU regex to emulate regcomp and > friends for regexi.c. Ok. oh - in that case you gotta talk to the gnulib people. I know nothing about gnu regex. Ubi nil vales, ibi nil veles. > Maybe wcscoll is broken on Solaris? could be... -- Sam Steingold (http://sds.podval.org/) on Fedora release 9 (Sulphur) http://iris.org.il http://pmw.org.il http://memri.org http://truepeace.org http://mideasttruth.com http://honestreporting.com I'm out of my mind, but feel free to leave a message... |
From: Raymond T. <ray...@er...> - 2008-09-24 13:11:15
|
Sam Steingold wrote: >> * Raymond Toy <enlzbaq.gbl@revpffba.pbz> [2008-09-23 18:05:22 -0400]: >> >> >> So, I see that clisp is actually using GNU regex to emulate regcomp and >> friends for regexi.c. Ok. > > oh - in that case you gotta talk to the gnulib people. > I know nothing about gnu regex. Oh, one other thing. I get the following warnings when compiling gnu regex. Perhaps a new version of gnu regex is needed? Ray In file included from ../../src/gllib/regex.c:60: ../../src/gllib/regex_internal.c: In function 're_node_set_remove_at': ../../src/gllib/regex_internal.c:1393: warning: comparison of unsigned expression < 0 is always false In file included from ../../src/gllib/regex.c:61: ../../src/gllib/regcomp.c: In function 'parse_dup_op': ../../src/gllib/regcomp.c:2553: warning: comparison of unsigned expression < 0 is always false In file included from ../../src/gllib/regex.c:62: ../../src/gllib/regexec.c: In function 're_search_2_stub': ../../src/gllib/regexec.c:381: warning: comparison of unsigned expression < 0 is always false ../../src/gllib/regexec.c:381: warning: comparison of unsigned expression < 0 is always false ../../src/gllib/regexec.c:381: warning: comparison of unsigned expression < 0 is always false ../../src/gllib/regexec.c: In function 're_search_stub': ../../src/gllib/regexec.c:434: warning: comparison of unsigned expression < 0 is always false ../../src/gllib/regexec.c:438: warning: comparison of unsigned expression < 0 is always false |
From: Raymond T. <ray...@er...> - 2008-09-24 14:46:47
|
Sam Steingold wrote: > please report this as well as your finding (the discrepancy between > gnulib and solaris regexp) to the gnulib list. > As I said, I'm going to blame gcc 3.3.3 for the regexp bug. gcc 3.3 on a different system works fine. I just don't have gcc 3.3 here and I'm too lazy to build it. But I did test 4.3.2, which causes clisp to segfault when building. 3.2.2 can't compile error.d. But 3.3.2 appears to work. I'm happy to just stick with 3.3.2. Just need to compile up the CVS sources with 3.3.2 to make sure everything else works.... Ray |
From: Sam S. <sd...@gn...> - 2008-09-24 15:13:10
|
Raymond Toy wrote: > But I did test 4.3.2, which causes clisp to segfault when building. I thought that 4.3.2 was the latest version and that it supported clisp. If this is not the case, it should be investigated and reported to the gcc maintainers. |
From: Raymond T. <ray...@er...> - 2008-09-24 18:40:58
|
Sam Steingold wrote: > Raymond Toy wrote: >> But I did test 4.3.2, which causes clisp to segfault when building. > > I thought that 4.3.2 was the latest version and that it supported clisp. > If this is not the case, it should be investigated and reported to the > gcc maintainers. > I think 4.3.2 is the latest. It probably supports clisp. But maybe not on Solaris. :-( Ray |
From: Raymond T. <ray...@er...> - 2008-09-23 14:07:07
|
Sam Steingold wrote: >> Form: (STRING= (SHOW (GETENV "USER")) (SHOW (FILE-OWNER *TMP1*))) >> CORRECT: T >> CLISP : NIL >> OUT: >> "NIL >> \"eusrtoy\" >> " > > please do: > $ set | grep eusrtoy Oh, I know what the problem is. I have USER, but it's not exported so getenv returns NIL. Don't know why it's not exported, but it's not on the Solaris 8 box that I'm using. (It is exported on a Solaris 10 box.) I think I'll just go export it in my .bash_profile.... Ray |
From: Raymond T. <ray...@er...> - 2008-09-24 13:03:03
|
Sam Steingold wrote: >> * Raymond Toy <enlzbaq.gbl@revpffba.pbz> [2008-09-23 18:05:22 -0400]: >> >> >> So, I see that clisp is actually using GNU regex to emulate regcomp and >> friends for regexi.c. Ok. > > oh - in that case you gotta talk to the gnulib people. > I know nothing about gnu regex. I'm going to blame this on gcc 3.3.3. I built CVS clisp on a different Solaris 8 box that has gcc 3.3. All tests pass, including the regexp tests. The only failure is the known socket issue. I might try again with a different version of gcc or even Sun C on this box. Oh, still need to test the clhs http proxy Host issue still.... Ray |
From: Sam S. <sd...@gn...> - 2008-09-24 14:21:20
|
Raymond Toy wrote: > Sam Steingold wrote: >>> * Raymond Toy <enlzbaq.gbl@revpffba.pbz> [2008-09-23 18:05:22 -0400]: >>> >>> >>> So, I see that clisp is actually using GNU regex to emulate regcomp and >>> friends for regexi.c. Ok. >> oh - in that case you gotta talk to the gnulib people. >> I know nothing about gnu regex. > > Oh, one other thing. I get the following warnings when compiling gnu > regex. Perhaps a new version of gnu regex is needed? clisp is fully in sync with gnulib. > In file included from ../../src/gllib/regex.c:60: > ../../src/gllib/regex_internal.c: In function 're_node_set_remove_at': > ../../src/gllib/regex_internal.c:1393: warning: comparison of unsigned > expression < 0 is always false > In file included from ../../src/gllib/regex.c:61: > ../../src/gllib/regcomp.c: In function 'parse_dup_op': > ../../src/gllib/regcomp.c:2553: warning: comparison of unsigned > expression < 0 is always false > In file included from ../../src/gllib/regex.c:62: > ../../src/gllib/regexec.c: In function 're_search_2_stub': > ../../src/gllib/regexec.c:381: warning: comparison of unsigned > expression < 0 is always false > ../../src/gllib/regexec.c:381: warning: comparison of unsigned > expression < 0 is always false > ../../src/gllib/regexec.c:381: warning: comparison of unsigned > expression < 0 is always false > ../../src/gllib/regexec.c: In function 're_search_stub': > ../../src/gllib/regexec.c:434: warning: comparison of unsigned > expression < 0 is always false > ../../src/gllib/regexec.c:438: warning: comparison of unsigned > expression < 0 is always false please report this as well as your finding (the discrepancy between gnulib and solaris regexp) to the gnulib list. |
From: Raymond T. <raymond.toy@Ericsson.com> - 2008-09-24 16:19:22
|
Raymond Toy wrote: > Oh, still need to test the clhs http proxy Host issue still.... That works fine. Yay! Don't know if this matters, but rfc2616 sec 14.23 says the Host should contain the port number, if it's not the default 80 for http. Maybe you should add that too? I assume it's the port number of the original URL. Ray |
From: Sam S. <sd...@gn...> - 2008-09-24 16:29:58
|
Raymond Toy wrote: > Raymond Toy wrote: >> Oh, still need to test the clhs http proxy Host issue still.... > > That works fine. Yay! > > Don't know if this matters, but rfc2616 sec 14.23 says the Host should > contain the port number, if it's not the default 80 for http. Maybe you > should add that too? I assume it's the port number of the original URL. > > Ray > --- clhs.lisp.~1.55.~ 2008-09-23 15:17:07.000000000 -0400 +++ clhs.lisp 2008-09-24 12:28:30.000831000 -0400 @@ -160,8 +160,9 @@ set *HTTP-PROXY*, and return it; otherwi (format *http-log-stream* "connected...") (force-output *http-log-stream*) ;; http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23 ;; http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 - (format sock "GET ~A HTTP/1.0~%User-agent: ~A ~A~%Host: ~A~%" path - (lisp-implementation-type) (lisp-implementation-version) url-host) + (format sock "GET ~A HTTP/1.0~%User-agent: ~A ~A~%Host: ~A:~D~%" path + (lisp-implementation-type) (lisp-implementation-version) + url-host url-port) #+unicode ; base64 requires unicode for some weird infrastructure reasons (when (first *http-proxy*) ; auth: http://www.ietf.org/rfc/rfc1945.txt ;; http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.34 |
From: Raymond T. <ray...@er...> - 2008-09-24 16:43:51
|
Sam Steingold wrote: > Raymond Toy wrote: >> Raymond Toy wrote: >>> Oh, still need to test the clhs http proxy Host issue still.... >> >> That works fine. Yay! >> >> Don't know if this matters, but rfc2616 sec 14.23 says the Host should >> contain the port number, if it's not the default 80 for http. Maybe you >> should add that too? I assume it's the port number of the original URL. >> >> Ray >> > > --- clhs.lisp.~1.55.~ 2008-09-23 15:17:07.000000000 -0400 > +++ clhs.lisp 2008-09-24 12:28:30.000831000 -0400 Works fine for me. Ray |
From: Aleksej S. <as...@in...> - 2008-09-29 20:19:09
|
Hello! Sam Steingold <sd...@gn...> writes: > Sorry about such a long pretest process. > Let us hope that it bodes well for the quality of the release. > Please stress-test clisp cvs head on your favorite platform. > Specifically, build clisp in a fresh check out and do "make all check mod-check". > Thanks. I was asked to support DragonflyBSD, and immediatly ran into this: ln -s gllib/localcharset.h localcharset.h cc -I/home/asau/build/pkg/include -I/usr/include -Igllib -O2 -I/home/asau/build/pkg/include -I/usr/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -fexpensive-optimizations -falign-functions=4 -DNO_SINGLEMAP -DNO_TRIVIALMAP -DUNICODE -DDYNAMIC_FFI -I. -c spvw.c In file included from spvw.d:23: lispbibl.d:9143: warning: register used for two global register variables In file included from spvw.d:520: spvw_sigsegv.d: In function 'stackoverflow_handler_continuation': spvw_sigsegv.d:157: warning: dereferencing 'void *' pointer spvw_sigsegv.d:157: error: request for member 'sc_ebx' in something not a structure or union *** Error code 1 CVS checkout as of today ("-Dtoday"). -- HE CE3OH... |