On Wed, Aug 31, 2011 at 2:08 PM, Edi Weitz <edi@weitz.de> 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

<juanjose.garciaripoll@googlemail.com> 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
> <juanjose.garciaripoll@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@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@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@common-lisp.net
>>> > http://common-lisp.net/mailman/listinfo/cl-ppcre-devel
>>> >
>>>
>>> _______________________________________________
>>> cl-ppcre-devel site list
>>> cl-ppcre-devel@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
>