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

[Dave Cooper]

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>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> 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 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/949eb675/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-it-so-cl-pdf-can-load-without-afm-directory-the.patch
Type: application/octet-stream
Size: 5079 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-pdf-devel/attachments/20130328/949eb675/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-make-it-so-you-can-load-without-afm-directory.patch
Type: application/octet-stream
Size: 1783 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-pdf-devel/attachments/20130328/949eb675/attachment-0001.obj>