[cl-pdf-devel] compile and load-time dependency on *cl-pdf-base-directory* considered harmful (was: Re: cl-pdf is moving to github)

[Marc Battyani]

ThanksDavid,

I will merge that patch and the cl-typesetting one tomorrow and I will
also push cl-typesetting to github at the same time.

Marc


On 28/3/13 15:15 , Dave Cooper wrote:
>
>
> To follow up, here is a subsequent patch for cl-pdf which smooths
> things out a bit more (I'm attaching both the 0001 patch and the 0002
> patch).
>
> Soon I will send a patch to the cl-typesetting list also, which
> implements a similar fix for cl-typesetting. 
>
>
>
> On Wed, Mar 27, 2013 at 12:45 AM, Dave Cooper
> <david.cooper at genworks.com <mailto:david.cooper at genworks.com>> wrote:
>
>
>     Hi Marc,
>
>     Thank you for the feedback. 
>
>     Ok, here is my proposed patch for this issue. It defers the
>     loading of fonts in chart.lisp until runtime, and adds a file
>     zzinit.lisp which contains an initialize! function as well as a
>     confirmation (with warning) if any of the *afm-files-directories*
>     do not exist. This confirmation is invoked at the toplevel so you
>     will see a warning during compile and/or load if the afm
>     directories are not existing, with suggestion to run the
>     initialize! function at runtime before trying to use cl-pdf
>     functions. 
>
>     This patch was made with 
>
>      git format-patch
>
>     so you should be able to apply it to a local clone of the master
>     branch with 
>
>      git apply
>     0001-Make-it-so-cl-pdf-can-load-without-afm-directory-the.patch
>
>
>
>
>     On Tue, Mar 26, 2013 at 11:04 PM, Marc Battyani
>     <marc.battyani at fractalconcept.com
>     <mailto:marc.battyani at fractalconcept.com>> wrote:
>
>         Hi Dave,
>
>
>         On 26/3/13 21:49 , Dave Cooper wrote:
>>         Hi All,
>>
>>          I'm not sure if I should put this on this mailing list or as
>>         an Issue on the new Github site (where I could claim "First!" : )
>         Well I have no idea either and I have to look at how this
>         works on github. Anyway this mailing list on common-lisp.net
>         <http://common-lisp.net> works well and is really low volume
>         so probably it's not useful to change for now. That said I
>         would be interested to here if people have more informed
>         opinions on that.
>
>>         How many of you have seen this error at some point during
>>         your time using cl-pdf:
>>
>>          "Error: Font Helvetica not Found" 
>>
>>         As you probably know, one of the things which can cause this
>>         is when cl-pdf is being loaded from a compiled fasl which is
>>         not in the location of the source codebase, and the source
>>         codebase is no longer available at the location where it was
>>         during compiling.
>>
>>         So my basic question is: does anyone have suggestions what to
>>         do about *cl-pdf-base-directory* and
>>         *cl-typesetting-base-directory* so that a fasl or built
>>         runtime can be used without the depending on the original
>>         absolute pathname to afm/ directory, etc. still existing as
>>         they were during compilation? As it is currently, the full
>>         hardcoded pathname of the *cl-pdf-base-directory* and
>>         *cl-typesetting-base-directory* are baked into a compiled
>>         fasl. I understand this used to work from *load-truename*
>>         instead of *compile-file-truename*, and the hardcoding of
>>         compile-time source location was introduced as a "fix" for
>>         the fact that ASDF started using output-translations which
>>         resulted in the fasl being loaded not being in the source
>>         location. But this "fix" still assumes that the sources are
>>         always going to be available in their original location every
>>         time a fasl is loaded, which I consider to be a fragile
>>         assumption. 
>>
>>         For me, the ideal solution would be: 
>>
>>          1. First of all, don't have any compile-time or load-time
>>         dependencies on these variables at all. As it is now, only
>>         chart.lisp in cl-pdf appears to depend on
>>         *afm-files-directories* -- couldn't this stuff be deferred to
>>         runtime? For cl-typesetting I'm not sure what are the
>>         dependencies at compile and load time, but I speculate that
>>         they are few. 
>>
>>          2. Provide an "initialize!" function for use at runtime
>>         startup, which is supposed to establish base directory
>>         locations for afm/ directory etc.
>>         Then it would be (as it rightfully should be) the
>>         responsibility of any runtime application which is using
>>         cl-pdf to set the *-base-directory* variables and call the
>>         initialize! function as part of its "restart" function, much
>>         the same way as many applications normally have to initialize
>>         themselves at startup to find the location of outside
>>         resources (e.g. webserver applications have to be set with
>>         the location of static files for publishing, etc). 
>>
>>         Before I go any deeper into this direction I just wanted to
>>         get any feedback that current users have about this issue.
>>         And let me know if it should be opened as an Issue on the
>>         github project or stay on this mailing list.
>         Seems good for me. Anyway as you mentioned, probably everybody
>         had to integrate that into some initialization function.
>
>>         Best Regards
>>
>>          Dave
>>
>>         P.S. Are there plans to bring cl-typesetting to github as
>>         well, side-by-side with cl-pdf?
>         Sure! I wanted to clean them up somewhat like I have done with
>         cl-pdf but maybe I should move all this to github and clean it
>         later.
>         I'm also planning to modernize my web framework and put it on
>         github too but this will take some time.
>
>         Cheers,
>
>         Marc
>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cl-pdf-devel/attachments/20130328/eb6a4bad/attachment.html>