From juanjose.garciaripoll at googlemail.com Tue Aug 2 20:41:50 2011 From: juanjose.garciaripoll at googlemail.com (Juan Jose Garcia-Ripoll) Date: Tue, 2 Aug 2011 22:41:50 +0200 Subject: [cl-ppcre-devel] Problem with pathnames Message-ID: I reported a related problem some time ago http://lists.common-lisp.net/pipermail/cl-ppcre-devel/2011-January/000706.html However, instead of the values I supplied now cl-unicode is using :unspecific for the :type of a pathname. (defun dump-derived-tests () "Parses the Unicode data file \"DerivedCoreProperties.txt\" \(which is not used in read.lisp) and uses it to create a file \"derived-properties\" which will be used by CL-UNICODE-TEST." (with-output-to-source-file (out (make-pathname :name "derived-properties" :type :unspecific :directory '(:relative :up "test")) :no-header-p t) This is not supported by ECL, which uses NIL to represent an unfilled value (absent therefore). From the Hyperspec http://www.lispworks.com/documentation/HyperSpec/Body/19_bbbc.htm A conforming program must never unconditionally use a :unspecific as the value of a pathname component because such a value is not guaranteed to be permissible in all implementations. Probably what you want to solve is the merge-pathnames above the code (in the macro), which might instead read `(let* ((directory (make-pathname :name nil :type nil :version nil :defaults *this-file*)) (pathname (merge-pathnames ,relative-path directory)) Cheers, Juanjo -- Instituto de F?sica Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Sun Aug 7 11:44:38 2011 From: edi at agharta.de (Edi Weitz) Date: Sun, 7 Aug 2011 13:44:38 +0200 Subject: [cl-ppcre-devel] Problem with pathnames In-Reply-To: References: Message-ID: Hi Juanjo, Thanks for the heads-up. Can you send a diff against the BKNR repository? I'll review and apply it. Thanks, Edi. On Tue, Aug 2, 2011 at 10:41 PM, Juan Jose Garcia-Ripoll wrote: > I reported a related problem some time ago > > ?http://lists.common-lisp.net/pipermail/cl-ppcre-devel/2011-January/000706.html > However, instead of the values I supplied now cl-unicode is using > :unspecific for the :type of a pathname. > (defun dump-derived-tests () > ? "Parses the Unicode data file \"DerivedCoreProperties.txt\" \(which > is not used in read.lisp) and uses it to create a file > \"derived-properties\" which will be used by CL-UNICODE-TEST." > ? (with-output-to-source-file (out (make-pathname :name "derived-properties" > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? :type :unspecific > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? :directory '(:relative :up > "test")) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?:no-header-p t) > This is not supported by ECL, which uses NIL to represent an unfilled value > (absent therefore). From the Hyperspec > http://www.lispworks.com/documentation/HyperSpec/Body/19_bbbc.htm > > A?conforming program?must never unconditionally use a?:unspecific?as the > value of a?pathname?component because such a value is not guaranteed to be > permissible in all implementations. > > Probably what you want to solve is the merge-pathnames above the code (in > the macro), which might instead read > ? `(let* ((directory?(make-pathname :name nil :type nil :version nil > :defaults *this-file*)) > ? ? ? ? ? (pathname (merge-pathnames ,relative-path directory)) > Cheers, > Juanjo > -- > Instituto de F?sica Fundamental, CSIC > c/ Serrano, 113b, Madrid 28006 (Spain) > http://juanjose.garciaripoll.googlepages.com > > _______________________________________________ > cl-ppcre-devel site list > cl-ppcre-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cl-ppcre-devel > From juanjose.garciaripoll at googlemail.com Tue Aug 9 09:12:45 2011 From: juanjose.garciaripoll at googlemail.com (Juan Jose Garcia-Ripoll) Date: Tue, 9 Aug 2011 11:12:45 +0200 Subject: [cl-ppcre-devel] Problem with pathnames In-Reply-To: References: Message-ID: I am sorry, I live behind a firewall and unblocking SVN is quite a hassle. Is it ok with the patch attached? It is against cl-unicode-0.1.1 juanjo On Sun, Aug 7, 2011 at 1:44 PM, Edi Weitz wrote: > Hi Juanjo, > > Thanks for the heads-up. Can you send a diff against the BKNR > repository? I'll review and apply it. > > Thanks, > Edi. > > > > On Tue, Aug 2, 2011 at 10:41 PM, Juan Jose Garcia-Ripoll > wrote: > > I reported a related problem some time ago > > > > > http://lists.common-lisp.net/pipermail/cl-ppcre-devel/2011-January/000706.html > > However, instead of the values I supplied now cl-unicode is using > > :unspecific for the :type of a pathname. > > (defun dump-derived-tests () > > "Parses the Unicode data file \"DerivedCoreProperties.txt\" \(which > > is not used in read.lisp) and uses it to create a file > > \"derived-properties\" which will be used by CL-UNICODE-TEST." > > (with-output-to-source-file (out (make-pathname :name > "derived-properties" > > :type :unspecific > > :directory '(:relative > :up > > "test")) > > :no-header-p t) > > This is not supported by ECL, which uses NIL to represent an unfilled > value > > (absent therefore). From the Hyperspec > > http://www.lispworks.com/documentation/HyperSpec/Body/19_bbbc.htm > > > > A conforming program must never unconditionally use a :unspecific as the > > value of a pathname component because such a value is not guaranteed to > be > > permissible in all implementations. > > > > Probably what you want to solve is the merge-pathnames above the code (in > > the macro), which might instead read > > `(let* ((directory (make-pathname :name nil :type nil :version nil > > :defaults *this-file*)) > > (pathname (merge-pathnames ,relative-path directory)) > > Cheers, > > Juanjo > > -- > > Instituto de F?sica Fundamental, CSIC > > c/ Serrano, 113b, Madrid 28006 (Spain) > > http://juanjose.garciaripoll.googlepages.com > > > > _______________________________________________ > > cl-ppcre-devel site list > > cl-ppcre-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/cl-ppcre-devel > > > > _______________________________________________ > cl-ppcre-devel site list > cl-ppcre-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cl-ppcre-devel > -- Instituto de F?sica Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cl-unicode.patch Type: application/octet-stream Size: 1329 bytes Desc: not available URL: From juanjose.garciaripoll at googlemail.com Tue Aug 9 09:13:42 2011 From: juanjose.garciaripoll at googlemail.com (Juan Jose Garcia-Ripoll) Date: Tue, 9 Aug 2011 11:13:42 +0200 Subject: [cl-ppcre-devel] Problem with pathnames In-Reply-To: References: Message-ID: Sorry, wrong order of arguments to diff. Here goes the right one On Tue, Aug 9, 2011 at 11:12 AM, Juan Jose Garcia-Ripoll < juanjose.garciaripoll at googlemail.com> wrote: > I am sorry, I live behind a firewall and unblocking SVN is quite a hassle. > Is it ok with the patch attached? It is against cl-unicode-0.1.1 > > juanjo > > > On Sun, Aug 7, 2011 at 1:44 PM, Edi Weitz wrote: > >> Hi Juanjo, >> >> Thanks for the heads-up. Can you send a diff against the BKNR >> repository? I'll review and apply it. >> >> Thanks, >> Edi. >> >> >> >> On Tue, Aug 2, 2011 at 10:41 PM, Juan Jose Garcia-Ripoll >> wrote: >> > I reported a related problem some time ago >> > >> > >> http://lists.common-lisp.net/pipermail/cl-ppcre-devel/2011-January/000706.html >> > However, instead of the values I supplied now cl-unicode is using >> > :unspecific for the :type of a pathname. >> > (defun dump-derived-tests () >> > "Parses the Unicode data file \"DerivedCoreProperties.txt\" \(which >> > is not used in read.lisp) and uses it to create a file >> > \"derived-properties\" which will be used by CL-UNICODE-TEST." >> > (with-output-to-source-file (out (make-pathname :name >> "derived-properties" >> > :type :unspecific >> > :directory '(:relative >> :up >> > "test")) >> > :no-header-p t) >> > This is not supported by ECL, which uses NIL to represent an unfilled >> value >> > (absent therefore). From the Hyperspec >> > http://www.lispworks.com/documentation/HyperSpec/Body/19_bbbc.htm >> > >> > A conforming program must never unconditionally use a :unspecific as the >> > value of a pathname component because such a value is not guaranteed to >> be >> > permissible in all implementations. >> > >> > Probably what you want to solve is the merge-pathnames above the code >> (in >> > the macro), which might instead read >> > `(let* ((directory (make-pathname :name nil :type nil :version nil >> > :defaults *this-file*)) >> > (pathname (merge-pathnames ,relative-path directory)) >> > Cheers, >> > Juanjo >> > -- >> > Instituto de F?sica Fundamental, CSIC >> > c/ Serrano, 113b, Madrid 28006 (Spain) >> > http://juanjose.garciaripoll.googlepages.com >> > >> > _______________________________________________ >> > cl-ppcre-devel site list >> > cl-ppcre-devel at common-lisp.net >> > http://common-lisp.net/mailman/listinfo/cl-ppcre-devel >> > >> >> _______________________________________________ >> cl-ppcre-devel site list >> cl-ppcre-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/cl-ppcre-devel >> > > > > -- > Instituto de F?sica Fundamental, CSIC > c/ Serrano, 113b, Madrid 28006 (Spain) > http://juanjose.garciaripoll.googlepages.com > -- Instituto de F?sica Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cl-unicode.patch Type: application/octet-stream Size: 1329 bytes Desc: not available URL: From hans.huebner at gmail.com Tue Aug 9 09:38:22 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 9 Aug 2011 11:38:22 +0200 Subject: [cl-ppcre-devel] Problem with pathnames In-Reply-To: References: Message-ID: You can access the SVN repository through http: http://bknr.net/svn/trunk/thirdparty/cl-unicode/ -Hans On Tue, Aug 9, 2011 at 11:13 AM, Juan Jose Garcia-Ripoll wrote: > Sorry, wrong order of arguments to diff. Here goes the right one > > On Tue, Aug 9, 2011 at 11:12 AM, Juan Jose Garcia-Ripoll > wrote: >> >> I am sorry, I live behind a firewall and unblocking SVN is quite a hassle. >> Is it ok with the patch attached? It is against cl-unicode-0.1.1 >> >> juanjo >> >> On Sun, Aug 7, 2011 at 1:44 PM, Edi Weitz wrote: >>> >>> Hi Juanjo, >>> >>> Thanks for the heads-up. ?Can you send a diff against the BKNR >>> repository? ?I'll review and apply it. >>> >>> Thanks, >>> Edi. >>> >>> >>> >>> On Tue, Aug 2, 2011 at 10:41 PM, Juan Jose Garcia-Ripoll >>> wrote: >>> > I reported a related problem some time ago >>> > >>> > >>> > ?http://lists.common-lisp.net/pipermail/cl-ppcre-devel/2011-January/000706.html >>> > However, instead of the values I supplied now cl-unicode is using >>> > :unspecific for the :type of a pathname. >>> > (defun dump-derived-tests () >>> > ? "Parses the Unicode data file \"DerivedCoreProperties.txt\" \(which >>> > is not used in read.lisp) and uses it to create a file >>> > \"derived-properties\" which will be used by CL-UNICODE-TEST." >>> > ? (with-output-to-source-file (out (make-pathname :name >>> > "derived-properties" >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? :type :unspecific >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? :directory >>> > '(:relative :up >>> > "test")) >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?:no-header-p t) >>> > This is not supported by ECL, which uses NIL to represent an unfilled >>> > value >>> > (absent therefore). From the Hyperspec >>> > http://www.lispworks.com/documentation/HyperSpec/Body/19_bbbc.htm >>> > >>> > A?conforming program?must never unconditionally use a?:unspecific?as >>> > the >>> > value of a?pathname?component because such a value is not guaranteed to >>> > be >>> > permissible in all implementations. >>> > >>> > Probably what you want to solve is the merge-pathnames above the code >>> > (in >>> > the macro), which might instead read >>> > ? `(let* ((directory?(make-pathname :name nil :type nil :version nil >>> > :defaults *this-file*)) >>> > ? ? ? ? ? (pathname (merge-pathnames ,relative-path directory)) >>> > Cheers, >>> > Juanjo >>> > -- >>> > Instituto de F?sica Fundamental, CSIC >>> > c/ Serrano, 113b, Madrid 28006 (Spain) >>> > http://juanjose.garciaripoll.googlepages.com >>> > >>> > _______________________________________________ >>> > cl-ppcre-devel site list >>> > cl-ppcre-devel at common-lisp.net >>> > http://common-lisp.net/mailman/listinfo/cl-ppcre-devel >>> > >>> >>> _______________________________________________ >>> cl-ppcre-devel site list >>> cl-ppcre-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/cl-ppcre-devel >> >> >> >> -- >> Instituto de F?sica Fundamental, CSIC >> c/ Serrano, 113b, Madrid 28006 (Spain) >> http://juanjose.garciaripoll.googlepages.com > > > > -- > Instituto de F?sica Fundamental, CSIC > c/ Serrano, 113b, Madrid 28006 (Spain) > http://juanjose.garciaripoll.googlepages.com > > _______________________________________________ > cl-ppcre-devel site list > cl-ppcre-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cl-ppcre-devel > From hans.huebner at gmail.com Tue Aug 9 09:40:22 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 9 Aug 2011 11:40:22 +0200 Subject: [cl-ppcre-devel] Problem with pathnames In-Reply-To: References: Message-ID: You can access the SVN repository through http: http://bknr.net/svn/trunk/thirdparty/cl-unicode/ -Hans On Tue, Aug 9, 2011 at 11:13 AM, Juan Jose Garcia-Ripoll wrote: > Sorry, wrong order of arguments to diff. Here goes the right one > > On Tue, Aug 9, 2011 at 11:12 AM, Juan Jose Garcia-Ripoll > wrote: >> >> I am sorry, I live behind a firewall and unblocking SVN is quite a hassle. >> Is it ok with the patch attached? It is against cl-unicode-0.1.1 >> >> juanjo >> >> On Sun, Aug 7, 2011 at 1:44 PM, Edi Weitz wrote: >>> >>> Hi Juanjo, >>> >>> Thanks for the heads-up. ?Can you send a diff against the BKNR >>> repository? ?I'll review and apply it. >>> >>> Thanks, >>> Edi. >>> >>> >>> >>> On Tue, Aug 2, 2011 at 10:41 PM, Juan Jose Garcia-Ripoll >>> wrote: >>> > I reported a related problem some time ago >>> > >>> > >>> > ?http://lists.common-lisp.net/pipermail/cl-ppcre-devel/2011-January/000706.html >>> > However, instead of the values I supplied now cl-unicode is using >>> > :unspecific for the :type of a pathname. >>> > (defun dump-derived-tests () >>> > ? "Parses the Unicode data file \"DerivedCoreProperties.txt\" \(which >>> > is not used in read.lisp) and uses it to create a file >>> > \"derived-properties\" which will be used by CL-UNICODE-TEST." >>> > ? (with-output-to-source-file (out (make-pathname :name >>> > "derived-properties" >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? :type :unspecific >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? :directory >>> > '(:relative :up >>> > "test")) >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?:no-header-p t) >>> > This is not supported by ECL, which uses NIL to represent an unfilled >>> > value >>> > (absent therefore). From the Hyperspec >>> > http://www.lispworks.com/documentation/HyperSpec/Body/19_bbbc.htm >>> > >>> > A?conforming program?must never unconditionally use a?:unspecific?as >>> > the >>> > value of a?pathname?component because such a value is not guaranteed to >>> > be >>> > permissible in all implementations. >>> > >>> > Probably what you want to solve is the merge-pathnames above the code >>> > (in >>> > the macro), which might instead read >>> > ? `(let* ((directory?(make-pathname :name nil :type nil :version nil >>> > :defaults *this-file*)) >>> > ? ? ? ? ? (pathname (merge-pathnames ,relative-path directory)) >>> > Cheers, >>> > Juanjo >>> > -- >>> > Instituto de F?sica Fundamental, CSIC >>> > c/ Serrano, 113b, Madrid 28006 (Spain) >>> > http://juanjose.garciaripoll.googlepages.com >>> > >>> > _______________________________________________ >>> > cl-ppcre-devel site list >>> > cl-ppcre-devel at common-lisp.net >>> > http://common-lisp.net/mailman/listinfo/cl-ppcre-devel >>> > >>> >>> _______________________________________________ >>> cl-ppcre-devel site list >>> cl-ppcre-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/cl-ppcre-devel >> >> >> >> -- >> Instituto de F?sica Fundamental, CSIC >> c/ Serrano, 113b, Madrid 28006 (Spain) >> http://juanjose.garciaripoll.googlepages.com > > > > -- > Instituto de F?sica Fundamental, CSIC > c/ Serrano, 113b, Madrid 28006 (Spain) > http://juanjose.garciaripoll.googlepages.com > > _______________________________________________ > cl-ppcre-devel site list > cl-ppcre-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cl-ppcre-devel > From edi at weitz.de Tue Aug 9 13:31:28 2011 From: edi at weitz.de (Edi Weitz) Date: Tue, 9 Aug 2011 15:31:28 +0200 Subject: [cl-ppcre-devel] Problem with pathnames In-Reply-To: References: Message-ID: That should do, thanks. I'll take care of it in the next days. Edi. On Tue, Aug 9, 2011 at 11:12 AM, Juan Jose Garcia-Ripoll wrote: > I am sorry, I live behind a firewall and unblocking SVN is quite a hassle. > Is it ok with the patch attached? It is against cl-unicode-0.1.1 > > juanjo > > On Sun, Aug 7, 2011 at 1:44 PM, Edi Weitz wrote: >> >> Hi Juanjo, >> >> Thanks for the heads-up. ?Can you send a diff against the BKNR >> repository? ?I'll review and apply it. >> >> Thanks, >> Edi. >> >> >> >> On Tue, Aug 2, 2011 at 10:41 PM, Juan Jose Garcia-Ripoll >> wrote: >> > I reported a related problem some time ago >> > >> > >> > ?http://lists.common-lisp.net/pipermail/cl-ppcre-devel/2011-January/000706.html >> > However, instead of the values I supplied now cl-unicode is using >> > :unspecific for the :type of a pathname. >> > (defun dump-derived-tests () >> > ? "Parses the Unicode data file \"DerivedCoreProperties.txt\" \(which >> > is not used in read.lisp) and uses it to create a file >> > \"derived-properties\" which will be used by CL-UNICODE-TEST." >> > ? (with-output-to-source-file (out (make-pathname :name >> > "derived-properties" >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? :type :unspecific >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? :directory '(:relative >> > :up >> > "test")) >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?:no-header-p t) >> > This is not supported by ECL, which uses NIL to represent an unfilled >> > value >> > (absent therefore). From the Hyperspec >> > http://www.lispworks.com/documentation/HyperSpec/Body/19_bbbc.htm >> > >> > A?conforming program?must never unconditionally use a?:unspecific?as the >> > value of a?pathname?component because such a value is not guaranteed to >> > be >> > permissible in all implementations. >> > >> > Probably what you want to solve is the merge-pathnames above the code >> > (in >> > the macro), which might instead read >> > ? `(let* ((directory?(make-pathname :name nil :type nil :version nil >> > :defaults *this-file*)) >> > ? ? ? ? ? (pathname (merge-pathnames ,relative-path directory)) >> > Cheers, >> > Juanjo >> > -- >> > Instituto de F?sica Fundamental, CSIC >> > c/ Serrano, 113b, Madrid 28006 (Spain) >> > http://juanjose.garciaripoll.googlepages.com >> > >> > _______________________________________________ >> > cl-ppcre-devel site list >> > cl-ppcre-devel at common-lisp.net >> > http://common-lisp.net/mailman/listinfo/cl-ppcre-devel >> > >> >> _______________________________________________ >> cl-ppcre-devel site list >> cl-ppcre-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/cl-ppcre-devel > > > > -- > Instituto de F?sica Fundamental, CSIC > c/ Serrano, 113b, Madrid 28006 (Spain) > http://juanjose.garciaripoll.googlepages.com > From edi at weitz.de Wed Aug 31 12:08:36 2011 From: edi at weitz.de (Edi Weitz) Date: Wed, 31 Aug 2011 14:08:36 +0200 Subject: [cl-ppcre-devel] Problem with pathnames In-Reply-To: References: Message-ID: I was going to apply your patch this morning, but I just realized this had already been done eight months ago... :) http://bknr.net/trac/changeset/4626/trunk/thirdparty/cl-unicode Cheers, Edi. On Tue, Aug 9, 2011 at 11:13 AM, Juan Jose Garcia-Ripoll wrote: > Sorry, wrong order of arguments to diff. Here goes the right one > > On Tue, Aug 9, 2011 at 11:12 AM, Juan Jose Garcia-Ripoll > wrote: >> >> I am sorry, I live behind a firewall and unblocking SVN is quite a hassle. >> Is it ok with the patch attached? It is against cl-unicode-0.1.1 >> >> juanjo >> >> On Sun, Aug 7, 2011 at 1:44 PM, Edi Weitz wrote: >>> >>> Hi Juanjo, >>> >>> Thanks for the heads-up. ?Can you send a diff against the BKNR >>> repository? ?I'll review and apply it. >>> >>> Thanks, >>> Edi. >>> >>> >>> >>> On Tue, Aug 2, 2011 at 10:41 PM, Juan Jose Garcia-Ripoll >>> wrote: >>> > I reported a related problem some time ago >>> > >>> > >>> > ?http://lists.common-lisp.net/pipermail/cl-ppcre-devel/2011-January/000706.html >>> > However, instead of the values I supplied now cl-unicode is using >>> > :unspecific for the :type of a pathname. >>> > (defun dump-derived-tests () >>> > ? "Parses the Unicode data file \"DerivedCoreProperties.txt\" \(which >>> > is not used in read.lisp) and uses it to create a file >>> > \"derived-properties\" which will be used by CL-UNICODE-TEST." >>> > ? (with-output-to-source-file (out (make-pathname :name >>> > "derived-properties" >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? :type :unspecific >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? :directory >>> > '(:relative :up >>> > "test")) >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?:no-header-p t) >>> > This is not supported by ECL, which uses NIL to represent an unfilled >>> > value >>> > (absent therefore). From the Hyperspec >>> > http://www.lispworks.com/documentation/HyperSpec/Body/19_bbbc.htm >>> > >>> > A?conforming program?must never unconditionally use a?:unspecific?as >>> > the >>> > value of a?pathname?component because such a value is not guaranteed to >>> > be >>> > permissible in all implementations. >>> > >>> > Probably what you want to solve is the merge-pathnames above the code >>> > (in >>> > the macro), which might instead read >>> > ? `(let* ((directory?(make-pathname :name nil :type nil :version nil >>> > :defaults *this-file*)) >>> > ? ? ? ? ? (pathname (merge-pathnames ,relative-path directory)) >>> > Cheers, >>> > Juanjo >>> > -- >>> > Instituto de F?sica Fundamental, CSIC >>> > c/ Serrano, 113b, Madrid 28006 (Spain) >>> > http://juanjose.garciaripoll.googlepages.com >>> > >>> > _______________________________________________ >>> > cl-ppcre-devel site list >>> > cl-ppcre-devel at common-lisp.net >>> > http://common-lisp.net/mailman/listinfo/cl-ppcre-devel >>> > >>> >>> _______________________________________________ >>> cl-ppcre-devel site list >>> cl-ppcre-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/cl-ppcre-devel >> >> >> >> -- >> Instituto de F?sica Fundamental, CSIC >> c/ Serrano, 113b, Madrid 28006 (Spain) >> http://juanjose.garciaripoll.googlepages.com > > > > -- > Instituto de F?sica Fundamental, CSIC > c/ Serrano, 113b, Madrid 28006 (Spain) > http://juanjose.garciaripoll.googlepages.com > From juanjose.garciaripoll at googlemail.com Wed Aug 31 12:14:58 2011 From: juanjose.garciaripoll at googlemail.com (Juan Jose Garcia-Ripoll) Date: Wed, 31 Aug 2011 14:14:58 +0200 Subject: [cl-ppcre-devel] Problem with pathnames In-Reply-To: References: Message-ID: Hmm, then why didn't this propagate to quicklisp's release? I bet they try to keep on the edge of various libraries and eight months is a long time. Juanjo On Wed, Aug 31, 2011 at 2:08 PM, Edi Weitz wrote: > I was going to apply your patch this morning, but I just realized this > had already been done eight months ago... :) > > http://bknr.net/trac/changeset/4626/trunk/thirdparty/cl-unicode > > Cheers, > Edi. > > > On Tue, Aug 9, 2011 at 11:13 AM, Juan Jose Garcia-Ripoll > wrote: > > Sorry, wrong order of arguments to diff. Here goes the right one > > > > On Tue, Aug 9, 2011 at 11:12 AM, Juan Jose Garcia-Ripoll > > wrote: > >> > >> I am sorry, I live behind a firewall and unblocking SVN is quite a > hassle. > >> Is it ok with the patch attached? It is against cl-unicode-0.1.1 > >> > >> juanjo > >> > >> On Sun, Aug 7, 2011 at 1:44 PM, Edi Weitz wrote: > >>> > >>> Hi Juanjo, > >>> > >>> Thanks for the heads-up. Can you send a diff against the BKNR > >>> repository? I'll review and apply it. > >>> > >>> Thanks, > >>> Edi. > >>> > >>> > >>> > >>> On Tue, Aug 2, 2011 at 10:41 PM, Juan Jose Garcia-Ripoll > >>> wrote: > >>> > I reported a related problem some time ago > >>> > > >>> > > >>> > > http://lists.common-lisp.net/pipermail/cl-ppcre-devel/2011-January/000706.html > >>> > However, instead of the values I supplied now cl-unicode is using > >>> > :unspecific for the :type of a pathname. > >>> > (defun dump-derived-tests () > >>> > "Parses the Unicode data file \"DerivedCoreProperties.txt\" \(which > >>> > is not used in read.lisp) and uses it to create a file > >>> > \"derived-properties\" which will be used by CL-UNICODE-TEST." > >>> > (with-output-to-source-file (out (make-pathname :name > >>> > "derived-properties" > >>> > :type :unspecific > >>> > :directory > >>> > '(:relative :up > >>> > "test")) > >>> > :no-header-p t) > >>> > This is not supported by ECL, which uses NIL to represent an unfilled > >>> > value > >>> > (absent therefore). From the Hyperspec > >>> > http://www.lispworks.com/documentation/HyperSpec/Body/19_bbbc.htm > >>> > > >>> > A conforming program must never unconditionally use a :unspecific as > >>> > the > >>> > value of a pathname component because such a value is not guaranteed > to > >>> > be > >>> > permissible in all implementations. > >>> > > >>> > Probably what you want to solve is the merge-pathnames above the code > >>> > (in > >>> > the macro), which might instead read > >>> > `(let* ((directory (make-pathname :name nil :type nil :version nil > >>> > :defaults *this-file*)) > >>> > (pathname (merge-pathnames ,relative-path directory)) > >>> > Cheers, > >>> > Juanjo > >>> > -- > >>> > Instituto de F?sica Fundamental, CSIC > >>> > c/ Serrano, 113b, Madrid 28006 (Spain) > >>> > http://juanjose.garciaripoll.googlepages.com > >>> > > >>> > _______________________________________________ > >>> > cl-ppcre-devel site list > >>> > cl-ppcre-devel at common-lisp.net > >>> > http://common-lisp.net/mailman/listinfo/cl-ppcre-devel > >>> > > >>> > >>> _______________________________________________ > >>> cl-ppcre-devel site list > >>> cl-ppcre-devel at common-lisp.net > >>> http://common-lisp.net/mailman/listinfo/cl-ppcre-devel > >> > >> > >> > >> -- > >> Instituto de F?sica Fundamental, CSIC > >> c/ Serrano, 113b, Madrid 28006 (Spain) > >> http://juanjose.garciaripoll.googlepages.com > > > > > > > > -- > > Instituto de F?sica Fundamental, CSIC > > c/ Serrano, 113b, Madrid 28006 (Spain) > > http://juanjose.garciaripoll.googlepages.com > > > -- Instituto de F?sica Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Wed Aug 31 15:11:30 2011 From: edi at agharta.de (Edi Weitz) Date: Wed, 31 Aug 2011 17:11:30 +0200 Subject: [cl-ppcre-devel] My open source libraries (aka "ediware") Message-ID: [My apologies if you receive multiple copies of this email.] Hi everybody! As some of you will know, I'll start on a new job tomorrow. This new job won't involve much hacking, if at all, and thus it doesn't look like I'll have a lot of time to maintain my open source libraries in the near future. I have no plans to suddenly disappear from the CL world, but don't expect new releases of any of my libs any time soon. (At least none published by me or on my server.) Luckily, Hans H?bner - who already did most of the maintenance and development work for Hunchentoot in the last two years or so - offered to coordinate further development via github. See his full announcement at . I'll continue to read the mailing lists for my libs and I'm still interested in fixing bugs you might find in the release tarballs available on my web server. However, I will likely not bother to discuss or work on new features or compatibility code for implementations other than LispWorks (which happens to be the one I'm using). Lastly, I hope to see a lot of you in Amsterdam in October. The number of registrations so far has been pretty disappointing, but you still have three weeks left to change your mind... :) Take care, Edi.