[cl-gd-devel] Tiny patch for create-image-from-file

Hans Hübner hans.huebner at gmail.com
Sat Dec 29 11:00:35 UTC 2012


Oleg,

the cmucl specific code has made it into cl-gd when I was using that
compiler years ago. It would be nice to support cmucl, preferably through
one new function that is called for all pathname translations and that has
the platform specific functionality.

Thanks!
Hans
Am 29.12.2012 11:27 schrieb "Left Right" <olegsivokon at gmail.com>:

> Hi Hans,
>
> I'm now going through the source to find all places where the pathname
> string is used with further I/O, and I found that in
> draw-freetype-string the routine for loading font files (or rather
> extracting strings from pathnames) differs from other places. I.e.
> this is the code in draw-freetype-string
>
> (when (pathnamep font-name)
>       (setq font-name (namestring font-name)))
>
> And this is the code in create-image-from-file
>
> (when (pathnamep file-name)
>       (setq file-name
>               #+:cmu (ext:unix-namestring file-name)
>               #-:cmu (namestring file-name)))
>
> I.e. draw-freetype-string seems like it doesn't care about CMUCL - was
> this intended? Or, maybe, the exception made for CMUCL was an extra
> precaution in the create-image-from-file?
>
> Best.
>
> Oleg
>
> On Fri, Dec 28, 2012 at 11:00 PM, Hans Hübner <hans.huebner at gmail.com>
> wrote:
> > Oleg,
> >
> > please send a pull request on github.  I like the idea to make cl-gd
> > CL pathname aware.
> >
> > Thanks,
> > Hans
> >
> > On Fri, Dec 28, 2012 at 2:59 PM, Left Right <olegsivokon at gmail.com>
> wrote:
> >> Hello list!
> >>
> >> I've realized that create-image-from-file will not try to expand
> >> logical pathnames. So, I wanted to suggest to change the line:
> >>
> >> (namestring file-name)
> >>
> >> to
> >>
> >> (namestring (translate-logical-pathname file-name))
> >>
> >> but I also saw that for CMU there is some other function used to read
> >> the name, and so long I don't have it installed and never used it - I
> >> don't know whether the same will fit there too.
> >>
> >> This is line 115 in my version of sources (not modified).
> >> This shouldn't break older programs because if there are no
> >> translation rules, then the original pathname is returned from
> >> translate-logical-pathname, but theoretically, it could produce
> >> situations when previously some bizarre file name was taken literally
> >> instead of being interpreted.
> >>
> >> Well, that's it.
> >>
> >> Oh, and this would probably then apply to other functions that call on
> >> C functions to do I/O... If this makes sense, I could search for all
> >> such functions and export a clean patch for them. Should I?
> >>
> >> Best.
> >>
> >> Oleg
> >>
> >> _______________________________________________
> >> cl-gd-devel site list
> >> cl-gd-devel at common-lisp.net
> >> http://common-lisp.net/mailman/listinfo/cl-gd-devel
> >
> > _______________________________________________
> > cl-gd-devel site list
> > cl-gd-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/cl-gd-devel
>
> _______________________________________________
> cl-gd-devel site list
> cl-gd-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cl-gd-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cl-gd-devel/attachments/20121229/91f64b07/attachment.html>


More information about the Cl-gd-devel mailing list