[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]

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
>
>
> On Thu, Feb 28, 2013 at 12:28 PM, Marc Battyani <
> marc.battyani at fractalconcept.com> wrote:
>
>>  Hi all,
>>
>> cl-pdf is moving to https://github.com/mbattyani/cl-pdf.git
>>
>> Please contact me if want to have push access.
>>
>> Marc
>>
>>
>> _______________________________________________
>> cl-pdf-devel site list
>> cl-pdf-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/cl-pdf-devel
>>
>
>
>
>  --
> My Best,
>
> Dave Cooper, Genworks Support
> david.cooper at genworks.com, dave.genworks.com(skype)
> USA: 248-327-3253(o), 1-248-330-2979(mobile)
> UK: 0191 645 1699
>
>
>


-- 
My Best,

Dave Cooper, Genworks Support
david.cooper at genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cl-pdf-devel/attachments/20130327/b8268cf5/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: 5098 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-pdf-devel/attachments/20130327/b8268cf5/attachment.obj>