[cl-ppcre-devel] Problem with pathnames

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Tue Aug 9 09:13:42 UTC 2011


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 <edi at agharta.de> 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
>> <juanjose.garciaripoll at googlemail.com> 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: <https://mailman.common-lisp.net/pipermail/cl-ppcre-devel/attachments/20110809/40596033/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cl-unicode.patch
Type: application/octet-stream
Size: 1329 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-ppcre-devel/attachments/20110809/40596033/attachment.obj>


More information about the Cl-ppcre-devel mailing list